Lecture de Steve Yegge :  « The Death of the Junior Deve­lo­per »

De  « The Death of the Junior Deve­lo­per »

Gene, as an accom­pli­shed and senior author, is deligh­ted with his produc­ti­vity gains with his LLM of choice, Claude Opus. He showed me a big writing project that he’d just fini­shed, in which he had spent easily 45+ minutes craf­ting the prompt, refi­ning it until he had a 7500-word narra­tive that could serve as a star­ting point for rewri­ting, editing, and adjust­ment. (In compa­ri­son, this blog post is about half that size.) And that draft was fantas­tic. I’ve read it and it’s glorious.

On a good day, Gene can write 1,000 words per day. His esti­mate is that Claude did for him in 90 minutes what would normally have taken him ten days. It solves the « blank-page problem » and gets him to the 20-yard line, where the fun begins.

Il y a d’autres histoires. Je note un motif que ceux qui répondent « qualité » ne semblent pas voir.

L’IA est un outil. On ne lui demande pas force­ment de savoir tout faire, ni même de le faire bien. On lui demande de savoir faire assez pour amener le donneur d’ordre plus loin, ou plus vite, et majo­ri­tai­re­ment de lui permettre de se concen­trer sur sa tâche réelle, son vrai métier. C’est vrai même pour celui dont la tâche est l’écri­ture.

My senior colleagues have recently recoun­ted simi­lar chat scena­rios in which a more junior dev would have been comple­tely taken in, poten­tially losing days to weeks of work going the wrong direc­tion.

Or worse.

Chat, it seems, is safer for senior program­mers than it is for junior ones. And a lot of compa­nies are going to inter­pret « safer » to mean « better. »

(…)

Brie­fly, what do I mean by « senior » here? Really just two things:

–  You know what you want before the AI writes it. You already have a vision for how you would write this by hand, or have it narro­wed to a few reaso­nable options.
–    You can detect when it is giving you bad guidance.

J’ajou­te­rais : savoir utili­ser l’ou­til. Ça reste un outil. Comprendre ses limites, sa zone d’ef­fi­ca­cité et comment en obte­nir le meilleur peut faire la diffé­rence.

Rien que : aujourd’­hui les tâches répé­ti­tives finissent toujours par dérailler mais qu’il est parfait pour créer le code qui va faire cette tâche répé­ti­tive (comme un déve­lop­peur en fait).