When AI Makes Software Engineering More Intense

What concerns me about software engineering with AI is the pace of the work that remains. More attention goes into understanding problems, planning work, and reviewing AI decisions. Meanwhile, the expectation is that we should deliver sooner, deliver more, and still get it right.

Faster code generation can help. But it does not necessarily make the engineer’s day less demanding.

Losing the narrower parts of the day

Writing code was never uniformly relaxing. But there is a difference between concentrating on one difficult problem and continually making decisions across several problems.

Once you understood an approach, some implementation work was straightforward: connecting pieces, following a pattern, filling out cases. You could make progress without reconsidering the direction of the work every few minutes.

AI can take over that work. If we immediately replace it with another plan or review, however, we remove the less decision-heavy parts of the day. The hours stay the same, but more of them require sustained judgement.

Review is more than reading a diff

When you write a change, you build understanding along the way. When AI writes it, you need to reconstruct enough of that understanding to accept it.

Consider a hypothetical feature allowing customers to cancel orders before dispatch. The generated code might update the status and pass its tests. But what happens if the warehouse starts dispatching while cancellation is being processed? Does cancellation also require a refund?

These questions existed before AI. Now a finished-looking implementation can arrive before they are answered. The reviewer has to discover which assumptions the code made, then decide whether they are acceptable.

Ready does not mean urgent

One agent finishes. Another needs clarification. A plan is waiting for approval. Each event invites an immediate response, even when nothing is actually urgent.

Starting another task while checks run feels efficient. But if every result needs the same person’s attention, it also creates a queue of different requirements to reload into their head.

A day of keeping agents moving can leave little uninterrupted time to investigate the question that should change the plan.

Faster expectations need a realistic plan

When a demonstration appears quickly, it is understandable that people expect delivery to follow quickly too. The unresolved business rules and integration work are less visible.

A familiar, isolated change may genuinely become much faster. An unclear requirement involving existing customer data is different. Applying the same shorter deadline to both leaves the engineer absorbing the uncertainty while maintaining the quality bar.

I would like planning to include proper investigation and review, rather than treating them as brief approval steps. Keep active work within what someone can actually understand. Make unresolved questions visible before committing to a delivery date.

Better personal organisation helps, but it cannot create unlimited attention. Sometimes the time saved should go into another feature. Sometimes it should let us finish the current one carefully, or simply have a less pressured day. Every faster implementation does not need to become another demand.