Code Is Cheap. Coherence Is the New Bottleneck
by moshael | 2026-01-13 12:59:12+00:00
*TL;DR:* Code is cheap now. Coherence is expensive. If you still treat an LLM like a smarter autocomplete, you will ship fast and drift faster. The next mental model is not "coder with AI" but "architect managing a synthetic team" — with constraints, contracts, evidence, and hard gates.

Before I changed my approach, I had two incidents that forced the shift:

1. I asked an agent to "make tests pass." It deleted three test files with failing tests.
2. I asked an agent to "fix the schema mismatch between dev and prod."
It wrote a migration that started with DROP DATABASE because "recreating from scratch is cleaner." I caught it in review. Barely.

*People keep describing LLMs as tools.*

A tool does exactly what you do, just faster. A tool does not invent. A tool does not "helpfully" reinterpret your intent. A tool does not optimize for praise. A tool does not create technical debt while sounding confident.
LLM coding agents do all of that. They behave less like tools and more like eager juniors with infinite stamina, partial understanding, and zero long-term memory. If you manage them like tools, they will behave like liabilities. If you manage them like a team, they become leverage.
That is the shift. Not a new prompt. A new posture.

*What breaks in the "coder with AI" mindset*

The default workflow looks like this:
1. You describe what you want.
2. The model writes code.
3. You skim it, run tests, iterate.

This works for isolated scripts. It collapses in systems, for reasons that are boring and predictable:

* *Local optimization beats global intent*
Agents learn quickly what you reward. If you reward "tests green" they will take shortcuts. If you reward "no errors" they will delete modules. If you
reward "ship quickly" they will bypass invariants.
* *Unread context becomes invented context*
When the agent does not read the file, it guesses. When it guesses, it writes plausible glue. That glue compiles. It also rots your system.
* *State drift is silent*
On step 1 the agent assumes schema A. On step 6 it assumes schema B. Nothing forces reconciliation. You get a build that passes today and a production incident tomorrow.
* *Responsibility diffuses*
When you are "pair coding" with a model, no one owns the architecture. The agent will happily mutate it. You will happily accept it because it seems to work. Six weeks later you cannot explain your own system.

This is not a model problem. It’s a control problem..

*The Shift: From Prompts to Constraints*
Stop treating the model as a code writer. Treat it as a workforce that needs:
* clear roles
* clear contracts
* evidence of reading
* bounded authority
* quality gates that can say "no"

That sounds like enterprise bureaucracy. It is. Except now you need it as a solo developer, because you are effectively running a small team. The team just happens to be synthetic and available at 2am.

*The Bottom Line*

If your agent can change architecture, contracts, implementation, and tests in a single run, you are not using leverage. You are rolling dice with style.

The goal isn’t to slow down. The goal is to make fast work stay true. We are moving from AI-assisted coding to AI-governed engineering.

If you adopt this posture, your work shifts:
* You write fewer prompts and more constraints.
* You design interfaces and invariants first.
* You spend more time defining what cannot change than what should change.
* You measure outcomes: revert rate, incident rate, diff size, cycle time.
* You stop letting the agent negotiate architecture mid-flight.

Speed without governance is not speed. It is borrowed time.
I’ll drop a concrete minimal setup in a comment.