One problem of AI-assisted coding
Jun. 4th, 2026 06:33 pmFor the sake of simplicity, let's assume that AI, given a reasonably good spec, can output a reasonably good piece of code in a few seconds. It is actually way more often than not exactly the case. Let's say that you need some 5 mins to write a spec and some 10 minutes to write a function to that spec, so your productivity should triple yet it does not. I have a theory which seems to match the results on a sample size of one.
I've done a disturbingly high proportion of my coding while sitting in boring meetings, listening to boring infodumps (which you are still required to attend) - in public transport even. This makes me think that most of writing code is "low-brain" activity. This activity is almost completely replaced by AI.
What isn't replaced is, first, actually writing the spec, second, testing the code and the spec. The former is "does the code do what I think it does" while the latter is the much more difficult "does what I think the code does actually match what is needed". And while one can argue that code testing can be AI-offloaded, the spec testing and spec writing is hard to AI-offload. And that's "high-brain" activity which a human has a pretty limited daily supply of.
Moreover, "high-brain" activity requires, at least for me, concentration and a lack of distracting factors. You don't do that in a boring meeting. It's pretty hard to do that when sick, tired or otherwise not at your best.
So the human (or, as it becomes customary to say, meatsack) becomes again a bottleneck. The time savings are quite real, yet in an area where the shortage of man-hours wasn't acutely felt. In arbitrary numbers, a Joe developer was able to design 50 lines of code a day and write 40 of them . Now he's able to write 400 lines a day but he still can design only 50. It's still a 25% improvement... but not a 900% or even 300%.
I've done a disturbingly high proportion of my coding while sitting in boring meetings, listening to boring infodumps (which you are still required to attend) - in public transport even. This makes me think that most of writing code is "low-brain" activity. This activity is almost completely replaced by AI.
What isn't replaced is, first, actually writing the spec, second, testing the code and the spec. The former is "does the code do what I think it does" while the latter is the much more difficult "does what I think the code does actually match what is needed". And while one can argue that code testing can be AI-offloaded, the spec testing and spec writing is hard to AI-offload. And that's "high-brain" activity which a human has a pretty limited daily supply of.
Moreover, "high-brain" activity requires, at least for me, concentration and a lack of distracting factors. You don't do that in a boring meeting. It's pretty hard to do that when sick, tired or otherwise not at your best.
So the human (or, as it becomes customary to say, meatsack) becomes again a bottleneck. The time savings are quite real, yet in an area where the shortage of man-hours wasn't acutely felt. In arbitrary numbers, a Joe developer was able to design 50 lines of code a day and write 40 of them . Now he's able to write 400 lines a day but he still can design only 50. It's still a 25% improvement... but not a 900% or even 300%.