For many of the projects Diffco delivered in the last six months, AI wrote 100% of the code, and the cost of comparable projects has fallen five times or more. We deliver better products, release faster, and ship with fewer issues.
The model is the smallest part of that. The rest is a handful of decisions we make on every project — and this is how we make them.
Start with one question: are we building the right thing?
There is a long graveyard of products that launched and never reached their first thousand customers — thousands of hours built against a founder’s belief instead of a customer’s behavior. The most expensive mistake in software is still building the wrong thing well.
So every engagement starts with that question, and our discovery phase — one to two weeks — exists to answer it before anyone writes a specification. On a complex project we will have hundreds of conversations with the client before the architecture is settled, because the decisions are real: regulation, integrations, what the data actually looks like. A half-page brief for a complex product cannot produce a good result, no matter what generates the code.
The best brief we can get is a working prototype with real users. Roughly 70–80% of what reaches us now arrives with one — built in Lovable, Claude Code, whatever. That is a far better starting point than a deck.
The specification is the product
Once we know what to build, the work is the specification. Not a document that gets read once — a structured spec that agents execute against and that we verify output against.
That is what makes 100% AI-written code possible: the right specification, the right harness, the right memory management. Take any one away and the number drops.
One uncomfortable consequence: technical product managers now ship more complex systems than many career developers, because they write better specifications.
The harness decides where the humans go
Our internal delivery system runs on top of the current agent harnesses. Its job is not only to make agents faster — it is to decide where a human has to look.
Changing copy, images, or an onboarding flow? The founder or the marketing team can do that themselves, and the harness keeps them from breaking anything. That covers about 90% of what people want to try.
Touching the database schema? Stop. A human, or a stronger reviewing agent, looks first.
Pixel-perfect design? Still human-led with AI assist. AI is not there yet on the front end, and pretending otherwise ships bad work. I expect that to change within about six months.
A banking system moving millions a minute? Not autonomously. Not this year.
Compliance-heavy work follows the same rule — more oversight, not less — and I still expect 90%+ AI-written by the end of the year even there.
At one enterprise client, the department working this way ships 20–30x faster than the department next door that insists on pixel-perfect everything. Same company. The difference is the decision about where the human belongs, not the tooling.
Every architecture decision includes the maintenance bill
Software is never finished. Stop at version one and you die.
So “should we build this?” always includes “who maintains it?” Build-versus-buy has changed shape. We recently replaced a SaaS tool after a 10x price increase: found an open-source alternative in minutes, migrated in a few hours. Internal tools we wrote in an evening are now maintained by agents, not people. But it cuts the other way too. A company told me they rebuilt a complex CRM in two months with three developers and killed a seven-figure subscription. They also built about 5% of the platform they replaced, and they own it forever.
If a system touches six APIs — who monitors it? Who verifies it still works? Who verifies your AI won’t delete your data? If the answer to the last one is “AI,” the architecture isn’t finished.
Security is a posture, not a feature
AI writes far more code, far faster, so the risk surface scales with it. That argues for testing more, not for slowing down. A standard pentest is cheap. Most teams launching today still skip it, and doing it puts you ahead of nearly everyone. We work with third-party security partners and insist on at least some independent testing — clients rarely say no.
But across 18 years, roughly 95% of the incidents we’ve seen came down to people, not code — and the other 5% to systems customers declined to update. Disaster recovery, backups, incident response: those are company decisions, not developer tasks, and part of our job is making sure they get made.
The engineer we hire
People ask whether we still hire developers. We do. We hire the ones who can design a system that builds the system.
“Front-end developer” or “back-end developer” isn’t a role we can staff anymore — 99% of our work is full-stack across the board, and we don’t care which language you came from. What we care about: can you design an architecture that spans domains, write a specification an agent executes correctly, tell us what your observability stack looks like, and show us how you verify output against the spec. What was best practice three months ago isn’t today, so the real qualification is current practice, not years.
What you’re actually hiring
A senior engineer leading dozens of agents around the clock — 30–40 across our systems today, several of them assemblies of sub-agents, with hundreds the realistic next step. Not a team of developers with AI assist.
We have fewer developers than a year ago and we’re growing faster than ever. What hasn’t shrunk is the human work at both ends: understanding what you actually need, and knowing where to point the agents. Without that, it’s a very fast journey to nowhere.
Check full podcast episode here:
“We Don’t Hire Developers Anymore” — Silicon Valley Agency CEO on 100% AI-Written Code.
Weighing a move to agentic architecture, or sitting on a prototype that needs to become a product? We offer a free architecture review — no strings. Book a time with Diffco.
