Speed of writing code has never been a problem

The Mirage of Optimization, or Goldratt Already Said It All

As the creator of the Theory of Constraints — Eliyahu Goldratt — said:

“An hour saved anywhere other than the bottleneck is a mirage.”

• optimization outside bottlenecks: improving the work of tools, processes, and people that are not constraints leads to more work in progress and higher costs
• focus on constraints: a system’s effectiveness is determined by the performance of its weakest link
• exploiting the constraint: instead of optimizing everything, you should first identify and eliminate the bottleneck. Real savings appear only when the bottleneck itself is optimized

In other words, when you optimize a stage that is not the bottleneck, you do not get a faster system. You get a less efficient system.

How Much Time Do Engineers Spend on Code?

Various studies analyzing engineers’ work show that the share of time spent writing code relative to other stages ranges from ~10-16% to ~50-65% in small early-stage projects. In the study Microsoft Research — “Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era”, engineers report an estimate of 11%. At the same time, in their “ideal week” they would like to spend 20% on writing code and 15% on technical design.

The 2022 Global Code Time Report gives a median figure of 52 minutes per day.

More Serious Problems

We will undoubtedly get a significant increase in the amount of code produced by introducing AI agents into the development process, and as a result we will amplify all bottlenecks if we do not optimize them in time.

Now we write more code, but create less quality functionality.

The Real Bottleneck

The quality of hypotheses and ideas in our backlogs. That is what should be optimized as much as possible — what lies far before the start of the development process. Too often, we are overly confident that these tasks are necessary, without sufficient research, hypothesis validation, and clear enough descriptions before handing them over to development.

If we know for sure what to build and how to build it, then every feature will bring significant value to the customer — and therefore to us as a team or company.

Tools built for AI-first development, created by engineers, follow a clear principle:

• the less time implementation takes, the more thorough the planning must be in order to avoid chaos and still deliver what matters most

What does this look like in AI-assisted development? You spend several hours describing the task with an agent, and if you stay disciplined, there is a high probability that you will get a quality, expected result in 10 minutes spent on code generation.

One way or another, this is also discussed both in the novels of Tom DeMarco and in professional project management literature such as the guides by Joseph Heagney.

What Should We Do?

• The shorter the planning horizon, the more accurate the forecast and the higher
• the task granularity Plan carefully what exactly to do and why Protect
• development from building functionality nobody needs Stop measuring quantity and
• frequency — measure the value delivered instead