The software engineering war

L'histoire personnelle de l'auteur sert de point de départ : cofondateur et CTO d'une startup, il vit un premier mois euphorique avec son associé (lui aux commandes technique, l'autre côté business), puis les tensions montent dès le deuxième mois. L'associé ne comprend pas pourquoi tout avance lentement « alors qu'on a des LLM », et veut pouvoir déployer en production depuis son téléphone sans relire le code, en misant sur la capacité des agents à corriger les bugs a posteriori. Sept mois plus tard, la société se sépare sans client payant et avec un produit à peine fonctionnel. Zaides résume : « il était un builder, j'étais un keeper — c'est le même combat que mène toute notre industrie en ce moment ».

Il replace ce clivage dans une histoire plus longue : le débat « on ship vite et sale » contre « on construit proprement » existe depuis quinze ans, opposant traditionnellement PM et ingénieurs. Ce qui a changé depuis 2023-2024, c'est que les builders ont désormais un outil concret — les agents de code — qui rend leur position crédible à l'échelle d'une équipe entière, pas seulement d'un individu. Dans son équipe de six personnes, la coupure est nette. Les builders ne regrettent pas de moins taper de code eux-mêmes, se lassent vite d'un refactor sans impact visible pour le client, et poussent des idées comme : le code deviendra bientôt illisible pour l'humain, l'idée prime sur l'exécution, un ingénieur sans sens produit est condamné. En face, les keepers défendent que les modèles produiront toujours des résultats fragiles, qu'ignorer le code mène au désastre, et que le « vibe coding » finira par couler des entreprises.

Le point le plus original de l'article porte sur la relativité de cette identité. Comme en politique, où l'on se définit autant par rapport aux autres que par ses propres opinions, Zaides observe qu'il est perçu comme un « keeper » pur face à son associé non-technique, mais plutôt comme un « builder » au sein de son équipe d'ingénieurs — lui qui n'a pas écrit de code depuis des mois et tire sa satisfaction de l'impact business plutôt que de la qualité du code. Il ajoute une seconde dimension : la position évolue dans le temps, et le vrai courage consiste à admettre s'être trompé sans pour autant renier son camp. Il illustre ce point avec DHH, longtemps porte-drapeau des keepers (« je sens la compétence s'écouler de mes doigts » quand il ne code pas lui-même), qui a ensuite publiquement reconnu que les modèles avaient franchi un cap et changé sa pratique.

Il conclut que les postures extrêmes sont les pires dans les deux sens : le builder qui vibe-code un système critique sans jamais rien lire, et le keeper qui, encore en 2026, refuse toute ligne de code écrite par un agent — tous deux s'accrochent à une opinion dépassée en refusant d'admettre qu'il y a une part de vérité dans l'autre camp. Avec le recul sur son propre échec de startup, il reconnaît qu'aucun des deux associés n'avait totalement raison, mais qu'il aurait pu se montrer plus flexible tant que l'entreprise n'avait aucun client.