Leadership - 2026-08-13 - 3 min read

Why Code Is About to Get Cheap — and What Actually Becomes the Moat

As frontier models keep closing the cost gap on code generation itself, the layer that stays scarce is the judgment behind what to build and why, captured in a form someone else can check.

AI-Native EngineeringMoatOrganonOrvena

Originally published on LinkedIn on August 13, 2026.

Every AI coding tool on the market is racing to answer the same question: how do we generate code faster and cheaper? It's a real, measurable win, and it's the obvious place to compete right now.

I don't think it's the place to build a career around.

Frontier models get better every few months at going straight from a plain-language description to a working, deployable app. Every intermediate layer built to make code generation cheaper (templates, IR, scaffolding) has a shelf life set by how fast the model underneath it improves. The better the model gets, the thinner that cost advantage gets. You're optimizing something on a depreciation curve you don't control.

What doesn't depreciate as fast: the judgment behind what to build and why, and a record of that judgment made honestly enough that someone else can check it. As code gets cheaper to produce, the layer that stays scarce is the one nobody can generate for you: intent, trade-offs, the "why this and not that," captured in a form you can version and hold someone accountable for.

This is the bet I'm making, not a proven result. I haven't sold this to a regulated buyer yet, and the honest test is whether anyone will actually pay for an audit trail instead of just trusting the agent. I run this filter mainly on the governance/architecture side of what I build, not as a universal law for every AI project.

Two things I've built recently make this concrete.

I designed a schema for organizational design: eight parameters (purpose, who has a claim on surplus, who controls decisions, resource flow, surplus allocation, legal shell, lifecycle, and who does the work — new because of AI, ranging from fully human to fully agentic) plus eleven constraint rules that rule out combinations that are legally or logically impossible. Pick "foundation" as the legal shell and you can't have a residual claimant; surplus can only be reinvested. That's not a rule I made up, it's what the underlying legal structure forces. The value isn't the eight boxes — it's turning "what even is a legitimate organization" from intuition and case studies into something you can enumerate and check.

I also built a governance runtime for coding agents on a simple premise: don't trust the agent's report of what it did, verify it at the OS level. The agent can only touch files it was scoped to touch because the filesystem refuses the write, not because the prompt asked nicely. Every run produces a frozen, auditable record. I ran the same task governed and ungoverned and published the difference: it's a small, self-hosted signal from one local model on one machine, and the run that produced it barely got attacked — every recorded breach happened on the ungoverned side, nobody tried to actually beat the sandbox. I'd rather show that than pretend the number proves more than it does.

Neither project makes code cheaper. Organon doesn't write code faster. Orvena, if anything, adds friction on purpose. What they share is turning a decision or a boundary into something you can inspect, instead of something you take on faith.

I'll walk through both in more detail over the next couple of posts, starting with the organizational schema, then the governance runtime. If "AI architect" means more than prompting a model well, this is what I'd point to.

Working on something like this?

I help teams ship AI-native systems — architecture, governable autonomy, and the evidence discipline to back them. One conversation is enough to see whether it fits.

Discuss fit