The best code I shipped last quarter, I did not write. An AI did. I reviewed it, shaped it, redirected it a dozen times, caught three silent errors that would have cost us, and approved the final version. My fingerprints are all over it, just not on the keystrokes.

If you're mid-career, that either sounds liberating or vaguely threatening. A year ago, it would have felt threatening to me too.

The shift that already happened to you

Here's the framing that finally landed for me: the job of a programmer in the LLM era is no longer execution. It's direction-setting, risk management, and human-AI teaming. The loop has changed. You are not the one typing; you are the one deciding what gets typed, reviewing what comes back, and catching what goes wrong.

Most engineers I talk to already know this in practice. They use Copilot or Claude or Cursor every day. But they still think of themselves primarily as coders who use AI tools, rather than engineers who set direction and rely on AI to execute. That framing gap is costing them.

The tools are not a faster keyboard. They are a different job function wearing the same title.

What I actually stopped doing

Twelve years of ML, full-stack, and healthcare systems gave me a lot of muscle memory. Some of that muscle memory I had to deliberately unlearn.

I stopped writing boilerplate. Not just tolerating it being generated: I stopped allocating mental energy to it entirely. CRUD scaffolding, test harnesses, API wrapper code, migration scripts — I describe what I need, the agent produces a draft, I review and correct. The draft is correct about 80 percent of the time. The other 20 percent would have taken me longer to write from scratch than to fix.

I stopped Googling syntax. This sounds small. It is not. The hours I used to spend in documentation tabs, cross-referencing library versions, checking StackOverflow — that time collapsed. I ask the model, I verify once against the actual docs if it matters, and I move on. The cognitive overhead of switching contexts dropped sharply.

I stopped prototyping alone. For years, my default was to spike something in code to test a hypothesis. Now I spike in conversation first. I describe the architecture, the AI pushes back, I find the flaw in my reasoning before I've written a line. The code phase starts much later in the process than it used to, and that has made me faster overall.

What I now spend time on

Related Articles

Your Support Team Is Claude Code on a Timer

An L2 support engineer that's just Claude Code on a /loop, with all its state living in Slack reactions. No app, no database, no deploy — and it only pings you when it's real.

What an AI Audit Actually Finds

Most teams asking for AI don't have a model problem. They have a "which problem is even worth it" problem. Here's what a real AI audit surfaces — and why "don't build this" is often the most valuable line in the report.

Inside a Production Voice Agent: How the Stack Actually Ships

Production voice-AI has converged on a pattern: graph-based conversations, separated decision and response prompts, synthetic-call regression testing, and per-component latency budgets. Why the stack looks the way it does — and what most teams are still missing.