What Are Developers Actually Doing Now That AI Writes the Code?

There’s a question that gets asked in hushed tones at engineering offsites and in Slack threads that go a little too long: If AI is writing the code, what exactly are we doing all day?

It’s not a rhetorical question. It’s a genuine, slightly uncomfortable one. And the honest answer is: it depends enormously on the person, the team, and whether anyone is paying attention.

Let me try to give you the full, messy picture.

First, Let’s Acknowledge What AI Coding Tools Actually Changed

Tools like Claude Code, Cursor, GitHub Copilot, and their successors didn’t just make developers faster at typing. They changed what kind of thinking the job demands.

Before these tools, a significant portion of a developer’s day was:

• Translating a well-understood idea into syntactically correct code
• Remembering or looking up API signatures, library methods, boilerplate patterns
• Writing tests for logic they already understood conceptually
• Debugging typos, off-by-one errors, and other mechanical mistakes
• Writing the same CRUD scaffolding for the hundredth time

A lot of that work wasn’t intellectually hard. It was cognitively expensive but not cognitively demanding. There’s a difference. It required attention and time, but not necessarily deep insight.

AI tools largely automated that layer.

What’s left — and this is the crux of everything — is either more valuable or more uncomfortable, depending on who you are.

What Developers Are Actually Doing Now: Six Real Patterns

1. The Prompt Engineers (The Optimists)

Some developers have genuinely leveled up. They’ve become extraordinarily good at decomposing problems, specifying requirements precisely, reviewing AI output critically, and stitching together complex systems.

They spend their days doing things like:

• Writing detailed specifications that give AI tools enough context to produce good output
• Reviewing and stress-testing AI-generated code for edge cases, security issues, and architectural coherence
• Thinking about system design at a higher level because the implementation layer is faster
• Shipping features in hours that would have taken days

These developers are genuinely more productive, and they’re often also happier. The boring parts got automated. The interesting parts — the design decisions, the tradeoffs, the user-facing thinking — got amplified.

They’ll tell you, and they’re not wrong, that this feels like the transition from assembly to high-level languages. Productivity exploded. The nature of the work changed. The job didn’t disappear.

2. The Velocity Illusionists (The Danger Zone)

This is a larger group than most engineering managers want to admit.

These developers are shipping code much faster — but the code is not proportionally better. They’re accepting AI output that roughly works, passing it through a quick mental scan, and merging it. Tickets are closing. Velocity metrics look great.

But here’s what’s accumulating underneath:

• Architectural drift — AI tools optimize locally. They solve the problem in front of them. They don’t know about the three other places in the codebase that established a different pattern, and the developer isn’t slowing down enough to check.
• Test theater — AI writes tests easily. It also writes tests that test the wrong things, or that are tautological, or that mock away the exact behavior that should be tested. Developers who don’t understand testing deeply are approving these with a nod.
• Competency debt — The developers aren’t building mental models of what they’re shipping. When something breaks at 2 AM, they’ll understand it less well than if they’d written it.

The output looks like productivity. The metrics support it. But there’s a slow-motion problem building.

3. The Newly Paralyzed (The Surprising Losers)

Here’s one nobody talks about enough: some experienced developers are actually slower now.

They sit down with Claude Code or Cursor, get output, and then spend enormous energy second-guessing it. They rewrite sections the AI got right. They go back and forth in prompts trying to get output that matches their mental model exactly, rather than just writing the code themselves — which they’re extremely capable of.

They’ve lost confidence in their own instincts and haven’t fully developed confidence in the AI’s output. They’re stuck in the middle.

There’s also a subtler version: senior developers who are uncomfortable admitting they don’t know how to use these tools well. They use them performatively, superficially. They’re not getting the productivity gains. And they’re too proud to ask the 24-year-old on the team who’s figured it out.

4. The Scope Expanders (The Hidden Gems)

Some developers have responded to increased velocity by taking on more. Not more tickets — more ambition.

They’re building internal tools they always wanted to build but couldn’t justify the time for. They’re refactoring that legacy module that’s been on the “someday” list for three years. They’re finally writing the documentation. They’re doing exploratory prototypes that previously would have required a sprint of planning.

This is genuinely valuable and often invisible on dashboards. The work doesn’t show up as shipped features. But it’s compounding interest. The codebase gets better. The team moves faster in ways that don’t trace back to any single PR.

These developers are a gift to any engineering organization and are currently underappreciated by metrics-focused leaders.

5. The Systems Thinkers (The Real Winners)

At the senior end, something interesting is happening. The developers who were already thinking at the architecture and systems level have become dramatically more powerful.

Previously, a staff engineer’s ideas were bottlenecked by implementation time — their own, and their team’s. A good architectural decision might take a quarter to validate through code. Now they can prototype it in a day.

They’re spending time on:

• Evaluating architectural decisions by actually building multiple alternatives and comparing them
• Writing clearer, more detailed RFCs because they can validate assumptions quickly
• Doing deeper technical due diligence — reading more code, asking harder questions, because they have time
• Mentoring more, because their own implementation burden is lower

The thinking-to-building ratio has shifted dramatically in favor of thinking, and for people who were already good thinkers, this is a superpower.

6. The Quietly Coasting (The Uncomfortable Truth)

Let’s be honest. In every organization, some developers have discovered that AI tools make it very easy to appear productive without being productive.

Generate code, review it lightly, push it. Attend standup. Close tickets. The output looks fine on the surface. Performance reviews are based on velocity and ticket closure. The metrics support a good review.

This isn’t unique to AI — it’s a management and incentive problem that predates these tools. But AI has lowered the floor. The minimum viable output of a mediocre or disengaged developer has gone up, making it harder for managers to detect disengagement through output alone.

The uncomfortable corollary: if your only evidence of developer productivity is tickets closed and code shipped, you’ve already lost the plot, and AI just made it worse.

The Productivity Question: Honest Accounting

Are developers more productive?

At the individual task level: mostly yes. The research and anecdotal evidence broadly agree that developers complete individual coding tasks significantly faster — often 30–50% faster on benchmarks, sometimes dramatically more on boilerplate-heavy work.

At the system level: unclear, and possibly no, yet.

Here’s why:

Productivity in software development is not determined by how fast you write code. It’s determined by how often you build the right thing, how maintainable that thing is, how rarely it fails, and how quickly you can change it when you’re wrong.

AI tools have improved the speed of code production. They have not necessarily improved — and may in some cases have worsened — the quality of problem definition, the clarity of system design, and the long-term maintainability of codebases.

We’re potentially in a phase where we’re spending our productivity gains on volume rather than quality, and the bill will come due when those codebases need to be maintained, extended, or debugged by people (or AIs) who didn’t write them.

The teams that are genuinely winning are the ones that have shifted their attention to the higher-level questions that AI can’t yet answer well: What should we build? Why? For whom? How do we know if it’s working? They’ve used velocity gains to invest in correctness, not just speed.

What Actually Changes About the Job

Here’s the deeper shift, and it’s worth sitting with:

The job of a software developer is becoming less about knowing how to write code and more about knowing what code to write, why, and how to evaluate whether the result is any good.

These are harder skills to teach, harder skills to measure, and harder skills to hire for — because for years we’ve been hiring largely based on coding ability, as demonstrated in coding interviews.

The developers who thrive in this new environment have:

• Strong opinions about product and user outcomes, not just technical elegance
• Deep enough expertise to evaluate AI output critically, not just approve it
• Comfort with ambiguity and system-level thinking
• Intellectual honesty about what they don’t know
• Good taste — the hard-to-define ability to recognize good design

Interestingly, these look a lot like the qualities that distinguished the best developers before AI. The bar for adequacy has risen. The ceiling for excellence has also risen, probably faster.

What Should Engineering Leaders Do With This?

A few things worth doing differently:

Stop measuring productivity by code output. Seriously. If your team is producing twice the code with AI tools, that’s not twice the value. It might be twice the maintenance burden.

Invest in taste and judgment. The leverage point has moved. A developer with excellent judgment about what to build and strong ability to evaluate AI output is worth significantly more than before. Train for that. Hire for that.

Create space for the scope expanders. The people refactoring, documenting, and building internal tools are doing compounding work. Don’t punish them for not closing tickets at the same velocity as someone who’s shipping sloppy AI output.

Pay attention to competency debt. If your junior developers are never working through hard problems because AI solves them, they’re not building the judgment they’ll need to be senior developers. This is a slow-burning crisis in early-career development that the industry hasn’t fully reckoned with.

Raise the bar on code review. If AI is making code cheaper to produce, your review process needs to compensate. More careful review of AI-generated code, not less. The asymmetry has flipped: writing code is cheap; understanding code is still expensive and now more important.

The Honest Bottom Line

Most developers at firms using AI coding tools are doing one of a few things:

• Genuinely thriving — they’ve adapted their role, they’re thinking bigger, they’re building better
• Appearing to thrive — the metrics look good, but the foundation is shaky
• Quietly struggling — they haven’t found their footing in the new model
• Doing something interesting and invisible — work that doesn’t show up in sprint velocity but matters enormously

The introduction of AI coding tools is, above all, a character-revealing technology. It amplifies good habits and bad ones. It accelerates good judgment and poor judgment with equal enthusiasm.

The developers who were already thinking hard about why they were writing code, and whether it was the right code, are doing better than ever.

The ones who were going through the motions are going through them faster.

And the job of every engineering leader right now is to figure out which is which — before the technical debt, the coasting, and the competency gaps come due at the worst possible moment.

The code is writing itself. The question of what to build, and whether it’s any good, is still very much a human problem. For now.

The firms that understand this distinction will compound. The ones that mistake velocity for value will eventually feel it.