Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
Main idea
The supervision work is the same an experienced developer does alongside a beginner: restating why one file shouldn't contain everything, why one layer shouldn't know about another, why you don't load all the data, why you have to write tests and why you have to rerun them. You hand over a screenshot of a component, and what comes back is a simplified interpretation you have to rework.
What differs is what that effort buys. Mentoring a junior is an investment: the same remarks don't repeat indefinitely, because the person accumulates. An assistant accumulates nothing by itself — the correction holds for the session, not for the next one, and the same drift comes back on the following feature.
Supervising an assistant therefore only pays if it changes medium: what you would say to a junior has to be written once into the frame the assistant rereads — instruction files, conventions, a catalog of patterns. Restating every time is the expensive regime; writing is the regime that capitalizes.
Why it matters
This corrects the spontaneous reading of the relationship. Those who describe the assistant as a very fast junior usually draw an optimistic conclusion from it — you just have to supervise it well — when the very mechanism that made supervision bearable has disappeared.
It also indicates where the time genuinely saved goes: not into producing code, which really is faster, but into the repetition of a supervision that doesn't capitalize as long as nothing writes it down.
Nuances and limits
The analogy has its limits: unlike a junior, the assistant doesn't tire of being corrected, doesn't lose confidence and doesn't cost a career. The comparison serves to situate the supervision load, not to describe the relationship.
And writing the frame has a cost of its own, justified only on repeated work. For a tool built in one evening and abandoned the next day, restating is cheaper than writing.
Open questions
- What share of what an experienced developer passes on to a junior can actually be formalized in an instruction file, and what share holds only in a discussion about a specific case?