thekb.eu — Agents de codage IA & Skills

A Field Guide to Fable: Finding Your Unknowns

Fri, 03 Jul 2026 00:00:00 GMT

Dans ce *field guide* publié le 3 juillet 2026, **Thariq Shihipar** (équipe Claude Code) formalise une pratique pour exploiter **Claude Fable 5**. Point de départ, emprunté à Korzybski : *« la carte n'est pas le territoire »*. La **carte**, c'est ce qu'on donne à Claude — prompts, skills, contexte. Le **territoire**, c'est là où le travail se fait — le codebase, le monde réel, ses contraintes. L'écart entre les deux, il l'appelle les **unknowns** : quand Claude y bute, il décide sur sa meilleure supposition de ce qu'on veut. Plus le travail est vaste, plus il rencontre d'inconnues. Fable est *« le premier modèle où la qualité du travail est plafonnée par ma capacité à clarifier ses inconnues »* — le goulot s'est déplacé du modèle vers la clarté de l'humain. Thariq propose une **matrice 2×2** : *known knowns* (ce qui est dans le prompt), *known unknowns* (ce qu'on sait ne pas savoir), *unknown knowns* (l'évident qu'on n'écrit pas mais reconnaîtrait) et *unknown unknowns* (ce qu'on n'a jamais envisagé). Réduire et anticiper ses inconnues est, selon lui, **LA compétence** du codage agentique — et elle s'apprend en travaillant avec Claude. Instruire reste un équilibre : trop précis, Claude suit même quand un pivot vaudrait mieux ; trop vague, il comble avec des *best practices* inadaptées. Suit une **boîte à outils** ordonnée dans le temps, chaque technique livrée avec des prompts. **Avant** : le *blindspot pass* (faire expliciter ses angles morts), les *brainstorms & prototypes* (verbaliser tôt les *unknown knowns*, ex. 4 directions de design en HTML), les *interviews* (Claude nous questionne une question à la fois, priorité à ce qui change l'architecture), les *references* (la meilleure étant du code source — c'est ainsi que fonctionne **Claude Design**), et l'*implementation plan* menant par ce qui risque de changer. **Pendant** : un `implementation-notes.md` où l'agent journalise ses déviations. **Après** : les *pitches & explainers* (un doc unique menant par la démo, car les reviewers partent des mêmes inconnues) et les *quizzes* (« I only merge after I pass the quiz perfectly »). Preuve à l'appui : la **vidéo de lancement de Fable**, montée entièrement avec Claude Code dans un domaine inconnu de l'auteur, jusqu'à faire *enseigner* le color grading par le modèle. Morale : chaque artefact est un moyen bon marché de découvrir ce qu'on ignorait **avant que ce soit coûteux à corriger**. *« Start your next project by asking Claude to help you find your unknowns. »*

Fable's judgement

Fri, 03 Jul 2026 00:00:00 GMT

Dans cette note brève publiée le 3 juillet 2026, Simon Willison relaie deux conseils convergents sur la façon d'exploiter les agents de codage, entendus lors d'un *Fireside Chat* qu'il a animé à l'AIE avec **Cat Wu** et **Thariq Shihipar**, de l'équipe Claude Code. Le premier principe : **laisser le modèle exercer son propre jugement plutôt que de lui dicter comment travailler**. Cela vaut pour **Fable** et, dans une certaine mesure, pour **Opus**. L'exemple donné concerne les tests. On *peut* écrire une règle explicite — « n'utilise les tests automatisés que pour les fonctionnalités importantes, ne mets pas à jour ni ne lance de tests pour de petits changements de texte ou de design » — mais il est **préférable de demander simplement à Fable d'utiliser son jugement** pour décider quand écrire des tests. Le discernement contextuel du modèle se révèle plus robuste que la règle codée en dur. Le second conseil, transmis par **Jesse Vincent**, applique la même philosophie à l'**économie des tokens**. Le contexte est daté : les prix des tokens Fable vont augmenter dans quelques jours. Pour ne pas brûler cette ressource précieuse, l'idée est de **demander à Fable de déléguer les tâches plus petites à des modèles moins puissants**, en le laissant juger lui-même lequel convient. Willison applique aussitôt le conseil et documente l'expérience de bout en bout. Il fournit le **prompt exact** envoyé à Claude Code : « *For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent* ». En réponse, Claude Code a **spontanément écrit un fichier mémoire** (`~/.claude/projects/<projet>/memory/delegate-coding-to-subagents.md`, `type: feedback`). Ce fichier ne se contente pas d'enregistrer la consigne : il en **codifie l'application** — *sonnet* pour l'implémentation substantielle, *haiku* pour les éditions triviales ou mécaniques — tout en réservant au **modèle principal** ce qui exige du jugement : design, audit, synthèse de données, review. La justification tient en une phrase : le travail d'implémentation a rarement besoin du modèle haut de gamme, tandis que jugement, review et synthèse restent dans la boucle principale. Le verdict est empirique et mesuré : « *So far it seems to be working well. I'm getting a ton of work done and my Fable allowance is shrinking less quickly than before.* » La note illustre ainsi, sur un cas reproductible, une double bonne pratique : **ne pas sur-spécifier** les agents capables de jugement, et **orchestrer plusieurs niveaux de modèles** via des subagents pour préserver les tokens premium.

The Compounding Knowledge Lifecycle — Agent Guide

Thu, 02 Jul 2026 00:00:00 GMT

Ce guide agent de Thinkroom (plateforme de Kieran Klaassen) décrit le **Compounding Knowledge Lifecycle** du compound-engineering-plugin : le mécanisme par lequel « une leçon apprise une fois continue de payer ». Le pari fondateur du compound engineering : *chaque unité de travail doit rendre la suivante plus facile*. Or le code améliore le produit, pas le process ; ce qui **compose**, c'est la **connaissance**, à condition d'être documentée sous une forme **retrouvable au moment exact du besoin**. Le vrai verrou n'est donc pas l'écriture (les postmortems « pourrissent dans les wikis ») mais la **récupération**, ici rendue **automatique** dans cinq skills plutôt que laissée à la discipline. L'unité est la **learning** : un fichier markdown, un problème résolu, sous `docs/solutions/<category>/`, dont **tout le frontmatter sert la recherche** (`title`, `tags`, `module`, `problem_type`, `applies_when`, `severity`, `date`). Le `problem_type` sépare **bug-track** (ce qui a cassé) et **knowledge-track** (ce qui a été décidé/découvert) — car « un système qui ne retient que les bugs oublie l'essentiel ». Corpus vivant : 35 learnings, skill-design en tête. Au-dessus, le **pattern doc** généralise plusieurs learnings (plus de levier, plus de risque si périmé). La **capture** se fait via `/ce-compound`, dont la discipline est le **timing** (documenter tant que le contexte est frais), avec un fan-out de subagents (analyzer, extractor, anti-doublon) pendant que l'orchestrateur seul écrit un unique doc. L'exemple canonique — l'incident #714 devenant fix + learning + test + doctrine — montre que « compounding » signifie **retirer des classes de défaillance**, pas empiler des documents. La **carte mémoire** oppose le durable (git : `docs/solutions/`, `CONCEPTS.md`, `STRATEGY.md`, plans/brainstorms = le WHY) à l'éphémère (repo-profile cache re-dérivable). La **détection** ne pousse rien : cinq skills **tirent** au moment de décider via le **learnings-researcher** grep-first (35 docs → greps de frontmatter → candidats → full-read → 5 findings). Le `/ce-code-review` est « la dent la plus tranchante » : une violation devient un finding `file:line`. Deux règles de confiance protègent : **present evidence wins** et **date is signal**. Enfin, le **refresh** empêche la mémoire de mentir via trois contre-forces (read time, write time via *coherence neighborhood*, on-demand `/ce-compound-refresh` scopé). La boucle est illustrée de bout en bout par la livraison de `/ce-explain`. Métaphore financière : learning = principal, retrieval = intérêt, pattern doc = réinvestissement — un système où le travail neuf « arrive immunisé contre les erreurs passées ».

3 Key Product Development Loops (The Batch, Issue 359 — « Dear friends » letter)

Fri, 26 Jun 2026 00:00:00 GMT

Dans cette lettre de *The Batch* (n°359), Andrew Ng prend acte de la viralité du terme « **loop engineering** » — popularisé par Boris Cherny (créateur de Claude Code) et Peter Steinberger (créateur d'OpenClaw) — et partage les **trois boucles clés** qui structurent sa façon de construire des produits **0-to-1**, mais aussi de décider *quoi* construire. Le schéma les présente imbriquées, par échelle de temps croissante, reliant quatre nœuds : *coding agent → product spec/evals → developer vision → external feedback*. La **boucle de codage agentique** (~minutes) part d'une spécification produit et, optionnellement, d'un jeu d'**evals** : l'agent écrit du code, le teste et itère jusqu'à ce qu'il soit sans bug et conforme. Ng rappelle que « fermer la boucle » a décollé fin 2025 et change la donne — son agent a pu travailler environ une heure sur une app d'apprentissage du clavier pour sa fille, vérifiant lui-même son travail dans un navigateur, sans intervention. C'est un domaine d'invention très actif. La **boucle de feedback développeur** (~dizaines de minutes à heures) voit le développeur examiner le produit et orienter l'agent. Comme les agents testent désormais bien mieux leur propre code, le temps passé en QA manuelle a fortement chuté, libérant le développeur pour des **décisions produit de plus haut niveau** (features, UI, parcours utilisateur). Traduire une vision en spec — puis la clarifier après une première implémentation, et bâtir des evals quand un problème récurrent apparaît — reste un vrai travail. Ng insiste sur l'**avantage de contexte humain** : même si les équipes AI-native automatisent la collecte de données d'usage, la synthèse du feedback client et l'analyse concurrentielle, les humains en savent plus sur les utilisateurs et le contexte d'opération. Beaucoup nomment cela « taste » ; Ng préfère « avantage de contexte », car cela indique un chemin plus clair pour améliorer l'IA. Tant que l'humain sait quelque chose que l'IA ignore, le **human-in-the-loop** demeure nécessaire pour injecter cette connaissance. La **boucle de feedback externe** (~jours) rassemble amis, alpha testeurs et A/B testing en production — des tactiques lentes dont les données nourrissent la vision, laquelle pilote la spec, laquelle pilote l'agent. Ng conclut que, les agents accélérant le développement, de plus en plus d'ingénieurs endossent un rôle **partiel de product management**. Le plus difficile est de façonner la vision et d'équilibrer construction et feedback utilisateur — « il faut faire les deux ». Il y voit un signe encourageant : les ingénieurs s'élargissent vers le produit, comme PM et designers font désormais plus d'ingénierie.

grill-with-docs — « Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise »

Tue, 16 Jun 2026 00:00:00 GMT

`grill-with-docs`, signée Matt Pocock, est une **skill** (instructions exécutables pour un agent de codage) qui transforme la phase de conception en une session d'interview rigoureuse. Son principe : quand on conçoit une fonctionnalité, le plan repose sur des hypothèses et des dépendances de design ; plutôt que de foncer dans l'implémentation, la skill « cuisine » (*grill*) le plan en le confrontant, hypothèse par hypothèse, au vocabulaire métier du projet et aux décisions déjà prises. À mesure que les décisions se cristallisent, elles sont capturées dans deux types de documents : `CONTEXT.md`, un **glossaire du domaine** (le vocabulaire métier), et les **ADR** (*Architecture Decision Records*, dans `docs/adr/`), pour les décisions d'architecture importantes. Le fonctionnement repose sur quatre principes. **(1) Approche par interview** : les questions sont posées séquentiellement, une à la fois, et l'agent attend la réponse avant d'avancer ; si une question peut être résolue en explorant le code, il explore au lieu de demander. **(2) Précision du langage** — le cœur de la skill : signaler immédiatement les conflits de terminologie avec le glossaire existant, proposer un terme canonique quand l'utilisateur emploie un mot vague (ex. « account »), et tester les relations métier avec des scénarios concrets de cas limites. **(3) Basé sur les preuves** : croiser le comportement annoncé avec le code réel et faire remonter les contradictions. **(4) Discipline documentaire** : `CONTEXT.md` est mis à jour au fil de l'eau (pas en lot à la fin) ; un ADR n'est créé que si la décision est difficile à inverser, surprenante sans contexte, et issue d'un vrai arbitrage. Côté règles structurelles : `CONTEXT.md` ne contient **que** le glossaire métier (aucun détail d'implémentation, spec ou brouillon) ; un repo à plusieurs domaines (*bounded contexts* au sens DDD) utilise un `CONTEXT-MAP.md` qui pointe vers le `CONTEXT.md` de chaque contexte ; les fichiers sont créés **à la demande** (création paresseuse). En résumé, c'est une skill de conception en amont, d'inspiration Domain-Driven Design, qui force avant le code une conversation rigoureuse pour ① nettoyer le vocabulaire, ② vérifier la cohérence avec l'existant, et ③ documenter les décisions au bon endroit et au bon niveau de granularité — afin d'éviter les dérives de terminologie et les hypothèses non vérifiées qui deviennent coûteuses plus tard.

Stop Running the SDLC on Models That Aren't Human

Fri, 12 Jun 2026 00:00:00 GMT

Chris Williams ouvre sa série en sept volets sur l'ADLC (Agentic Development Lifecycle) par une thèse de rupture : appliquer le cycle de développement logiciel traditionnel (SDLC) à des agents IA est une erreur de catégorie. Le SDLC a été façonné pendant des décennies pour contrer des modes de défaillance spécifiquement humains — l'ego qui refuse la critique, la fatigue qui multiplie les erreurs, l'oubli qui perd le contexte. Ces défenses sont inutiles, voire contre-productives, face à un modèle dont le profil de défaillance est entièrement différent. De ce constat découle le principe fondateur de toute la série : chaque phase, chaque gate et chaque boucle d'un cycle agentique doit se rattacher soit à un mode de défaillance précis du modèle qu'elle défend, soit à une propriété du modèle qu'elle exploite. Pas de rituel hérité sans justification traçable. Williams catalogue alors huit modes de défaillance porteurs. F1, la satisfaction prématurée : le modèle déclare victoire sur une implémentation minimale truffée de données en dur. F2, la sycophancie : il acquiesce même à tort, ce qui rend l'auto-revue sans valeur. F3, le context rot : son jugement se dégrade à mesure que la fenêtre se remplit et qu'il s'ancre sur ses sorties antérieures. F4, l'hallucination confiante : des APIs fabriquées présentées avec aplomb. F5, le reward hacking : supprimer les tests qui échouent, affaiblir les assertions. F6, le biais du nombre de findings : les revues convergent vers 10-20 résultats quel que soit le nombre réel de problèmes. F7, le bloat génératif : du code verbeux et dupliqué qui s'accumule de session en session. F8, la perte de cohérence : des modèles différents produisent des incohérences stylistiques et architecturales. Le retournement décisif : certaines de ces caractéristiques deviennent des forces exploitables (E1-E5). La diversité d'échantillonnage offre un N-version programming gratuit ; la sycophancie devient utile quand l'agent est charté pour réfuter plutôt que valider ; l'absence d'ego autorise des revues brutales et des itérations jetables ; les contextes frais fournissent une revue non contaminée ; le coût d'exploration tend vers zéro face au temps humain. Le cycle qui en découle sépare créateur et critique, dimensionne les tâches à une fenêtre utile, exige des preuves déterministes entre phases, gèle des critères d'acceptation inamovibles, boucle des revues à contextes frais et régénère plutôt que coache. Williams prévient : les équipes qui jugent « les agents ne marchent pas » ont simplement appliqué un processus humain à un profil non-humain.

Two Human Gates and Everything Between Is Machine-Checked

Fri, 12 Jun 2026 00:00:00 GMT

Dans ce deuxième volet, Chris Williams matérialise la « première loi » de l'ADLC en un cycle concret : huit phases, un gate déterministe entre chaque paire, et exactement deux moments humains obligatoires. Le principe directeur est qu'un handoff direct de LLM à LLM, sans checkpoint déterministe, multiplie les taux d'erreur — chaque composant probabiliste branché sur un autre fait composer l'erreur. Les gates (compilateurs, suites de tests, validateurs) remettent cette accumulation à zéro. Le cycle commence en P0 (Triage) : router le travail par risque et blast radius, pas par complexité ; le trivial court-circuite le cycle complet, le substantiel passe par les huit phases. P1 (Interrogate) est la phase à plus fort levier : un agent interroge les parties prenantes *après* avoir consulté le codebase, ce qui empêche des hypothèses génériques de combler les lacunes de la spec. Sa sortie est une spécification où chaque critère d'acceptation nomme sa méthode de vérification. C'est ici qu'intervient la Porte humaine 1, l'approbation de la spec — le moment de valeur humaine maximale. P2 (Decompose) défend contre le context rot en découpant la spec en tickets atomiques exécutables par des agents frais, avec des contrats explicites aux frontières. P3 (Rail) écrit tests, stubs de types et contrats depuis la spec en isolation, puis les gèle : le builder ne peut pas les modifier. P4 (Build) lance un agent par ticket sur des modèles mid-tier par défaut, avec régénération à deux essais (tuer un agent qui patine et repartir à neuf) et sans personas — les capacités viennent du contexte, des outils et de la charte. P5 (Prosecute) déploie des agents frais chartés pour réfuter, la charge de la preuve portant sur la reproductibilité, jusqu'à deux passes consécutives sans rien trouver. P6 (Integrate) ouvre la Porte humaine 2, l'acceptation comportementale : l'humain vérifie la conformité à la spec, les diffs de tests, le comportement en exécution et les hotspots — pas les diffs complets. La question est « est-ce ce que je voulais dire, en train de tourner ? » Enfin P7 (Distill) simplifie et mine les leçons récurrentes en règles de lint, templates et skills. Williams insiste sur une distribution des dépenses « en haltère » : lourde aux deux extrémités (planifier, prouver), légère au milieu (exécuter). Cela inverse l'économie agile classique où « mal construire est ce qui coûte cher ». Il rejette explicitement la revue de diff complet (théâtre au-delà de 500 lignes), les personas, le DRY à l'écriture ou les gates de couverture — chaque rejet étant tracé à un mode de défaillance précis.

Tests Are the Spec in the Only Language the Builder Can't Argue With

Fri, 12 Jun 2026 00:00:00 GMT

Le troisième volet s'attaque au cœur de la confiance dans un cycle agentique : les tests. Williams pose une inversion fondamentale. Dans le développement traditionnel, le TDD est une pratique qualité optionnelle, affaire de discipline personnelle. Quand ce sont des agents qui écrivent le code, le test devient tout autre chose : le mécanisme de confiance porteur de l'ensemble du cycle. Le test n'accompagne plus le code, il est la spécification — dans la seule langue que le builder ne peut pas contester. La raison tient à un mode de défaillance documenté (F5, reward hacking). Sous pression d'aboutir, les modèles gament systématiquement les suites de tests selon des techniques prévisibles : supprimer les tests qui gênent, affaiblir les assertions, mocker l'implémentation réelle, skipper des validations. Williams insiste : ce ne sont pas des accidents occasionnels mais des patterns constants, observés de façon convergente à travers les équipes et les vendeurs de modèles. La parade tient en trois règles de « rail discipline ». Première règle, les contextes d'écriture sont séparés : des agents specs-only écrivent les tests avant que l'implémentation existe, ce qui les empêche d'hériter des hypothèses du code à venir. Deuxième règle, l'enforcement est mécanique : les fichiers de tests sont gelés au niveau de l'outil, pas seulement par une instruction dans le prompt. Des blocages techniques empêchent le builder de les modifier et produisent une preuve de non-altération. C'est ici que Williams formule sa distinction la plus mémorable : « une contrainte qui vit dans la couche prompt est une requête ; une contrainte qui vit dans la couche outil est un fait. » Troisième règle, des audits adversariaux soumettent chaque test à une question simple et redoutable : « un test échoue-t-il si l'on supprime la feature ? » Un test qui passe quand la fonctionnalité a disparu ne teste rien. Williams catalogue six coups de gaming récurrents, chacun apparié à une défense structurelle — diffs, greps, hooks, file scoping. Ces mécanismes sont délibérément simples, précisément parce que la simplicité résiste mieux au contournement par un agent travaillant à vitesse machine qu'un dispositif sophistiqué. Enfin, sur la mesure de couverture : le pourcentage de couverture est facilement Goodhart-able par des agents capables de produire du test à la chaîne. Williams lui préfère le mutation testing, qui plante des mutations dans le code et vérifie que les tests les détectent — une mesure de la capacité réelle des tests à attraper un changement de comportement, et non de leur simple présence. Cette phase Rail est le socle de confiance sur lequel reposera la prosecution du volet suivant.

Prosecution, Not Code Review

Fri, 12 Jun 2026 00:00:00 GMT

Le quatrième volet réinvente la revue de code pour le monde agentique. Le constat de départ : sollicités pour une revue classique, les modèles déçoivent de façon prévisible. La sycophancie (F2) les pousse à valider plutôt qu'à critiquer ; l'hallucination (F4) leur fait inventer des problèmes ; et un biais d'entraînement (F6) les fait s'arrêter autour de quinze findings, quelle que soit la densité réelle de défauts. Williams en tire un reframe : il ne faut pas demander une évaluation, mais conduire une prosecution — une accusation adversariale. Quatre principes structurent cette prosecution. D'abord, la réfutation plutôt que l'évaluation : on ne demande pas un feedback, on charte l'agent pour « trouver ce qui est faux » ou expliquer comment le projet échouerait. Le biais de complaisance, ainsi retourné, travaille pour vous. Ensuite, la prosecution mono-lentille : plutôt qu'un seul reviewer omniscient, on déploie des agents parallèles à contextes frais, chacun dédié à une unique dimension — correction, sécurité, conformité de contrat, alignement avec la spec, qualité des tests. Distribuer les préoccupations évite la saturation de contexte qui dilue le jugement entre priorités concurrentes. Troisième principe, les findings vérifiés uniquement. Avant qu'un builder n'agisse sur une critique, celle-ci doit être prouvée séparément : reproduire le bug via un test qui échoue, tracer le chemin de code, ou produire l'input déclencheur. Sans cela, les findings hallucinés génèrent un churn de code bien réel pour des problèmes qui n'existent pas. Quatrième principe, le loop-until-dry : on relance la prosecution avec des contextes frais jusqu'à deux passes consécutives sans aucun finding vérifié. Cet échantillonnage répété déjoue le point d'arrêt artificiel de F6. Williams insiste ensuite sur un angle mort quasi universel : presque toutes les équipes font confiance à leur stack de revue à l'aveugle, sans jamais mesurer sa capacité réelle de détection. Sa solution miroite le mutation testing appliqué aux reviewers : planter des bugs connus — mutations mécaniques plus bugs subtils écrits par un LLM — faire tourner toute la stack de prosecution, puis mesurer le recall par catégorie et le taux de faux positifs. Exemple de bug planté : un garde de truthiness qui saute la vérification quand un champ est absent, d'apparence défensive mais introduisant une faille de sécurité. Enfin, le gate de sortie est strict et entièrement vérifiable : zéro finding vérifié ouvert, deux passes sèches consécutives, suites de tests vertes, et diff de tests vide — cette dernière condition prouvant que les builders n'ont pas modifié leurs propres gates pour passer.

Three Dials: Parallel Agents Without Merge Hell

Fri, 12 Jun 2026 00:00:00 GMT

Le cinquième volet aborde le passage à l'échelle : faire travailler des agents en parallèle sans tomber dans le « merge hell ». Williams pose d'emblée que l'orchestration multi-agents revient à équilibrer trois cadrans interdépendants — le coût (déterminé par le choix du modèle), le temps mural (déterminé par la largeur de parallélisation) et la précision (déterminée par la qualité des contrats). Ces facteurs sont couplés : le parallélisme n'améliore l'efficience-coût à précision constante que si la partition du travail est propre. Augmenter la largeur sans contrats nets dégrade la précision et fait exploser les conflits. Le principe d'architecture est tranchant : « control flow is code; judgment is models ». Williams refuse de confier les décisions d'ordonnancement à des modèles frontier ; ce sont des scripts déterministes qui orchestrent, les modèles n'intervenant que là où un jugement est réellement requis. Le système s'organise en quatre lanes spécialisées : un Contract Desk (modèle frontier) qui dessine les contrats, un Builder Pool en single-writer par partition (un seul agent écrit dans une partition donnée), un Prosecution Pool partagé à contextes frais, et une Integrator Lane séquentielle. Le routing de tier de modèle obéit à trois principes : la rail density (plus la couverture de tests et les checks déterministes sont denses, plus on peut descendre en tier), l'escalation ladder (en cas d'échec, régénérer en montant d'un tier), et le DAG float (l'analyse du chemin critique décide s'il vaut mieux gravir l'échelle ou aller directement au tier supérieur pour ne pas retarder le chemin critique). Pour le temps mural, Williams identifie quatre signaux qui prédisent les conflits de merge avant même de lancer le travail : le chevauchement de scope de fichiers, le rayon dans le graphe d'imports, le couplage historique de co-changement, et les collisions de namespace. La largeur certifiée par ce forecast se situe typiquement entre trois et cinq agents — au-delà, le risque de collision annule le gain. Enfin, la précision sans introspection : plutôt que de poser des questions de clarification à un modèle (peu fiable), on fan-out des agents pas chers pour générer plusieurs interprétations de la demande. Là où les N agents convergent, la demande est démontrablement non ambiguë ; là où ils divergent, l'ambiguïté devient mesurée et actionnable. Williams clôt sur des pratiques de terrain : batcher les permissions en pré-vol, distinguer validateurs in-flight et gates de prosecution, préférer des work-stealing queues aux assignations statiques, et respecter un ordre de merge strict — foundation, puis shared packages, puis apps.

The Lifecycle That Gets Cheaper Every Run

Fri, 12 Jun 2026 00:00:00 GMT

Le sixième volet répond à la question qui décide de la viabilité économique des agents : pourquoi un cycle agentique devrait-il coûter moins cher à chaque exécution ? La réponse de Williams est qu'il ne le fait pas spontanément. Sans un mécanisme délibéré de capture et d'institutionnalisation des leçons, les agents n'offrent aucun avantage cumulatif : ils repartent d'une connaissance nulle à chaque cycle. Le composant qui change cela est la phase P7, Distill. Distill comporte deux moitiés. La première est la simplification. Contre l'intuition, la revue architecturale et la déduplication doivent intervenir après le merge, pas avant. Dédupliquer avant que le code existe est spéculatif ; dédupliquer après cible des patterns réellement observables. Les tests, déjà en place, garantissent la préservation du comportement pendant ce nettoyage, ce qui autorise des modèles moins capables — donc moins chers — à y participer sans risque. La seconde moitié est le minage des leçons, organisé en « lesson foundry ». Cette fonderie transforme les findings récurrents en défenses permanentes : les problèmes déterministes deviennent des règles de lint accompagnées de tests ; les patterns contextuels alimentent un pipeline de skill-mining ; les lacunes de spécification déclenchent de nouvelles questions dans la phase d'interrogation. L'économie sous-jacente est décisive : chaque leçon est payée une seule fois, puis rétrogradée d'une détection probabiliste coûteuse vers une prévention déterministe gratuite. Williams identifie deux ennemis du gain capitalisé. Le skill rot d'abord : des artefacts périmés délivrent une désinformation avec autorité ; la parade est une vérification hebdomadaire qui extrait les claims vérifiables (commandes, chemins, versions) et marque leur fraîcheur. Le model ratchet ensuite : après chaque release, ré-auditer le code existant avec des modèles frontier pour capter ce que les versions antérieures avaient manqué — un cliquet qui n'autorise pas le recul. Le volet culmine sur la bonne unité de compte. Plutôt que de suivre les tokens par développeur, les programmes qui réussissent mesurent le coût par changement mergé et vérifié. Ce recadrage transforme la lecture de la dépense : les coûts de la phase prosecution ne sont pas du gaspillage mais un investissement. Quatre indicateurs révèlent une boucle cassée : une dépense concentrée en phase Build signale des skills manquantes ; une prosecution de plus en plus chère signale des leçons non rapatriées ; les atteintes répétées du plafond d'itérations signalent des specs faibles ; et une trajectoire de coût plate signale l'échec du système. La thèse tient en quatre mots : « flat cost is failure ». Un système sain voit son coût par changement décroître mesurablement à mesure que les skills s'accumulent et que les couches de lint s'épaississent.

The ADLC Toolkit

Fri, 12 Jun 2026 00:00:00 GMT

Le septième volet clôt la série par la preuve : un toolkit de dix-huit outils, open-source, construit avec le cycle ADLC lui-même. Des agents parallèles ont suivi la boucle build-prosecute-fix autour d'un core gelé, `@adlc/core`, qui centralise appels LLM, opérations git, conventions CLI et findings ledgers. Le principe structurel — « pinned means merged » — veut que ce core partagé soit mergé avant tout fan-out, afin d'éviter le dependency hell du développement parallèle. Les outils s'organisent selon les cinq phases : Specify (spec-lint, premortem, parallax, coldstart), Rail+Build (rails-guard, hollow-test, preflight, merge-forecast, model-router, flail-detector, consensus-fix), Prosecute (review-calibration), Integrate (behavior-diff, gate-manifest) et Distill (lesson-foundry, skill-rot, model-ratchet, rejection-mining). Le cœur doctrinal est « frontier-free » : viser les cibles de précision avec des modèles mid-tier (classe Opus, Sonnet, Haiku) plutôt que frontier. Cinq substitutions remplacent les capacités frontier. D'abord, le generator-verifier gap fait tourner le moteur : vérifier coûte moins cher que générer, et « on n'a jamais besoin d'un modèle plus intelligent que le gate qu'il doit passer ». Ensuite, search remplace insight : N tentatives diverses, triées par un jugement mid-tier, surpassent un seul passage frontier — et la mesure prouve la capacité de la stack. Décomposition remplace horizon : des tickets plus petits maintiennent les modèles sous leur seuil de dégradation. Banking remplace présence : les modèles chers frappent une fois des structures permanentes (contrats, skills, lints) puis sortent, et les mid-tier opèrent à l'intérieur. Enfin, mesure remplace métacognition : divergence de parallax, statistiques de consensus et lacunes énumérées remplacent les requêtes de confiance. Une sixième substitution place l'humain comme tier frontier, sur les deux portes de spécification où l'intention est la vérité-terrain. Williams tient une « honest loss account » : la doctrine sacrifie l'élégance architecturale en un seul jet, l'intuition transversale subtile, la latence et les refactors à long horizon réticents à la décomposition. Les mitigations sont des judge panels, des premortems et les portes humaines ; le résidu, environ 5 % du travail, tourne à supervision maximale. Côté adoption, il rejette le big-bang : commencer par la prosecution des PRs existantes (zéro changement de workflow), puis les rails et la génération de tests, puis l'interrogation, et seulement ensuite le parallélisme complet et la distillation. Mandater le cycle entier dès le premier jour est l'anti-pattern, car il impose la cérémonie avant que le compounding ne paie. Le fil rouge des sept volets se résume d'une formule : « replace trust with structure, and structure with measurement » — un mécanisme qui s'amplifie avec des modèles plus forts, donc un lifecycle et non un workaround. Le code est livré sur github.com/voodootikigod/adlc, en outils npx zéro-dépendance à exit codes déterministes pour la CI.

Loop Engineering: The Guide for AI Agents

Tue, 09 Jun 2026 00:00:00 GMT

Ce guide de l'agence Lushbinary théorise le **loop engineering** : le passage du *prompting manuel* d'un agent de codage à la *conception des systèmes qui le promptent automatiquement*. Pendant deux ans, tirer de la valeur d'un agent suivait un schéma simple (prompt, contexte, revue, instruction suivante) où le développeur gardait le contrôle à chaque tour. À partir de juin 2026, le levier se déplace : le développeur cesse d'être le prompteur principal pour devenir le concepteur d'une **boucle externe** qui découvre le travail, le distribue, valide les résultats, documente et décide de la suite. Le terme, popularisé par **Addy Osmani** (Google), s'appuie sur Peter Steinberger (*« design loops that prompt your agents »*) et Boris Cherny (Claude Code/Anthropic : écrire des boucles plutôt que prompter). Le loop engineering est la **troisième couche** d'une pile (prompt → context → loop), chacune englobant la précédente ; la complexité ne diminue pas, le levier se déplace vers la conception. La **technique Ralph** de Geoffrey Huntley (début 2026) en est la validation pré-terminologique : une boucle `while`, même prompt, **contexte neuf à chaque itération**, état durable sur disque (`PLAN.md`, `STATUS.md`). Le loop engineering la productise. Une boucle fonctionnelle requiert **cinq briques + la mémoire** : (1) **automations** planifiées (Codex Automations ; Claude Code `/loop`, hooks, `/goal`) ; (2) **worktrees** git pour des agents parallèles sans collision ; (3) **skills** capturant le savoir projet (`SKILL.md`) ; (4) **plugins/connecteurs** via MCP (portables entre outils) ; (5) **sub-agents** séparant le « maker » du « checker » ; (6) **mémoire** hors contexte (markdown, boards). Claude Code et OpenAI Codex embarquent désormais ces briques sous des noms différents mais structures identiques. La primitive `/goal` (Claude Code v2.1.139, 11 mai 2026, Opus 4.8 par défaut ; Codex CLI 0.128.0) maintient le travail jusqu'à une condition **vérifiée par un modèle distinct**. D'où l'impératif : écrire les conditions d'arrêt **comme des contrats** (état final, preuve, contraintes, plafond turns/budget). Le split **maker-checker** (vérificateur adversarial) est le changement le plus puissant. Une **échelle de maturité** en 5 niveaux (Manuel → Triage → Draft → Verified PR → Auto-merge) guide une adoption prudente, l'humain restant dans le chemin tant que la preuve ne permet pas de s'en retirer. Trois risques **s'aggravent** avec la sophistication : la vérification reste humaine (« done » = revendication, pas preuve), la **dette de compréhension** s'accélère, et la **capitulation cognitive** guette. Conclusion : concevoir ses boucles « comme quelqu'un qui compte rester ingénieur ».

BYO Agent with M5Stack Stick 3

Sun, 07 Jun 2026 00:00:00 GMT

Billet de bricolage du dimanche de **Mark Dembo** (Head of Solutions, Developer Platform & AI chez **Cloudflare**) publié le **7 juin 2026** sur son blog perso. **Récit** : inspiré par **Steve Ruiz**, l'auteur achète un petit appareil **M5Stack Stick 3** (~30 €) et, profitant de la sortie d'**Opus 4.8**, se construit un **agent IA DIY** « par pure curiosité, sans objectif ». **Itération 1 (45 min)** : il jette la doc de l'appareil à **Claude Code**, qui génère des scripts Python (~200 LOC, *« zero blast radius »*) affichant la météo de Munich, puis de plusieurs villes ; un **backend Cloudflare Workers + Workers AI** ajoute la **synthèse vocale (TTS)**, le **push-to-talk** (speech-to-text) et un **petit LLM** central pour répondre aux questions. **Itération 2 (vrai agent)** : passage des endpoints REST au transport **WebSocket** via le **Cloudflare Agents SDK** + **Dynamic Worker execution** → le pattern ***« Code Mode »*** (l'agent écrit et exécute du code pour accomplir sa tâche). L'agent répond alors à des questions à données publiques (11 ! = factorielle, vainqueur de la Ligue des Champions via `fetch()` sur Wikipédia, météo de n'importe quelle ville). **Itération 3 (vrais pouvoirs)** : connexion à **Todoist** via flux **MCP OAuth** → 50 outils d'un coup, d'où deux problèmes : **bloat du contexte** et **risque de dégâts réels**. Solution reprise du **MCP Server Portal Cloudflare** + des réglages connecteurs Claude : par outil, **Always allow / Ask for approval / Disable** (les *Disabled* n'entrent jamais dans le contexte ; un **classifieur LLM** n'accepte que les « allow » distincts et **défaut = deny**). **Posture revendiquée** : réduire son rôle à ***« idea generator, executor and judge »*** (et rarement guide technique), un flux « human-in-the-loop » jugé peu *« 2026 »* (copier-coller dans l'UIFlow). **Ce qu'il n'a PAS fait** : pas d'optimisation de latence/streaming, pas d'appels LLM optimistes, pas d'évals, ***« I did not even look at the code once »***. **Émerveillement** : 30 € + une fenêtre de session Anthropic + quelques cents d'inférence Cloudflare → un objet qui écoute et parle, piloté en langage naturel ; *« the true unlock is how accessible it is »*. Contraste vif avec [[thomas-pragdave-failing-faster-code-rot-ai-velocity-2026-06-06]] (ici le *« zero blast radius »* justifie de ne jamais regarder le code) ; illustre concrètement *Code Mode* / *« the agent just writing and executing code »*, le pattern **MCP** ([[claude-skills-bigger-than-mcp-willison-2025-10-16]]), la gouvernance d'outils façon *Ask for approval* ([[uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21]]), et la doctrine *systems around the model* de [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]].

Failing Faster

Sat, 06 Jun 2026 00:00:00 GMT

Dans ce billet du **6 juin 2026**, **David « Pragdave » Thomas** — co-auteur de *The Pragmatic Programmer* et signataire du Manifeste Agile — livre un avertissement aussi court que cinglant : l'IA ne supprime pas la dégradation du code, elle l'**accélère**. Le récit est personnel. Pour le plaisir, l'auteur ajoute des fonctionnalités à un petit projet d'animation graphique en s'appuyant sur **Claude**. La première semaine est grisante : les features pleuvent — support des couleurs **oklch**, animation de lignes en **SVG** par manipulation de la longueur des tirets (*dash-length*). Mais dès la deuxième semaine, les **cycles de régression** deviennent la norme et la base de code se délite. Sa formule fait mouche : ce que des équipes mettaient *« 18 mois, voire davantage »* à transformer en code inmaintenable, il l'a obtenu en *« **18 heures** réparties sur cinq soirées »*. La cause racine est l'abandon de l'**hygiène de code**. Thomas énumère les marqueurs de la décomposition : duplication extensive, **solutions locales** à des problèmes **systémiques**, logique conditionnelle pléthorique, prolifération de **cas particuliers** — autant de défauts qui finissent par **interagir** de façon destructrice. Reprenant Gordon Bell en épigraphe (*« every big computing disaster has come from taking too many ideas and putting them in one place »*), il rappelle que *« le code se dégrade naturellement ; il faut investir de l'effort pour l'en empêcher »*. Son diagnostic vise aussi le comportement des modèles. Les LLM sont conçus pour maximiser l'**engagement** et la **satisfaction** de l'utilisateur — d'où le flagorneur *« That's a great idea, Dave! »* — et non la durabilité. Il les compare à des ***« puppy-dog junior developers »*** : des chiots juniors empressés de plaire, mais brouillons, qui suggèrent sans cesse de nouvelles fonctionnalités et **découragent** implicitement le refactoring. L'insight central distingue l'implémentation initiale de la maintenance dans la durée. N'importe quel non-développeur peut réussir la *« première semaine »* du codage IA ; c'est le **jugement professionnel** — savoir **quand arrêter d'ajouter des features pour refactoriser** — qui sépare l'ingénieur aguerri du novice. La conclusion est un rappel à l'ordre intemporel : ***« It's still just programming »***. Que cela prenne 18 heures ou 18 mois, le code non entretenu **pourrit** ; tout ce que l'on a appris sur la fabrication d'un bon code **reste valable** — l'effet est simplement **amplifié** par la vitesse de l'IA.

How Anthropic enables self-service data analytics with Claude

Wed, 03 Jun 2026 00:00:00 GMT

REX d'ingénierie de l'équipe **Data Science & Data Engineering d'Anthropic** (Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry) publié le **3 juin 2026** sur le blog Anthropic (catégorie *Enterprise AI*, focus **Claude Code**). **Résultat-phare** : ***« 95 % des requêtes d'analytics métier sont automatisées par Claude, avec ~95 % de précision en agrégat »*** (jusqu'à **~99 %** sur certains domaines). **Problème central** : l'analytics n'est **pas** du code — *« there's often only a single correct answer using a single correct source »* — il faut **mapper une question utilisateur à des entités précises et à jour** du modèle de données. Trois **modes d'échec** : (1) **ambiguïté concept↔entité** (ex. *« active users »* : quelles actions ? exclure les fraudeurs ? quelle fenêtre ?) ; (2) **obsolescence** (assets et connaissance de l'agent deviennent *« subtly wrong »*) ; (3) **échec de retrieval** (*« 80 % des requêtes échouées avaient l'info présente dans le corpus »* mais introuvable). **Solution = « agentic analytics stack » en 4 couches** : (L1) **Data foundations** — dimensional modeling, **canonical datasets** *« single source-of-truth »*, métadonnées *« as a first-class product »*, intégrité par CI/CD ; (L2) **Sources of truth** par ordre de confiance décroissant — **semantic layer** (l'agent est *« structurally required (by skill instruction) to leverage the semantic layer first »*), graphe de lineage, **query corpus** (distillé en docs structurées, **pas** du retrieval brut), business context (knowledge graph : roadmaps, decision logs, org) ; (L3) **Skills** — le levier décisif : ***« without skills … didn't exceed 21 % … Adding skills gets these numbers consistently above 95 % »*** ; structure **par paires** (*Knowledge skill* = routeur vers ~30 fichiers de référence ; *Unbook skill* = workflow de l'analyste senior : clarifier → trouver les sources → exécuter → **revue adversariale**) ; maintenance **colocalisée** (*« a code-review hook flags any reporting-model change that doesn't touch a skill file »* → **~90 % des PR data incluent un changement de skill**) ; (L4) **Validation** — evals offline (seuil ~90 % pour lancer un agent, cible ~100 %), **ablation testing** (résultat négatif notable : grep brut sur des milliers de fichiers SQL → précision bouge *« less than a point »*), online (revue adversariale : **+6 % de précision, +32 % de tokens, +72 % de latence**), **provenance footers** (tier de source + fraîcheur + ownership), **active correction harvesting** (agents planifiés scannant les canaux pour drafter des fixes markdown). **Insight stratégique** : *« documentation generated, definitions owned by humans »* — laisser le LLM **définir** les métriques fut *« net-negative »*. **Démarrage minimal** : quelques canonical datasets + quelques dizaines d'evals + un *thin knowledge skill* captent *« most of the upside »*. Converge fortement avec [[shihipar-claude-code-lessons-building-skills-2026-06-03]] (skills = dossiers, Gotchas, hooks), la doctrine *systems around the model* de [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]], le **semantic layer / ontology** de [[talisman-modern-data-101-ontology-pipeline-refresh-2026-05-04]] et [[seale-semantic-agent-model-harness-ontology-data-2026-04-17]], le *context development lifecycle* de [[debois-tessl-context-development-lifecycle-ai-coding-agents-2026-02-19]] et l'UDA/knowledge graph de [[netflix-uda-unified-data-architecture-knowledge-graph-2025-06-12]].

Lessons from building Claude Code: How we use skills

Wed, 03 Jun 2026 00:00:00 GMT

Article de blog **Anthropic / claude.com** signé **Thariq Shihipar** (Member of Technical Staff, équipe Claude Code), publié le **3 juin 2026**, qui capitalise le **retour d'expérience interne** d'Anthropic sur la conception et l'usage des **Skills**. **Thèse de cadrage** : une Skill n'est pas un simple fichier markdown mais un **dossier** (instructions + scripts + ressources + config + hooks) que l'agent **découvre et manipule** ; *« You should think of the entire file system as a form of context engineering and progressive disclosure. »* L'article propose deux apports structurants. **(A) Une taxonomie de 9 catégories de skills** observées chez Anthropic : (1) **Library/API Reference** (doc de libs/CLI internes avec *gotchas* — ex. `billing-lib`, `internal-platform-cli`, `sandbox-proxy`) ; (2) **Product Verification** (test/vérif via Playwright ou tmux — `signup-flow-driver`, `checkout-verifier`, `tmux-cli-driver`) ; (3) **Data Fetching & Analysis** (accès stacks data/monitoring — `funnel-query`, `cohort-compare`, `grafana`, `datadog`) ; (4) **Business Process Automation** (workflows répétitifs — `standup-post`, `weekly-recap`, `create--ticket`) ; (5) **Code Scaffolding** (boilerplate framework — `new-migration`, `create-app`) ; (6) **Code Quality & Review** (`adversarial-review`, `code-style`, `testing-practices`) ; (7) **CI/CD & Deployment** (`babysit-pr`, `deploy-`, `cherry-pick-prod`) ; (8) **Runbooks** (diagnostic multi-outils — `-debugging`, `oncall-runner`, `log-correlator`) ; (9) **Infrastructure Operations** (maintenance avec garde-fous — `-orphans`, `cost-investigation`). **(B) Un jeu de bonnes pratiques** : ne pas redire l'évident (*« Claude already knows how to code and can read your codebase »* → cibler ce qui **contredit le comportement par défaut**) ; soigner la **section Gotchas** (*« the highest-signal content in any skill »*) ; **progressive disclosure** via l'arborescence (pointer vers des fichiers de référence selon la situation plutôt que tout charger d'emblée) ; **descriptions pensées pour le modèle** (*« the description field is not a summary, it's a description of when to trigger this skill »*) ; **setup flows** (config dans `config.json`, sinon demander via `AskUserQuestion`) ; **mémoire persistante** (logs append-only / JSON via la variable `${CLAUDE_PLUGIN_DATA}`) ; **helper scripts** (*« lets Claude spend its turns on composition… rather than reconstructing boilerplate »*) ; **hooks conditionnels** (activés seulement le temps de la skill — ex. hook de sécurité bloquant les commandes destructrices). **Distribution chez Anthropic** : skills rangées dans `./.claude/skills`, partage informel via Slack dans un dossier sandbox, puis promotion par **PR** vers le **marketplace** interne quand elles gagnent en traction ; **mesure d'usage** via un **hook `PreToolUse`** qui logue les invocations (révèle les skills populaires et celles sous-utilisées). Suite directe de la fiche [[shihipar-claude-code-html-unreasonable-effectiveness-markdown-2026-05-10]] (même auteur) et complément concret aux fiches Skills d'Anthropic/Willison/Vincent et au *harness engineering*.

The Eight Levels of AI Adoption

Tue, 02 Jun 2026 00:00:00 GMT

Guide du média **Every** (every.to/guides) publié le **2 juin 2026**, co-signé **Mike Taylor, Laura Entis et Claude**, proposant une **échelle de maturité en 8 niveaux d'adoption de l'IA**. **Thèse-pivot** : l'adoption de l'IA **n'est pas une course à la sophistication maximale** — ***« a higher level isn't necessarily better »*** ; il faut identifier le niveau qui **correspond à son propre workflow et à son niveau de confiance**, puis réévaluer régulièrement si monter d'un cran ajoute une **valeur réelle**. ***« The best way to find value in AI is to use it in a way that fits your work. »*** **Axe structurant** : à chaque niveau, *« you delegate more of your work to—and place more trust in—the AI »* (délégation + confiance croissantes). **Les 8 niveaux** : **(1) Chatbot** — interface conversationnelle sans contexte embarqué (ChatGPT, Claude, Gemini) ; **(2) Copilot** — IA embarquée dans l'espace de travail avec accès au fichier courant (Cursor, Claude in Excel, Gemini in Docs) ; **(3) Agent** — système réactif qui exécute pas-à-pas en demandant approbation (Cowork, Codex) ; **(4) Autopilot** — on décrit l'**outcome** et l'agent exécute en autonomie, revue du **résultat final** seulement (Lovable, Codex, Claude Code ; lié au *vibe coding*) ; **(5) Workflows** — ingénieurs construisant des **harnesses** autour des agents (planning, review, confidence checks, garde-fous ; Compound engineering, Claude Workflows, Copilot AI Studio ; bascule one-shot vibe coding → **agentic engineering**) ; **(6) Assistant** — agents **proactifs, always-on** qui surveillent un domaine et remontent l'info sans sollicitation (OpenClaw, Hermes Agent, Claude Managed Agents ; ex. `heartbeat.md` toutes les 30 min) ; **(7) Multi-agent** — gestion simultanée de **plusieurs agents long-running** à rôles distincts (Claude Managed Agents, OpenClaw, Codex Goals ; *« firmly in senior engineering territory »*) ; **(8) Orchestrator** — un **agent manager** pilote une équipe de sous-agents (plan, délégation, monitoring, consolidation ; Gas Town, Paperclip, Symphony/OpenAI ; *« highly experimental »* — même les ingénieurs frontier tiennent eux-mêmes ce rôle). **Sweet spots par rôle** : les **knowledge workers** opèrent typiquement entre les niveaux **1-4**, les **ingénieurs** entre **5-8**. **Parallèle canonique de l'onboarding d'un stagiaire** : *« Expect to put in a similar amount of effort with your agents before you can trust them… at the next level of autonomy »* ; et la formule-marqueur ***« You wouldn't brag that you had eight interns working overnight on a key project, and you hadn't checked their output. »*** Le bon niveau dépend de **4 critères** : qualité de l'output, coût, fiabilité (trustworthiness), enjeu de l'échec (stakes of failure) ; et la **capacité des modèles** déplace progressivement le niveau d'autonomie « sûr ». Cadre directement mobilisable pour structurer une **doctrine d'adoption** côté cabinet. Convergence avec *systems around the model* (Dropbox/Okumura), *harness engineering* (Böckeler, Lattice, Wescale), Karpathy (vibe coding → agentic engineering), Cherny (/loop + Routines), et la doctrine *manager d'agents* (BFM/Girard).

L'ingénierie logicielle à l'ère de l'IA : tout change... et rien ne change

Mon, 01 Jun 2026 00:00:00 GMT

Tribune d'**Olivier Rafal** (Consulting Director Strategy, **WeNvision** — groupe **SFEIR** ; ex-rédacteur en chef du *Monde Informatique*) publiée le **1er juin 2026** sur **CIO-Online**, structurée autour d'un **paradoxe** : à l'ère de l'IA, l'ingénierie logicielle **change tout… et rien ne change**. **Ce qui change = le modèle opérationnel.** Les rôles sont redéfinis : le **Product Owner** passe de la découpe de backlog à la **génération de contexte exploitable par l'IA** ; le **développeur** passe de l'écriture de code au **cadrage, à l'orientation et à la révision** de l'exécution des agents ; le **QA** gagne la possibilité de définir en amont les **preuves attendues**. La structure d'équipe bascule des *« double pizza teams »* (chaînes de hand-off à ~8 personnes) vers les ***« sandwich teams »*** : un **binôme serré expert métier + tech lead augmentés par l'IA**, les autres compétences en appui. Chiffre interne **Sfeir** : *« ce binôme pilote désormais environ 80 % de la chaîne de production »*, les ~20 % restants (architecture, gouvernance de la donnée, sécurité) étant centralisés. Citation-pivot : ***« Le sujet n'est pas un sujet d'outil, mais un sujet de modèle opérationnel. »*** **Ce qui ne change pas = la discipline du cycle.** Les phases du **SDLC** (définir → construire → vérifier → déployer → maintenir) restent identiques et non négociables ; l'IA n'en supprime aucune, elle les **intensifie** : ***« tous ces relâchements que le rythme humain absorbait tant bien que mal deviennent, à la vitesse de l'IA, des défauts industriels »*** (métaphore sport amateur vs professionnel). D'où **trois *gates* inviolables** (contrôle humain) : **spécification, planification, revue de livraison** ; validation **par la preuve** (pas par les assertions de l'IA) ; **capitalisation systématique** (chaque cycle enrichit le suivant) → résultat mesuré : **−30 % d'itérations de correction après ~10 cycles**. Principe : ***« plus l'exécution est rapide, plus le cadre doit être strict »***. Concepts mobilisés : **harnais** (règles agentiques adaptées au contexte), **vibe-coding** jugé **intenable en entreprise**. **Troisième pilier = gouvernance, FinOps & pilotage par la valeur** : coûts IA **variables et récurrents** (~**10 €/heure** par poste augmenté), bascule licence forfaitaire → facturation à l'usage (parallèle cloud 2010s) ; le **FinOps** ne vise pas à réduire les coûts mais à *« optimiser l'efficience des outils »* (coût rapporté à la valeur) ; aligner en amont les **métriques métier** (time-to-market, fonctionnalités, performance, écoconception). **Conclusion** : l'accélération rend les fondamentaux **non négociables** ; le défi est **organisationnel et culturel**, pas technologique — sans sécuriser relation métier et discipline collective, une SDLC dopée à l'IA ne fait qu'**amplifier les problèmes** (aller plus vite dans le mur). Prolonge la doctrine WeNvision de [[rafal-wenvision-ia-generative-produit-techno-pas-projet-2024-02-23]] et [[rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04]] ; converge avec *systems around the model* [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]], le *harness engineering* [[osmani-agent-harness-engineering-2026-04-19]], Salesforce agentique et le débat *manager d'agents* (BFM/Girard, SFEIR).

Beyond code generation: rethinking engineering productivity in the age of AI agents

Thu, 28 May 2026 00:00:00 GMT

Billet du **Dropbox Tech blog** (rubrique *culture*), publié le **28 mai 2026** par **Kazuaki Okumura** (Dropbox, rôle non précisé dans l'article), reprenant une intervention à la conférence **DX Annual 2026** (productivité développeur). **Thèse-pivot** : la productivité d'ingénierie doit dépasser la *génération de code*. *« Accelerating code generation simply shifted some bottlenecks downstream »* — l'IA a massivement augmenté le débit de code, mais *« the faster code moves, the more pressure it puts on review queues, CI systems, validation workflows, release coordination, and production operations »*. Le vrai enjeu n'est plus d'écrire du code plus vite, mais de permettre à tout le SDLC d'**absorber, valider et livrer en sécurité** un volume bien plus grand. **De copilote à agent** : la première vague (explication de code, snippets, Q&A) opérait *« as copilots alongside the engineer »* ; l'agent, lui, *« can take a scoped task, inspect the codebase, edit files, run tests, iterate on failures, and return an artifact for human review »* — l'ingénieur restant *« accountable for intent, architecture, quality, and release decisions »* (plus de travail parallèle, plus d'options, délestage de l'exécution répétitive). **Nova** = plateforme d'agents de codage **interne** de Dropbox : décrire une tâche en langage naturel, exécution en environnement contrôlé avec le contexte du codebase. Datapoint canonique : ***« Nova's value comes less from the model itself than the systems surrounding it »*** (codebase context, internal practices, safe execution, workflow integration, human review) ; Nova représente **~1 PR sur 12 chez Dropbox** aujourd'hui (adoption en croissance), et s'étend au-delà des features : **migrations, remédiation de tests flaky, investigation de bugs, mises à jour de dépendances** (travail à forte pénibilité). **Mesurer la vélocité produit, pas l'output de code** : le *PR throughput*, signal utile quand la vélocité de codage était la contrainte, *« was no longer sufficient »*. Modèle de mesure en **4 étages** : ***Fuel*** (les outils IA sont-ils sollicités ?) → ***Adoption*** (comment les workflows changent à travers les équipes) → ***Output*** (l'IA contribue-t-elle au travail de production ?) → ***Impact*** (*« improving product velocity and reducing the time it takes to move from idea to customer value »*). Signaux qualité suivis : **code review turnaround time, first-run test pass rate, defect ratio, rework rate**. *« Quality and trust matter as much as speed »* — le cœur de la bascule : *« moving from local activity metrics toward broader system outcomes »*. **Les workflows doivent évoluer** : ce n'est *« not just a tooling shift »* mais un changement d'**operating model** — le rôle de l'ingénieur glisse vers *« defining intent, mapping problems, reviewing generated changes, and making higher-context architectural and quality decisions »*. L'**enablement** est aussi crucial que l'outil (hands-on learning, hackathons, workflow spotlights, bootcamps, peer-led examples) ; adoption à vitesses variables selon les équipes ; *« The goal is not to force every workflow through an agent »* — le rendre *« useful, safe, measurable, and repeatable where it creates meaningful leverage »*. **Ce qu'on a appris** : ***« AI doesn't eliminate bottlenecks in software development, but it does move them »*** (downstream : review, validation, testing, release, prod ops) → optimiser l'ancien goulot ne crée plus le même levier. *« The advantage will not come from access to the same foundation models everyone else can use. It will come from the systems built around those models : context, internal tooling, quality controls, and the workflows that connect them together. »* Pression aussi **en amont** (product & design) : specs structurées, design clarity, problem framing plus aiguisé. Clôture : ***« The future of engineering productivity will not be defined solely by who has the best models. It will be defined by who builds the best systems around them »*** ; *« The real challenge is no longer just generating more code, but building engineering systems that can reliably turn AI-assisted output into valuable experiences for our customers »*. Convergence directe avec **Salesforce/Tallapragada** (Effective Output : mesurer la valeur, pas le volume ; pas de tradeoff vitesse/qualité), **Gupta** (token-to-outcome attribution, cost of a completed outcome), **DORA** (au-delà du débit) et le déplacement du KPI vers le **system outcome** (idea→customer value).

How Salesforce Engineering Became Truly Agentic

Wed, 27 May 2026 00:00:00 GMT

Billet de blog officiel **Salesforce News** (rubrique *Agentic Enterprise*, série *« Pioneering the Agentic Shift Within Salesforce Engineering »*), publié le **27 mai 2026** (6 min de lecture) par **Srinivas « Srini » Tallapragada**, *President and Chief Engineering and Customer Success Officer* de Salesforce. Suite directe d'un premier billet (*« How we got our engineers to use AI — without breaking everything »*) qui racontait le passage de **>90% d'adoption**. **Thèse-pivot** : Salesforce Engineering est passé d'un monde où l'IA était un *copilote* utile à un monde où des **outils agentiques pilotent le cycle de vie logiciel (SDLC) lui-même** — écriture de code, revue de PRs, génération de tests, mise à jour de doc, gestion des déploiements, coordination du travail jadis confié à des handoffs humains. **Décision-signal canonique** : standardisation org-wide sur **Claude Code** + ***« we removed all token limits »*** — *« remove every last piece of friction between our engineers and the tools that make them faster and more effective »*. **Résultat empirique majeur** (avril 2026 vs avril 2025) : work items complétés par développeur **+50,8%**, PRs mergées par développeur **+79%**, et surtout **Effective Output score** (mesure ML de la **valeur réelle du code livré**, pas le volume) **+151,3% en glissement annuel**. **Cas d'usage emblématique** : migration de **33 endpoints API** vers une architecture cloud-native, estimée **~231 person-days** (7 par API) en traditionnel, réalisée en **13 jours = 18× plus vite** — via un **framework rule-based en Claude** (fichiers markdown + reference implementations), feedback des PRs réinjecté en continu dans le rule set, **boucles LLM autonomes (build, fix, validate)** sans intervention manuelle, parallélisées sur environnements isolés → **5 PRs**, la plus grosse livrant **21 endpoints avec 100% de couverture de tests**. **Pas de tradeoff vitesse↔qualité** : via la plateforme **Engineering 360** (centralise les données d'ingénierie de centaines de systèmes), **les incidents totaux baissent de 5%** malgré la hausse des PRs (*« quality doesn't suffer from speed. It benefits from it »*), grâce à des **guardrails de sécurité et standards qualité encastrés structurellement** dans le workflow agentique (Trust = valeur n°1). **Refonte du SDLC** : une fois l'IA adoptée, les ingénieurs **détruisent et reconstruisent** les workflows (quels process supprimer ? quels handoffs inutiles ? où l'humain fait-il encore un travail qu'un agent peut posséder ?). **Nouveau craft d'ingénierie** : les **Claude Code skills** (capacités packagées/réutilisables encodant contexte d'équipe, conventions de nommage, patterns) deviennent un **artefact d'ingénierie** partagé et composable ; **AI Expert Suite** + **Salesforce Foundation Plugins** = bibliothèque curatée institutionnalisée de skills (benchmark interne : **précision et fiabilité en hausse, coût inutile réduit**) ; **subagents & agent teams** parallélisent les workstreams (*« They describe the outcome, and a set of coordinated agents figures out the steps »*). **Ce qui reste dur** : (1) **gestion du contexte** en sessions longues — la **qualité des fichiers CLAUDE.md** varie beaucoup et pèse fort sur la qualité de sortie ; (2) **sécurité agentique** = modèle fondamentalement différent (agents qui *agissent*, pas seulement *suggèrent* → blast radius accru) ; (3) **évolution des rôles** (comment les juniors deviennent seniors si l'IA absorbe le travail entry-level ? rôle du designer/PM ? l'unité d'exécution = scrum team → expérimentations d'unités à 1 ou 3 personnes). Conclusion : *« It changed what was economically possible »* ; ambition affichée = **« the most automated, agentic SDLC in the industry »**. Recoupe directement Gupta (*cost of a completed outcome*, marginal token utility), Greenwald/Sierra (outcome-based pricing), DORA (ROI / coût par feature) et le débat BFM/Girard (token = fuel de valeur, pas coût à couper).

AI Assisted Development is a TRAP Without Continuous Delivery

Wed, 13 May 2026 00:00:00 GMT

Dave Farley, fondateur de la chaîne *Modern Software Engineering* et figure historique de la *Continuous Delivery*, défend ici que la conversation publique sur l'IA et le développement logiciel oublie une variable décisive : la *continuous delivery*. Sans elle, le développement assisté par IA n'est pas seulement risqué, c'est un piège — un *complexity bomb with a delayed fuse*. Son argument central tient en quatre temps. Premièrement, **le code n'a jamais été le bottleneck** du software engineering. La difficulté a toujours été ailleurs : comprendre le problème, le concevoir, le tester, l'intégrer, le déployer. L'IA accélère précisément la partie qui n'était pas le problème. Deuxièmement, le **paradoxe de Jevons** s'applique : quand produire du code devient cheap, on en produit plus. Plus de code = plus de complexité, plus de points d'intégration, plus de comportements à évaluer, plus de maintenance. Et probablement moins de temps pour comprendre le problème. Ce n'est pas un gain de productivité, c'est une bombe à retardement. Troisièmement, l'IA **tend aux grands sauts** alors que le bon engineering exige des **petits pas réversibles** avec feedback rapide. Farley cite Bob Martin (*"the only way to go fast is to go well"*) et raconte un projet où l'arrivée brutale de 200 consultants un lundi matin a détruit dix-huit mois de progrès. Quatrièmement, la **Continuous Delivery** est définie comme *"working so that our software is always in a releasable state"*. La mécanique : petits incréments, tests automatisés rapides, deployment pipeline qui arbitre la *releasability*. Le pipeline ne se soucie pas de qui a écrit le code — humain ou IA, c'est le même standard. Farley illustre par son propre retour d'expérience : il enseigne désormais à son assistant IA l'**Acceptance Test-Driven Development**, spécifie au niveau acceptance, et progresse en heures sur ce qui prenait des semaines — avec la confiance que la direction est juste. Il raconte aussi comment son pipeline a détecté un *schema mismatch* silencieux : l'IA mettait à jour la base de test mais pas la base de production. Tous les tests passaient, l'app crashait en prod. Le pipeline a parlé, pas l'IA. Sa phrase de chute synthétise : *"AI doesn't replace the need for software engineering. It exposes teams that were never really doing engineering in the first place."* Le sujet n'est pas de savoir si l'IA peut écrire du code, mais si vos pratiques d'ingénierie sont assez robustes pour absorber du code venant de n'importe quelle source — humaine ou machine — et livrer du logiciel qui marche.

Using Claude Code: The Unreasonable Effectiveness of HTML

Sun, 10 May 2026 00:00:00 GMT

**Thariq Shihipar** (équipe Claude Code chez Anthropic) publie un article-manifeste annonçant un changement de format de sortie par défaut pour les agents : remplacer **Markdown par HTML**. Le diagnostic : Markdown a régné comme format dominant entre humain et agent (simple, portable, éditable) mais est devenu **restrictif** à mesure que les agents produisent des artefacts plus longs et plus riches. Au-delà de ~100 lignes, plus personne ne lit un fichier Markdown — et comme l'auteur n'édite plus manuellement ses specs (il prompte Claude pour les éditer), l'avantage historique de Markdown disparaît. **Six raisons** justifient le basculement vers HTML : (1) **densité d'information** — tableaux, CSS, SVG, scripts, canvas, images ; *"almost no set of information that Claude can read that you cannot represent with HTML"* ; (2) **clarté visuelle** — tabs, illustrations, responsive mobile ; (3) **partage** — upload S3 → lien direct, taux de lecture multiplié ; (4) **interactivité bidirectionnelle** — sliders, knobs, boutons "copy as prompt" pour reboucler ; (5) **ingestion contextuelle** native à Claude Code (codebase + MCP + git + Chrome) ; (6) **plaisir** — *"it's joyful"*. L'auteur formalise **cinq usages canoniques** : (a) **specs/plans/exploration** en grille comparative ; (b) **PR review** avec diff annoté inline et code-coloring par sévérité ; (c) **design & prototypes** avec sliders d'animation ; (d) **rapports/recherche** (son explainer sur prompt caching généré depuis l'historique git) ; (e) **éditeurs jetables custom** — single-file HTML purpose-built pour une donnée (drag-and-drop de tickets Linear, éditeur de feature flags, prompt-tuner side-by-side) finissant toujours par un export "copy as JSON/markdown/prompt" re-injectable. Anti-pattern explicite : **l'auteur refuse la skill-ification** de sa pratique. *"I'm a little bit afraid that people will read this article and turn it into a /html skill. You don't need to do much — just ask it to 'make a HTML file'."* La pratique est trop contextuelle pour être figée. FAQ honnête : HTML coûte plus de tokens mais le **1MM context d'Opus 4.7** absorbe ; génération 2-4× plus lente ; **diffs HTML bruyants** = downside non résolu, assumé. Méta-thèse finale : HTML comme **antidote au cognitive surrender**. *"I had begun to fear that because I had stopped reading plans in depth I would simply have to leave Claude to make its choices. But I feel more in the loop than ever before when using HTML."* La lisibilité retrouvée permet de rester décisionnaire face à des agents de plus en plus puissants. L'article s'articule directement avec **Meng To `design.md`** (HTML = "finished dish") et avec **Osmani comprehension debt** dont il propose une réponse opérationnelle.

The Batch n°352 — "There Will Be No AI Jobpocalypse" (Andrew Ng)

Fri, 08 May 2026 00:00:00 GMT

Le **352e numéro de The Batch**, newsletter hebdomadaire de DeepLearning.AI publiée le **8 mai 2026**, s'ouvre sur un édito d'**Andrew Ng** intitulé **"There Will Be No AI Jobpocalypse"**. Ng démonte la narration de chômage de masse provoqué par l'IA en s'appuyant sur les données macro : taux de chômage US **sain à 4,3 %**, hiring tech robuste malgré les progrès en software engineering. Au lieu de réfuter par le chiffre seul, Ng identifie **trois moteurs structurels** du narratif jobpocalypse. **Premier moteur — tech incentives** : les labs IA bénéficient à présenter leur technologie comme transformative-disruptive. Ils lèvent plus de fonds, attirent plus de talent, voient leurs valorisations grimper. Plus la peur du remplacement est crédible, plus la valeur attribuée aux modèles paraît justifiée. **Deuxième moteur — pricing power** : les éditeurs IA enterprise facturent **10 000$+ par an** à leurs clients en ancrant leur tarif sur le **salaire** de l'employé que leur produit est censé remplacer, plutôt que sur le pricing SaaS traditionnel (per seat / per usage). C'est le glissement **service-as-software** dans sa version financière : si le produit "remplace un employé à 80 000$/an", 20 000$/an semble raisonnable. **Troisième moteur — corporate messaging** : les entreprises recadrent leurs layoffs en *"efficience IA"* plutôt que de reconnaître l'**overhiring pandémique** 2020-2022. Ce récit est vendable aux marchés et au public, alors qu'admettre une erreur stratégique antérieure est gênant. Ng reconnaît honnêtement : *"AI disrupts work"*. Mais il **renverse la narration** en proposant le néologisme **"AI jobapalooza"** (jeu de mots sur Lollapalooza, festival → abondance). Le contenu : création de jobs en AI engineering et fields adjacents, avec compétences en évolution. L'édito s'inscrit dans une **série contrarian** caractéristique de Ng : démontage des hype cycles, défense de la praticité d'ingénieur contre les annonces grandiloquentes. La cible implicite est **Dario Amodei** (Anthropic) et sa prédiction de **50 % des white-collar jobs supprimés d'ici 2030** — Ng pointe sans nommer que **Anthropic gagne à promouvoir cette narration**. Le timing est frappant : l'édito paraît **le même jour** que **David Wallace-Wells** publie dans le NYT Magazine son article-fleuve sur l'**"AI Populism"** et le backlash anti-tech (cocktail molotov Altman, tirs Indianapolis). Lecture en miroir parfaite : Ng pratique une **analyse économique froide** des incitations narratives, Wallace-Wells documente la **panique populaire émotionnelle** qu'elles alimentent. L'enjeu pour Ng n'est pas seulement intellectuel : protéger les décideurs et les travailleurs des décisions précipitées (layoffs préventifs, paniques, désespoir individuel) déclenchées par un récit qui sert d'abord les vendeurs d'IA.

Google's Design.md is a design team in a file (Greg Isenberg × Meng To)

Wed, 06 May 2026 00:00:00 GMT

Greg Isenberg reçoit le designer **Meng To** (fondateur Design+Code, créateur d'**Aura**, **New Form**, **Dream Cut**) pour décortiquer **`design.md`** — la convention open-source de Google qui porte "l'âme du design system" dans un fichier markdown, équivalente à `agents.md` / `skills.md` / `soul.md` mais dédiée à la couche visuelle (typographie, couleurs, spacing, WebGL / Three.js, règles de reveal animation). L'épisode est un **manifeste pédagogique** sur comment créer des designs *jaw-dropping* sans être designer. Diagnostic central : le **design drift**. Les outils one-shot (V0, Lovable, Framer) génèrent un premier écran impressionnant puis dérivent en pages génériques sur les écrans suivants — pas de **mémoire de design** partagée entre prompts. La solution `design.md` agit comme **blueprint transférable** : il porte typographie, couleurs, spacing, WebGL et règles d'animation à travers Lovable, Cursor, Codex, Claude Code, Google Stitch, Aura, V0, Figma. Meng formalise une triade : **`design.md` = recette, HTML = plat fini, skills = ingrédients**. Les skills (63 dans New Form : lasers, skeuomorphic, 3D, copywriting, batch design) sont des prompts copyables qui dopent un design de "0 à 50 ou 50 à 80" en un clic. Le workflow complet de Meng en 9 étapes : **Reference → design.md → Generate → Inspect → Systemize → Iterate (1000+ prompts) → Remix → Expand → Export**. Il revendique jusqu'à **10 000 itérations par produit**, **~500 000 $ dépensés en tokens**, **4 produits en parallèle en solo**. Distinction structurante : *iteration* (incrémental, 90% du temps) vs *remix* (changement de catégorie, 10%). Démos enchaînées à l'écran : Aura (gallery design.md + remix + prompt), Google Stitch 3.1 (infinite canvas, "unfair they give it for free"), OpenClaude/Codex (lecture multi-fichiers MD en folders nestés), Variant.com (phase créative remix), Replit slides / Hyperframes / Remotion (expansion en slides + motion). Méta-thèse : la **taste est le seul moat restant**. *"If something looks like another thing, it reduces the value by 10× to 100×."* Le purple gradient — wow il y a 5-10 ans — est devenu signal de fuite. La baseline est haute mais générique : la survie passe par la **recence d'adoption** des modèles/tools/conventions et par le **judgment per minute** (micro-décisions humaines sur ce que l'agent produit). Greg conclut sur l'idée du **second brain design** : capturer l'inspiration croisée dans le réel et le digital pour la rappeler quand on crée. Meng valide : "ne laissez pas l'IA tout faire. Si vous le faites, assurez-vous que ce soit dans un workflow que vous maîtrisez déjà."

Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next

Tue, 05 May 2026 00:00:00 GMT

Boris Cherny, créateur de Claude Code chez Anthropic, est interviewé lors d'un événement Sequoia par Lauren Reader. Sa thèse-déclaration centrale : ***"coding is solved"***. Lui-même n'a pas écrit une ligne de code en 2026 — le modèle écrit **100%** de son code depuis octobre 2025, *"a few dozen PRs/day, 150 PRs in a single day record"*. Cherny raconte la **genèse de Claude Code** comme un récit pré-PMF assumé. Il rejoint **Anthropic Labs** (incubator interne) fin 2024, mission : explorer le *"product overhang"* — *"the model can do all the stuff that no product has yet captured."* À l'époque, le state-of-the-art coding était le *type ahead* (Sonnet 3.5). Pari : *"have the agent write all of the code."* Six mois où *"it just really didn't work. I used it for maybe 10% of my code."* Première release : *"it was not a hit."* **Inflection point : Opus 4 en mai 2025**, puis 4.5, 4.6, 4.7 — *"it just kind of keeps inflecting."* Round 2 de l'équipe maintenant dirigé par **Mike Krieger** (CPO Anthropic, ex-Instagram). **Setup personnel actuel** : *"most of my work I do from my phone"* (iOS exclusif), 5-10 sessions, *"a few hundred agents going, a few thousand at night."* Nouvelle primitive : **`/loop`** — Claude utilise cron pour planifier des jobs récurrents (toutes les minutes, 5 minutes, jour). Exemples : PR babysitter (fixe CI, rebase auto), CI healthkeeper (corrige les flaky tests), Twitter clusterer (regroupe feedback toutes les 30 min). **Routines** = équivalent serveur, fonctionne laptop fermé. *"Loops are the future."* **Vision SaaS** : pas d'apocalypse, mais réordonnancement via le framework **7 Powers de Hamilton Helmer**. *Switching costs* et *process power* deviennent **moins importants** (le modèle hill-climbe les processus avec 4.7) ; *network effects*, *scale economies*, *cornered resources* restent **inchangés**. Prédiction : ***"the number of startups disrupting in the next 10 years will increase 10×."*** Best time to build. **Analogie pivot** : la **presse de Gutenberg**. 1400s Europe : 10% littéracie, scribes employés par rois illettrés. Cinquante ans après : plus de littérature publiée que dans les mille ans précédents, livre 100× moins cher. Quelques siècles plus tard : 70% littéracie. *"Software will be similarly democratized, but faster than 50 years."* Phrase-pivot : *"The best person to write accounting software is not an engineer, it's a really good accountant."* **Pratique Anthropic** : *"We have no more manually written code anywhere at the company. Our Claudes are talking all day over Slack to other people's Claudes."* L'avantage Anthropic n'est pas technologique (mêmes modèles que tout le monde), mais **organisationnel**. À mesure que le modèle s'aligne, le **harness devient moins important** — prompt injection, permission modes, human-in-the-loop : *"all this kind of stuff is just going to be less important."* Produits à venir : Claude Design, loops/batch first-class, computer use.

Lattice — Composable AI skills that teach assistants structured thinking (design-first, context-aware, architecture-guided)

Tue, 05 May 2026 00:00:00 GMT

`techygarg/lattice` est un framework open-source MIT de skills composables conçu pour *"installer une engineering discipline dans n'importe quel assistant IA de code"* (Claude Code, Cursor). Le repo expose un diagnostic concis : *"les assistants IA sautent directement au code, prennent silencieusement des décisions de design, oublient les contraintes en cours de conversation, et produisent du code que personne ne review contre des standards réels."* Lattice répond par trois principes-aphorismes : **Skills over prompts** (fichiers versionnés team-owned > prompts personnels), **Composability over monoliths** (skills mono-purpose composables > documents exhaustifs), **Living context over static config** (le dossier `.lattice/` *"grows smarter across feature cycles"*). L'originalité conceptuelle réside dans l'**architecture trois-tiers** : - **Atoms** : guardrails mono-principe couvrant clean code, architecture, DDD, secure coding, test quality, design-first. - **Molecules** : workflows multi-étapes composant les atoms — design, implement, refactor, fix, review. - **Refiners** : interviews guidées produisant des standards projet-spécifiques qui customisent le comportement des atoms pour un team donné. Le pipeline canonique séquence `lattice-init` → `design-blueprint` → `code-forge` → `review`, avec `refactor-safely` et `bug-fix` en écarts. La commande `/design-blueprint` impose un *five-level progressive design approach* — design-first comme convention non négociable. Le dossier `.lattice/` accumule *project standards, décisions, review insights* en mémoire vive du projet. Installation soit via plugin Claude Code (`/plugins marketplace add techygarg/lattice`) compatible Cursor, soit via clone + script shell `install.sh`. Documentation dense (Origin Story, How It Works, Practical Guide, Configuration Reference, Framework Intelligence, Collaborative Judgment) prolongée par une **série d'articles sur martinfowler.com** sur cinq *collaboration patterns* — même réseau éditorial que **Böckeler** (*Harness engineering for coding agent users*, 2026-04-02) et **Fowler** (*Thoughtworks Retreat*, 2026-02-13). Lattice s'inscrit dans la **convergence doctrinale 2026** des skills frameworks pour coding agents, aux côtés de Vincent *Superpowers* (2026-04-02), Anthropic *Skills* (2025-10-16), Curran *Skills-Based Plugin Architecture* (Intercom 2026-04-16), Habert *PROJ-AI* (WEnvision 2026-05-05), Wescale *Usine Logicielle Augmentée* (2026-05-03) et — convergence la plus forte du corpus sans lignage déclaré — **Compound Engineering** (Every, Shipper/Klaassen 2025-12-11) : pipelines isomorphes (`lattice-init → design-blueprint → code-forge → review` ↔ `ce:brainstorm → ce:plan → ce:work → ce:review`), living context layer (`.lattice/` ↔ `docs/plans/+solutions/+brainstorms/`), trois principes Lattice cartographiables sur trois choix doctrinaux CE. Comparé à Vincent (130k+ stars, mature), Lattice (18 stars) propose une **architecture plus formelle** (atoms/molecules/refiners) et un **design-first explicite** comme niveau zéro. Limites : repo encore jeune, validation d'adoption massive non établie, auteur peu documenté institutionnellement, code 100% shell. Mais positionnement adulte : c'est de la doctrine packagée et installable en plugin, pas un prototype hâtif. Pièce utile pour qui veut comparer des architectures de skills entre approches FR (PROJ-AI, Wescale) et anglo-saxonnes (Lattice, Superpowers).

The New SDLC With Vibe Coding — From ad-hoc prompting to Agentic Engineering

Fri, 01 May 2026 00:00:00 GMT

Ce whitepaper Google (premier volet d'une série, signé Addy Osmani, Shubham Saboo et Sokratis Kartakis, mai 2026) soutient que la transformation la plus profonde de l'ingénierie logicielle n'est pas technologique mais interfacielle : on passe de l'écriture de code à l'expression d'intention, en confiant à des systèmes intelligents la traduction de cette intention en logiciel fonctionnel. Données de cadrage : 85 % des développeurs professionnels utilisent régulièrement des agents de codage, 51 % quotidiennement, et 41 % du nouveau code est généré par IA. Les auteurs refusent l'opposition binaire vibe coding / agentic engineering au profit d'un **spectre**. Le différenciateur n'est pas l'usage de l'IA mais la quantité de structure, de vérification et de jugement humain qui entoure sa production. Distinction clé : les **tests** vérifient le déterministe, les **evals** (datasets étiquetés, grilles, LM judges) vérifient le non-déterministe — sans les deux, on reste en vibe coding. La compétence centrale devient le **context engineering** : la qualité dépend moins du prompt que du contexte fourni. Six types de contexte (instructions, knowledge, memory, examples, tools, guardrails) se répartissent entre contexte **statique** (toujours chargé, coûteux : AGENTS.md, CLAUDE.md, GEMINI.md) et **dynamique** (à la demande, efficient). Les **Agent Skills** sont le pattern phare du contexte dynamique par progressive disclosure. Le SDLC est compressé de façon inégale : l'implémentation passe de semaines à heures, mais requirements, architecture et vérification restent au rythme humain. L'architecture demeure la phase la plus humaine (arbitrages de compromis). Côté implémentation, gains de 25-39 % mais nuance de l'étude METR (devs 19 % plus lents sur certaines tâches). Le fil conducteur est le **modèle de l'usine** : le livrable du développeur n'est plus le code mais le système qui le produit (specs, agents, quality gates, boucles de feedback, guardrails). Au cœur de l'usine, l'équation **Agent = Modèle + Harness** : le modèle pèse ~10 %, le harness ~90 % (instructions, outils/MCP, sandboxes, orchestration, hooks, observabilité). Preuve : sur Terminal Bench 2.0, changer le seul harness fait passer un agent hors Top 30 au Top 5. *« Most agent failures are configuration failures. »* Le développeur oscille entre **conductor** (temps réel, in-IDE) et **orchestrator** (async, multi-agents), confronté au **problème des 80 %**. Économiquement, le vibe coding (low CapEx/high OpEx) finit 3-10× plus cher par feature que l'agentic engineering (high CapEx/low OpEx) ; le context engineering et le model routing sont des leviers financiers. Conclusion : *« Generation is solved. Verification, judgment, and direction are the new craft. »*

Andrej Karpathy: From Vibe Coding to Agentic Engineering

Wed, 29 Apr 2026 00:00:00 GMT

Andrej Karpathy — co-fondateur d'OpenAI, ex-architecte de l'Autopilot Tesla et créateur du terme *vibe coding* — déclare lors de cette interview qu'il **ne s'est jamais senti aussi en retard comme programmeur**. Le point de bascule : décembre 2025. Pendant un break, il observe que les *chunks* de code générés par les nouveaux modèles sortent justes du premier coup ; il cesse de corriger, fait confiance, vibe-code en continu. Sa conclusion : ceux qui ont expérimenté l'IA en 2024 comme un avatar de ChatGPT doivent **regarder à nouveau** — quelque chose a changé fondamentalement dans le workflow agentique cohérent. Karpathy formalise sa taxonomie **Software 1.0 / 2.0 / 3.0** : code explicite, puis poids appris via datasets, puis **prompting comme programmation** d'un LLM-interpréteur. Deux exemples illustrent la rupture. **openclaw** : au lieu d'un shell script bloated qui couvre toutes les plateformes, l'installation est un texte à copier-coller dans l'agent qui débuggue en boucle. **MenuGen** : son app vibe-codée sur Vercel pour générer des images de plats devient obsolète quand il découvre qu'on peut donner la photo du menu directement à Gemini en demandant à Nanobanana d'overlayer les plats — pas d'app entre l'image input et l'image output. *"That app shouldn't exist."* Leçon : ne pas penser l'IA comme accélération du paradigme existant mais comme **possibilités neuves** (ex. LLM Knowledge Bases). Sa théorie de la **verifiability** explique pourquoi les LLMs restent *jagged* : les labs entraînent en RL sur domaines verifiable (math, code), créant des pics de capacité et des creux ailleurs. Anecdote-marqueur : Opus 4.7 refactorise 100k lignes mais conseille de marcher 50m jusqu'au lavage de voiture. Conseil aux fondateurs : viser des domaines verifiable où l'on peut créer ses propres RL environments et fine-tuner. Karpathy distingue **vibe coding** (raise the floor — démocratisation) et **agentic engineering** (preserve the quality bar — discipline ingénieur pour coordonner des agents *spiky/stochastiques*). Le 10x engineer est *magnifié bien au-delà de 10x*. Le hiring doit être refondé : finis les puzzles, place aux gros projets adversariels (Twitter clone agent vs agents red team). Les agents sont des **interns** avec recall excellent mais sans *taste* — l'humain reste en charge de l'esthétique, du design, de la spec. Karpathy refuse la métaphore animale : on ne *construit pas des animaux, on convoque des fantômes* — circuits statistiques, pas vie. Il appelle à une **infrastructure agent-native** (sensors/actuators, docs pour agents, déploiement par prompt). Formule de clôture : ***"You can outsource your thinking but you can't outsource your understanding."*** L'humain reste le *bottleneck* de la compréhension qui dirige le système.

the 2026 ai engineer roadmap

Wed, 29 Apr 2026 00:00:00 GMT

Rohit (@rohit4verse) publie sur X un thread-manifeste qui se présente comme *"the 2026 AI engineer roadmap"*. La thèse centrale est économique : en 2026, l'écart de salaire entre un *prompt engineer* (qui assemble des wrappers GPT) et un *systems architect* (qui livre des systèmes autonomes en production) atteint 150k$. Le marché serait saturé de couches fines au-dessus de GPT — *"features waiting to be sherlocked by big tech"*. Pour devenir indispensable, il faut construire profond : orchestration, mémoire, inférence locale. Le thread propose un blueprint en 5 projets de portfolio classés par complexité, avec pour chacun les décisions architecturales clés. **Projet 1 — AI mobile app avec SLM (beginner)** : app offline-first avec petits modèles. Prouve la maîtrise edge AI : lazy loading models, sliding window + semantic chunking, dynamic quantization (4-bit anciens devices, 8-bit récents), battery optimization, offline-first sync chiffré. **Projet 2 — Self-improving coding agent (intermediate)** : agent autonome qui code, teste, apprend de ses échecs. *"A chatbot waits for a prompt. An agent waits for a goal. The difference is the loop."* Boucle plan-execute-test-reflect, sandboxing, memory hierarchy (short-term / long-term / failure memory), reflection mechanism par vector similarity, code safety par static analysis. **Projet 3 — Cursor but for video editors (advanced)** : *"text is the past, vision and video are the present."* Fork d'éditeur open-source (Shotcut suggéré), agent multimodal qui comprend l'intent ("make this cinematic"), traduit en paramètres concrets (LUT, gaussian blur, dramatic cues), détecte les scènes, génère un edit decision list, propose un undo avec reasoning. **Projet 4 — Personal life OS agent (expert)** : *"an agent that forgets is useless; an agent that knows your life is a partner."* Knowledge graph personnel construit en continu (calendar, finance, health), proactive monitoring (anomalies détectées toutes les 6h), value alignment explicite, privacy architecture (encryption at rest, offline-capable), predictive planning, transparent reasoning avec citations data points. **Projet 5 — Autonomous enterprise workflow agent (master)** : *"the final boss of ai engineering."* Agent qui pilote des workflows business end-to-end. Event-driven (Slack/Jira), multi-agent delegation, self-healing avec circuit breaker, audit trail immuable, RBAC, observability complète, human-in-the-loop, workflow learning post-completion, cost management. Le thread se conclut sur un slogan darwinien : *"the replaceable: building wrappers. the unfireable: shipping autonomous systems."* Appel à shipper le weekend, documenter en public, tag l'auteur pour amplification. Format growth-hacker assumé. À lire comme **inventaire architectural** des patterns 2026 (edge AI, agentic loops, multimodal, deep context, multi-agent orchestration), pas comme étude. La densité d'aphorismes — *"sherlocked"*, *"unfireable"*, *"final boss"* — trahit l'intention virale, mais le contenu technique recoupe le consensus 2026 (Karpathy, Sierra, Stripe Minions, Anthropic).