Coding is Dead, Long Live Agentic Engineering
We’re calling it folks. Coding is dead.
Agentic Engineering is not only alive, it’s the main attraction in the AI revolution.
Every engineer should be ramping on Agentic Engineering (prompt to code, Claude code, etc… ). On my team I’m setting a goal of 1,000 hours of prompt / or vibe coding experience for every engineer by the end of 2026. We may go higher. I think this is about the minimum to become a competent practitioner of this new art.
In my last couple posts I argued for what is now rapidly becoming the consensus opinion. Models will write the code, all of it. Humans can not compete with Model generated code. A couple hundred years after it started, The Industrial Revolution has hit coding. Coding has now automated coding.
When I say coding, I mean directly writing, editing, or at some point even viewing individual source files, lines of code, etc. I do not mean software engineering. That is just changing and moving to a new level of abstraction.
As Steve Yegge pointed out, the resistance to this is mainly in the group of engineers with 10-15 years of coding experience. Change is hard, and for those who have built up a large corpus of knowledge and an expert level of craft as a coder there will be a transition. Clopus (Claude Code + Opus 4.5) is now your coder. Don’t worry your skills and knowledge is not going to be devalued or irrelevant. Just the opposite, this new set of tools is going to turbo charge your output. But a huge retooling and ramp of knowledge is required, don’t miss the boat!
Clopus, (or more wild projects like OpenClaw) are bringing an army of billions of expert coders. There’s no question this is happening. The only question is how to react to it. Will we grab these tools and embrace the learning and tremendous acceleration that come with them? I believe so, and those who get started on that transition right now will do the best.
Come with us on an exploration of what is possible with the massive leverage that AI code generation brings.
Dynamic Capacity
Over the 30 years I've been working in b2b software companies I’ve come to understand the core differentiator between low-to-mid success vs high performance and massive success is the engineering team's ability to maintain dynamic capacity for the business.
I defined dynamic capacity within an engineering team as its ability to change and adapt itself and the systems it has created to meet new requirements and challenges. This is why engineers who are great at refactoring are so valuable. They maintain the team’s dynamic capacity to move forward. Refactoring = adapting the code to meet changing demands.
Clopus (Claude Code + Opus 4.5) is a watershed moment for this ability. Agentic engineers using Clopus are playing at a level of dynamic capacity far above line-by-line coding. And we’re just getting started, even with no model improvements, there is a gigantic overhang of capabilities yet to be unlocked with improved tooling and understanding. Pair that with Clopus being the worst it will ever be and the future is exponential in terms of software creation (we are only going up from here).
DORA and High Performance Teams
In many ways the core tenants of DevOps, the habits and practices of high performance teams, can be boiled down to this:
High performance teams that create outsized success maintain their dynamic capacity to keep creating software. They don’t slow down, they speed up.
Anything that maintains or increases a team's capacity to produce more software reliably has an outsized impact, dwarfing all other improvements. That’s the key take away of DORA. When you improve your workflow, you improve all work.
As an aside: This is the key insight into understanding why improving LLM model intelligence is so powerful. In base terms, when a model gets slightly better, it then applies this improvement in understanding and reasoning across all human knowledge at once. The future is exponential because increases in any model baseline performance (speed of hardware, speed of algorithms, strength of algorithms, size of network) immediately create an exponential increase in capabilities across the broad spectrum of all human knowledge. This is especially potent in computer use and coding, because model improvements are immediately and directly visible and applicable. Clopus is an inflection point because it gives an accessible and direct way to translate model improvements to software creation efficiency improvements.
Engineering Dynamic Capacity drives to Exponential Outcomes (Positive Feedback Loops)
It’s important to understand the interplay of engineering team performance and the businesses they operate within.
When you pair an engineering team that maintains its dynamic capacity with a business team hungry for success you get explosive growth and outsized financial outcomes. This is why team and execution typically trumps ideas in software ventures.
Every startup success story, every pivot, every zero-to-one adventure is an iteration of this. A hunger to create a business intersects with an engineering team's ability to create and automate solutions continuously at scale.
There’s an important interplay here. Come along with me on a story of divergent paths. If you’ve been around for a while you’ve seen these different stories play out.
Bob the CEO:
“Hey team we got funding, I just hired you, and we’ve got our first opportunity to close some business deals, build this thing and I’ll sell it".
Two very different outcomes then occur:
High Performer Team:
"Yes! We love building and delivering software."
2 weeks later, some sort of demo or product is delivered to the Bob. He goes and sells it to the customer.
Low Performer Team
“Wow that is a big product, it’s going to take probably a year or more to build that."
The team goes into a tailspin over how to build and scale, bogging down in any number of minutia or technical constraints.
Let’s go with high performance team. Because the low performance team just failed to launch and that startup is now dead.
Two weeks later...
Bob the CEO:
“Hey that was great, but I talked to the customer and they actually want this other thing, they’ve got a check ready if we can deliver.”
High performance Team:
“ok, well I guess it’s just lines of code, we’ll rewrite it or throw out what we just did, and build the new thing. Let’s go!”
They get to work and get something back to to the business quickly, again, even if it’s not perfect.
Mid performance team:
They are now tired from last week. They’re pretty proud of what they created. They say back:
“But last week you told us to do something different, we can’t just change everything now."
Again, let’s go with the high performance story (the mid performer just leveled off and created a small niche business).
Dynamic Capacity Virtuous Feedback Loop
Bob's high performance team is killing it. He's excited about their work and goes out to the market again. Bob's optimistic about the future, he is starting to see a pattern: I find business, and the engineering team delivers a solution for me to sell. The high performance team also learns an important lesson, “when we say yes and adapt and keep creating, the business keeps growing. It’s hard work but it’s fun and we’re gonna be rich!”
The true high performance team keeps accelerating in this fortunate feedback loop with the business and sales team. Exponential growth occurs.
Of course the details are complicated and nuanced, but if you step back you see that,
Every conversation between the business and the engineering team is an opportunity for these paths to start to diverge.
In significant ways every book by Martin Fowler, the Agile Manifesto, the DevOps metrics, CI/CD, Test Driven Development, DRY code, and all the other concepts and practices that we hold so dear is an attempt by great engineers to build systems and organize teams to maintain this type of dynamic capacity for change and growth.
Remember the first time you learned about functions? Or Arrays? That ah-ha moment was you leveling up your dynamic capacity to create software you can adapt and keep extending and building on top of. Sure you can build a simple BASIC application with GO TO statements and no functions, and you can get it to do some cool stuff, but what happens when you need to change it? What happens when someone else needs to change it? I know I’m telling you things you already know, but for our purposes here think of these as tools to maintain your dynamic capacity to adapt and meet new and changing demands.
As an engineering leader, this is my singular guiding principle: Find ways to keep saying “yes we can build that” to the business (aka the customers).
The Claude Code Team and Boris
In a recent interview, Boris said something very telling, he basically said that now when he does code reviews he doesn’t hesitate to ask his team to add more unit test coverage, because Claude Code makes it so easy for them write these. Previously it used to be a big ask. I think we’re all familiar with this. “Hey can you add some more unit tests to cover XYZ” in a code review. You can almost hear the resulting “ugh” on the other end by the developer who has to go back and add these in order to get through the code review. No longer, Claude Code makes it easy. I’ve found myself just saying “Claude… look at the PR comments and address them all.”
So let’s imagine that Claude Code + Opus 4.5, our buddy Clopus, was only good at writing unit tests.
This alone, in the hands of a capable team or engineering lead, is exponential technology.
Why? Because it dramatically increases a team's ability to maintain its dynamic capacity.
More unit tests = easier refactors = “Yes, we can build that!” answers to the business.
Of course, Clopus can do a lot more than that. And it’s just getting started.
Recommended by LinkedIn
# The Agentic Engineering Exponential Path
Let’s travel along the exponential leverage curve of agentic engineering. Engineer with Clopus and daring to go where no engineer has gone before. If you haven’t already, get started on this learning path right now in a serious way.
1 * 1: Coding
The old way. Sit down, write code, drink coffee, repeat. Every line of code typed or tab completed by an engineer.
1 * 1: Prompt to Code
The first goal of the agentic engineer is to become proficient at prompt to code techniques. Clopus at the core is this. You tell it what you want it to code, and it goes right to work doing it for you. You are pair programming with the world’s best coder (for all practical purposes), but it’s always day 1 on the job at your company, it misunderstands your directions (probably because you weren’t clear). It also is really good at iterative improvement. Steve Yegge pointed this out, these models might get 60-80% correct on the first shot. You’ve got to keep steering them to iterate and improve.
You all know about this. Context is king. Prompt engineering. All the techniques to steer and correct the AI Coder.
First there was prompt libraries, then slash commands, MCPs, skills, ...
1 * 1: Planning or Spec to Code
I’ll break this out, because it’s the precursor to multicellular life. Some sort of primordial soup that is starting to create symbiotic relationships between the engineer and the coding agent.
First we got BMAD, now GSD, Ralph, and even Gas Town (and it’s mitochondria, Beads, and oh did you hear about the upgrade to Claude Code , todos are now persistent tasks.
Now coders are turbo charged in their daily activities. And because of this they have leveled up significantly in dynamic capacity. Need to do large scale refactor, no prob, I’ll whip up a GSD plan, I’ll set my agent to work, and prompt it along the way to keep it on track. Go down he wrong refactor path that would have previously taken you days, you just did it in hours, so just git reset and try another way.
Gas Town starts to move beyond this. You start to see the multicellular organism forming. Place your prompt or GSD type plan into a Gas Town factory of agents, they get to work completing all of the tasks.
In its current form this is still 1 engineer creating one stream of work. I’ll try to explain why this is just the start of the exponential leverage curve of agentic engineering:
1 * n: Autonomous Agents producing Code
Gas Town, and maybe Ralph on top of GSD, is almost there. These may be creating a lot of AI slope code right now, but you can still see the future, these are going to start to work, and when they do it's going to be another step function.
There’s an interesting tool chain that everyone in the know is starting to implement: You go get a Mac Mini (or the Rolls Royce Mac Studio). And you setup your always on agent coding buddy Clopus:
For bonus points you setup Termius and you become that crazy person talking to your agents while you walk your dog. “Good boy Rex! Clopus I want you to continue refactoring the socket layer to include fault tolerance with retry backoffs. Remember I want e2e tests and TDD development."
You no longer build code on your laptop. This is too fragile and short lived. Close your lid, or loose connectivity, your entire software factory goes on strike.
You know you are ready for this change when you do either of the following:
The creator of OpenClase, Peter Steinberger, recently was talking about how he knew he had a problem when he was ignoring his friends at dinner to vibe code on his phone in a terminal setup like the one above.
Then you make the shift, you setup your always on agent coding environment. You get a desktop (maybe for the first time in quite a while) and setup the Clopus tool chain, you might write your prompts on your laptop and look at code reviews there, but you’re building continuously so that’s on your personal server. Congratulations you are a two cell organism. The singularity is nearer.
Your new friend Clopus is always hungry and you’re trying to keep it fed with prompts all the time. We aren’t working less, quite the opposite, but we are getting way way more done. Your creative output just went through the roof, it’s exhausting and satisfying.
Since I started writing this, OpenClaw / ClawdBot / Moltbot has taken off. It’s pushing the boundaries and moving us quickly from 1 * n autonomous coding agents and is poised to take us into the next phase:
n * n: The Software Factory
This is the fast approaching world of agentic engineering.
The software factory is a collection of people and agents writing code together. Agents no longer belong to particular human counterpart. They live on their own and operate continuously. You may spend some time 1:1 getting your agent onboarded and productive, but then you are going to let them loose to interact with everyone else in the factory.
If you’ve moved to the 1 * n world, you’ve got your home server running the Clopus tool chain, and you work in an organization with other engineers starting to do the same, I think you know what I’m talking about.
If you don’t know what I'm talking about, just trust me and start working your way up the stack. Start with Claude Code, earn your apprentice credentials and work towards that 1,000 hours. Go install GSD, try creating some Ralph style loops and agent orchestrations. Then get your rig going and your “always coding” home or desktop server for this setup.
We’re moving into the future and it’s one where it’s not just Human Agent = multiplied leverage, it’s Group of Humans Group of Agents = Exponential Leverage.
This is the hard take off.
n * n: Are there less human engineers?
Ok, let’s say you get this factory setup. You have infinite (N) agent coders. Do you now eliminate the (N) humans?
Heck no. You want more of both. You are churning out software products and solutions at a rate never before seen. You turn up the dial to 11 and you go!
For me, what this looks like is probably something like this:
There is a core group of Agentic Engineering Wizards. They fundamentally get it, they have deep engineering knowledge and systems thinking experience, they also are the type of engineers that have great capacity for empathy and understanding customers and the business.
They build the core set of agents. Maybe they build the agents that build the other agents. Or the agents that improve the other agents. They architect the factory and ensure that new factories can be setup easily.
Then there is an ever growing network of agentic engineers and agents working together within these software factories to create bespoke, highly targeted and tailored solutions for customers and internal users. If you love building and delivering software to solve real world problems, this is going to be your jam.
These teams and organizations will embed themselves within their customers, extending the factory and network straight into the customer organization. They will transform industries. Their customers will flurish as they are unblocked on technology and allowed to think and build at much bigger scales.
The successful versions of this n*n agentic software factory will spread very quickly subsuming all current software verticals and the businesses that adopt and leverage these solutions will consume and dominate the general business landscape.
This is what people mean when they say SaaS software is dead. The fundamental building blocks are just:
Everyone will customize the stack for their specific needs. It’s hard to see where most current SaaS solutions fit in this mix, they feel outdated and redundant now.
A Note on The Details: Test Driven Development
It’s interesting how best practices in engineering extend directly into this era of agentic engineering.
The key unlock of Agent Coders is testability of the systems they are building.
Agents succeed when they can autonomously test and verify their solutions. You get predictably poor results without this.
This is why I’ve been focusing on test automation (including full agent driven autonomous end-to-end testing) within our systems and engineering teams. This is the foundation. Luckily these tools make it a lot easier to build these components as well.
If you do one thing to prepare for full n*n software factories, it is to build full test automation and plug that into your agent coders build and deploy pipeline.
CI/CD for the win as always.
The Tote Software Factory
I’m the CTO of Tote.AI. We’re building a software factory for our customers. We’re transforming ourselves into agentic engineers and our customers right beside us.
Get your 1,000 hours of agentic coding experience and let’s go into the future together.
Love the direction. Big vision. Real question is can it scale reliably in production yet? And if not when ... I am sure it's coming. Just don't know when
The Dynamic Capacity framing is the key insight here. Most discussions about AI coding tools focus on speed — writing code faster. But the real unlock is organizational agility. When refactoring becomes cheap and testing catches regressions automatically, you can restructure systems in response to business changes instead of accumulating technical debt. The Software Factory model also shifts what engineering leadership actually means. Less time reviewing syntax, more time defining constraints and evaluation criteria for what the agents produce. The 1,000-hour requirement you mention is interesting too — the skill ceiling isn't disappearing, it's moving from writing code to architecting the systems that generate and validate it.
Your Software Factory Model makes perfect sense. Even non-engineering leaders like me are now capable of coding, and doing it!
I'll go through the whole document, but encouraging Clawbot or openclaw, needs consideration. Agents need firewalls and should not have full system access.