Before the dawn of LLMs, software projects always had a large absorption factor. Despite surprises blowing up in your face, a project would absorb the damage and continue on as normal.

At the beginning of each project, an engineer would scope the problem based on their understanding of the code and their familiarity with a domain. Inherent in this project lifecycle was complexity hidden just out of sight by surreptitious bugs, dependencies or legacy code. So, much of an engineer’s planning process made them act as a minesweeper: they lift up boulders, they comb through the earth and they disarm along the way. But an engineer was never a full-time minesweeper.

At the end of the day, the engineer still had to put the pen to paper and deliver code. And much of a project’s absorption factor was driven by the fact that engineers had to hand-craft code. Greater the amount of code to be written, greater the complexity. Greater the complexity, larger the absorption factor.

Now, while code itself was rarely the true hurdle, it still took time. And it was this time spent writing code that allowed an engineer to resolve these surprises in parallel. In between design patterns, tests and attempts at coherent taste, messages are sent, meetings are held and consensus or tradeoffs made to deliver all on time. These surprises were the things which caused the most anxiety:

A team can no longer deliver X dependency by such-and-such date, so we must scale back on delivery goals. We’ll push it to phase two. Or, a new way of provisioning infrastructure secrets is tied to a manual gatekeeper. But by whom? Which engineer out of thousands? And in what timezone? Ah! The team is found, but they only respond when it’s 8:00 PM and I’m just putting the kids to bed. That’s fine, I’ll sacrifice it just this once. Actually, I’ll keep this going because it somehow keeps my stress down. No wait, the stress is feeding on itself. At last, it’s been ten years hence, so maybe I’ll stick it out until I can retire early.

Take this experience. I know many of us have lived it. Project after project, the pattern of human and corporate bodies reassemble themselves into monstrosities. They delay us. They confuse us. And they fight us tooth and nail until we reach the bitter end and start all over again with the next one.

Less code to be written, the less of an expectation of inherent complexity. You see, by reducing the expected delivery time of hand-crafted code, AI has reduced the absorption factor to a fraction of what it once was. Gone are the days of hollowed-out time in which engineers could multi-task surprises at a slower pace. Now they must be resolved soon. Preferably yesterday. And it’s not like the work has gotten easier.

In fact, with the advent of AI, these most painful parts are about to get a lot worse. And not because the problems are more complex or tediously boring, but because there are more of them to deal with at once. More monsters to defeat. All at once.

I don’t want to be seen as a doomsayer. I’m just a repair man, an observer. This phenomenon is happening and fast. In fact, it’s happening so fast that our industry is still figuring out how it shapes our careers as engineers and managers.

My prediction is that one thing will remain and it will be that which already distinguishes a cut of engineers from the rest: how you deliver the hard parts.