Who is in charge here

the roles of human and AI, and what happens when they blur

What it is

Working with an AI has a structure worth saying out loud, because by default it blurs.

You are the architect and the reviewer. The AI is the implementer.

You decide what the result should be and whether what came out fits. The AI proposes how to do it, and does it. The decision stays with you — not because the AI is stupid, but because you are the one who will answer for the result.

What this means in practice

The architect decides what to build

Which problem is being solved at all. What parts the project has. Where the data lives. What matters more — speed or simplicity. These are decisions that cannot be delegated: the AI has neither your constraints, nor your plans, nor any knowledge of why the whole thing was started.

The reviewer decides what to accept

Code does not become yours because it appeared in your file. It becomes yours when you have read it and agreed. Until that moment, what sits in the project is someone else's decision that you never checked.

The implementer builds and proposes

The AI writes code well, suggests options, explains other people's decisions and notices what you missed. It can — and should — argue and propose something better (article 3.11). But the last word is not its own.

What happens when the roles blur

Two extremes, and both are common.

You become the implementer

It looks like this: got the code, didn't understand it, pasted it, ran it. Didn't work — asked for a fix. Still didn't understand. Repeat.

This is exactly the no-reading loop from article 1.2. Formally the work is moving, but the decisions are being made by someone who does not answer for them. A month later the project holds code nobody has read and a bug nobody can find.

The sign: you cannot explain what a file in your own project does.

The AI becomes the architect

This one looks different: the task is stated broadly — "build me a reminder bot" — and the AI makes every decision for you. Which database, which structure, which libraries, how data is stored. All of it gets locked into the project, and changing it later is expensive.

The problem is not that the decisions are bad. Usually they are fine — average for the industry. The problem is that they are not yours, and you find out about them a month later, when something needs to change.

The sign: the project contains a library and you don't know what it is for.

What to tell the AI

Roles are not set by settings; they are set by how the task is stated. The architect says what to build:

Storage will be SQLite, not JSON — there will be a lot of
records and we need queries by date. No ORM, we write the
queries by hand, there aren't many.

The implementer gets what it is good at:

Propose a table structure for subscriptions. It needs
user_id, city and creation date. Tell me which indexes
are worth adding and why.

And one separate move — asking for your role back, when you feel decisions are being made without you:

Which decisions did you make on my behalf in this code?
List them, with the alternatives that existed.

What to look for

You haven't argued with the AI in a while. If every proposal is accepted, odds are they are not being read. Normal work includes a few "no, let's do it differently" per session.

You don't know why the project is built that way. Any part you cannot say "I chose this because…" about belongs to someone else.

Tasks are phrased as "make it good". That is how a customer talks, not an architect. An architect names the constraints.

Changes are accepted without reading the diff. The most reliable sign that the reviewer's chair is empty (article 2.13).

Cheat sheet