It has been almost a year since my last blog post. This terrible track record is on me, I really should commit to writing more. So, what on earth spurred me into action to write now? That would be the deep desire to jump on my soap box as if I am at Speaker’s Corner.
I have always enjoyed the writing of Steve Yegge. He is clearly a very experienced and accomplished engineer. His writing on the Sourcegraph blog has been great. But his post on 22 March 2025 titled Revenge of the junior developer was the kick up the backside I needed to write again. I recommend you read it before you continue with this post because I will be “Don Quixote-ing” my way into some of the windmills I have picked out of that post.
Buckle up fellow nerds! This one is not for people with weak stomachs. There will be foul language… and I am possibly going to go full Karen… you have been warned!
(If you want to get into the full spirit of this post then may I suggest you pair it with Anarchy in The UK by the Sex Pistols)
Opening credits
For almost two years I have been building LLM based applications and solutions, or “AI” as most people now seem to call it. Not only have I been building solutions that use it heavily to solve problems, but I have also been using AI agents and IDEs for the development of these solutions.
Two years is sufficient time to get so close to the tech that what you see as normal is actually not the norm.
On top of that, if you did not know, I don’t live in Silicon Valley or in a Big Tech “scene”. I have been a tech consultant for a large part of my career and then went rogue and became a freelancer, before going mad and bootstrapping a startup.
So why am I telling you this? Because I want you to know I come from a world where your mouth needs to write cheques that your arse can cash. If you can’t deliver what you say you will deliver you won’t be in business for long. Also, you carry liability for the work you deliver. If you screw up on a project you can and will get sued for damages. We will get back to liability later, just let it sit there in the back of your mind as you keep reading.
Commentary on the “Waves”
The first thing that kicked me square in the “WTF?!!” was the “six waves” presented at the start of the post. Even though we are told that this is coming from “Exaggeration Central”, we are still introduced to the timeline of how chat-based vibe coding is going to be obsolete by Q3 of 2025. Yes, you read that correctly. Vibe coding is evolving, and the evolution is spectacular!
Below is Figure 1: Overlapping waves of AI coding modalities, taken from Steve’s blog post.
The following is a direct quote from the post.
The chart in Figure 1 depicts six overlapping waves of programming: traditional (2022), completions-based (2023), chat-based (2024), coding agents (2025 H1), agent clusters (2025 H2), and agent fleets (2026).
Holy *&^%&^ batman! Forget that these tools need CONSTANT supervision to ensure they don’t go off the rails. Forget that a single chat-based LLM in “Agent Mode” can already generate more code than an experienced developer can review in a timely fashion. Just forget about all of that because what we have to look forward to is “agent clusters” in less than 6 months’ time, and “agent fleets” in 2026. (On a side note, who has money on the job title Admiral of Architecture appearing on a job post soon?)
There is another industry where this sort of “like cures like” thinking is very prevalent. Yes people, I am going there! This sounds like the tech equivalent of homeopathy. Because if Agents cause issues then surely MORE agents would be the cure.
Now if you are thinking “surely Christo has gone mad, or he is now just a coding boomer coming to spoil our fun. This like cures like stuff is just an old man running at windmills”. Well may I present to you the solution proposed to keep those AI Coding Agents in line: (Figure 2: FY26 Org Chart from Steve’s blog post)
I present to you AI Managers! Are you starting to see that homeopathy analogy come to life yet?
Productivity gains
Right, that was a lot of ranting and raving. I think you probably want a break from my soapbox antics, and I need to have another hot beverage (probably one with less caffeine).
Let’s slow down and now look at some of the productivity gains that people claim all of this produces.
The blog post in question states that each new modality in coding brings a 5X to 10X productivity boost. This is also the sort of figures you see thrown around online on LinkedIn and Twitter, sorry I mean X.
What no one is talking about are the details surrounding those claimed productivity gains. Think about it, is this how much faster you can generate code? Is this how much faster your team completes work? Which parts of the work are we talking about? All of it?!!
It matters knowing what the claims apply to. Most of your time as a software engineer is not spent writing code. Yes, that is correct, most of your time is spent gathering requirements, speaking to users, other teams, speaking to your own team, doing code reviews etc. It is not just sitting with your headphones on cranking out code.
Another thing that is very rarely mentioned when these claims are made is the type of environment they are realised in. Is this an indie dev working on their own? Is this a large development team working in a larger organisation? All of this matters.
There are clear signs that indie devs and small teams have a much bigger performance increase than teams in large organisations. You can already guess why that is right? That is correct, it is because small teams that can operate autonomously always move faster than large teams that need a lot of additional coordination to keep things on track and aligned to the overall goal.
The argument can be made that there are tons of productivity gains to be realised in larger teams by simply helping make these teams more autonomous without introducing tooling that can create an avalanche of code each day.
This brings me to my next point, what is the word on the street where people are currently using these tools?
Where the tyre hits the road
Let’s start by mentioning another blog post that made it to the font page of Hacker News. This one is called Why LLM-Powered Programming is More Mech Suit Than Artificial Human by Matthew Sinclair. It strongly aligns with my own experience using these tools daily.
Now Matthew looks to be a seasoned professional with bucket loads of experience through many different roles. What stood out to me was his mentioning of the vigilance required when working with a coding agent, a single coding agent not a cluster or fleet of them. He was specifically talking about Claude Code.
Here are some quotes from his blog post.
With great power comes great responsibility. You must maintain constant awareness when working with AI coding tools—something I learned through several painful lessons.
Claude Code occasionally made bewildering decisions: changing framework code to make tests pass, commenting out whole sections of code and replacing them with hardcoded values to achieve a passing test rather than fixing the underlying problem, or introducing dependencies that weren’t necessary or appropriate.
…
Taking your eyes off the process, even briefly, can lead to trouble. In my case, the backend required three complete rewrites because I looked away at crucial junctures, allowing the AI to go down problematic implementation paths that weren’t apparent until much later.
Let that sink in for a moment. Then read the next quote.
For me, using Claude Code has been a learning exercise in itself. Progress often felt like two steps forward and three back, particularly in the early stages. Generating 20k+ lines of code became relatively straightforward on a daily basis, but knowing when to throw everything away and rebuild from scratch—that took 30 years of experience.
20k+ lines of code generated daily. Stew in that statement for a bit. Can you imagine having to review that amount of code daily?!
Can you ensure that the code will be of good quality, that the agents have not gone off the rails in a moment where you looked away and took a sip from your avolatte? If you say to me “yes” then I am going to call you a liar right here and now. It is simply not possible for a human to review and ensure code quality at that scale each and every day.
So obviously the only way to handle that volume of code is to have machines do that work. But if the machines writing the code can go off the rails, then surely the machines checking them can go off the rails too. See where I am going with this? DO YOU SEE WHERE I AM GOING WITH THIS?!!
Let me illustrate with a picture.
The revenge of Liability
Hello liability my old friend… you have come to talk to us again… because a vision is softly creeping…
It is time we speak the name of the one thing in GenAI no one wants to talk about. L-I-A-B-I-L-I-T-Y
Everyone wants to sell you an agent or a service where you hand over your money, but you keep all the risk and liability. Can you imagine that ever happening when you bring in a freelancer or a consulting firm? HELL NO! Consulting firms and freelancers cannot simply put a little sentence on a screen that says, “People make mistakes so please be aware of it and double check everything”.
No no no sir, we carry liability for our work. Don’t believe me? Think I just made that up? Let me tell you that I have been on projects where the consulting firm I was working for needed a project signed off by its parent company due to the project carrying unlimited risk. Yes, that means that if we did anything that caused damage to the client, they could take us to court for whatever amount of damages we caused. Literally they could sue us and the parent company for any amount even if it means the whole group of companies went bankrupt. (That type of project makes you think twice about spouting BS to a client)
As a freelancer I must have insurance as well for exactly this same reason. Clients demand it because otherwise they are left out of pocket when something bad happens and I am unable to pay the damages from my own assets. Oh, and as a startup we also need insurance with minimum amounts dictated by the clients that we do business with.
Why am I droning on about this? Because it is the answer to adopting the fantastical “Fleet of Agents” scenario.
If you are willing to accept liability for your Fleet of Agents’ output, then I am willing to sign up to that service. Yes, you must accept the same liability a consulting firm or agency accepts when you engage them for work.
We already know that humans will have to trust the AI Managers that oversee the Coding Agents because no human will be able to review all the work produced by a single coding agent in full flow, never mind a Fleet of Agents. So, the seller of this service or tooling needs to be willing to accept liability. If they don’t, then you are clearly not confident in the output of your product.
If we need each human to check every line of code, then those fantastical 10X productivity gains are starting to look more and more out of reach won’t you say?
What about the junior developers
I cannot help but get one last jab in at the ludicrous idea that junior developers will do much better in this new world of agentic coding cluster armadas. Do you think, after everything that I have highlighted, that junior engineers will have the skill and intuition to deliver better outcomes in this new world?
If you do then please reach out, I have a supplement that works for all ailments and has no negative side effects. Big pharma does not want you to know about it…
What we need is even more rigorous training for those in our field that will oversee these tools. The amount of damage that can be done is orders of magnitude more with these tools than when you wrote code by hand. I am inclined to say that those productivity gains of 10X are more realistic as damage multiples in the hands of someone that does not know what they are doing.
Before you get on your high horse and come at me with your posse of agentic agents, I am not anti-junior. Relying only on the experienced developers is not an option because we all end up being a junior in some way shape or form at certain points when we tackle something new. So just because you are experienced in one domain does not mean you are not going to juggle chainsaws like a vibe ninja and lose your limbs when you tackle another domain.
We need to hammer home the fundamentals now more than ever! We need a new appreciation for knowing the fundamentals because only those that know them will be able to call bullshit on the “agent fleet” when it goes off the rails. Everyone else will be vibe coding their way into an episode of The Lazarus Heist. (Go listen to the podcast, all seasons of it. It is amazing!!!)
Wrapping up
I have had a lot of fun just “vibe blogging” this post. No, I did not write a single piece of it with AI, I cranked up the tunes and simply wrote what was on my mind without much of a filter.
Where we are at today in tech feels a bit like one has stumbled into a trance party by accident. There are vibes all around. People making bold claims, while others are just chilling and embracing things one moment at a time.
I cannot help but get angry at some of the ridiculous claims being made. Especially because they are so far removed from my own experience over the last two year, and because I see the damage these claims are already causing.
We have not even touched on issues such as security, data sovereignty, financial feasibility or any of the many other things that factor into this discussion. I might write some more about that at some point.
What I do know is that we need to call bullshit on things loudly and more often than we currently do. This tooling is not magic and making exaggerated claims that read like fan fiction is helping no one in the real world.
I cannot predict the future, but neither can anyone else! What I can do is point out the flawed logic of some of what we are being bombarded with at the present time.
Things could change tomorrow, there could be a breakthrough that completely changes things. When that day comes, we will adapt.
Until then, I will catch you on the flip side.