There are two anecdotes that color my opinion here.

1. If you'll recall I worked for a while inside a tech startup building a mobility app. Dev work was split into a small onshore and a large offshore team in India. The onshore team was, essentially, the product manager and four coders of varying seniority. The offshore team was something like 20-30 fulltime developers? If there's anything I'd want to get built or get changed I had a feedback slack that the onshore devs would process into Jira. If there was anything big that I needed to be implemented, I'd get the onshore junior dev to essentially parse my request into Jira for me, often after a few meetings because chopping my idea into baby-sized steps is never a straightforward task. It'd be well-documented what the desired change was, and what the steps were to get there before it went to offshore. Then a week or so later they'd be working on it and have a bunch of extra questions. Then I'd get a new TestFlight version of the app, I'd do a bunch of testing with that, and would often come back with half a dozen edge cases and misinterpretations. Back and forth, testing, questions, back and forth, testing and then it would usually be fine.

2. A good friend of mine works for a Dutch competitor to EPIC. She graduated CS just over a year ago. Basically landed the job as a college intern and was allowed to stay. The first months of her job, she was not allowed to write code, instead just having to review other people's code in order to initiate osmosis for the inner workings of EHRs because there is, essentially, no documentation. The entire company from what I gather seems to operate on tribal knowledge, the elders passing down quirks and edge cases that stay in. It is also company policy to forbid writing any documentation in the code. Instead of documentation, they've created a layer cake of processes that code has to go through to be reviewed and checked. The processes are well-defined, but what goes through it could be whateverthefuck. Most of the time, the changes are very small. They're scared to accidentally break anything in production (and hey, rightly so!) but that also means they rarely change anything large, so the codebase is never refactored and is a layer cake too of cruft accumulating by hundreds of individual developers making changes and writing code in their little corner of the monolith in their particular way.

Are... you going to explain to the AI fleet why that bug has to stay?

You don't think you can include that in the prompt? Or documentation it reads? I had to regularly instruct the offshore team to do things in a particular way in the app, because I was using a third party tool for our analytics and that tool needs data in a specific way to work. "Yeah I know this is not ideal but can you please define sessionID as text, even though it always consists of numbers only?"

The timeline in the past half year or so has been wild, in my humble opinion. When the term vibecoding was coined this January, Claude 3.5 was the best we had, which is (still) quite good at writing a few dozen lines of code but gets lost as soon as it's even slightly bigger than that. My first vibecoding experiences were...rough. The improvements in the past months have been incredibly siginificant but specifically for coding. For my first vibecoded app I had a prototype in 2 minutes and would spend a good hour or two debugging by "there's a new error, go fix it" again and again. For the OVguesser app I mentioned in Pubski? I had a prototype in 2 minutes and...essentially only one or two bugs, despite being a more complex app with 50+ files spread across client and server. I could go straight to "this is great, let me tweak it until I'm happy". Adding reasoning, better prompts, and most of all tool use (you tell the AI how it can Google something, how it can grep a file, how it can use any tool you can imagine) has dramatically improved its ability to do the vast majority of software work. I used to be able to tell AI-gen code from regular code apart. I lost that ability - there are no longer six fingers on the hand, the lighting isn't "off" anymore, especially not with the right prompt. When I showed my EHR friend this week the code Sonnet 4 produces, she too could not find anything bad about it. It genuinely just writes decent code now.

The size of what it can write has dramatically increased, from autocompleting your sentence in an IDE to writing functions for you to, now, being able to writing an entire app out of nowhere that sometimes actually works. Now - that does not mean Jesus can take the wheel. I know. The main issue, now, is that the agents are not very good at exploring the solution space. When the code base becomes larger, they often struggle to take the logic of line 265 in file A into account when writing line 1,038 in file B. Or they are too eager to jump to the first solution that sounds remotely like it could work. So you end up with short-sighted solutions that break something else somewhere. It really, really needs checks and balances now to prevent the &nbsp's from happening but let's be honest, do you realized how often shit breaks in normal software developers? Are the blanks you are getting from the EHR API any better than the &nbsp's because those shit sausages were made differently?

Even if there is not a single inch of progress in the models, I'm fairly certain we'll still see progress in the coming years in the ability of AI to improve software engineering. What I didn't know, until reading this article, is what that future could look like. I don't think the blog is a blueprint? There's every chance it will be kneecapped in multiple ways? But I'd be surprised if this is not the direction we'll be heading in for the next few years. Right now we're in the It Moves Fast And Breaks Things era. But that era will end and I'm intrigued slash terrified slash in awe of what that might look like.

The upcoming wave, which I'm calling "agent clusters" – the chariot I hinted at in the last section – should make landfall by Q3. This wave will enable each of your developers to run many agents at once in parallel, every agent working on a different task: bug fixing, issue refinement, new features, backlog grooming, deployments, documentation, literally anything a developer might do.

In a way, some of this is already here and working, just in small pockets. NotebookLM's podcast feature is a single button to the user but behind the scenes it is basically an agent cluster that takes a document, creates a podcast script, refines the script to add uuhs and ahs and other vocal nuances, and text-to-speeches it. Not just in a single pipeline, but even on-the-fly when you "call into" the podcast. You take a complex task, break it up into its constituent parts, and refine an agent with a specific agent-prompt and toolset. Then you tell the smartest AI you can afford "these are your minions, go do this overarching task" and have only that one talk to the human in the loop.

From my experience, both this concept of agent clusters and vibecoding feels eerily similar to the way I worked at that mobility app. The onshore dev I worked with the most was a junior dev. He wasn't particularly bright or experienced (he was the same age as I at the time) but he had a) a few tools at his disposal b) he knew what the architecture of the app looked like and c) he was somewhat good at reasoning about code (but I'd often be just as good). His task was to pour my request into the molds of the Jira processes they were used to and he would delegate everything else to his offshore colleagues to actually do. Along the entire process of going back and forth with the junior dev and at times with the Indian devs I'd do nothing different from what the article describes as agent babysitting. And the results of that process was often just, like, implementing 1 new class or function call in the backend.

I also don't think my friend at Not-EPIC should be unworried. She knows how wretched the way they develop is. She doesn't know what her code does IRL or what workflow it could break. This fall she has a surgery coming up which will knock her out for a good three months. That means for three months, there are exactly zero people available to deal with problems in her corner of the monolith. When people leave the company (because of course they under-pay and over-ask) it often results in a plethora of problems because the next person put on that bit of the system breaks a bunch of shit because there is nothing documented.

My expectation is that management will, sometime in the next years, realize that they can actually fix the fundamental problems with their organization and get more done. Get everyone to talk through the code they manage, record and transcribe it all, and autogenerate the mother of all documentation and mandate docs updates from there on in the code change process. Now you're no longer dependent on tribal knowledge and expensive senior devs. Then, talk to every client about all of their wishes they have, for as long as the client wants. Record and transcribed it all and generate the mother of all backlogs and requirements. You give every medior or even junior tasks from that list and assign them an agent cluster, only requiring the senior devs for the aforementioned checks and balances. They could even take all 8 hours of a work day just for picking the tasks and for checks and balances, and have the agent cluster work throughout the night to provide new code to check and balances.

But I highly doubt all of that will require more devs.