Vibe Coding : comment les ingénieurs deviennent curateurs et éditeurs

Ce que signifie « vibe coding » (sans le battage)

« Vibe coding » désigne un flux de travail précis : vous décrivez ce que vous voulez en langage naturel, un assistant IA rédige du code, et vous orientez le résultat jusqu'à ce qu'il corresponde à votre intention. L'IA effectue une implémentation rapide en première passe ; vous prenez en charge la direction, la sélection et la vérification.

L'idée clé n'est pas une productivité magique, mais un déplacement du temps investi. Plutôt que de passer l'essentiel de votre énergie à taper du boilerplate, raccorder des endpoints ou rappeler des patterns connus, vous passez plus de temps à façonner la solution : clarifier les exigences, choisir des compromis et garantir que le code final est adapté à votre produit.

D'implémenteur à curateur/éditeur

En vibe coding, l'ingénieur joue davantage le rôle de :

• Un curateur : choisir la meilleure approche parmi plusieurs brouillons
• Un éditeur : resserrer la logique, le nommage, la structure et les cas limites
• Un juge : décider ce qui est acceptable à livrer (et ce qui ne l'est pas)

Ce changement de rôle est subtil mais important. L'IA peut générer vite, mais elle peut aussi se tromper, mal comprendre des contraintes ou produire du code qui « a l'air juste » tout en échouant en production. Le gain vient du drafting, pas de la responsabilité.

Poser les attentes tôt

Le vibe coding fonctionne mieux si vous traitez la sortie de l'IA comme un point de départ, pas comme la clé de la réponse. Vous restez propriétaire de :

• La correction et la qualité
• Les décisions de sécurité et de confidentialité
• L'adaptation à votre base de code et à vos standards

Pour qui est-ce utile

Ce flux est particulièrement utile aux équipes produit, aux startups et aux développeurs solo qui doivent itérer rapidement—livrer de petites parts, apprendre du feedback et affiner en continu—sans prétendre que la génération de code supprime le jugement d'ingénierie.

D'implémenteur à curateur : le changement de rôle central

Le grand changement du vibe coding n'est pas que les ingénieurs « arrêtent de coder ». C'est que le centre de gravité passe de la saisie de lignes à la mise en forme des résultats.

La boucle ancienne : écrire → tester → refactorer

Traditionnellement, l'ingénieur produisait la plupart du premier brouillon. Vous conceviez l'approche, l'implémentiez ligne par ligne, l'exécutiez, répariez les erreurs puis refactorisiez jusqu'à obtenir du code lisible et maintenable. Le clavier était le goulot d'étranglement—et le signal le plus visible de progrès était souvent « maintenant il y a plus de code qu'avant ».

La nouvelle boucle : spécifier l'intention → générer des brouillons → juger et orienter

Avec la programmation assistée par IA, le premier brouillon devient bon marché. Votre travail se déplace vers :

• Spécifier l'intention clairement : ce que le code doit faire, ce qu'il ne doit pas faire, les cas limites, les contraintes et comment mesurer le succès.
• Curater les options : choisir entre plusieurs approches générées (plus simple, plus sûre, plus rapide, plus maintenable).
• Éditer avec jugement : intégrer les bonnes parties, supprimer les raccourcis risqués, aligner sur les conventions et rendre la conception cohérente.

Ce changement s'accélère parce que les outils deviennent enfin accessibles : meilleurs modèles, boucles de rétroaction plus rapides et interfaces qui rendent l'itération conversationnelle plutôt qu'un cycle compiler/exécuter.

Ce qui ne change pas : la responsabilité

Même si une IA écrit 80 % des caractères, l'ingénieur reste responsable du résultat. Vous êtes redevable de la correction, de la sécurité, des performances et de la sûreté—en particulier des éléments « ennuyeux » que les outils oublient souvent : gestion des erreurs, conditions aux limites, validation des données et interfaces claires.

Le vibe coding récompense les ingénieurs capables de prendre des décisions tranchées : « Est-ce la bonne solution pour notre système ? » ou « Est-ce que je ferais confiance à ça en production ? » Ce jugement—et non la vitesse de frappe brute—devient le différenciateur.

Où l'IA aide le plus — et où elle échoue généralement

La programmation assistée par IA excelle quand la « forme » du code est connue et que l'objectif principal est la vitesse. Elle est moins performante quand le travail réel consiste à déterminer ce que le logiciel doit faire dans des situations métier complexes.

Là où l'IA produit de bons brouillons

Quand vous pouvez décrire la tâche clairement, l'IA peut fournir des premiers jets solides—souvent plus vite que partir d'un fichier vide.

• Boilerplate et scaffolding : création d'un nouvel endpoint, structure de module de base, fichiers de configuration, handlers CRUD.
• Glue code : adapter le modèle de données d'une API à une autre, déplacer des données entre couches, brancher des clients.
• Tests (surtout simples) : tests unitaires pour le « happy path », tests table-driven, assertions de type snapshot.

Dans ces domaines, le vibe coding peut sembler « magique » car le travail consiste largement à assembler des patterns familiers.

Là où il échoue souvent

L'IA hésite quand les exigences sont implicites, spécifiques au domaine ou pleines d'exceptions.

• Cas limites : retries, timeouts, problèmes de concurrence, pannes partielles, erreurs d'index.
• Exigences implicites : les règles du type « bien sûr il faut… » qui vivent dans la tête de quelqu'un ou dans un vieux ticket.
• Règles métier : logique de tarification, permissions, contraintes de conformité, tout ce qui est lié à la sémantique métier.

Un modèle peut paraître confiant tout en inventant des contraintes, mal lisant la forme des données ou choisissant une bibliothèque incompatible avec votre stack.

Temps de frappe vs temps d'éditeur

L'IA réduit le temps de frappe (mettre du code à l'écran). Mais elle peut augmenter le temps d'édition—relire, clarifier les exigences, exécuter les tests, déboguer et resserrer le comportement.

Le gain de productivité est réel quand les équipes acceptent l'échange : moins de frappes, plus de jugement. Le travail de l'ingénieur devient « prouver que ça marche, que c'est sûr et que ça correspond à ce dont on a besoin ».

Le prompt comme spécification : comment demander le bon code

Traitez votre prompt comme une spécification légère. Si vous voulez du code prêt pour la production, ne demandez pas « une implémentation rapide ». Demandez un changement avec un objectif clair, des limites et un moyen de vérifier le succès.

Commencez par objectif + contraintes + critères d'acceptation

Démarrez par ce que doit faire la fonctionnalité, ce qu'elle ne doit pas faire et comment vous saurez qu'elle est terminée. Incluez des contraintes comme les limites de performance, les environnements supportés et les exigences de non-régression (compatibilité ascendante, routes existantes, stabilité des schémas).

Un schéma utile :

• Objectif : « Ajouter un endpoint pour créer des factures. »
• Contraintes : « Node 20, Postgres, pas de nouvelles dépendances, respecter notre format d'erreur. »
• Critères d'acceptation : « Renvoie 201 avec l'ID de la facture ; rejette les items invalides avec 400 ; idempotence via requestId. »

Demandez des incréments petits : plan → brouillon → affiner

Les gros prompts invitent aux grosses erreurs. Itérez plutôt en petites étapes :

1. Plan : demander une liste d'étapes et les fichiers touchés.
2. Brouillon : générer le code minimal pour une étape.
3. Affiner : resserrer les types, la gestion d'erreurs et le nommage.

Cela vous garde en contrôle et rend la revue simple.

Fournissez du contexte (et des exemples)

L'IA produit de meilleurs résultats quand elle peut « voir » votre univers. Partagez les APIs existantes, les règles de style et la structure des fichiers attendue. Quand c'est possible, incluez des exemples :

• Entrées/sorties types (payloads, query params)
• Cas d'erreur attendus et messages
• Cas limites (listes vides, doublons, timeouts)

Terminez chaque boucle par une checklist

Clôturez chaque itération en demandant un auto-audit :

• Tests mis à jour/ajoutés (et lesquels)
• Cas limites traités
• Notes de sécurité (auth, injection, secrets)
• Docs ou commentaires mis à jour

Le prompt devient le contrat—votre revue consiste à vérifier que le contrat est respecté.

Éditer et curer : transformer un brouillon en code de production

Le code généré par l'IA est surtout une proposition : un premier jet rapide qui nécessite un éditeur. Votre travail passe de « écrire chaque ligne » à « décider ce qui mérite d'être conservé », « prouver que ça marche » et « l'adapter à la base de code ». Les équipes rapides n'acceptent pas la sortie brute—elles la curent.

Traitez la sortie comme une pull request

Lisez la sortie IA comme vous reliriez la PR d'un collègue. Demandez-vous : cela correspond-il à notre architecture, notre nommage et notre gestion d'erreurs ? Si quelque chose semble flou, supposez que c'est faux tant que ce n'est pas vérifié.

Utilisez des diffs et des commits petits et focaux pour rendre les changements compréhensibles. Plutôt que de coller une réécriture de 300 lignes, appliquez une série de commits ciblés : renommage + restructuration, puis changement de comportement, puis cas limites. Cela facilite le repérage et le revert éventuel.

Éditez en place avec des « questions » pour le modèle

Quand vous voyez des zones risquées, ajoutez des commentaires inline et des questions pour l'IA. Exemples : « Que se passe-t-il si cette API retourne null ? », « Cette boucle de retry est-elle bornée ? », « Peut-on éviter une allocation dans le hot path ? » Cela concentre l'itération sur le code plutôt que sur une conversation vague.

Gardez une checklist d'éditeur

Une courte checklist évite les revues « ça a l'air bien » :

• Nommage : cohérent avec les modules et le vocabulaire du domaine
• Logique : flux de contrôle correct, pas de conditions dupliquées
• Gestion d'erreurs : messages utiles, fallback sûr, pas d'exceptions avalées
• Logs/métriques : actionnables, pas bruyants
• Frontières : timeouts, validation d'entrée, limites sur retries et boucles

Savoir quand arrêter d'itérer

Si vous passez plusieurs tours de prompts à patcher une fonction embrouillée, arrêtez et réécrivez manuellement cette partie. Une réécriture propre est souvent plus rapide—et produit du code que vous pourrez maintenir avec confiance le mois suivant.

Contrôle qualité : tests, vérifications et « définition du terminé »

L'IA peut vous amener à « ça tourne » rapidement. Le changement professionnel est d'exiger « c'est vérifié ». Traitez le code généré comme un brouillon jusqu'à ce qu'il atteigne le même niveau d'exigence que celui d'un coéquipier.

Passer de la sortie à la preuve

Un bon flux de vibe coding produit des artefacts fiables : tests, gestion d'erreurs explicite et une checklist répétable. Si vous ne pouvez pas expliquer comment vous savez que c'est correct, ce n'est pas fini—c'est de la chance.

Tests : avant quand c'est possible, immédiatement après sinon

Quand les exigences sont claires (entrées, sorties, contraintes), écrivez les tests d'abord. Cela donne une cible à l'IA et réduit les errances d'implémentation.

Quand les exigences sont floues, générez le code puis écrivez les tests immédiatement, tant que le contexte est frais. L'important est le timing : ne laissez pas du code « temporaire » non testé devenir permanent.

Attraper les cas limites volontairement

L'IA gère bien le happy path et oublie souvent les coins bizarres. Deux patterns pratiques aident :

• Tests table-driven : une liste de cas couvrant entrées typiques, limites et valeurs invalides.
• Tests basés sur les propriétés : au lieu de quelques exemples, on affirme une règle (ex. « le tri ne perd jamais d'éléments ») et on génère beaucoup d'entrées.

Ajouter des vérifications aux frontières

Placez des assertions et des validations là où le système rencontre le monde externe : requêtes API, parsing de fichiers et surtout écritures en base. Une mauvaise donnée laissée passer une fois coûte cher à long terme.

Définition du « terminé » (aussi pour le code généré)

Une checklist simple maintient la qualité :

• Tests passés localement et en CI
• Revue de code complétée (humaine + IA optionnelle)
• Docs/commentaires expliquant les décisions non évidentes
• Validation d'entrée et gestion d'erreurs en place

C'est ainsi que la vitesse reste soutenable.

Risques à surveiller : bugs, sécurité et conformité

Le vibe coding peut sembler rapide car il produit du code plausible vite. Le risque est que « plausible » n'est pas synonyme de « correct », « sûr » ou « autorisé ». Traitez la sortie IA comme un brouillon non fiable qui doit mériter sa place dans la base de code.

Bugs subtils et mauvaises hypothèses

L'IA échoue souvent de manière discrète : off-by-one, cas limites manquants, mauvaise gestion des erreurs, problèmes de concurrence qui n'apparaissent qu'en charge. Elle peut aussi faire des hypothèses erronées sur votre architecture—par exemple attendre un service synchrone, supposer qu'une table existe, ou inventer une fonction utilitaire qui n'existe pas.

Un échec fréquent est les APIs hallucinées : le code compile dans l'imagination du modèle, pas dans votre dépôt. Surveillez les noms de méthodes « presque bons », l'usage de bibliothèques obsolètes et les patterns dépréciés.

Pièges de sécurité et de confidentialité

Le code IA peut introduire des configurations peu sûres (choix cryptographiques faibles, contrôles d'autorisation manquants, désérialisation dangereuse, CORS permissif). N'acceptez pas de changements sensibles sans revue ciblée et, si possible, des scans automatisés.

La confidentialité est plus simple : ne copiez pas de secrets, tokens ou données clients dans les outils publics, sauf si votre organisation l'autorise explicitement. Si nécessaire, anonymisez ou utilisez des outils internes approuvés.

Conformité, licences et règles d'escalade

Connaissez la politique de votre org sur la provenance du code et les licences—surtout pour des extraits générés ressemblant à des exemples publics. Pour les changements à fort impact (flux d'auth, paiements, infra, migrations de données), définissez une règle d'escalade : second reviewer obligatoire, exécution de la suite complète de tests et, le cas échéant, un modèle de menace léger avant merge.

Flux d'équipe : rendre le vibe coding reproductible

Le vibe coding réussit mieux comme processus d'équipe, pas comme astuce individuelle. L'objectif est de rendre la sortie IA prévisible, relisable et facile à améliorer—pour que la base de code ne devienne pas un tas de « code mystère ».

Une boucle simple et cohérente

Utilisez le même workflow pour la plupart des tâches :

brief de tâche → brouillon IA → édition humaine → tests

Le brief est la clé. Il doit définir entrées/sorties, contraintes et critères d'acceptation en langage clair (et pointer les fichiers pertinents). Ensuite l'IA produit une première passe, un humain rend le code prêt pour la production : nommage, structure, cas limites, gestion d'erreurs et compatibilité avec les patterns existants. Enfin, tests et vérifications confirment le comportement.

Garder le travail petit et relisible

Découpez les tâches en tranches petites et relisables. Les PRs plus petites facilitent la détection des mauvaises hypothèses, régressions subtiles et styles incohérents. Si l'IA propose une grosse refactorisation, fractionnez-la : d'abord ajouter des tests, puis changer le comportement, puis nettoyer.

Exiger du raisonnement, pas que du code

Pour réduire le « nonsense confiant », demandez des explications avec le brouillon :

• « Pourquoi cette approche ? »
• « Quels sont les compromis ? »

Cela donne aux reviewers des éléments concrets à évaluer (performance, complexité, maintenabilité) avant de débattre des détails d'implémentation.

Rendre l'IA visible dans vos PRs

Notez l'influence de l'IA dans la description des PRs. Pas comme un badge, mais comme contexte : ce qui a été généré, ce qui a été édité et ce que vous avez vérifié. Cela améliore la qualité des revues et construit une intuition partagée sur la fiabilité des suggestions IA.

Standardiser ce qui peut l'être

Créez des templates de prompt réutilisables pour les tâches récurrentes (nouvel endpoint, migration de données, commande CLI, ajout de tests). Les templates transforment les habitudes d'une personne en un actif d'équipe—et rendent les résultats plus cohérents selon les reviewers et les dépôts.

Nouvelles compétences plus importantes que la vitesse de frappe

L'IA peut produire beaucoup de code vite. Le différenciateur n'est pas la vitesse de frappe : c'est la capacité à orienter, évaluer et intégrer ce qui est généré.

Penser en système, pas en extraits

Le vibe coding favorise les ingénieurs qui modélisent l'ensemble du système : flux de données, frontières et modes de défaillance. Quand vous décrivez où l'état vit, comment les requêtes traversent les services, ce qui arrive en cas de timeouts et ce qu'est une mauvaise entrée, vous pouvez guider l'IA vers du code qui colle à la réalité, pas juste au happy path.

Lire devient la nouvelle vitesse

Savoir lire rapidement est une super-puissance. Les sorties IA peuvent sembler plausibles tout en manquant l'intention : cas limites erronés, bibliothèques mal utilisées, abstractions qui fuient ou types mal appariés. Le travail consiste à repérer rapidement les écarts entre la spécification et ce que le code fait réellement.

Débogage et observabilité gagnent toujours

Quand le code généré échoue, il faut localiser le problème : des logs qui répondent aux questions, des métriques qui montrent les tendances et des traces qui révèlent les goulots. L'IA peut proposer des corrections, mais il faut la discipline pour reproduire les problèmes, inspecter l'état et vérifier les résultats.

La communication devient du travail d'ingénierie

Des exigences claires, des prompts précis et des narratives de PR soignées réduisent le retravail. Documentez les hypothèses, listez les critères d'acceptation et expliquez le « pourquoi » dans les revues. Cela facilite la validation de la sortie IA et l'alignement des coéquipiers.

Le goût et le jugement : le multiplicateur caché

La cohérence, la simplicité et la maintenabilité n'apparaissent pas par hasard. Les curateurs font respecter les conventions, suppriment la complexité inutile et choisissent la solution la plus ennuyeuse qui survivra au changement. Ce jugement—plus que des frappes—détermine si le vibe coding vous accélère ou crée un coût à long terme.

Pile d'outils : ce qui complète le code généré par l'IA

L'IA peut générer du code vite, mais elle ne garantit ni cohérence, ni sécurité, ni maintenabilité. Les équipes qui progressent traitent le modèle comme un générateur et leur outillage comme des garde-fous pour aligner la sortie sur les standards de production.

Garde-fous : automatiser le basique

Commencez par des outils qui font respecter les conventions sans débat :

• Associer l'IA à formatters, linters et vérification de types (ex. Prettier/ESLint, Black/Ruff, ou TypeScript strict). Exécutez-les à la sauvegarde et en CI pour que le style et les erreurs évidentes n'atteignent jamais la revue.
• Utilisez l'analyse statique là où elle convient à votre stack. Elle aide particulièrement à attraper les chemins null/undefined, APIs dangereuses et code mort qu'un LLM pourrait introduire.

Sécurité et dépendances : faire confiance mais vérifier

L'IA importe volontiers des packages ou copie des patterns obsolètes.

• Ajoutez du scanning des dépendances et des alertes de vulnérabilité en CI. Traitez les nouvelles dépendances comme une demande de changement : justifiez-les, figez les versions et préférez des bibliothèques établies.
• Incluez le scanning des secrets et des règles de hardening de base (pas de credentials dans le code, pas de désérialisation non sécurisée, etc.).

Workflow de revue : mettre des humains où ça compte

Utilisez les outils de PR pour concentrer l'attention sur les risques :

• Exploitez les outils de revue de PR et CODEOWNERS pour les zones sensibles (auth, paiements, export de données). Routez automatiquement ces changements vers les bons reviewers.
• Encouragez les revues assistées par IA, mais exigez une validation humaine pour les modules critiques.

Templates et « exemples dorés »

Réduisez la variance en donnant un chemin au modèle :

• Adoptez des templates pour scaffolds de tests, gestion d'erreurs et logging. Quand l'IA génère du code, il doit s'insérer dans ces patterns.
• Conservez un dossier d'exemples dorés : petites implémentations de haute qualité que vous pointez dans les prompts (« respecte ce style et cette structure »).

Le choix de la plateforme compte

Où vous exécutez le vibe coding influence ce que vous pouvez standardiser. Par exemple, des plateformes comme Koder.ai enveloppent le workflow chat-driven avec des contrôles d'ingénierie pratiques : mode planning (pour revoir un plan avant génération), export du code source (pas de verrouillage), snapshots/rollback (pour revert facile). Si votre équipe génère des frontends React, des services Go/Postgres ou des apps Flutter, avoir les conventions de stack intégrées au workflow réduit la variance des brouillons IA.

L'objectif n'est pas plus d'outils, mais une pipeline fiable où la sortie IA est immédiatement formatée, vérifiée, scannée et relue comme n'importe quel autre changement.

Plan d'adoption : commencer petit, mesurer et standardiser

Déployer le vibe coding marche mieux comme une expérimentation observable—pas un mandat massif. Traitez-le comme l'introduction d'un nouveau système de build : choisissez une zone bornée, définissez les attentes et mesurez si ça améliore les résultats.

1) Choisir un pilote à faible blast radius

Commencez là où les erreurs sont peu coûteuses et le retour rapide. Bons candidats : outils internes, un petit service aux entrées/sorties claires, ou un composant UI autonome.

Règle utile : si vous pouvez revert rapidement et valider le comportement avec des checks automatisés, c'est un bon pilote.

2) Écrire des guidelines légères avant de commencer

Les équipes vont plus vite quand ce qui est autorisé est explicite. Gardez la première version courte et pratique :

• Quelles tâches peuvent utiliser l'assistance IA par défaut (scaffolding, refactors, génération de tests)
• Ce qui nécessite une revue supplémentaire (auth, paiements, accès aux données, code sensible)
• Ce qui ne doit jamais être délégué (gestion des secrets, copie de code sous licences inconnues)

Si vous avez déjà des standards d'ingénierie, liez-les et ajoutez un addendum plutôt que tout réécrire (ex. « le code généré IA doit respecter le même barême de revue et de tests »).

3) Mesurer des résultats, pas des impressions

Choisissez quelques métriques pendant le pilote :

• Cycle time (idée → merge)
• Défauts échappant en staging/production
• Temps de revue et nombre d'itérations de revue
• Taux de révision (fixes dans les 1–2 semaines)

L'objectif est d'apprendre où l'IA aide et où elle crée des coûts cachés.

4) Faire des rétros courtes et extraire des patterns

Après chaque sprint (ou chaque semaine), collectez des exemples :

• Prompts ayant produit du code propre et correct
• Modes d'échec (hypothèses erronées, cas limites manquants, style incohérent)
• Checks ayant détecté des problèmes tôt

Transformez cela en templates de prompt réutilisables, checklists de revue et avertissements « ne faites pas ceci ».

5) Publier un playbook partagé et standardiser

Documentez vos apprentissages dans un endroit central (ex. /engineering/playbook). Incluez :

• Workflows approuvés (draft → tests → review)
• Patterns et antipatterns de prompt
• Validations requises (votre Definition of Done)

Quand le pilote est positivement constant, étendez à la zone suivante—sans baisser le niveau de qualité.

Si vous utilisez un environnement hébergé de vibe coding (comme Koder.ai), la standardisation est souvent plus simple car le workflow est déjà structuré autour d'étapes répétables (plan, générer, relire, déployer), avec déploiement/hébergement et domaines personnalisés quand vous voulez passer du prototype à la production.

Conclusion : le travail de l'ingénieur devient direction et jugement

Le vibe coding ne retire pas les ingénieurs de la boucle—il change ce que signifie « être dans la boucle ». Le travail à fort effet passe de la saisie de chaque ligne à décider quoi construire, contraindre comment c'est construit et vérifier que le résultat est sûr, correct et maintenable.

De l'écriture de code à l'orientation des résultats

Quand l'IA peut rédiger rapidement des implémentations, votre avantage est le jugement : choisir la bonne approche, repérer les cas limites subtils et savoir quand ne pas accepter une suggestion. Vous devenez le curateur de l'intention et l'éditeur du résultat—guidant le modèle avec des contraintes claires, puis façonnant le brouillon pour qu'il soit prêt pour la production.

La vitesse est réelle—les garde-fous sont non négociables

Oui, vous pouvez livrer plus vite. Mais la vitesse ne compte que si la qualité reste stable. Les garde-fous sont le travail : tests, contrôles de sécurité, discipline de revue et une définition claire du « terminé ». Traitez l'IA comme un junior rapide et infatigable : utile, infatigable et parfois confiant en se trompant.

Adopter une mentalité d'éditeur basée sur une checklist

Les vibe coders fiables ne « sentent » pas quand c'est fini—ils révisent systématiquement. Entraînez-vous à une checklist légère : correctitude (y compris entrées étranges), lisibilité, gestion d'erreurs, bases de performance, logging/observabilité, risque lié aux dépendances et attentes de sécurité/confidentialité.

Prochaines étapes simples pour concrétiser

Créez deux actifs réutilisables :

• Un template de prompt qui force la clarté : objectif, contexte, contraintes, interfaces, exemples et ce qu'il ne faut surtout pas faire.
• Une checklist de revue qui standardise les critères d'acceptation et réduit les validations « ça a l'air bien ».

Avec ces éléments, le travail devient moins une question de vitesse de frappe et plus une question d'orientation, de vérification et de goût—les parties de l'ingénierie qui prennent de la valeur dans le temps.