Something in this year''s engineering surveys does not match the sales pitch. AI tools were supposed to give hours back. Instead, 45% of engineers in LeadDev''s Engineering Leadership Report 2026 say they are working more hours per week than the year before, up from 38% in 2025.

The senior end is worse. Among staff, principal and distinguished engineers, it went from 28% to 53% in twelve months. Your most experienced people are the ones absorbing this.

The easy explanation is that companies just loaded more work on. That is part of it. A Harvard Business Review study in February tracked 200 tech employees and found they did not use AI to finish earlier. They used it to take on broader work, faster, and extend their hours. But there is a second thing happening that is structural, and it is the one you can actually design around.

Engineering used to have built-in stopping points

Think about what used to end a coding session. You hit a wall on a bug. You ran out of context on an unfamiliar part of the codebase. You needed a colleague who had gone home. You got tired of typing boilerplate. None of these were pleasant, but all of them were brakes.

AI removed most of them. Every problem now has an immediate next step. Stuck on the bug? Paste the trace. Unfamiliar module? Ask for a summary. Boilerplate? Generated in four seconds. The session no longer stops on its own. It only stops when someone consciously decides to stop, and at 11pm on a Thursday very few people make that decision.

That is why engineers describe AI coding as addictive rather than efficient. It is not a discipline failure. The friction that used to end the day was doing real work, and nobody replaced it.

The middleman problem is the other half

In a 2026 survey of 2,147 engineers, 71% agreed with the statement "I often feel like a middleman between AI output and actual results."

The numbers back the feeling up. Developers now spend around 11.4 hours a week reviewing AI-generated code against 9.8 hours writing new code. That ratio flipped from 2024. Reviewing is cognitively expensive and, unlike writing, it produces no sense of authorship at the end of it. You finish a day of review with the same output volume and none of the satisfaction.

Combine the two effects and you get the pattern in the data: longer sessions, more review load, less closure. Hours go up, morale goes down, and the dashboard still says velocity improved.

Put the brakes back in on purpose

We treat this as a process design problem, because that is what it is. Four things that have worked on teams we build with:

Cap concurrent agent work. WIP limits are old advice, but they matter more now that a single engineer can have four generation loops running. Two open threads per person is a reasonable ceiling.
Make "done" include the review. If your definition of done stops at "PR opened", you have moved the cost onto someone else and made it invisible. Count the review hours as part of the work.
Set explicit stop conditions before you start. "I am fixing this one bug" beats "I am working on the checkout flow." A scoped task ends. An open-ended one does not.
Measure merged changes, not opened ones. Volume of generated code is a vanity number. Cost per merged, reviewed, shipped change tells you whether the tooling is actually helping.

None of this is anti-AI. We build with these tools every day and would not go back. But a tool that removes friction from the work also removes the signals people used to pace themselves, and if you do not replace those signals deliberately, your senior engineers will quietly absorb the difference until they leave.

We are here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you are looking to build something, get in contact with us today!

The teams getting real leverage out of AI are not the ones running the most sessions. They are the ones who decided in advance what a finished day looks like.