Amdahl's Law, applied to vibecoding
Thesis: There exists something like Amdahl's Law for vibecoding: the fraction of non-vibecodable work will start to dominate your work time, no matter how small it started out with. In an enterprise context, code was never the bottleneck.
In parallel computing, there is a formula called Amdahl's Law. In my own words it sounds like this: the amount of total speedup you can gain by parallelisation is limited by the fraction of work that can not be parallelised.
We assume a simple world, where there is a part of a program that can be linearly parallelised. Using 2 processors halves the runtimeNote that we're already finding diminishing returns using this approach. Adding one processor reduces runtime by 50%, adding another reduces by another 16.7%, adding another by 8.3%, adding another by less than five percent, and so on. This is inherent when doing division, because your result will be like 1/n, and that's just a really unforgiving curve., using 3 processors thirds it, and using n processors divides the runtime by n. However, the second part of our hypothetical program is fully linear: no amount of processors can give you any speedup in that part. These assumptions are somewhat realistic, in that different parts of your program will respond differently to parallelisation, and there will always be parts that parallelise well and others that don't. But it also means that, given enough processors, the parallelisable part tends to zero, while the rest stays constant. And that's really the crux, the limiting factor here, because the maths are now against us.
Let's say your program is 90% parallelisable. This is a great coefficient already, having only 10 percent setup/loading/gathering/whatever is very, very respectable. Using 1000 processors reduces that time to a thousandth of the previous runtime. But what's the speedup? Well, it is 1 / (0.9 / 1000 + 0.1) = 9.91. Using one thousand times more processors increased your speed by less than 10 times. In fact, that is the absolute limit: even if you used an infinite number of processors, you would only gain a speedup of 10.
Ah, but what if your problem is 95% parallelisable? Then your maximum speedup is 20. Using 1000 processors will give you merely 19.63 times the speed.
That's sobering, isn't it.
Now here's my hypothesis: the same process is at work with vibecoding. Let's go with the silly-but-often-repeated assumption that vibecoding, or agentic coding, or whatever-coding, makes a programmer ten times more efficient. Heck, let's say it makes you one hundred times more efficient at producing code.
Now, let me ask you, in an enterprise context, what fraction of time does a programmer spend on actual coding? What did you say, 75%? You've never worked in an enterprise context, did you? I'd say 50% is more likely, or maybe even less than that. How much faster does our code monkey get under those assumptions? A mere 3.88 times in the very optimistic case, and 1.98 times in the more realistic case.
That's sobering, isn't it? You used so much infrastructure and wonder-machines to make someone a 100-times better programmer and you merely made them twice as fast. It's almost as if the actual programming is not the bottleneck, nor has it ever been.
However, there's more bad news, because now that you've freed up more programmer time, do you think it will be spent on programming? I don't think it will, for two reasons: First, because a lot of that un-speed-upable time is “friction”: coordination, waiting, discussions on decisions, other dependencies. And, just like the other kind, this kind of friction gets harder with speed. You will need to spend more time on these topics when you go faster. And that's the first part that eats up your gains.
The second reason is another law, Parkinson's LawThis book from 1955 is more well-written and more applicable to todays work world than most of the books written today. I recommend this to everyone and I will recommend this to you: go get a copy and read it!: “Work expands so as to fill the time available for its completion.” In addition to the first reason, which necessitates more work for more speed, this reason enables more work for more speed. Our programmers are so fast, let's add another steering committee, another group chat, another discussion, another workgroup, irrespective of whether they're actually needed or useful. If you can speed up efficiency, you can also speed up timewasting. And you can do that until your work-time is filled upIn my humble opinion, that's the reason why there are so many “bullshit jobs”. All of these have a core of usefulness, that gets bolstered by bullshit work, until you forget that there's an actual core. Side note to the side note: will AI also take care of all the bullshit jobs?.
And this is my argument for why, even under the most charitable assumptions, vibecoding will not make anyone into a 10X-programmer, no matter how much you might wish for it.