I train people who write software, and people who decide which tools those teams will use. Over the last few years I have trained more than 2,500 executives and employees on generative AI, in real workplaces. I live in Montpellier. The pattern that now shows up most often in engineering rooms is quieter than a failed agent in production.
A team gets a coding assistant. Someone pastes a ticket into the prompt box. A plausible patch appears. The existing tests still pass. The pull request is opened the same afternoon. Two or three people skim a diff they did not design. The change lands. A week later, a teammate has to extend that code, and nobody can explain why a branch exists, what happens if the input is empty, or which constraint the model quietly dropped. The team did not lose a feature. It lost ownership of the reasoning that should have produced it.
I gave this pattern a name in 2025: ipromptisme. In plain terms, it is what happens when a team lets the prompt, and the fluent draft that follows, replace the work of thinking, checking, and deciding. I set the idea out in French on my site, in a short page on ipromptisme. This article is the engineering version of that idea: a review method you can use before you roll a coding assistant out to the whole team.
This is not a product review, and it is not a tutorial on "better prompts." It is a field method.
The prompt is not the design review
A coding assistant is very good at producing a first draft that looks like the house style. That is useful. The danger starts when the draft becomes the design.
In a healthy review, someone can answer four questions out loud:
- What problem are we solving, in one sentence?
- What did we decide not to do, and why?
- What could go wrong with this change, in this codebase?
- How will we know, after the merge, that we were wrong?
When the first draft comes from a model, those questions often arrive too late, or not at all. The prompt already "solved" the ticket. The human work shrinks to cleanup: rename a variable, accept the linter, add a comment. Cleanup is not review. Cleanup is typography.
I have watched capable engineers approve a change they could not reconstruct from memory ten minutes later. They were not careless. They were busy, the draft was fluent, and fluency reads like competence. Fluency is not competence.
The fix is not to ban the assistant. It is to put the reasoning back in front of the merge, and to train that habit before the tool is everywhere.
Three failures I see when the model writes first
I do not name clients, and I do not invent figures. These are patterns I see, in anonymized form, when I work with technical teams.
The design talk never happens. The model proposes an approach. Nobody writes down the alternatives. Six months later, the approach is "how we do it," with no record of why. That is not documentation debt. That is a missing decision.
The bar for "good enough" becomes "it compiles and the existing tests pass." Those tests were written for the old shape of the code. They rarely check the new branch the model just invented. A green pipeline is necessary. It is not a substitute for a reviewer who can explain the change.
The author cannot defend a surprising line. I ask a simple question in training rooms: point to the most surprising ten lines in this diff, and tell me why they are there. If the author needs to re-run the prompt to answer, they do not own the change yet.
None of these failures require a leaked key or a spectacular outage. They require a tool that writes quickly, and a review culture that has not caught up.
A review ritual that fits in one pull request
Here is the method I use with engineering teams. It is deliberately small. It should work on the next pull request, not after a six-month AI program.
1. State the intent in your own words, before you paste the draft. One short paragraph, written by a human, in the ticket or at the top of the pull request: the problem, the chosen approach, and what you are not doing. If you cannot write that paragraph without looking at the model's output, you are not ready to generate code.
2. Generate the draft only after that paragraph exists. Treat the output as a first draft from a fast junior teammate who has never been on call for this system. Useful, often impressive, and not yet trusted.
3. Annotate the surprising parts. Before you request review, mark the lines a knowledgeable teammate would not have expected. For each mark, add one sentence: why this is here, and what you checked. If you cannot annotate those lines, rewrite them yourself, or go back to the design paragraph.
4. Ask a reviewer to play opponent, not typist. The job is not to polish names. It is to challenge the intent paragraph, look for a missing test on the new path, and ask the author to defend the surprising lines without re-opening the assistant. If the author needs the model to explain the change, the change is not ready.
5. Add one test or one check that did not exist before the draft. A unit test, a property, a log assertion, or a manual check in the ticket. The point is to verify a behavior the model introduced, not to re-run the suite that already passed. If you cannot think of such a check, you do not yet understand what the draft changed.
This ritual is slower than "prompt, apply, merge" on the first day. It is faster than debugging a change that nobody can explain in three weeks.
Train the team before you roll the tool out
The most common sequence I still see is the wrong one. Licenses arrive first, a lunch-and-learn shows a happy path, and everyone is expected to be faster by Monday. That trains speed. It does not train judgment.
The order I defend is the opposite, and it is the same order I defend for any AI tool. First, practice the review habit on a small set of real tickets, with the assistant in the room and a human still owning the merge. Then, and only then, open the tool more widely.
A concrete way to do that in a single week:
- Pick six to eight recent tickets, stripped of secrets, from the last month. Keep the messy ones.
- In pairs, write the intent paragraph first, then use the assistant, then apply the five-step ritual.
- End with a short debrief: which drafts survived review, which ones looked fluent and still failed the "defend the surprising lines" test, and what check you had to add.
- Only after that debrief decide who gets the tool, on which repositories, and with which review rule.
You do not need a new platform for this. You need one owner, one week, and a written rule: a pull request whose author cannot defend the surprising lines does not merge, even if the pipeline is green. If the assistant is already everywhere, freeze the "just prompt and merge" habit for a week on one squad, run the ritual, then make that the default.
This is not a call to write every line by hand. Assistants are good at boilerplate, at exploring an unfamiliar API, at proposing a first shape. A sharper prompt can also improve the draft. It cannot replace a human who can say why a change is acceptable. If your training plan is a catalog of prompt recipes and nothing else, you are training the team to talk to the model, not to keep the judgment the model cannot own.
The skill that matters, once the draft is easy to obtain, is the skill of disagreeing with a fluent answer, in the review, without drama. That is a trained habit. It is not a setting in the tool.
A next step for your team this week
You can start with a single pull request. Tomorrow, take one ticket you would have sent straight to the assistant. Write the intent paragraph first. Only then generate the draft. Annotate the surprising lines, and add one new check. In review, ask the author to defend those lines without asking the model again. If they cannot, do not merge.
If that feels heavy for a small change, good. That friction is cheaper than owning code that nobody can stand behind. The teams that get value from coding assistants, in the rooms I train, are rarely the ones who adopted the tool first. They are the ones who delayed the wide rollout long enough to practice this review, and who kept the rule after the novelty wore off. The model can write the first draft. The team still has to own the reasoning.
About the author
Romain Bailleul is an AI trainer and consultant, working as Better Call Rom. He trains leaders and technical teams on critical use of AI, on practicing review habits before rolling out tools, and on the scope of AI systems in a company. He formalized ipromptisme in 2025, spoke at TEDx at the Grand Rex, and has trained more than 2,500 people. He lives in Montpellier. Site: https://www.romainbailleul.fr/.
Top comments (1)
초안을 보기 전에 의도와 제외 범위를 먼저 쓰고, 예상 밖의 줄마다 검증 이유를 붙이는 순서가 핵심이네요. 새 검증 항목을 만들 때는 정상 입력뿐 아니라 빈 입력이나 충돌하는 제약처럼 초안이 놓치기 쉬운 반례를 하나 짝지으면, 기존 테스트 통과와 새 동작 검증을 더 분명히 나눌 수 있겠습니다.