Leaders must stay hands on

A designer on our team rebuilt two critical platform pages, the ones carrying ninety percent of platform traffic, in three days using an agent.

We had estimated two months through traditional engineering.

The number that should bother you is not the three days, it is the two months. That estimate came from experienced people applying sound judgment to a world that had already changed underneath them. Nobody was sandbagging. Nobody careless, either. Their instincts were tuned to tools that no longer described the work.

The claim

For twenty years the advice was that the best leaders don't write code, they build teams that write code.

That advice is wrong now.

It made sense when a leader spending three hours debugging lost three hours of alignment and hiring, and the tradeoff held because building software was slow. When a working prototype takes twenty minutes instead of three weeks, the context-switching penalty shrinks and the maths flips.

This is not about proving you can still code. It's about keeping the technical judgment that sits underneath every other decision you make: timelines you cannot validate, architecture you can't evaluate, backlogs you rank on estimates that are themselves guesses about tools you have never used. Leaders who stay out of the details make worse decisions. The sideline coach had a good run, and it's over.

Estimates break first

Estimates are the first thing to break, they break quietly, and they keep getting produced with full confidence.

Which is the practical argument for staying hands on. You can't spot a five times gap in an estimate you have no way to check, and if you've never built anything with the tools your team is using, the two-month number looks exactly as reasonable as it did last year. So you plan a quarter around it.

I already think the number was never the point. Estimation is a conversation, and the useful output is the disagreement it surfaces rather than the figure. But a conversation needs someone in the room who can say "that seems long" and mean it, and a leader who hasn't touched the work can't do that. They can only nod. Or push back on instinct, which is exactly what went stale.

Where the gap actually hides

Coding is only fifteen to twenty-five percent of shipping software, with review, testing, deployment, integration and monitoring making up the other three quarters. That's why individual practitioners report three to ten times gains on specific tasks while most engineering leaders report one to ten percent at the organisation level. The tools aren't underdelivering. Leaders who haven't built anything with them simply don't know which parts got faster and which part is now the constraint.

You find out by shipping something. Nothing else works.

How to stay calibrated

Shipping features weekly isn't the goal. Three habits, that's all.

First, build a prototype with an agent before your next planning cycle and compare how long it took against what your team estimated. A five times gap is a conversation worth having.

Second, ship a small change through your own pipeline and feel the friction your team feels. Thirty minutes from commit to production is healthy. Two days is a systems problem, and you would not have known without touching it (if that number surprises you, straight to production is where I'd go next).

Third, use the tools on a real problem rather than a demo. Write a spec, get to a running prototype inside an hour, and you'll learn more in that session than in a quarter of executive briefings.

The point of all three is the same: stay close enough that your judgment on timelines, architecture, hiring and prioritisation stays calibrated. Put it in the calendar, because the calendar is the strategy, and an hour a week you never protect is an intention. Not a habit.

Go first, visibly

There's a second reason to do this in the open.

One of the most effective things a manager can do is use the tools visibly in their own work, whether that's the incident postmortem or the technical proposal. When the manager uses it in the open, it stops being a mandate and starts being normal.

Early on the blocker is almost never sophistication. Access and psychological safety, mostly. So the unglamorous work is auditing who actually has the tools, having honest one-to-ones about where each person really is, and making it safe to experiment and fail. A leader who's visibly mediocre with the tools in week one, and visibly better in week four, does more for that safety than any all-hands slide.

Culture spreads through behaviour, not announcements, and yours is the behaviour people are watching most closely.

What didn't get cheap

I want to be careful about what this argument claims.

AI made implementation cheap. It didn't make judgment cheap. Legacy code is still hard, distributed systems still fail in strange ways at 2am, and getting an organisation to change how it works is still political.

So the leader doesn't stay hands on to become an implementer again. The engineers who thrive won't be the fastest prompt writers, and neither will the leaders. They'll be the ones who can hold a system with twelve services in their head, state clear intent for an agent, and make the right call when three options look equally reasonable and the data doesn't point anywhere.

Taste still matters. Built by contact with the work, and decaying without it.

Short version: your judgment is the product you're paid for. The inputs to that judgment changed underneath you, and the only way to notice is to go and look.