Architecture Is the Interface Now

Ask a senior engineer what they actually did all day, years before AI: they read code more than they wrote it. They argued about boundaries. They wrote design docs, reviewed diffs, decided what not to build, and spent their credibility vetoing clever things that would be expensive later. The syntax was always the cheap part — juniors produced it by the yard.

AI didn’t change what the senior work is. It changed who has to do the cheap part. Syntax became delegable; architecture didn’t.

That inversion is the thesis of this site: specs, ADRs, tradeoff analysis, test strategy, and review judgment aren’t the overhead around the work — they are the work, and they’re now the interface through which software gets built. Every case study here is evidence for that claim.

The interface, concretely

Here’s what “architecture as interface” means in a real build, not as a metaphor.

Specs are the function signature. An agent given a vague intention returns plausible junk with perfect syntax. An agent given a written problem statement, target metrics, and acceptance criteria returns something you can judge. When output is wrong, the first diff to read is the spec — the same way you’d check a caller before blaming the library.

ADRs are the type system. An Architecture Decision Record isn’t documentation after the fact; it’s a constraint the agent reads before proposing changes. My repos carry halt-on-violation rules: if an accepted ADR contradicts the proposal, stop and say so. Agents honor this with remarkable reliability — because a written decision is machine-legible in a way that tribal knowledge never was. Decisions you don’t write down get re-made, badly, by every session that follows.

Test gates are the contract. Generated code follows a failing test, and nothing is “done” until the quality gates pass. I don’t take a model’s word that something works, for the same reason a reviewer doesn’t take a human’s. The gate is the agreement; everything before it is conversation.

Reading reasoning is code review. A chain of thought reads like a diff: what was considered, what was rejected, where the confidence got suspicious. When the reasoning is sloppy, the code is sloppy — I have yet to see an exception. The review skill transfers whole; only the altitude changes.

Judged by outcomes

The fair objection: can you claim the architecture if an agent produced the implementation? The answer every engineering organization already accepts: no leader reads every diff. They build systems of verification — review, CI, budgets, incident response — and they’re judged by what ships and whether it holds. That’s the standard I work to. The chatbot either grounds its answers or it doesn’t. The Lighthouse gate either holds or it doesn’t. The tool either survives contact with the sales team or it doesn’t.

I’m a marketer by trade — a former demand-gen director who now owns the marketing technology and AI function end to end: tooling, budget, design, development, and the DevOps behind the internal apps our GTM teams run on. Architecture wasn’t my title; it was the necessity that came with owning outcomes. The discipline in this essay is how one person carries that scope without the wheels coming off.

Syntax was never the moat. Judgment was — and now judgment has a direct interface to execution. That’s not a diminished version of building software. It’s the senior job, available to anyone rigorous enough to do it.