If it’s anything like AWS there’s hundreds of people making bespoke software factory setups, enhanced interfaces for ai tools, spinning up 10 parallel review agents with the best model available, etc because the budget is basically unlimited.
The other part that is kind of comical is that the software factories keep growing quality gates and automated tasks that need to run for every commit, PR, deploy, etc. Then someone goes "oh, but now it's slowing us down", so a new thing gets added which decides when it's appropriate to run the gate, and on and on endlessly until it's a gigantic soup of actions that are running which provide negligible, and more frequently negative value over the software lifecycle. People are making big expensive messes of agents and acting like it's galaxy brain stuff.
The biggest bottleneck in most organizations is not the production of said work, but the bureaucracy surrounding it. AI isn’t going to solve that. So it really doesn’t matter if AI makes programmers 20, 30, 40 percent faster, they will still be facing the same bottleneck at the end.
It's also frequently the same old bottleneck/problem that we already consciously decided to move away from. We used to produce big binders of specifications. Then a lot of us switched over to "agile", or a more flexible, JIT'd style where you iterate as you go, because surprise, you learn a lot as you go. This remains as true as ever, even with agent help.
Probably more, but not necessarily functionality users requested or even know about.
Case in point: VSCode has a multistage "upgrade project to the latest .NET runtime with Copilot" process that takes several minutes of processing punctuated by frequent authorization prompts for even the most trivial project, resulting in the functional equivalent of
find . -iname '*.csproj' | xargs sed -E -i.bak 's/(net)8(\.0<\/TargetFramework>)/\110\2/'
along the happy path.
It has many more features than my shell command, of course, but none that I care about when migrating trivial projects from runtime version n-1 that are unlikely to hit breaking runtime or compiler changes that don't elicit warnings from the toolchain.
Most of the times, the bottleneck is mainly the company’s legacy. People are using AI on an old, rigid codebase and are still following processes and team rituals dating back from before the IA.
I find it a bit comical. AI tools are so easy to pick up, and it's unlikely you've pushed some highly critical features which couldn't have waited for a few months.
You make a good point. That’s why there is AI fatigue. People are moving at speeds that aren’t normal and it’s mentally taxing.
If it’s not already a thing, it will be soon, the mental health aspects of all professions moving at unsustainable speeds and what that will do to people.
> You make a good point. That’s why there is AI fatigue. People are moving at speeds that aren’t normal and it’s mentally taxing.
I don't think any vague claim of "speed" has anything to do with fatigue.
I do think the parallel world monitoring and validating N work fronts, followed by rounds of fixes where you lay there waiting for the agents to converge, is the defining factor.
Instead of you hunkering down and hammering out a single task where your full attention can be focused 100% on a problem, your mindset is a kin to juggling N balls and hoping to not let any of which to fall.
So it's not really about speed but throughput, and keeping up with the throughout rate is mentally taxing.
Reading, understanding and verifying code has always required more cognitive effort than typing it out. Running agents in parallel just forces you to spend 100% of your day doing the most taxing part of the job
I guess a shop can burn away his whole crew, no newcomers- and the old guard is burned out and quits- and the profession suddenly is just AI and managers yelling at AI realizing the job leads to burn out fast.
Budget unlimited + upper management claiming that engineers should be spending at least their salary equivalent on token costs or they're being ineffective. So many possible misaligned incentives...
All these things are sort of irrelevant amounts of tokens. Even if the answers are worthless.
Like in my experience the real burn is if there is some sort of feedback edge where an agent is producing stuff that eventually it has to reconsume.
Like if there is a dag of agents doing something its almost fine.
But if there is a loop somewhere without a huge amount of damping then you have an issue.
If you have ever been a human debugging in the middle of an agent it produces like so many commands and tests for you to do. Like way more than a human would.
I'm pretty sure they do the same thing to each other. Like the loop will amplify the yapping.
If you can use as many as you want but only 1% productively, thats still potentially infinite productivity. Of course, the efficiency is not that great, but more tokens = more productive work. This is only a thing if your token budget is unconstrained, which isn’t sustainable and never lasts.
> If it’s anything like AWS there’s hundreds of people making bespoke software factory setups
Yep, this is happening in lots of companies. I know my small company has about ~1/3rd of the developers working on one (different ones, all semi-personal projects).
I sometimes wonder if we are drawn to building these because it feels like one of the remaining challenges and a desire not to be an "LLM text shuttle". Additionally/alternatively, you can go as fast as you want with building a software factory and you aren't held back by the "bottlenecks" (PR review, QA, etc).
Working on my software factory is the closest to a "flow state" I've been able to achieve since LLMs turned the corner earlier this year and replaced the vast majority of our code-writing work.
I think one thing that muddles this in online discussions is that there are many voices saying many things about AI, Data Centers, etc. It's easy believe that everyone involved in obstructing data centers is some sort of NIMBY crank that believes fake news about electricity or water usage. But if you look at reporting from people like Jasmine Sun who visited these towns, the actual activists are a lot more sophisticated than tech forums think.
There's a lot of examples of companies failing to deliver things they promised at this level like the FoxConn complex in Wisconsin. Making city leaders sign NDAs doesn't help this. People are more skeptical of future tax revenue claims and it's hard to sell a direct benefit of the AI itself when you spent two years talking about eliminating all white collar jobs. The trust just isn't there.
Given the classical liberal philosophy of The Economist, this just reads like scolding when their world-view is falling out of favor. Luckily for AI boosters, I think data center builders are adapting to reality.
"Just" feeding paper is extreme engineering. And a disposable vape has more compute in it than a toner cartridge. (Though there is insane non recurring engineering in an inkjet cartridge. But I bet just the warehousing of a printer is a significant part of the total cost of a printer.
This is eerily similar to how a few people at work did some presentations about ralph loop and connecting agents to slack right when management was really pushing unrealistic AI productivity boosts. I was repeatedly asked to speed things up with AI while I was already heavily using AI to do work.
You are making claims for why you think the emissions are worth it but I don't see how this makes concerns about emissions invalid. Even water usage, while blown out of proportion, can be a rational concern if you have a fossil fuel power station.
You can just flip this around and ask why is slowing down AI to control emissions harmful? What numbers that don't make tail risk claims are you providing for this?
wait, please stick to the argument. Why is increasing emissions bad while considering tradeoffs?
>You can just flip this around and ask why is slowing down AI to control emissions harmful? What numbers that don't make tail risk claims are you providing for this?
Slowing down reduces the value it provides to humans, that's clear to me and you I hope.
>Why is increasing emissions bad while considering tradeoffs?
Because climate change stands to be the biggest market failure in history. You need to show that the rapid scale out of data centers is going to reasonably offset the current trajectory we're on.
“Climate change presents a unique challenge for economics: it is the greatest and widest-ranging market failure ever seen.”
-- Nicholas Stern, Leading climate economist; former World Bank chief economist.
“The ultimate commons problem of the twenty-first century—global climate change.”
-- Robert Stavins, Harvard environmental economist and climate-policy expert.
“Climate change, an externality that is unprecedentedly large, complex, and uncertain.”
-- Richard Tol, Prominent economist specializing in climate-change impacts.
“Climate change is a global public-goods externality whose formal resolution requires an unprecedented degree of international cooperation and coordination.”
-- Martin Weitzman, Harvard economist; pioneering scholar of climate risk.
“Climate change is the Colossus of all global public goods.” -- William Nordhaus, Nobel laureate and pioneer of climate economics.
“The problem with climate change is that there’s a market failure.”
-- Joseph Stiglitz, Nobel laureate and former World Bank chief economist.
If they are strictly increasing our already unsustainable emissions level, yes. Eg. I am very much in favour of replacing coal and gas power stations with nuclear power stations, banning cars from city centres, etc.
