Something funny happened last week. But also normal.
My agent lost its way. Not in the philosophical sense humans do. After all, let’s not anthropomorphise the artificial. But in a really practical way. It considered something done. And it looked done on a superficial level. But when you dug deep into the issue, it wasn’t.
The task was simple. Make a field in the UI editable. The UI was perfect. It looked good, the field was really editable and persisted across sessions. However, after a deeper investigation it turned out the edit only happened at the local storage level. Nothing hit the backend to update the value. Trivial. Yet the mistake was made.
The hype
A year ago agentic harnesses were the hype. Everyone was doing them. Or at least everyone in the bubble of early adopters. Now a lot of companies use Cursor, Claude Code, Open Code or another harness. Even the laggards. We went through tokenmaxxing, saw this isn’t sustainable, learned what we could (or at least we thought we learned something) and the CFO cut our budgets. The laggards skipped that whole fiasco and just started using the stuff. Probably in a somewhat responsible manner.
Now we’re seeing the same thing repeat with dark factories. It started in 2024 with Devin. It was a joke back then. Some other companies tried to productize it. I still think most won’t do a good job above the trivial stuff. But the cool thing is that some companies are starting to explore the space themselves. In the last few months we’ve seen more and more people talk about this concept and experiment with it. And the winning move seems to be building your own dark factory. Tailored to your company. Not just taking a generic solution off the shelf.
Despite all of this, I’d argue most teams aren’t ready for it. And might never be.
Code generation is easy
Implementing a greenfield software system to spec with AI was something we were able to do since around 2023 with the invention of Lovable (then GPT Engineer). This kicked off the era of vibe coding, even before Andrej Karpathy coined the term. All kinds of applications were launched. Mostly prototypes. People were excited that regular folks out there could code and see their idea become reality. Soon, however, some interesting security incidents started to appear.
People could launch their apps, maybe even some mildly successful software businesses, just to get bankrupted because of basic security issues. Anyway, this got fixed in the coming months and people kind of got educated on it. And usually it was people who’d never done software development that got affected by this.
The more interesting stuff started happening when software engineers started using AI for code generation. This was happening in parallel, even before vibe coding. Professionals were excited by the amount of code they could churn out. And they weren’t facing as many issues as reported by non-software engineers. Productivity skyrocketed. People started thinking about 1-person teams, where a single engineer is the manager of a fleet of agents coding on their project. All software capacity issues were thought to be resolved. Dario Amodei even claimed that 100% of code would be written by AI.
But most teams fail at it
Despite that, Claude now has around 99% availability for the past 90 days. But that’s probably what you would’ve gotten pre-AI at a move-fast-and-break-things Facebook, or another fast-growing scale-up.
Most teams, however, fail even at code generation. Because in the real world you’re hardly ever working on greenfield stuff. You have a legacy big ball of mud that you have to push through. Each software change in that system might lead to something entirely unrelated breaking. This legacy system can be decades old or just your 1-year-old vibe-coded startup.
People using AI on such systems decide that they’re just going to review all code changes. But that defeats the purpose of using AI to write code. If I’m going to review each change, I might as well write the code myself. Otherwise, I’ll still end up with a really superficial understanding and won’t be able to catch the most important bugs and architectural problems in the system. As a human, I’m not a match for the speed at which AI generates stuff. And this builds on top of the false belief that the best way to understand what a software system does and how it does it is by reading the code, and later using that understanding to figure out whether the system has issues or is maintainable.
Those who decide not to review the code end up with a system that’s becoming harder and harder to extend with each day.
All else is 70%
To add insult to injury, most teams are failing at code generation. But that’s usually only 30% of all work that has to be done on a software system. The rest is spent on several broad categories.
First, understanding the why, what and how of a system. Which usually involves reading thousands of lines of code. Even though with the advent of Moldable Development, some engineers are finding out that there are much better ways to understand a software system. Ways that involve generating views on it instead of diving into the code. Which is more suitable for the AI era, and Claude Code or other harnesses have already started doing it. The agents write their own tiny contextual tools to do a job instead of relying on feeding the codebase into their context windows.
Second, if they’re lucky, actual interactions with customers to figure out what drives value and what doesn’t. I’m saying “if they’re lucky” because most engineers and managers still expect coders to just code based on a fixed specification. That’s hardly worked before, and it’ll hardly work now. Truly productive software teams care about their customers, and their number one focus is providing them value. They don’t play with software tools just because they want to play with shiny technology. They play because they want to bring value to the business and to the customer.
Third, collaborating with their peers and the broader business. A lot of software work requires navigating the complexity of an organization. No matter if that organization is small or big. Hardly anyone lives in a perfect world where there’s no politics, conflicting agendas or silos. You have to understand that context and use it to make the system you’re building a success.
And some teams are doing really badly on those 70% too. Apart from the code generation part. They gate reviews, gate customers, gate developers from “the management chaos.” It’s all gating, gating, gating. That reduces the engineer to a code churner. And hence makes people think the only thing they have to solve is how to automate the code churning. But if you’re bad at those 70%, you most probably won’t get much value from the code churning either.
The middle is solved
For those who understand how software should be built, the middle is already solved. Software is a learning activity with intense collaboration. The software you build is an automation for a business problem you’ve understood. Once this automation is in place, the assumption is that the business will get value from it. Because of reduced costs, increased revenue, or reduced risk.
The middle then is as simple as plugging in a framework like nWave or your own bespoke harness and making sure it’s tailored to your own high-quality standards and approaches. Which usually fall into three categories:
- Iterative, small step increments that you get feedback on;
- Test-driven development and proper acceptance tests. Shift-left QA;
- Modular and domain-driven architecture.
If your team is already doing those, then it can ship high-quality software for the long term. Fast. Encoding them into an AI harness is simple. The hard part was already done in the culture, discipline and practices you’ve built over the years.
Are you at the edge of AI for software development at the moment? Or just dipping your toes in it?
Either way, I’d love to exchange ideas. DM me.
