Most of the people doing the most rote and monotonous work were and are doing so in some of the least productive circumstances, with clear ways of increasing speed and productivity.
If development velocity was truly an important factor in these businesses, we'd migrated away from that gang of four ass Java 8 codebase, given these poor souls offices, or at least cubicles to reduce the noise, we wouldn't make them spend 3 hours a day in ceremonial meetings.
The reason none of this happens is that even if these developers crank out code 10x faster, by the time it's made it past all the inertia and inefficiencies of the organization, the change is nearly imperceptible. Though the bill for the new office and the 2 year refactoring effort are much more tangible.
Yep. It's ridiculous to talk about 10x or 5x or 2x anything in any but the smallest companies. All this talk about programmer velocity is micro-optimizing something that's not a bottleneck.
I’ve been thinking a lot about this. I think that AI software automation tools are disproportionately more useful in greenfield work done by small or tiny organizations. By an order of magnitude, maybe 2 in some cases.
What that means is anyone’s guess, but it seems like it should result in a Cambrian explosion of disruptive new companies, limited in scope by the idea space.
The thing about small teams is, with a few exceptions, the biggest challenges are typically funnels for users and product-market fit, overcoming and exploitation of network effects, etc… so even in small orgs, if you make 30 percent of the problem 4x faster/smaller you still have the other 70 percent which is now 92.5% of the problem.
This applies even more acutely in larger organizations… so for them, 99 percent of the problem remains.
Intangibles in an organization like reluctance, education, and organizational inertia fill the gap left by software acceleration, and in the end you only see tiny gains, if any.
What really happened, on an organizational scale, is that software development costs went down. We wouldn’t expect a wage collapse in coding to foment an explosive revolution in company profitability or dynamism. We shouldn’t expect those things of LLM assistance.
We should look at it as a reduction in cost with potentially dangerous side effects if not managed carefully, with an especially big reduction in r&d development costs.
>all the inertia and inefficiencies of the organization
Honestly you can probably use this as a means to measure the amount of regulation, graft, and corruption in an economy.
In a wild west free for all code velocity would likely be very fast with software popping up, changing rapidly, and some quickly disappearing.
But in an economy that doesn't care what you make, then who you pay or what laws you buy is far more important.
In many organizations, software just isn't what makes the money. It's a supporting role at best. The software needs to work reliably, and it needs to keep working for a long time, but it doesn't need to gain new features at a rapid pace.
If the janitors swept the floors 10x faster, we wouldn't any KPIs to shoot up from that. You still need it to happen regularly and reliably and on demand in case there's a mess, but it doesn't need to be fast.