C’est un peu comme dire : « Le FSD est devenu plus intelligent, donc le conducteur peut dormir. »
Techniquement, on a l’impression qu’on se dirige progressivement vers une époque comme celle-là, mais la vraie question sera de savoir comment franchir l’obstacle de la responsabilité.
J’ai l’impression que la revue de code est au moins un minimum de garde-fou.
Moi aussi, j’utilise Opus pour la planification et Codex high pour la revue, tandis que pour le codage proprement dit, je passe sur sonet ou codex medium.
C’est aussi un sujet sur lequel je réfléchissais souvent en entreprise, c’est intéressant. J’aimerais aussi essayer de l’introduire dans Harnes, que je développe personnellement.
Jusqu’à présent, le LLM/Agentic Coding reste un excellent outil, pas encore un excellent ingénieur. Tout comme un bon plan est important dans l’Agentic Coding, l’utilisateur doit au final être capable de comprendre le code et de porter un jugement dessus. Par exemple, fastrender et CCC ont montré le potentiel de l’Agentic Coding, tout en en révélant clairement les limites.
Il ne s’agit pas simplement de supprimer la code review, mais plutôt de proposer de faire la review à partir de livrables d’un niveau plus élevé, qui permettent de vérifier explicitement l’intention et si cette intention fonctionne correctement.
À l’heure actuelle, je pense qu’il est souhaitable de conserver comme boîte noire les détails d’implémentation du code, tant qu’on n’est pas au niveau de la conception ou de l’architecture.
Les écosystèmes Rust et Zig s’élargissent de plus en plus.
Je me demande encore combien de temps JavaScript restera pertinent pour l’IA.
Il paraît donc que les autres formes de programmation ont une sorte de valeur sacrée.
C’est un peu comme dire : « Le FSD est devenu plus intelligent, donc le conducteur peut dormir. »
Techniquement, on a l’impression qu’on se dirige progressivement vers une époque comme celle-là, mais la vraie question sera de savoir comment franchir l’obstacle de la responsabilité.
J’ai l’impression que la revue de code est au moins un minimum de garde-fou.
Moi aussi, je fais la planification avec Sonnet et l’implémentation du code avec Opus, mais la méthode de l’auteur est peut-être plus efficace.
Moi aussi, j’utilise Opus pour la planification et Codex high pour la revue, tandis que pour le codage proprement dit, je passe sur sonet ou codex medium.
Pourquoi la validation de l’intention, qui est un concept d’un niveau plus élevé, est-elle faite par un humain..?
Waouh, merci !!
Je me demande par quel canal cela a fuité, ou été rendu public.
> Les modèles coûteux (Opus) sont utilisés pour la planification, les modèles moins chers (Sonnet) pour écrire le code, afin d’économiser des tokens
Souvent, on fait aussi l’inverse : Sonnet pour le plan, Opus pour l’implémentation du code. Ici, c’est l’inverse.
La configuration est un peu ambiguë..
C’est aussi un sujet sur lequel je réfléchissais souvent en entreprise, c’est intéressant. J’aimerais aussi essayer de l’introduire dans Harnes, que je développe personnellement.
Oh... ça, c'est pas mal... ?
Je trouvais ça peu pratique moi aussi, et en cherchant, j’ai découvert OpenUsage, que j’utilise désormais, et j’en suis plutôt satisfait.
En voyant ce commentaire, j’ai décidé de ne pas l’utiliser… je pense que la statusline suffit largement.
Je pense qu’on va progressivement évoluer vers des revues de plus en plus légères et des tests beaucoup plus stricts.
Jusqu’à présent, le LLM/Agentic Coding reste un excellent outil, pas encore un excellent ingénieur. Tout comme un bon plan est important dans l’Agentic Coding, l’utilisateur doit au final être capable de comprendre le code et de porter un jugement dessus. Par exemple,
fastrenderetCCCont montré le potentiel de l’Agentic Coding, tout en en révélant clairement les limites.De mon côté, la connexion saute souvent, donc j’ai tendance à ne pas trop l’utiliser. Est-ce que c’est pareil pour les autres ?!
Le nom de la bibliothèque aussi est resté
pymath, sans doute par fidélité à l’original.Il ne s’agit pas simplement de supprimer la code review, mais plutôt de proposer de faire la review à partir de livrables d’un niveau plus élevé, qui permettent de vérifier explicitement l’intention et si cette intention fonctionne correctement.
À l’heure actuelle, je pense qu’il est souhaitable de conserver comme boîte noire les détails d’implémentation du code, tant qu’on n’est pas au niveau de la conception ou de l’architecture.
Ah, désolé.