Le domaine dans lequel je travaille n’est pas extrême à ce point non plus, mais je fais de la recherche et du développement en IA.
En plus des frameworks couramment utilisés, il arrive aussi que l’environnement cible où le modèle est réellement déployé soit différent de celui dans lequel il a été entraîné.
Il arrive aussi que certaines opérations spécifiques ne soient pas prises en charge, et qu’il faille donc créer des opérations personnalisées selon la plateforme. Dans ce cas, il est souvent impossible de tester directement dans l’environnement de développement.
Il m’arrive aussi de modéliser directement des modèles ; on peut écrire des tests avec certaines données, mais selon le dataset, les valeurs varient de manière probabiliste, et des phénomènes comme une explosion des valeurs à un moment donné sont difficiles à couvrir avec du code de test.
J’imagine qu’il existe sans doute pas mal d’environnements où les tests sont encore plus difficiles que dans mon cas.
L’approche de SQLite est vraiment impressionnante. Garder privée une suite de tests 590 fois plus volumineuse que le code, cela signifie au fond que « la vraie valeur d’un logiciel réside dans sa spécification de fonctionnement ».
En pratique, quand on crée aujourd’hui des projets avec des outils de codage IA, s’il existe le README du projet, la documentation API et les tests, on peut reproduire les fonctionnalités essentielles à une vitesse étonnante. C’est ce que j’ai ressenti en gérant moi-même 7 projets : paradoxalement, plus un projet est bien testé, plus il est facile à répliquer.
Cela dit, il y a un point négligé dans le cas Cloudflare vs Vercel : « répliquer » et « exploiter » sont deux problèmes totalement différents. Pour reproduire les cas limites de Next.js, l’écosystème de plugins et jusqu’à la dépendance à la communauté, les tests seuls ne suffisent pas. Au final, j’ai l’impression que le moat réside plutôt dans la combinaison du code de test, de la communauté et du savoir-faire opérationnel.
Je doute que le GC pose un problème à ce point pour ce projet. Parmi « la plupart des projets récents », j’ai l’impression que, dans bien des cas, le choix d’un langage de programmation relève davantage de la préférence que des avantages ou limites propres à un langage donné. Malgré cela, si l’on me demande quel avantage comparatif Rust a sur Go en tant que langage de programmation généraliste, je répondrais sans doute que c’est le niveau d’abstraction qu’offre Rust, ainsi que sa capacité à détecter diverses erreurs à la compilation. Bien sûr, Go a aussi des atouts face à Rust, comme une programmation asynchrone plus simple, un temps de compilation plus rapide et une syntaxe plus concise.
Même avec un contrat du même niveau, la confiance qu’il inspire et l’image qu’il renvoie me semblent vraiment très différentes.
Je vais peut-être résilier mon abonnement à GPT.
Avec Rust, une grande part des erreurs est détectée à la compilation, donc un échec de compilation donne presque l’impression d’aider l’IA à se remettre sur la bonne voie.
Eh bien, ce n’est qu’une supposition, mais je me dis que c’est peut-être parce que la barrière à l’entrée de Rust a disparu.
La plus grande difficulté, c’est qu’on code puis que la compilation continue d’échouer, mais l’IA s’en charge à notre place.
Le DIY, le mouvement maker, l’indé, le punk et l’open source sont tous des contre-arguments à l’industrialisation, au capitalisme et au consumérisme, mais voilà que pour dépasser leurs limites, il faudrait accepter le consumérisme.
Je suis d’accord avec l’idée que le vibe coding correspond bien à une logique de consommation. J’ai l’impression que c’est la version codage de la mode récente du « Temu-kkang » et de l’« Ali-kkang » (https://www.asiae.co.kr/article/2024053117460950053).
En revanche, s’il s’agit de dire que cette logique de consommation est un moyen d’éviter de répéter l’échec du mouvement maker, alors, comme dans les commentaires sur HN, je ne peux pas être d’accord à bien des égards.
Le vibe coding s’inscrit dans la continuité historique du citizen development.
Je pense que le vibe coding évolue désormais vers quelque chose qui rend le codage aussi simple, rapide et indispensable que l’électricité.
Déjà, même de nombreux programmeurs de génie dans les entreprises poursuivent le développement sans écrire une seule ligne de code, uniquement avec des prompts et des agents.
Certains cherchent à en minimiser la portée, mais il me semble difficile de contester que le vibe coding d’Andrej Karpathy marque un tournant dans l’histoire de l’informatique.
C’est une bonne question. En réalité, la condition « hybride » de notre expérience allait précisément dans ce sens — une configuration où un résumé structuré était fourni avec des journaux d’expérience bruts.
Au final, c’est l’hybride qui a obtenu le meilleur score, avec 4,95/5,0. Quand on ne donnait que le résumé, on était à 2,65, mais en y ajoutant des traces du processus comme « échec », « cause inconnue », les faiblesses du résumé étaient au contraire compensées.
La conclusion est donc que « le résumé en soi n’est pas mauvais ; il faut simplement y inclure aussi le processus et les incertitudes ».
Mais comme N=1, des recherches complémentaires sont nécessaires pour savoir si cela peut être utilisé de façon générale auprès de profils d’utilisateurs variés.
Dans ce cas, est-ce que cela changerait quelque chose si l’on structurait la mémoire synthétique pour qu’elle contienne le processus de ces tâches, ainsi que le contenu des échecs et des réussites ?
Exactement. Moi aussi, au début, je pensais que la mémoire synthétique serait au moins meilleure que la baseline, donc j’ai été surpris en voyant les résultats.
En l’analysant, j’ai compris que le point clé était la « préservation de l’incertitude ». Dans les logs bruts, il reste des traces comme « j’ai essayé ça, mais ça n’a pas marché » ou « je ne connais pas la cause », si bien que l’agent répond qu’il ne sait pas quand il ne sait pas. Dans le résumé, en revanche, tout ce contexte disparaît, et il finit au contraire par donner avec assurance des réponses erronées.
Je vous lis toujours avec beaucoup d’intérêt, merci.
Il semble que cela arrive dans les cas où x devient un peu délicat à crawler. Nous allons essayer d’améliorer cela.
C’est la première fois que je vois une erreur de résumé indiquant qu’il n’y a pas de contenu..
Le domaine dans lequel je travaille n’est pas extrême à ce point non plus, mais je fais de la recherche et du développement en IA.
En plus des frameworks couramment utilisés, il arrive aussi que l’environnement cible où le modèle est réellement déployé soit différent de celui dans lequel il a été entraîné.
Il arrive aussi que certaines opérations spécifiques ne soient pas prises en charge, et qu’il faille donc créer des opérations personnalisées selon la plateforme. Dans ce cas, il est souvent impossible de tester directement dans l’environnement de développement.
Il m’arrive aussi de modéliser directement des modèles ; on peut écrire des tests avec certaines données, mais selon le dataset, les valeurs varient de manière probabiliste, et des phénomènes comme une explosion des valeurs à un moment donné sont difficiles à couvrir avec du code de test.
J’imagine qu’il existe sans doute pas mal d’environnements où les tests sont encore plus difficiles que dans mon cas.
L’approche de SQLite est vraiment impressionnante. Garder privée une suite de tests 590 fois plus volumineuse que le code, cela signifie au fond que « la vraie valeur d’un logiciel réside dans sa spécification de fonctionnement ».
En pratique, quand on crée aujourd’hui des projets avec des outils de codage IA, s’il existe le README du projet, la documentation API et les tests, on peut reproduire les fonctionnalités essentielles à une vitesse étonnante. C’est ce que j’ai ressenti en gérant moi-même 7 projets : paradoxalement, plus un projet est bien testé, plus il est facile à répliquer.
Cela dit, il y a un point négligé dans le cas Cloudflare vs Vercel : « répliquer » et « exploiter » sont deux problèmes totalement différents. Pour reproduire les cas limites de Next.js, l’écosystème de plugins et jusqu’à la dépendance à la communauté, les tests seuls ne suffisent pas. Au final, j’ai l’impression que le moat réside plutôt dans la combinaison du code de test, de la communauté et du savoir-faire opérationnel.
Waouh
Je doute que le GC pose un problème à ce point pour ce projet. Parmi « la plupart des projets récents », j’ai l’impression que, dans bien des cas, le choix d’un langage de programmation relève davantage de la préférence que des avantages ou limites propres à un langage donné. Malgré cela, si l’on me demande quel avantage comparatif Rust a sur Go en tant que langage de programmation généraliste, je répondrais sans doute que c’est le niveau d’abstraction qu’offre Rust, ainsi que sa capacité à détecter diverses erreurs à la compilation. Bien sûr, Go a aussi des atouts face à Rust, comme une programmation asynchrone plus simple, un temps de compilation plus rapide et une syntaxe plus concise.
Même avec un contrat du même niveau, la confiance qu’il inspire et l’image qu’il renvoie me semblent vraiment très différentes.
Je vais peut-être résilier mon abonnement à GPT.
Ça me déplaît, désolé.
Waouh, c’est génial. J’imagine que c’est grâce à RustPython que vous avez pu en bénéficier. J’espère que cela donnera de bons résultats !
Avec Rust, une grande part des erreurs est détectée à la compilation, donc un échec de compilation donne presque l’impression d’aider l’IA à se remettre sur la bonne voie.
J’ai essayé d’en faire la demande.
Eh bien, ce n’est qu’une supposition, mais je me dis que c’est peut-être parce que la barrière à l’entrée de Rust a disparu.
La plus grande difficulté, c’est qu’on code puis que la compilation continue d’échouer, mais l’IA s’en charge à notre place.
On dirait que c’était un test Joke.
Le DIY, le mouvement maker, l’indé, le punk et l’open source sont tous des contre-arguments à l’industrialisation, au capitalisme et au consumérisme, mais voilà que pour dépasser leurs limites, il faudrait accepter le consumérisme.
Je suis d’accord avec l’idée que le vibe coding correspond bien à une logique de consommation. J’ai l’impression que c’est la version codage de la mode récente du « Temu-kkang » et de l’« Ali-kkang » (https://www.asiae.co.kr/article/2024053117460950053).
En revanche, s’il s’agit de dire que cette logique de consommation est un moyen d’éviter de répéter l’échec du mouvement maker, alors, comme dans les commentaires sur HN, je ne peux pas être d’accord à bien des égards.
Le vibe coding s’inscrit dans la continuité historique du citizen development.
Je pense que le vibe coding évolue désormais vers quelque chose qui rend le codage aussi simple, rapide et indispensable que l’électricité.
Déjà, même de nombreux programmeurs de génie dans les entreprises poursuivent le développement sans écrire une seule ligne de code, uniquement avec des prompts et des agents.
Certains cherchent à en minimiser la portée, mais il me semble difficile de contester que le vibe coding d’Andrej Karpathy marque un tournant dans l’histoire de l’informatique.
C’est une bonne question. En réalité, la condition « hybride » de notre expérience allait précisément dans ce sens — une configuration où un résumé structuré était fourni avec des journaux d’expérience bruts.
Au final, c’est l’hybride qui a obtenu le meilleur score, avec 4,95/5,0. Quand on ne donnait que le résumé, on était à 2,65, mais en y ajoutant des traces du processus comme « échec », « cause inconnue », les faiblesses du résumé étaient au contraire compensées.
La conclusion est donc que « le résumé en soi n’est pas mauvais ; il faut simplement y inclure aussi le processus et les incertitudes ».
Mais comme N=1, des recherches complémentaires sont nécessaires pour savoir si cela peut être utilisé de façon générale auprès de profils d’utilisateurs variés.
Dans ce cas, est-ce que cela changerait quelque chose si l’on structurait la mémoire synthétique pour qu’elle contienne le processus de ces tâches, ainsi que le contenu des échecs et des réussites ?
Exactement. Moi aussi, au début, je pensais que la mémoire synthétique serait au moins meilleure que la baseline, donc j’ai été surpris en voyant les résultats.
En l’analysant, j’ai compris que le point clé était la « préservation de l’incertitude ». Dans les logs bruts, il reste des traces comme « j’ai essayé ça, mais ça n’a pas marché » ou « je ne connais pas la cause », si bien que l’agent répond qu’il ne sait pas quand il ne sait pas. Dans le résumé, en revanche, tout ce contexte disparaît, et il finit au contraire par donner avec assurance des réponses erronées.