We engineer with AI. We don't vibe code.

In recent months, well over 90% of the code we've shipped has been written through AI sessions. When people hear that, a lot of them picture vibe coding: describe something, accept whatever comes back, ship it and hope.

That isn't what we do, and the difference matters more than anything else about how we use AI.

We were engineers first

Our engineers are career software engineers. We were building and shipping production software for years before AI coding tools existed, and we value exactly the same things now that we did then.

AI changed how the code gets typed. It didn't change what good engineering is.

The question that matters most

Ask us what matters most in a software project and the answer isn't the language, the framework or even the architecture. It's this: how does your code reach production, quickly and safely?

Continuous integration and continuous delivery is arguably the most important thing in software engineering. A project with a good pipeline releases small changes, often, with confidence. Every change is built, tested and deployed the same way, every time. If something goes wrong, you find out fast, and the change is small enough to undo in minutes. A project without one releases rarely and nervously, and every release is an event.

If you already had a project with regular, quick and safe production releases, you already had the rails. Those rails are what let you move quickly without coming off them.

The bottleneck moved downstream

For most of software's history, writing the code was the slow part. With agents, it isn't. Writing code is no longer the bottleneck, so the queue forms further down the line: review, testing, merging, releasing, and finding out whether a change actually works in production.

That means your speed with AI is set by how mature your machinery is for getting code into production, safely. If your pipeline tests every change thoroughly and can ship to production several times a day, AI's speed turns straight into progress. If your tests are flaky, your releases are manual and you deploy once a fortnight, you just get a longer queue, and bigger, riskier releases at the end of it.

To be honest, this was always the case, long before AI. The teams that shipped small changes often, with confidence, always outpaced the ones that didn't. AI has made the downstream bottleneck painfully clear.

AI made the rails more important, not less

AI can produce code far faster than any person can read it. That's the opportunity and the danger in a single sentence.

Without rails, faster code just means faster mistakes: more changes, less understood, arriving in bigger batches with nothing between them and your customers. That's vibe coding, and it's why so much AI-written software falls over the moment it meets real users.

With rails, the speed becomes safe. Every change an agent makes goes through the same pipeline as a change a person makes: built, tested, reviewed and released in small steps. If it's wrong, the pipeline catches it, or the release is small enough to roll back before anyone notices.

So when code got cheap, we didn't relax. We invested in the rails:

• Fast, well-cached test runs that only test what changed, because CI and the merge queue are now the bottleneck, not the typing.
• More smoke testing, to catch the sneaky ways agents working in parallel can trip over each other.
• Adversarial review. A review agent challenges the coding agent before a person looks at the change, so the human review can focus on what humans are good at: intent, design and risk.

You still own every line

This is the rule everything else hangs off. If it ships under your name, it's yours, whether you typed it or an agent did. "The AI wrote it" is not an explanation anyone here accepts.

And caution scales with risk. On a certified B2B platform with large customers and SLAs, we're far more careful than on a pre-revenue prototype. That dial isn't a policy document. In small teams you can see the business risk directly and set it yourself, and that judgement is what we hire for.

What the job is now

The work that was always the hard part is now most of the work: understanding the problem, deciding what to build, breaking it into pieces an agent can do well, and recognising when what comes back is wrong. That's engineering. It always was.

It's also why T-shaped engineers get the most out of AI. Breadth across infrastructure, frontend, backend and data is what lets you ask for the right thing and spot the wrong answer, even outside your deepest specialism.

Why it works for us

Agents are only as good as the context you give them: what you're trying to do, where things really stand and why past decisions were made. We've spent over a decade writing all of that down as a habit, in log channels, descriptive commits and pull requests that explain their reasoning. I've written about why that turns out to matter so much in Reality Is the Source of Truth.

What it means if you work with us

Small teams get to working software sooner, and they get there on rails: small, frequent, safe releases from the first week. You pay for experienced judgement rather than typing. And you end up with a codebase your future team can take over, with every decision written down.

AI makes us fast. Engineering makes it safe. We engineer with AI. We don't vibe code.