I got my hands-on coding back, with a bonus

What restored the hands-on work wasn't a determined effort to carve out coding time. I'd tried that several times over the years, and the problem with 'I'll code on evenings' is that evenings also contain family, other work, and a finite energy budget. What actually worked was modern coding copilots - Copilot, Cursor, Replit's agents, Claude's code mode - lowering the activation energy of any individual coding task by enough that I'd actually do it. The typing speed gap I'd accumulated over years became mostly irrelevant in months.

What the tools actually gave back

The honest framing of what happened is not that my low-level implementation skill returned. Syntax familiarity for the languages I hadn't written in five years is still rough. What returned was my ability to translate architectural thinking into working code at a speed that matched my thinking. The tools handle the typing and the lookup. I handle the judgement about what to build and what to correct. That combination is quietly more productive than either younger-me with better typing speed or older-me with better judgement but no execution surface.

This is a subtly different thing from the 'AI will replace programmers' framing, and it deserves more precision than it usually gets. The tools haven't made me a better coder than I was at 28. They've made the version of me at 45 - with more judgement, less typing fluency, and much less uninterrupted time - able to execute at a pace roughly equivalent to the younger version. That's the gap they closed, and it's a different gap than the one the hype cycle talks about.

The leadership case

There's a version of this argument that matters specifically for engineering leaders. Over the course of a senior engineering career, most managers stop writing code. The explicit reasoning is that their time is better spent on higher-leverage activities. The implicit cost is that their technical judgement starts to drift from what's actually hard and what isn't. Engineers notice. Decisions suffer. The drift is slow and rarely self-identified, and by the time it's obvious, the damage has accumulated.

Copilots change the cost calculation for hands-on coding. Thirty minutes of prototype work in the new environment now produces enough calibration signal to inform decisions for a week. The 'management time is too valuable for coding' argument was never really about the coding; it was about the activation energy. Lowering the activation energy changes the argument. Engineering leaders who use these tools to keep their technical instincts calibrated tend, in my observation, to make materially better technical decisions than their peers who don't.

The tools haven't made me a better coder. They've made my current self able to execute at my younger self's pace.

Where this pattern breaks

The restoration isn't universal. The domains where copilots help most are the ones with high boilerplate, strong public training data, and common patterns - web backends, API integrations, typical CRUD work. They help less in domains that reward hand-crafted code: numerical libraries, systems programming at the silicon level, anything with tight performance constraints or unusual concurrency patterns. The 'flow restored' feeling I've been describing is domain-dependent, and it's worth being specific about when you're generalising from it.

There's also a quality-of-judgement caveat. Copilots make it faster to produce plausible code. They don't make it faster to produce correct code. For a returning engineer with dulled instincts, the seductive part is that the confidence often outruns the correctness. Some of the PRs I've written with copilot assistance have needed heavier review than I expected, because the code looked right even when it wasn't. The discipline of reading your own copilot-assisted output as critically as you'd read a junior engineer's pull request is one I've had to re-learn.

A recommendation

If you're an engineering leader who has stopped writing code, here's my concrete suggestion. Spend one afternoon a month, minimum, building something small with current tools. Not for production - for calibration. Pick a narrow problem, use a language you're not fluent in, and see how far you can get in four hours. The first couple of sessions will feel slow. The ones after that will feel fast enough that you start doing it voluntarily.

The side effect I didn't expect is that it's fun again. I'd forgotten that coding, when the tools aren't fighting you, is one of the more intellectually satisfying activities available to a human. For years the friction of rusty fingers made the activity feel like a duty. With the friction lowered, it's back to being a pleasure, and that's not a trivial reason to recommend the practice. Joy in work is scarce. If you can get some of it back by spending an hour with a coding copilot, that's a low-cost intervention with disproportionate return.

The bonus of experience is the phrase I keep coming back to. The tools plus years of accumulated judgement is a different combination than tools plus a two-year-old portfolio, and the gap is much wider than most experienced engineers realise. If you've been out of hands-on work for a while, the barrier to re-entry is lower than it's ever been. The incentive to go back is the one part nobody can do for you.