ai-engineering

16 posts

literate-programmingllmdocumentationai-engineering

Votre Thread avec Claude Est Déjà de la Documentation. Il Meurt Juste en Douze Heures.

Les conversations avec les LLM contiennent l'intention, les alternatives rejetées et le code fonctionnel. C'est exactement ce que la documentation devrait être. Voici comment transformer un chat éphémère en documentation durable et consultable sans perdre la narration.

Vous avez passé quarante-cinq minutes avec Claude à concevoir un circuit de réessai. Vous avez expliqué les modes de défaillance, rejeté le backoff exponentiel…
fagan-inspectionsllmcode-reviewai-engineering

Un LLM peut pré-inspecter votre code. Il ne peut pas animer la réunion.

Les inspections Fagan nécessitent quatre à six personnes et deux heures pour examiner 250 lignes. Un LLM peut réduire ce coût en gérant la préparation et le respect des checklists, mais il ne peut pas remplacer les rôles humains qui trouvent les défauts les plus coûteux.

Une inspection Fagan complète nécessite un modérateur, un lecteur, deux à quatre inspecteurs et l'auteur. L'équipe passe deux heures à examiner environ 250…
n-version-programmingimplementation-selectiondifferential-testingai-engineering

Cinq implémentations et aucune majorité : comment réellement choisir la meilleure

La programmation N-version a l'air simple : exécuter plusieurs implémentations et choisir la meilleure réponse. En pratique, 'meilleure' est bien plus difficile à définir que 'la plus commune'.

Vous avez cinq implémentations de la même fonction. Trois retournent le même résultat. Une est légèrement différente. Une lève une exception. Laquelle est…
n-version-programmingllmdiverse-implementationsai-engineering

Le même LLM peut écrire cinq versions de votre fonction. Voici comment les rendre réellement différentes.

La programmation N-version avec les LLM ne nécessite pas plusieurs modèles. Vous pouvez extraire des implémentations diverses et correctes d'un seul modèle en faisant varier les prompts, les personas et les contraintes de raisonnement.

La programmation N-version part du principe que la diversité vient d'auteurs différents. Avec les LLM, cela signifie des modèles différents, des fournisseurs…
ai-engineeringsoftware-architectureproductionai-codebaseteam-dynamics

Peur vs. Rouleau compresseur : Les deux réalités du codage IA

Le codage IA fonctionne pour les équipes d'élite capables de se relever de n'importe quel désastre. Tous les autres héritent de la peur, des échecs en CI et des expériences abandonnées. Le fossé ne vient pas du modèle.

Observez deux équipes utiliser le même modèle d'IA et vous verrez deux résultats complètement différents. La première équipe demande au modèle de construire un…
ai-engineeringsoftware-architectureproductionautotomyai-codebasebest-practices

Coder avec l'IA en production : pourquoi la plupart des équipes abandonnent

La plupart des équipes essaient le codage avec l'IA, livrent du code qui échoue en QA, et abandonnent. Le problème n'est pas le modèle — c'est l'absence de garde-fous qui rendent la sortie de l'IA digne de confiance.

La plupart des équipes qui essaient le codage avec l'IA suivent la même trajectoire. Elles commencent avec enthousiasme. Le modèle génère une fonctionnalité en…
ai-engineeringdeterministicguardrailscode-qualitystatic-analysisci

Fuck-u-code : le contrôle qualité déterministe que votre pipeline IA a oublié

Vous avez la vérification de types, le linting et les règles d'architecture. Mais votre stack déterministe est aveugle face à la complexité, à la duplication et aux catastrophes de nommage. Voici la solution à 0 $.

Soyons honnêtes sur ce à quoi ressemblent vraiment la plupart des pipelines de code IA en ce moment. Vous générez du code avec Cursor ou Claude Code. Vous…
ai-engineeringcode-reviewspecificationsliving-specificationsci

À l'ère de l'AI, le code review devient une revue des spécifications

Quand l'AI peut générer l'implémentation, les tests et les contracts à partir d'une spec, le travail humain le plus rentable remonte en amont. L'artefact qui demande le plus de rigueur, c'est la spécification elle-même.

Si vous shippez avec l'AI depuis plus de quelques semaines, vous connaissez probablement déjà cette sensation. Vous ouvrez une pull request. Le code est…
ai-engineeringsafety-stacktypesdesign-by-contractproperty-based-testingmutation-testing

La safety stack de l’AI: types, contracts, property tests et mutation gates

Si vous voulez que du code généré par AI tienne en production, le code review seul ne suffit pas. Il faut une safety stack en couches, des type constraints jusqu’au mutation testing et au runtime containment.

Le vrai danger du code généré par AI n’est pas qu’il soit toujours faux. Le vrai danger, c’est qu’il est souvent suffisamment plausible pour être mergé. C’est…
ai-engineeringsoftware-architectureautotomyproduct-developmentguardrails

Le Meteor development existe vraiment. Votre codebase n'a pas besoin de s'effondrer avec lui

Le meme fonctionne parce que les équipes développent réellement avec des cibles mouvantes, des échéances fixes et un périmètre à moitié défini. Autotomy ne corrige pas la planification fantaisiste, mais il évite que le développement s'arrête à chaque changement de route.

Appelons cela le Meteor development : la destination est annoncée d'abord, les arrêts changent en cours de route, le budget est supposé se débrouiller tout…
ai-engineeringsoftware-architecturestanfordcs146sguardrailsagentic-development

Stanford CS146S a raison sur l'AI coding. Le sujet manquant, c'est l'architecture

Cette critique de Stanford CS146S montre pourquoi le cours comprend bien l'AI coding, mais laisse encore de côté la leçon décisive d'architecture de l'AI sur les frontières du système et la remplaçabilité.

Stanford CS146S est le cours The Modern Software Developer, enseigné par Mihail Eric et lancé pour la première fois à l'automne 2025. Pour l'aperçu officiel du…
ai-engineeringsoftware-reliabilitydesign-by-contractproperty-based-testingmutation-testing

Pourquoi de grandes idées d’ingénierie sont restées de niche jusqu’à ce que l’AI les rende viables

Design by contract, property-based testing, mutation testing et model checking n’étaient pas de mauvaises idées. Elles demandaient trop d’expertise spécialisée pour être maintenues. L’AI change cette équation.

Le software engineering est rempli d’idées qui paraissent immédiatement justes dès qu’on les lit. Bien sûr que des contracts devraient définir ce qu’une…