Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
Angle
A Product Manager equipped with a coding assistant produces in four days what would have taken a month, and that speed says nothing about what they are entitled to build. What does say it is the state of the ground their work rests on: an up-to-date catalogue of internal APIs spares them the detours that manufacture inconsistency; tests carrying business intent give them a handle on code they have not read; a codebase whose business language is legible decides on its own whether they compose with existing blocks or cobble something together beside the product; and automated security checks hold the one requirement that is negotiable neither against the stakes nor against the deadline. Where those four pieces are missing, the same person, with the same competence and the same tool, produces only objects they will be able neither to explain nor to troubleshoot — and their technical competence, when they have any, merely delays the moment it shows. The ground therefore fixes both the authorized perimeter and the attainable speed, which places opening the code to product profiles among architecture decisions before making it a question of clearance.
Synthesis
Taken separately, these notes each describe one piece of the problem: speed, the defects the assistant creates on its own, authorization, review, tests, rails, the role of developers. What they bring out together is a shift in the deciding parameter. The usual discussion bears on the person — does she have enough technical background, is there a minimum level, should it be forbidden to non-technical profiles. Each note, taken by its own end, points elsewhere: to what was prepared before her.
The mechanism is the same every time, and it rests on a property of the assistant: it does not guess what is written nowhere. It has no idea of the real volumes, so it designs for the test dataset. It does not know the legitimate entry points, so it invents some. It does not retain what it was corrected on yesterday, so it starts over. None of these shortcomings is filled by the competence of whoever is steering; all of them are filled by information placed in the environment — and that is what tips the responsibility onto the side of those who maintain that environment.
A less expected consequence follows. The technical competence of whoever is steering stays useful, but its use changes: it no longer serves to produce, it serves to detect — seeing a file that is growing too fast, sensing one layer bleeding into another, recognizing an API response that will not hold under load. That capacity to detect has no automatic substitute, and it is the one thing the ground does not supply. It explains why the question of perimeter does not go away: an excellent ground widens what is feasible without making the operator capable of assessing what he produces.
There remains what this angle costs the organization. Moving the decision onto the ground amounts to saying that opening the code to other functions is paid for first in architecture work — clean APIs, conventions upheld, safe environments, automated checks — that is, in spending with no deliverable visible to the customer. It is the easiest line to cut, and yet it is the one that decides whether opening up produces relief or bodgework. The question "can Product Managers write code?" therefore has no general answer: it has one per company, and that answer was written before anyone asked, in the state of its codebase.
Tensions / contradictions
These notes do not agree on the real weight of individual competence. Those that move the decision onto the ground assume the assistant's shortcomings are filled by the environment; the one describing the running of a tool points out that knowing how to diagnose a breakdown is written in no API catalogue. If that share is large, the ground is only a necessary condition and competence stays the limiting factor.
A sharper disagreement sets two readings of acceleration against each other. The angle defended here treats speed as a benefit to be framed, and holds that the lost mechanisms can be reinstalled through the ground. The reading developed elsewhere on the manufacture of competence argues that some of those mechanisms — the analysable error, the first rung, the price of the gesture — cannot be reinstalled through tooling, because they required having been responsible for the result. Nothing here settles it: ground that removes the detours also removes the occasions to learn to recognize them.
Finally, the ungraduated security requirement and the lightening of review on disposable objects sit badly together in practice: they ask the same organization to relax a human control and to uphold an automated one, which presupposes tooling that organizations relaxing review often do not have.
Questions
- How much of the ground has to be built before opening up, and how much gets built in response to the first uses, at the risk of letting through the objects made in the meantime?
- Do ground designed for assistants and ground designed for human developers diverge, and at what point do you have to maintain both?
- How does an organization assess the state of its own ground before opening up, other than by observing after the fact what has been produced?
- On what is the decision to invest in that architecture work based, when its benefit is measured in inconsistencies that did not occur?