The speed of error grows with the speed of output

A few theses on AI-assisted development — drawn from firsthand experience. Treat them as notes for your own reflection, not as truth for all occasions.

What fundamentally shifts

• AI drives the cost of writing code to near zero — the bottleneck moves from "hands" to a coherent model of reality held in someone's head.

• The scarce resource is no longer code, but understanding of processes, data ownership, and where things fail to connect.

• The most valuable output is no longer the code itself, but the artifacts that externalize the model (decisions, open questions, contracts).

Primary risks

• AI accelerates building the plausibly-wrong as much as the right thing; the speed of error grows alongside the speed of output.

• The only reliable brake is a human with knowledge of reality and discipline; without it, a confidently-wrong system accumulates fast.

• Knowledge and plans settle into one head and into private chats — cognitive load and bus-factor both rise.

• Handing AI to everyone without rules scatters and loses knowledge rather than scaling it.

Where value and pain concentrate

• Maximum value lives in the seams between subsystems/domains — and that is exactly where reality bites hardest.

• A seam is its own kind of work: a contract over data ownership, formats, timing, and behavior on mismatch. It's 70% data semantics and politics, 30% code.

• If no explicit role owns the seam, it gets patched over with "glue" (often external) — continuously.

Brakes as a system (not as carefulness)

• Each practice is a counterweight to a specific AI failure mode:

  • plan-then-confirm — against running ahead and building the wrong thing.

  • reversible removal (archive, don't do the irreversible) — against the cost of rollback.

  • batched releases on command — against version noise and constant monitoring.

  • fail-safe by default — against code silently misfiring at scale.

  • dogfooding the live flow — against code drifting from reality (what tests and AI don't catch).

  • periodic debt audit — against accumulation of the confidently-wrong.

• Non-negotiable core, if you adopt only three:

  • a decision log (why it's built this way);

  • a reality-checkpoint by a live human before "done";

  • reversibility by default.

Brakes must be built into the flow (templates, mandatory checklists, default wrappers) — otherwise speed washes them away.

Infrastructure and stack

• AI doesn't repeal the gravity of ops: migrations, deploys, dependencies, and access eat disproportionate time and parallelize poorly.

• Stack immaturity/novelty amplifies this pain. Stack maturity > novelty.

• A solo or small team absorbs all the infrastructure noise personally — plan for it.

Architecture

• The "monolith vs. microservices" axis is obsolete. The live axis: code is cheap, seams are expensive, understanding is scarce.

• Microservices add exactly what got more expensive (seams) and what AI doesn't fix (ops) — don't fragment without need.

• A rewrite "because AI made rewriting cheap" is a trap: writing got cheap, not understanding and integration — and a rewrite is 90% those two.

• Optimize the codebase for understandability and reversibility, not for architectural purity.

• Launch new bets as separate services with an explicit, defended contract; keep the data model as the crown jewel.

People and organization

• Democratizing building is only safe with a system of brakes in place; otherwise "AI for everyone" = a faster mess.

• The seam-owner and the discipline-keeper are the same cross-functional role; its existence makes architectural debates secondary.

• This role demands a rare combination: knowledge of reality + discipline + the ability to build with AI. The key decision is whether to grow it, hire it, or keep it as an external function.