Try getting a development team to consistently write tests before every commit. Not "agree in principle" — actually do it, without reminders. Or document their code. Or have a senior engineer support code three juniors wrote six months ago.
If you've never managed developers, this sounds like a process problem. If you have — you understand why what I'm about to describe doesn't surprise me anymore.
The standard playbook, tried for 10 years
A company in warehouse logistics. Complex domain: multi-site warehouse management, integration-heavy, layered placement and picking rules.
Ten years of building the automation platform with external teams. The team grew. There was a CTO. Specs were written. Budgets spent. And the output was unstable legacy code where every deployment was a nightmare. Clients churned.
The usual overhead: coordination costs, telephone-game communication between analysts and developers, management friction, human error. The team got bigger. The system got worse.
At some point the founder — someone with deep domain expertise in logistics and an engineering background — cut his losses, scrapped the entire codebase, and rewrote the platform alone. With a different foundation.
What "different" actually means
This isn't a story about using AI to write code faster. That's a tool.
What the founder built was mature AI infrastructure: an agentic loop with proper orchestration across every stage of the SDLC. The difference matters: a tool plugs into an existing process and speeds up individual steps. Infrastructure replaces the process itself.
Six months of results
Deployment frequency. Instead of painful nightly releases followed by "nothing works in the morning" — 10 to 15 deploys per day during business hours. Users notice nothing. Not a delivery target, just the default operating mode.
Stability. Thousands of automated tests run before every commit. Six months in: zero system failures. Not "significant improvement." Zero. The logging infrastructure pipes automatically into tickets.
Throughput. What used to take a full team's two-week sprint now takes 10 to 30 minutes. Tasks are broken down jointly by the human and the agent.
Documentation. AI updates multilingual help files and API specs daily. It takes fresh interface screenshots and inserts them into the docs — automatically, every day. The thing teams plan to do and never get to is running on autopilot.
First-line support. When tickets come in, the agent reads the logs, reconstructs the user's session timeline, and surfaces a hypothesis — where the collision happened and why — before the engineer opens the ticket. The engineer looks at a diagnosis, not raw logs.
Why this is different from "AI as a tool"
When finance teams tried to replace accountants with Excel, or analysts with SQL, it was messy. The tool required people to adapt to it, created new skill requirements, and didn't eliminate the fundamental coordination problems.
Deep domain expertise combined with mature AI infrastructure cuts through those problems at the source. The coordination overhead goes away. So does the telephone game between roles, the management friction, the human error in the loop.
One person who genuinely understands what the system should do and how — in this combination — ships a higher-quality product faster and more reliably than a classic development department.
Not because the person is more capable. Because the coordination layer is gone — and that was where most of the resources were going.
The prerequisite
This only works under one condition: the person needs genuine domain expertise — enough to specify precisely what the agents need to build.
The founder in this case knew warehouse logistics from the inside. That's what made it possible to define tasks at the level of detail the agents needed. The AI infrastructure multiplied that expertise. It didn't replace it.
That's also why companies trying the same tools get different results — the tools are there, the expertise in the right place isn't.
I've seen this pattern more than once. The core role of people in software development is over. There are enough examples now to stop calling it an edge case.
The question is where you'll be standing when it gets to you.
If this is where you are right now — you know where to find me.