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

The software development landscape is changing rapidly, right now.

I have spent more than 15 years working in IT engineering.
I use AI tools actively every day in my work: for building internal tools, automation, analytics, and infrastructure management.

Over the past year, the nature and intensity of the part of my work related to writing code has changed significantly.

Very soon, we will look back on writing code by hand as a fond memory from the past — and we will miss it.

Changes in the nature and cognitive complexity of work

Engineers increasingly have to become operators: they no longer simply write code, but manage entire virtual teams of engineers capable of working in parallel with a level of multitasking that is impossible for humans. This is fundamentally changing the nature of the work and increasing its cognitive complexity.

Last week, I caught myself running several active AI agent sessions at the same time — each in different projects, with different tasks, workflows, and tools. In general, this is a normal mode of operation for a technical or project manager: they often have to manage several teams and projects at once. But for many engineers, this may be something entirely new, and adapting to it will require time and resources.

The feedback loop

I think many people who have seriously explored solving problems with AI have encountered a situation like this: just a little more, just a couple more fixes, one more question, one more answer — and it will finally work exactly as it should. Even though it already seems to be almost working. Just a little more… and suddenly it is already two in the morning.

Why does this happen? For roughly the same reason that the endless feed in a well-known app with photos and short videos is so addictive. In a short period of time, we manage to feel disappointed, excited, roll back changes, start over, and go through several such iterations in a row.

Many of us are not used to working in this kind of feedback rhythm. Usually, the results of solving complex problems come much more slowly — over days, weeks, or sometimes even months. This can disrupt the familiar reward cycle: complete a task, get dopamine, feel accomplished. We are not used to getting such fast results on tasks that AI is now capable of solving. Over time, of course, we will adapt, but this is the reality right now.

Team and individual efficiency

One of the key advantages of using AI agent systems in development is that an entire project — or a significant part of its architecture — can potentially be built by a single engineer. The most expensive and difficult part of the process is removed: communication.

The benefits of solo development with AI are much harder to transfer to team-based development.

Evaluating results

Evaluation in IT is a topic worthy of a whole library of its own. But how are we supposed to understand now what is truly time-consuming, what is difficult, and why?

We now have to build a new frame of reference and rethink complexity from the ground up.

Conclusion

We are already living in this future world of software development.

These changes are already here.

I am deeply inspired by modern tools and the capabilities of the latest generative models — this is genuinely something new. I believe that in the near future, the process of building IT projects, even in the most conservative domains, will undergo major change.