Main idea

Skipping a developer's review on a tool you built yourself has a counterpart that is not optional: when that tool breaks, nobody else is on the hook. Whoever chose to build it eats their own cooking, and the fixing falls to them.

This is where the promise cracks. A code assistant has removed the barrier to entry — writing the feature — without removing the competence needed on the way out: understanding why what worked yesterday no longer does, reading a stack trace, isolating a regression, telling a data problem from a logic problem. Plenty of Product Managers can now have a screen produced and cannot solve the bug they have just created.

The asymmetry is the heart of the matter: producing has become accessible, running what you produced has not become accessible at the same rate.

Why it matters

It gives a more honest entry criterion than coding level: not "could you write it?" but "will you manage when it breaks, without pulling in somebody else?". A tool you would not know how to fix is not a personal tool, it is debt parked at your neighbour's.

It also names what lies behind many requests for review: less a quality check than a way of transferring responsibility for fixing things in advance.

Nuances and limits

The assistant does take back part of the load — it reads the trace, proposes a fix, explains what it did. The limit is therefore not absolute; it bears on the cases where understanding the problem is the precondition for the question you should be asking it.

And the rule assumes the tool stays personal. As soon as a team depends on it, a failure stops being a private problem, and individual responsibility is no longer enough to absorb it.

Open questions

• What minimum diagnostic competence — reading a trace, checking a log, replaying a request — should be required before authorizing someone to put into service a tool they had produced for them?