Building with AI: what actually changes

11.1 The new practice

The deep shift: the human becomes the architect and the decider, the AI becomes the partner that explores the code, proposes options, writes the spec, generates the code, and verifies it. You don't type the code line by line. You frame, decide, re-read, validate.

11.2 The roles

Framing AI (the product partner): brainstorms, asks the trade-off questions one at a time, writes the spec, drafts the execution prompts, keeps a memory of the project for continuity. Executing AI (the coding agent): reads the repo first, edits files, writes code, runs the build and type-check, flags its blind spots. Sub-agents: explorers launched in parallel to map the code fast without cluttering the main thread. You: the product decisions, the trade-offs, the final verification, the deploy, the tests, the comms.

11.3 What the AI really does when it codes

It reads the existing code before writing (grounding): it maps the files, the conventions, the insertion points. It doesn't guess, it goes and looks. It proposes options with their trade-offs, but does not settle a product decision for you. It writes the spec then the code, reusing the patterns already in the repo. It verifies mechanically: compiles, types, syntax, style. It flags its blind spots: what it validated by reasoning and not live, the defaults it chose, the manual prerequisites (a secret to set, a migration to apply). And it deliberately does not do certain things, because they are yours: settle a business trade-off, push or deploy without your go, move real money.

In one line for the non-dev reader: the AI is a very strong executor that reads, proposes, codes and checks. The pilot and the safety rail is you.

The economics, because it's the first question a CPO asks. Your time shifts: less of it goes to writing code, more to deciding what to build and verifying what came back. Your costs shift too, from paying for hours to paying for tokens, the unit AI bills by. A session that explores a big codebase burns tokens fast, so grounding efficiently (send the agent to the right files, not the whole repo) is a cost decision, not just a speed one. The return is not free code, it's speed to a real, shippable product with one person instead of a team. Watch your token spend per shipped slice and the ratio of your decision time to the agent's execution time, and watch that ratio improve as your specs sharpen. A vague prompt is expensive twice: in tokens, and in the rework it causes.

11.4 The failure modes specific to agents

New tools, new ways to fail. An agent can be confidently wrong, stating a false fact in the same tone as a true one (Law 7). It can act on a stale doc it wrote itself. It can "verify" something it never ran (Law 4). Two agents in parallel can collide on the same files (Law 9). It can drift from the plan across a long session as its memory fills (Law 10). None of these are reasons not to use agents. They're the reasons you keep the human checks that catch them.

11.5 What AI makes mandatory that used to be optional

Some practices were nice-to-have with a careful human and are now non-negotiable with an agent. Grounding before acting. A written spec (the agent needs the source of truth you used to keep in your head). Mechanical checks calibrated on a known-red case (you can't rely on the agent's self-report alone). A project memory with a budget. Explicit "do not touch" boundaries in prompts. The agent doesn't make these optional. It makes them the price of going fast safely.

11.6 What stays human

The decisions. The trade-offs. The final verification. The deploy of anything hard to reverse. The taste. And the accountability: when it ships, it's your name on it, not the model's. That's the whole deal, and it's a good one.