A lot of the AI discussion seems to be focused on what these tools mean for an individual developer, but in a team setting any gains are at risk due to coordination tax and ideological friction. In my experience the ideological friction is most of it right now.
Figuring out a way to accelerate the process in light of the code writing bottleneck being removed is essential. I've observed a development team regress back to fully manual development because their daily PR/code review process is too slow. It doesn't matter how fast you write code if you can't actually merge it and ship it to the customer faster too. PR stacks can only take you so far before the conflict monster gets too big to fight.
I don't think AI can fix the process, ideology or people issues. I've seen how long an average PR review actually takes. If these employees were simply doing their jobs at all we'd be 10x better off regardless of AI. A truly skilled developer who makes a genuine attempt should be expected to solve 99% of their tasks within the same business day as of October 2026.
Burning down the backlog to zero doesn't mean the development team will be subsequently laid off. Quite the contrary. It will create a vacuum that the business will fill with new work that may incidentally increase the developers' compensation packages. No one is laying off the development team that just chewed through 50 items per day for 3 straight weeks. Who would support all the potential bugs they just created? That's right. They might hire even more developers. This is called a "win-win" scenario. Not every game must be zero sum, but I understand rejection of this possibility to be part of the aforementioned ideological issues.
AI should make us better, not just churn out trillions of lines of code.
The very idea of massive vibe coding efforts, where devs go to sleep with a hoard of agents churning away, makes me uncomfortable.
I worked in agile/scrum orgs with product managers who couldn't be bothered to write well formed tickets or truly keep a well groomed backlog, I think this is more normal than not outside Mag7.
A lot of work was noisy iteration with a guy/guys who change their mind a lot, and write nothing down. We met weekly to iterate, I suppose now one could meet 2x/day to iterate (10x!). I am not sure we would arrive at "done" 10x faster though. Probably 50-90% of the productivity boost would go towards.. doing more iterations.
For an external customer facing product with KPIs, A/B testing, etc that could show iterations relationship to revenue probably that's great. For a lot of internal tooling that is not good. A lot of senior devs kind of internalize this behavioral knowledge already and purposely cadence out changes to stakeholders to avoid this type of churn, while working on other things.
Re: backlog
My observation at work and in my work network is a lot of SWEs are using the productivity boost to burn down backlogs that probably never needed burning down. There's a reason some tickets were there for 2 years - they aren't actually needed, and everyone is too lazy to close them.
So in both cases we have problems expanding to fit the time available.
As soon as you have many engineers using agents in the same codebase, the process breaks down, and you start stepping on each other’s toes, collapsing those velocity gains.
Maybe the “software factory” pattern will work, where agents just pull from the backlog, and so the team can all focus on grooming and disambiguating tickets, with the coordinator agent flagging conflicts and ambiguities between different people’s asks?
The only thing I’m confident of here is that a “h1 planning exercise” doesn’t really make sense in most cases; ~everyone should be shifting to building a lot of prototypes and iterating with customers, rather than trying to prioritize how to spend scarce eng effort. (That resource is no longer scarce.)
I think a lot of teams are going to rediscover (by necessity) the good parts of Agile, namely finding the domain expert and iterating with them to solve the actual problems; that’s your bottleneck now.
If something that runs on those is somebody's idea of a good process, that's wrong from the inception. Good process looks like completely broken "Agile", but in a way that somehow everybody is happy with the results.
Prior to this, building the software was, generally, one of the main constraints. If the business wants to do X, then it takes 3 months to build.
That means the business ideation and governance cycle (what do we want to do, are there customers, what do we charge) can take 3 months.
If you 10x thay development process then you also have to do the same with the business processes.
Once engineering teams have cleared the backlog, then burned through the decades of tech debt the constraints will switch. And how businesses react to that will be interesting.
Riiight, except tech debt is the one thing that's actually been 10xed. People are now producing a decades' worth of tech debt in less than a year.
I have no doubt someone in business will have more ideas than any team can deliver.
Think about all those product-pitch PPTs. What if one could present a prototype instead? Boom, demand increased 100x.
That's Jevons Paradox https://en.wikipedia.org/wiki/Jevons_paradox
Or the extra time can be used towards polishing the software.
I largely agree with the main idea in the post, but would push back on this.
As I’ve gotten older, I notice a large proportion of tasks can be chalked up to busywork. Not in the sense that they aren’t real bugs, but they’re not fixing root causes of problems.
To your point about process, there may be a hundred tasks that stem from poor repents management or poor testing process etc. There will likely continue to be many bugs until that root process issue gets fixed. To that end, those root problems generally take much more work to solve.
So, yes, many tasks can be done quickly unless you’re doing true root cause analysis.
That will end well.
AI allows you to produce code without understanding the system, and that's how you can get delivery speed up. And, yes, AI is getting good enough that you can purchase large amounts of code from Anthropic without understanding much, so you can move very fast indeed as long as you never need to make sense of it.
> No one is laying off the development team that just chewed through 50 items per day for 3 straight weeks. Who would support all the potential bugs they just created?
Do you live under a rock, or are you hoping that saying this enough will law of attraction[1] it into being?
https://en.wikipedia.org/wiki/Law_of_attraction_(New_Thought...
Personally I do code review, it's what we do at my workplace, and we regularly improve the agents' code and design though human review, even with Opus 5.5.
But looking at some of the people who are pushing AI development the furthest, I do see the trend towards it just not being that useful anymore.
Real world example:
I use T3Code as my agent orchestrator and it's consistently pretty high quality and works well + regularly gets new useful features.
And with just a handful of maintainers, they're doing anywhere from 100 to 200 PRs a day!
And there are a ton of users of their nightly, which is a rolling 5-hour release, and nothing really breaks. And they have more real-world users than almost all the projects I've worked on before.
So I just can't really in good faith say that this extremely challenging to my world view.
If you're running tons of product/UX experiments code review is just going to waste everybody's time. But the volume of changes you can make now is so large, someone could touch something important about at any given time without proper oversight.
IMO an effective team has to be able to either trust each other enough/be accountable enough that code review is mostly unnecessary, or everybody just works really independently on mostly separable things, or you regularly pair/mob-program.
If you can trust your colleagues not to pump out code without messing it all up or turning everything into slop, or creating large amounts of work for other people, things are great. Realistically most dev teams have a wide range of skills and personalities and people also make mistakes, and code review helps us build shared knowledge and collaborate.
Maybe there is too much of a moral hazard from the reviewer's role as a cosigner, or some people are only as conscientious as necessary to get things done (not a problem writing every line by hand)... but people can ruin code review for everyone else by demanding an asymmetric level of accountability/judgment and oversight.
The bigger issue for me is whether or not you still do code review, you need to build shared knowledge within teams. I really think we should be reviewing our colleagues' coding agent session logs
Not even to critique them (but that could be useful), but just to understand what it is they are actually trying to do/what mental model they're operating under, and if there are issue in the PR, what miscommunication or technique or process could help fix it? I think a lot of people feel that asking to see those logs is invasive or embarrassing, but the problem is that it's just really hard to build a model for how someone works or thinks without it. You don't need that in a deontological sense, but you do if you want to fix coordination problems.
You need to decouple it, but you dont need to remove it.
Will it? Are you willing to test this?
>No one is laying off the development team that just chewed through 50 items per day for 3 straight weeks.
If there are no remaining items, or the amount of items processed per day has increased well above the amount of items that need processing every day, someone's certainly getting laid off.
>Who would support all the potential bugs they just created?
We have long criticised management for not caring about this. Now we are supposed to trust their good judgement?
I recently switched, but at my previous job, the PMs (who would typically do most of this work) got so overworked after AI took hold, that they’ve doubled the PM-to-dev ratios on all (the productive) teams.
I have read about this in other companies as well. Some teams in Google have a PM pr dev, I hear.
Where I work now, sh*t gets done MUCH quicker with AI, and to a higher quality as well.
IMO, if you work with software and can’t get a meaningful boost out of AI, I think you’re doing something wrong.
Many of these companies have no idea what to do to begin with, so improving dev throughput is not really the business problem to begin with (even though frequently blamed).
In every software job I’ve ever had, every released new feature leads to maybe three new requests to modify the new feature, two unintentional bug tickets, plus some tech debt. Work leads to more work, not less. I don’t see how increasing the velocity of the work should change that.
Yes, this literally happens all of the time today. Proof point - software development organizations hire to fill operating budget voids, not on what work needs to be done.*
*Source - I've seen 900+ software team's P&Ls and interviewed their CTOs.
Agreed, and in fact even pre-AI good development teams weren't limited by speed of code generation (how to build it), but rather making the right thing (what to build).
> Quite the contrary. It will create a vacuum that the business will fill with new work that may incidentally increase the developers' compensation packages.
This seems very disconnected with the reality of any company I've worked at in 25 years.
"Tasks" frequently are not spelled out, or if they are, they are wrong. There's almost no value to a company to blaze through all this.
Similarly, no one is getting rewarded for that type of speed, especially if the company has no idea how to uptake it.
Why not say outright that "ideological friction" is about AI usage? Maybe some devops have friction cause when things break at 2am and they get called up they don't want to dig through 500k lines of slop the author can't explain?
And "empty 99% of the backlog everyday" <-> "hire more people to fix the bugs" is illogical. Reviewing slop and fixing bugs make me want to go build houses instead of software.
Meanwhile, back in reality, DevOps now have a tool to help them sort through the slop that already exists.
So, go build houses, nobody cares. But go ahead and try and slow their process down with "the way you like to do things", see how that goes.
This was a problem well before AI, but it doesn't get talked about enough because so many developers are hooked on the power trip they get from making people waste time on crap that has no relevance to the user.
In my experience, this has been senior engineering leaders and project managers more than anything.
The user is not just the person consuming the finished product
What? You know there's only 24h in a day right? I work 8 of those and most tasks takes my agent far longer. And thats not including me correcting it, adjusting the spec so it does the right thing, etc etc. And I don't have anyone doing a PR waiting, I go straight into production.
I’d look into where the model is spending its time and see if you can save some time. Eight hours is more then enough time to have an entire new microservice up and running and to adjust existing microservices to utilize it.