Comment les pros du logiciel jugent-ils vraiment le code généré par IA ?

In plain terms

Un papier arXiv publié le 13 juillet 2026 (arXiv:2607.09434) formalise, en Registered Report, une étude sur la manière dont les développeurs professionnels évaluent le code généré par des outils comme Copilot, ChatGPT ou Claude. Autrement dit : la première tentative rigoureuse de mesurer ce que « accepter du code IA » veut vraiment dire dans la pratique.

Ce que la démarche apporte

Un Registered Report publie le protocole (question, hypothèses, plan d'analyse) AVANT collecte des données - méthodologie peer-reviewée en amont, résultats publiés quel que soit leur signe. Ce format, importé de la psychologie expérimentale, coupe le p-hacking et le storytelling post-hoc. Sa présence en Software Engineering est en soi un signal : le champ demande enfin des preuves construites, pas des anecdotes de démo. Le résumé arXiv l'annonce clairement : plusieurs années après Copilot, la littérature manque de fondations empiriques sur le geste central - la revue humaine du code IA.

Analyse - pourquoi ça compte pour le métier

1. Le trou dans la raquette. On mesure la vitesse de génération, l'acceptation dans l'éditeur, les tokens facturés. On ne mesure pas - sérieusement - la qualité des critères que les devs utilisent quand ils cliquent « accepter ». Ce papier vise pile ce point aveugle.

2. Le lien avec le fil « hype-fatigue ». Un autre papier arXiv paru le même jour (« Programmers Are Poor and Overconfident Judges of LLM-Generated Assertions », arXiv:2607.08885) suggère que les devs surestiment leur capacité à juger les sorties LLM. Croisés, les deux dessinent un tableau inconfortable : on juge vite, on juge mal, on est sûr de soi. Ça oblige à repenser les workflows - plus de garde-fous automatisés en aval, moins de foi dans l'œil humain en amont.

3. Ce que le craft peut en tirer, tout de suite. Deux gestes concrets : (a) rendre la revue d'un code IA explicite (checklist courte : intent, invariants, cas limites) plutôt qu'implicite ; (b) mesurer chez soi les incidents post-merge liés à du code IA « accepté sans discussion ».

So what

Pour un directeur technique : ne pas attendre les résultats finaux pour agir. La demande de fondations empiriques sur « comment on juge le code IA » est déjà une demande stratégique. Instrumentez vos propres flux d'acceptation - les organisations qui auront des données sur leurs devs auront un avantage réel sur celles qui pilotent la revue à l'intuition.