AI Is a Process, Not a Tool

Most teams adopt AI the same way they once adopted a new IDE plugin: install it, let developers autocomplete faster, and call it a productivity win. Then they measure the results and feel vaguely disappointed. Code appears faster, but reviews take longer. Juniors ship more, but understand less.

The mistake is in the framing. AI is not a better tool inside your existing process. It is a reason to redesign the process itself.

The tool framing and why it fails

When you treat AI as a tool, you keep every step of your workflow intact and just accelerate one of them: typing. But typing was never the bottleneck. In any system that has lived longer than a year, the bottleneck is understanding — of the domain, of the architecture, of the consequences of a change.

Accelerating typing while leaving understanding untouched produces a predictable result: you generate misunderstanding faster.

The process framing

Now consider what changes if you treat AI as a participant in the process instead:

• Specification becomes the primary artifact. If an agent writes most of the code, the thing worth engineering is the input: the domain model, the constraints, the acceptance criteria. Vague tickets that a human would “figure out” produce confidently wrong code.
• Review shifts from lines to intent. Reading every generated line does not scale. What scales is verifying behavior: tests, invariants, contracts. Your architecture either makes that possible or it does not.
• Architecture becomes a forcing function. Clear module boundaries, explicit domain language, and small well-named files are no longer aesthetic preferences. They are what allows both humans and agents to navigate the system without holding all of it in their head.

None of this is new advice. DDD practitioners have been saying it for twenty years. What changed is the cost of ignoring it: a human developer slowly compensates for a muddy codebase; an agent amplifies the mud at machine speed.

What I am practicing

I am rebuilding my own workflow around this idea: interview-driven specs before code, plans as reviewable documents, agents doing the implementation, and my attention spent where it actually matters — on the model of the problem.

This blog is partly a lab journal of that experiment. Some of it will work, some of it will not. I intend to write about both.