AI made code cheap. Judgment is still expensive.
We rebuilt how we work around AI — our own product team went from ten people to two and a half, and it moves faster now. So this is not a skeptic’s page. What stayed is the senior technical leadership: CTO-level judgment, experienced architects, delivery leads. That is not a seat on an org chart. It is six specific things, and you can check every one against the work.
Six things judgment does. None of them are typing.
A team used to be a front-end developer, a back-end developer, someone who knew C#, someone who knew Python — and above them, people whose whole job was to drive all of it into one coherent thing that worked. AI can now perform much of the implementation work the first list represents. It cannot do the second, and every saving on this website came from the second. Each of these names the project it came from, so you can go and check.
Deciding what not to build
The cheapest code is the code someone talks you out of. A rebranding was heading for a significant redesign until we found that the new business requirement could be met by configuring what already existed. That decision removed about a fifth of the work before anyone opened an editor.
The rebranding, −20% effortReframing the question being asked
A lender asked whether to hire more collection agents. The useful question was a different one — how much of this queue needs a person at all — and the answer was about half. Answer the question as asked and you build the wrong thing beautifully.
Collections, no new hiresSpotting the thing that will actually kill it
Two attempts at 800 KYC bots had already been abandoned. Not because writing them was slow — because maintaining them cost more than the data was worth. An AI that wrote those bots ten times faster would have produced exactly the same dead project, just sooner. Knowing which cost is the fatal one is the whole job.
KYC, 90% cheaper to keep aliveKnowing when a confident answer is wrong
Internal teams and outside vendors agreed a catalog replacement would take five years and $25M. They were confident, experienced, and wrong by more than an order of magnitude on cost. Models are wrong the same way — fluently, in complete sentences, with no tell.
The catalog, delivered for under $2MSequencing the risk
The same catalog had errors running live and needed total replacement. Treating those as one job is why every estimate was enormous. Stop the bleeding with a bolt-on in three months, build the replacement in parallel behind it. Nothing about that order is written in the code; it is decided before any code exists.
The same project, the other decisionKeeping it coherent
A marketplace had already produced a proof of concept that worked and could not scale. That is what you get when the parts are individually correct and nobody is holding the whole. AI is very good at locally correct parts. Someone has to be accountable for them adding up to a system.
The marketplace, after $50M of partsAnd the one that is not a skill at all
Someone has to carry the consequence. When an initiative has already failed twice, when the date is a sales conference with several thousand people in the room, when the thing being automated is a compliance obligation — somebody has to put their name on the call and be in the room when it is questioned. No model does that, and no model can be asked to.
Two reactions we get, and the honest answer to each
Because the bottleneck moved, it didn’t vanish
When writing code gets cheap, the expensive mistakes are all upstream — and they are precisely the six above. Building the wrong thing. An architecture that cannot scale. An initiative sequenced so the risky part arrives last.
AI will build the wrong thing very fast and very cheaply, and it will be polite about it. The $50M marketplace on our case studies page was never a typing problem.
It does. That is what the process is for
It is confidently wrong often enough that shipping its output unexamined would be reckless. So we don’t. A person reviews every stage — the spec, the architecture, the critical code paths, what the tests failed to think of.
You also own the code, and nothing is committed before a six-week proof you can judge for yourself.
How we actually build now
Our own process, running today on everTest. AI does the work at every stage. Technical leadership judges it at every stage.
What it did to our own team
We started building everTest in 2024 the normal way. We began working with AI development tools in mid-2025.
It was not a switch being flipped
Productivity did not jump overnight. It climbed over months, because the tools got better and because we got better at working with them. Every good developer has habits — things they are brilliant at, things they consistently get wrong, ways they need to be asked — and getting the best out of them is what technical leadership has always been. AI tools are the same job. Most of our gain came from learning the habits, not from the tools. Anyone promising you a step change in a fortnight is selling something.
Who this is for — and who it isn’t
We would rather say this plainly than discover it three months in.
When being wrong costs far more than the work does
- Wrong prices on millions of live items, in front of customers
- A compliance obligation, where a miss is a regulator conversation
- Fiduciary duty over somebody else’s money
- A platform a hundred thousand businesses depend on
- An initiative that has already failed once and cannot be seen to fail twice
In that territory judgment is cheap insurance and speed alone is a liability. It is also where almost all of our work has been for twenty years.
When you could afford to throw it away
- A prototype you want in front of users this month
- An internal tool a dozen colleagues will use
- Something you are still trying to decide is worth building
Pick up an AI coding tool and build it yourself. Genuinely — it will be faster and cheaper than hiring anyone, and if it comes out wrong you can bin it and start again. That is the right call, and we will tell you so.
And if we’re not right for you, we’ll still help.
Talk to us and the first thing we will tell you is whether you need us. If the answer is no, the conversation does not stop there — we will hand over what took us a year to learn, free, because we would rather you built the thing well than hired us to prove a point.
Which tools, and which to skip
What we use, what we tried and dropped, and what each one is genuinely good and bad at.
The habits we learned the hard way
Where these tools go confidently wrong, and how to ask so they don’t.
How to test what comes back
The review and testing process above, explained well enough that your team can run it.