DEV Community

Cover image for Why Code Is About to Get Cheap — and What Actually Becomes the Moat
weiche chiu
weiche chiu

Posted on Originally published at williamlab.dev

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

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.

Anything built to make code cheaper sits on a depreciation curve

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 stays scarce is judgment someone else can check

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 built that add friction on purpose

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.

Take the last internal tool your team built to speed up code generation. If the next frontier model shipped tomorrow, would that tool be worth more, or would the model just absorb it?

Top comments (0)