L’article Why write code in 2026 défend l’idée que, malgré l’essor des agents IA et des outils automatisés, écrire du code reste essentiel pour les développeurs. L’auteur souligne que coder permet une compréhension directe de l’architecture logicielle, bien au-delà d’une simple lecture passive ou d’une supervision d’agents. Cette pratique favorise une meilleure attention aux détails, une réduction des erreurs et une amélioration de la qualité du code, évitant ainsi l’accumulation de "slop" (code bâclé) qui nuit aussi bien aux humains qu’aux agents.
L’auteur reconnaît que la plupart de son code est généré par IA, mais insiste sur le fait que l’écriture manuelle offre une expérience immersive et une maîtrise impossible à obtenir autrement. Il compare les agents IA à des stagiaires fraîchement embauchés, capables de suivre des instructions mais souvent limités par des descriptions imprécises ou des environnements mal structurés. Écrire du code permet de penser de manière algorithmique et de calibrer la précision nécessaire, contrairement à l’anglais, trop vague pour exprimer des computations complexes.
Enfin, l’article critique l’idée que les agents IA devraient être traités comme des compilateurs, ce qui justifierait la production de code médiocre. Au contraire, les développeurs doivent rester actifs dans le processus pour garantir la robustesse et la cohérence du logiciel. L’auteur cite l’exemple d’un choix d’architecture (local storage) qui, bien que fonctionnel, illustre comment une décision prise par un humain peut avoir des conséquences durables, soulignant l’importance d’une réflexion approfondie dans le développement.
L’article explore la vertu de la paresse en programmation, popularisée par Larry Wall dans Programming Perl, qui encourage la création d’abstractions pour simplifier le travail futur. L’auteur souligne que cette paresse intelligente, bien que semblant contre-intuitive, nécessite un effort intellectuel important pour concevoir des solutions élégantes et réutilisables. Cependant, il critique l’évolution récente où cette notion a été détournée par une culture de productivité superficielle, incarnée par des figures comme Garry Tan, qui glorifient une écriture de code frénétique et désordonnée, notamment avec l’aide des IA génératives.
L’auteur dénonce l’absurdité d’une approche où la qualité du code est mesurée en lignes produites par jour, comparant ironiquement les 37 000 lignes quotidiennes de Tan à la taille totale de DTrace (60 000 lignes). Il illustre cette dérive avec l’exemple d’un projet de Tan, un "blog-newsletter-thingy", truffé de composants inutiles comme des tests redondants, une application Rails basique et plusieurs variantes de logo, dont une vide.
Enfin, l’article met en garde contre la perte de sens de la paresse comme vertu, notamment avec l’essor des outils automatisés qui amplifient une productivité illusoire. L’auteur plaide pour un retour à une paresse réfléchie, où l’abstraction sert non seulement le développeur actuel, mais aussi la communauté, en évitant les pièges d’une industrie obsédée par la quantité plutôt que par la qualité et la durabilité du code.
Tout est dans le titre
Tout est dans le titre
L'idée de l'auteur est de rajouter un service chargé d'hydrater l'entité en fonction des données envoyées, en utilisant l'API de réflexion de PHP.
Cela évite, si on a beaucoup de champs, de gonfler la taille des contrôleurs, etc.
Soit une classe Fille, héritant de la classe Mère. La classe Fille a une méthode methodeFille. Si j'instancie un objet O de la classe Mère, je ne peux pas appeler la méthode methodeFille. L'auteur explique comment faire dans ce cas
Des réflexions sur le design d'interfaces utilisateur