AI writes the code, humans check

On a Friday morning in late January, our VP of Engineering, Lorenzo, posted this in our engineering Slack: "We will run the entire MLP with a spec-driven development approach. Traditional software development is not allowed."

Not allowed. A top-down mandate, in a profession that treats top-down mandates as a bug. I want to explain why we made that call and what it did to our company, because the results have been the most surprising thing in my seven years of building Altura.

Why we bet the rebuild on it

Some context. In December, we kicked off a full rebuild of our platform. Our old codebase was six years old, full of spaghetti code, and built in an era when we were a team of juniors figuring things out. We had already decided to rebuild before this mandate; that decision deserves its own story.

What made us go further than a normal rebuild was timing. Claude Code had just crossed what our engineers called the "usable" threshold: it could reliably implement a well-described feature in a codebase it understood. And since we were starting from scratch anyway, we had a rare window to design the entire codebase and process around AI writing the code. Most companies have to retrofit AI onto structures built for humans. We didn't.

So we made the bet: humans would stop writing code entirely.

How spec-driven development actually works

Our engineers don't write code anymore. They specify it, review it, and ship it.

Every feature starts as a project brief from product. An engineering lead picks it up and owns it end to end, splitting the work into issues and turning those issues into specs: structured documents covering the business context, user stories, functional requirements, API contracts, and an implementation plan grounded in research on the actual codebase. The spec is the contract for the feature.

Then, something we borrowed from code review: the spec itself gets a pull request. Product and domain experts review the spec before a single line of code exists. Most of the real discussion now happens here, at the level of what we're building and why, when changing course costs nothing.

Once the spec is approved, Claude Code implements it. With a good spec, implementation is a fraction of the total time spent on a feature. The code gets its own PR, domain experts review it, and merged work deploys to staging automatically. Bugs follow a lighter track: an engineer handles them in the IDE with Claude Code, or simply assigns the Linear issue to a coding agent.

All the engineering time is still there, by the way. It just moved up front, into thinking, which turns out to be a much better place for it.

What it broke along the way

I should be honest about the start: we got slower before we got faster. The speed everyone associates with AI coding only showed up after weeks of investing in unglamorous basics. Spec templates, conventions, tooling, pipelines, but most importantly, many retros with the team. If you had watched us in February, you would not have been impressed.

Then the side effects started, and they reached much further than engineering.

PR reviews became the bottleneck almost immediately. When AI generates code faster than humans can read it, review is where everything piles up. We responded by rigorously documenting our code patterns and architecture rules, building custom checks that enforce them before a PR is even opened, and layering three AI reviewers on top of each other: one for line-level issues, one for higher-level bugs, one for architectural sweeps. Human review moved up to architecture and product decisions. Review throughput now keeps up.

Engineers started shipping outside their domain. When Claude handles the language-specific mechanics, a backend engineer can ship frontend and infra work. Our test suites catch what they'd otherwise break, and weekly retros absorb the friction of fishing in each other's pond. An unplanned benefit: the product silos are gone. Every engineer has now touched virtually every part of the product.

End-to-end ownership forced us into a monorepo because Claude Code works dramatically better when it can see the full context of the application. Four repos became one.

Even hiring changed. Our interview loop no longer resembles a classic dev role: we dropped take-home assignments and now run an architecture whiteboard (can you decompose a fuzzy problem?) plus a pair-programming session with the coding agent of the candidate's choice. We screen for architecture, product thinking, and how well someone collaborates with humans and agents alike.

And our tooling stack gets filtered on one question: does it work with AI? We moved from Jira to Linear for better agent integrations. In a recent procurement, MCP support was literally the deciding factor. The one area I'll admit is unsolved: design. Figma is no longer our single source of truth; we work with component-level designs plus markdown describing behavior, and the design handoff is still very much under development.

So, did it work?

Between mid-November and mid-April, we merged 652 pull requests. Our total Claude Code bill for that period: $10,768. For comparable features, we've measured how long a build took on the old platform versus the new one, and the difference runs up to 18x. We used to ship in sprints of three to six weeks; now something new goes live daily, enough that we built an automation that writes the daily product update, because no human could keep track anymore.

The question I kept getting in the months after was whether the pace would collapse once the rebuild sprint ended. The opposite happened. The new Altura shipped ahead of schedule, we're now moving all our customers onto it, and the daily shipping continues on a live product with real users on it. We also kept changing the process itself, which we treat as a product of its own. Spec templates have been through several versions by now, and when a new coding agent proves itself better than the one we use, it gets swapped in.

The 18x matters less to me than something else, though: our standards didn't change. Every line still gets reviewed and tested and still has to follow the same architecture rules as before. As Martijn put it when he presented this story to a room full of CTOs: our standards didn't change, our speed did.

Don't just copy us

One honest warning. This worked for us because the conditions were unusually favourable: we were mid-rebuild with a small, aligned team of seniors, and leadership was willing to enforce the mandate. I'd be much more careful with fifteen years of legacy, a sprawl of microservices and external integrations, or an organization where AI adoption is a suggestion rather than a decision.

And it was never free. We invested heavily in the process before it paid off, and we keep investing in it every week. That ongoing investment, more than any tool, is the actual bet. So far, it keeps paying.

‍