Every engineering leader I've spoken with over the last two years seemed to be making a similar quiet bet. The hope was that by putting effective AI tooling in front of a capable team, the grind would lift. Boilerplate would write itself, test scaffolding would appear, and that two-hour detour into an unfamiliar API would vanish. In my experience, those predictions largely held true. The grind did lift.
Then, we did something with the time we regained, and looking back, it seems most of us did it without really thinking. We asked for more.
It wasn't malicious. I didn't see anyone stand up and announce that the team was now expected to carry a heavier load. It seemed to happen by omission. A sprint that previously held six tickets quietly started holding eight, simply because eight now fit. The demo that would have taken a week landed in three days, so a three-day cadence became the new expectation. The speed became our baseline. And once that speed was the baseline, it stopped feeling like a gift and started to feel like a floor we were constantly bracing against.
That, as I've come to see it, is the trap. It wasn't that AI created burnout; it was that the way we reinvested its dividend may have accelerated it.
I include myself in this. Early on, I treated those reclaimed hours as pure capacity — free, high-quality capacity that saved us from hiring. So, I filled it. It took me longer than I'd like to admit to notice that a team shipping more wasn't necessarily a team doing better. The people around me seemed to grow quieter and flatter — careful in the way people become when they are running hard just to stay in the same place.
My takeaway from this period is a simple reframe: efficiency is not the same as throughput. We allowed those two words to become synonyms in our planning, and I believe it cost us. A team that ships more tickets is not necessarily more efficient if a significant portion of that output is code nobody fully understands, resting on debt that may cost more to remediate later than it saved to write initially. I've found that true efficiency often looks more like a team that understands the systems it owns, makes deliberate choices about what not to build, and doesn't burn itself out in the process. That is harder to track on a burndown chart, but I believe it is worth far more.
The risk, as I saw it, was that the baseline reset without a conscious decision. That strikes me as the classic signature of poorly managed change: the most consequential shift in how a team functions arrives as a default, and by the time you notice, it has already become culture. I've learned that a leader's role is to make that choice out loud — to decide, deliberately, where the saved time goes. Because it is going to be spent either way.
In my view, there are four key areas where we should be directing this dividend:
Thinking time. I realised the truly scarce resource in engineering was never typing speed. It was having the uninterrupted space to understand a problem before committing to a solution. AI writes code quickly, but it doesn't tell you what to build, and it will often confidently help you build the wrong thing. The best engineering decisions — the ones that remove the need for work entirely — only seem to emerge when someone has room to think. Filling every reclaimed hour with another ticket often results in the faster delivery of things that perhaps shouldn't have been built.
Depth over breadth. I've found it more effective to give people the room to truly know the systems they are responsible for, rather than skating across ten they only half-understand. AI makes it trivial to ship into a codebase you don't grasp, but that only lasts until it breaks at 2:00 AM and a human has to hold it together. I think reclaimed time should be used to buy comprehension, which is often what turns a potential crisis into a manageable incident.
Craft, and the broken ladder. Juniors historically learned by doing the unglamorous work that AI now absorbs. That work was rarely just output; it was an apprenticeship. If we remove that work, we may be quietly removing the rungs people need to climb. If we don't consciously reinvest that time into how engineers grow, we risk building a team that can prompt fluently but struggles to reason. Growth, I've learned, is no longer a guaranteed by-product of the work; it has to be designed back in.
Recovery. Not everything of value is output. A portion of that time should simply be for rest — the necessary input that keeps the other three goals sustainable. Speed as a permanent default, without a trough after the peak, is not a high-performance culture in my eyes. It is a burnout schedule with better branding.
I recognise the tension here; dodging it would feel naive. Businesses pay for speed, and they expect a return. I am not arguing for slack as a reward or comfort as a core company value. I am arguing that reinvesting the dividend in your people is a high-yield return. A team that understands its systems tends to ship faster over any horizon longer than a quarter. A team that isn't exhausted tends to keep its best people. In my experience, judgment, depth, and retention are not "soft" concepts — they are the assets that make next year more effective than this one. This isn't a wellbeing argument; it's a strategy argument that happens to be humane.
Innovation follows a similar pattern. True breakthroughs rarely come from a team running at full capacity. They come from the margins — the afternoon someone follows an interesting hunch, or the tangent that eventually becomes next year's product. Margin is the first thing a throughput-focused culture kills, yet it is the last thing it can manufacture on demand. If you want a team that invents, you have to leave them the room to do so.
Ultimately, this is the work of leadership. When AI hands your team time back — and it will continue to do so — you have to decide what happens to that time. You can let the baseline creep up in the dark until your best engineers are exhausted, or you can spend the dividend on the people themselves.
The tools got faster. The real question I've been asking myself is whether I am paying enough attention to where the time actually goes.
Top comments (0)