Comment by bob1029
3 hours ago
Our processes around software should come first.
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.
It's going to be a challenging period though - just because of constraints theory.
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.
>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
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?
Keeping the backlog funnel full has been nearly a full ltime job for me for about 5 years now. Both pre and post AI. Once you get a team together that knows how to execute keeping the backlog full of well defined and groomed tasks becomes the problem management rarely sees and subsequently doesn't know how to solve.
I mean, you're kind of in a self-fulfilling prophecy because any rational employer would prefer to terminate an employee who deliberately wants to slow things down for fear of being fired, regardless of whether they would cut employees or choose to just do more/cooler things.
Nobody wants to lay off an employee that is pleasant to be around, trustworthy, and good at what they do.
If you're worried about this, your manager is probably either just as worried as you, OR is worried about your paradoxically low performance in an environment where low performers might be on the path towards switching industries. I mean that sincerely. You are probably damaging your own career and the lives of those around you more than you know.
This is an absolutely unhinged personal attack on the op that has nothing to do with their comment. Why do you assume they are intentionally slowing things down? Because their analysis of the situation is that some people will be fired?
>Nobody wants to lay off an employee that is pleasant to be around, trustworthy, and good at what they do.
So if I hire a painter who is pleasant to be around, trustworthy, and good at what they do, I'm not going to "lay him off" the instant he's done painting my house?
I don't think AI can fix the process, ideology or people issues.
It can if a single developer replaces a whole team.
Anthropic recently published their code review approach that supports them deploying 30,000 (!) times a day:
https://claude.dev/blog/solving-code-review-at-anthropic/
I've been harping on about async review for so long now. Glad to see it finally becoming a thing. Code review as a gate doesn't work for remote teams or AI lead development.
You need to decouple it, but you dont need to remove it.
I think that now the bottleneck will be less the tasks after development but before. Deciding what to build will be the new bottleneck. Finding ways to measure the system to make decisions, all of these need to improve. We risk building the wrong thing at an accelerated pace
How does Hacker News work if absolutes like this opinion are the top comment people read first?
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.
>I've seen how long an average PR review actually takes
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.
> 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.
Opposite where i am. PMs would gladly ship good enough while some dev colleagues are more strict so to say.
1 reply →
> crap that has no relevance to the user.
The user is not just the person consuming the finished product