What Should Programmers Do While the AI Writes Code?

Devid E — Wed, 23 Sep 2026 16:29:21 +0000

There's a moment that didn't exist three years ago. You type out a task, hit enter, and then you just sit there. The agent is reading files, thinking, editing things. A little spinner goes around. Maybe it's forty seconds, maybe it's six minutes.

The first few times, I didn't know what to do with my hands.

What I did, for a while, was open Twitter. Then a Slack channel. Then a tab about a mechanical keyboard I had no intention of buying. By the time the AI finished, I'd lost the whole thread of what I asked for, and I'd read its output with the attention of someone reading terms and conditions.

That's the failure mode nobody warns you about. The AI didn't make me slower. It made me shallower, in the gaps. So I've spent the last while trying to figure out what to actually do in those gaps, and this is what I landed on. Some of it works every time, some of it only works on good days.

First, admit the wait is real work time

The mental shift that helped most was to stop treating the waiting as dead time. It isn't a coffee break the tool gave you. You've handed off the typing, but you still own the outcome. If the code is wrong, nobody is going to blame the spinner.

Once I saw it that way, the question changed from "how do I fill the time?" to "what part of the job is still mine while this runs?" And it turns out that's a lot.

Read the plan while it's still a plan

Most agents will tell you what they're about to do, or you can ask them to. That plan is the cheapest place to catch a mistake. If it says it's going to add a new table and you already have one that does the same job, you can stop it right there. Correcting that in a plan takes ten seconds. Correcting it after it's been threaded through eleven files takes an afternoon.

So while it works, I read the plan properly. I don't skim it. I ask myself a few boring questions:

Is it touching files I didn't expect?
Is it adding a dependency when the standard library would do?
Is it solving the problem I described or a slightly bigger, more exciting problem it invented?

That last one happens more than you'd think. These tools love to be helpful in ways you didn't ask for.

Start reviewing before it's done

You don't have to wait for the final diff. Files land one at a time, and you can start reading the early ones. By the time the whole thing finishes, you've already got a feel for the shape of it, and the review at the end is more like a final check than a cold read.

I noticed my reviews got a lot better when I did this. Reading a 600-line diff cold is exhausting and you start approving things just to make it stop. Reading it in pieces as it arrives is much easier on the brain.

And a note on review, since it's now the biggest part of the job: the code looking clean means very little. AI-written code is almost always tidy. Good naming, nice comments, consistent style. That's exactly what makes it dangerous, because tidy code feels correct. I've had to train myself to distrust the polish and go look for the actual logic. Where are the edge cases? What happens on an empty list, a null, a timeout, a user who clicks the button twice?

Write the tests, or at least the test list

This is my favorite thing to do in the gap, and it pays off the most.

While the AI is writing the implementation, I write down what "correct" means. Sometimes that's real test code. Sometimes it's just a rough list in a scratch file:

- empty cart returns 0, not an error
- discount can't push the total below zero
- two identical items merge into one line
- currency rounding: 3 items at 0.333 each

That list does two jobs. First, it forces me to think about the behavior independently of whatever the AI decided to build, so I'm not just anchoring on its version of the problem. Second, when it finishes, I've got a ready-made way to check the work that doesn't depend on trusting it.

If you've ever wondered why tests matter more now, not less, this is why. When you didn't write the code yourself, the tests are how you find out what it actually does.

Use the time to sharpen the next prompt

Vague instructions are the root of most bad AI output. "Add caching to the API" will get you something, and something isn't what you want.

While one task runs, I'll often draft the next one properly. What's the goal? What should it not touch? Which existing pattern in the codebase should it copy? Is there an example file I can point to? Spending three minutes on a tight request saves me from three rounds of "no, not like that."

It's a small habit, but it's basically the new core skill. Describing a problem precisely used to be a nice-to-have. Now it's most of the work.

Do the adjacent stuff nobody wants to do

Every project has a pile of small tasks that never quite get done. The README that's slightly wrong. The ticket that needs a real description. The changelog. The comment in a config file that says "TODO: explain this" from two years ago.

The gaps are the perfect size for these. They don't need deep focus, they don't need a big context switch, and you can drop them the moment the AI finishes. I've cleared out a shocking amount of backlog this way, mostly by accident.

Actually learn something

Here's one I don't see people talk about much. If the AI is using a library or a pattern you don't know well, go read about it while it works.

Open the docs. Skim the source. Figure out why it picked that approach. Otherwise you slowly turn into someone who ships code they can't explain, and that catches up with you at the worst possible time, like 2 a.m. when something is broken and the AI is confidently wrong about why.

I try to make sure that anything I merge, I could explain to a teammate without looking at it again. If I can't, I go and learn it. The gap is a good time for that.

Sometimes, run a second thing (carefully)

Yes, you can run multiple agents on multiple tasks at once. Some people love this. I have mixed feelings.

It works well when the tasks are truly independent, like a bug fix in one service and a small feature in another. It falls apart when you're juggling things that touch the same code, or when you're the bottleneck reviewing everything. There's a point where you're not being productive, you're just being busy, and you're reviewing four diffs at half attention instead of one at full attention.

My rule is roughly: two things at once is fine, three is where quality drops off a cliff. Your review capacity is the real limit, not the AI's speed.

And sometimes, do nothing

I know how that sounds. But I mean it.

Some of my best decisions came from standing up, walking to the window, and letting my brain chew on the problem without a screen. When you're no longer typing all day, there's a strange new risk that you never actually think all day. You're just reacting to output.

Getting up for water, stretching, staring at a wall for a minute. It's not laziness. Deep thinking about design and tradeoffs is what you're being paid for, and it doesn't happen while you're refreshing a feed.

What I try not to do

A short list of things that have burned me:

Approving without reading. The most tempting one, and the most expensive.
Starting a huge Slack thread. You'll come back with no memory of the task.
Stacking so many tasks that I can't review any of them well.
Treating "it runs" as "it's right." Code that runs and code that's correct are different things, and AI is very good at the first one.
Should you still write code by hand?

Yes. Regularly, and on purpose.

I don't say that out of nostalgia. It's the same reason pilots still practice flying manually even though autopilot handles most of it. If you never write anything yourself, your ability to spot a subtle bug or a bad design slowly fades, and that ability is exactly what makes you useful when you're supervising a machine that writes code faster than you ever could.

Pick something small each week and just do it the slow way. Notice how it feels. It keeps the instincts alive.

So, what's the job now?

If I had to boil it down: the AI is fast at producing code, and slow, or bad, at knowing whether that code is the right code. That gap is where we live now.

While it types, we do the parts that need judgment. We check the plan, define what correct means, learn what we don't understand, keep the project healthy, and think about the bigger picture. The typing was never the whole job. It was just the most visible part.

I don't know exactly where all this is heading, and anyone who claims they do is guessing. But for now, the gaps are what you make of them. You can spend them scrolling, or you can spend them getting better at the parts of the work that can't be handed off.

What do you do while the spinner spins? I'm genuinely curious, because I'm sure I'm missing good ideas. Drop them in the comments.

DEV Community: Devid E

What Should Programmers Do While the AI Writes Code?