🦄 Somewhere between studying for a certification, building an agent I only understand in theory, and waiting on a pipeline that isn't automated like I want it to be, I kept hitting the same dead air: AI is coding, and I'm... what, exactly?
So this post is me answering my own question — and inviting you to throw in more ideas. 🕰️✨
PS: @francistrdev the memes are special since you asked nicely last time 😆
This is for those of you who have decidedly finished hand-holding AI at every step of the process. If you're still prompting to change a method or implement a new environment variable, then this post is not for you.
If you're still reading then I'm guessing you've ran into the same problem that I have.
What on earth are you supposed to do while AI is busy coding?
That can take 5 minutes or 20, and it fundamentally changes the idea of the deep-focus time blocks we previously needed to be truly productive. We're not deep diving into the codebase regularly anymore, so what do you do with that time?
Here's some ideas and my thoughts on them, covering both personal projects — meaning there's no deadline — and work, where enterprise wants the deployment yesterday.
1. Slow Down 🐢🧘
Honestly, I'm terrible at this option. I want to be doing something at all times.
However, I recognize that sometimes I'm responsible for the same terrible output we accuse AI of: going with the first thing that makes sense and not stopping to consider all options every step of the way.
I'll catch myself stopping generations or retracting a previous statement when I could have sat with the problem statement a bit longer and came up with a better answer than the first one I had.
It's also the only option on this list that makes the next run better instead of just filling the time — sitting with the story a bit longer means I already know what I'm going to reject before the diff shows up.
2. Watch the Direction, Not the Diff 🧭🩻
This one is also difficult for me to accomplish because it feels like doing nothing.
I honestly do much less of this now than I used to. Before, I would watch the output, ready for something to go wrong at any point.
Then the trust grew — and yes, it still messes up sometimes — but that doesn't mean I'm back to watching it every step of the way.
If I am watching it, I'm looking more at the direction and less at the code itself. Is it touching the right portion of the file system? If I asked for a color change, but AI ended up changing a data file, that's a clue something went wrong somewhere. And keep an eye on the tests, because it will happily change them to go along with the code.
3. The Paperwork Nobody Automated 🗃️🪦
PR reviews, enterprise production requests, testing documentation — all the things that go along with a deploy when the pipeline isn't automated like you want it to be goes here — you know what I mean...
4. Study in the Cracks 🎓⏳
I'm currently studying for the GCP Architect Certification, so a lot of my free 5-minute time blocks are spent watching a short section of a video or taking a practice quiz — or a part of one, more likely.
It's nearly impossible to put aside time that doesn't get overtaken by a higher priority, but small, focused learning is doable in short intervals.
5. The "Quick" Slack Question 💬🪤
Helping the team usually means keeping up with my Slack messages for the day and monitoring channels that are particularly interesting — namely the AI ones. There's usually a quick question to answer or a quick call to make.
The challenge is making that "quick" call not take an hour while your AI is finished and now waiting on you.
Let me say that louder: this is a trap. Slack is interruptible in theory and never in practice. An hour into a "quick" call, the AI is done, waiting, and I've become the bottleneck — which is the one job I wasn't supposed to have anymore.
I did have a hook programmed in for Claude to announce itself when it finished. However, I ran into the problem with him announcing himself during meetings and often interrupting me (or someone else) with something hilariously off topic and not at all professional.
And yes — I know visual cues are an option, but honestly I don't even see them half the time. The audio cue works perfect, right up until it does not.
While You Wait 🕰️
That's my answer to my own question — sometimes productive, sometimes paperwork, sometimes just sitting with the problem longer than I want to.
⚖️ The filter: if you can't drop it in under 30 seconds when the agent finishes, it doesn't belong in the gap. Paperwork passes. A practice quiz passes. Slack fails. A meeting fails spectacularly.
Now it's your turn: what do you think is the best use of time through the day while AI is implementing the story (or two)? Throw your ideas in the comments — I'm collecting, clearly.
🛡️ Written While the Agent Was Busy
Claude ran the interview for this one — asked the questions, filed my answers where they belonged, and drafted this footer while I was off answering a "quick" Slack message. Every opinion, bad habit, and interrupted meeting is mine.



Top comments (131)
The memes are special lol. Glad to see them!
I just wait and do nothing while AI codes lol
That's definitely a good option! I can't sit still that long. Give me enough free time and I'll find a whole other project to add to the list. 😆
misse rules
Agent's session, checked against your own rules. What it followed. What it skipped.
npx rulereceipt checkI think the key at the end of the day is having a plan around an async workflow one way or another. Async work, organized in a way your brain can manage, has always been pretty important, but we're at the mecca for that right now.
Soo true..
You've reminded me of one I forgot in the list = "run another agent" 😆 I think smarter orchestrators will up the ante with this a bit, too.
the 30-second drop rule is the actual algorithm here. i'd add one constraint: only start work whose state is externally checkpointed, cuz interruptible isn't enough when the restart cost lives in ur head.
my queue would be: sharpen the acceptance criteria, inspect adjacent tests, write one negative control for the incoming diff. no slack, no second problem. then agent latency turns into verifier time without paying a context switch.
funny inversion: the best thing to do while ai codes is prepare the proof that its code shouldn't be trusted yet.
This is very useful insight, thanks! I think most everything I do is figuring out how to speed up the process without blind trust in the system. It's a tightrope some days.
that tightrope is the product. my practical rule is to automate the reversible middle and keep explicit checkpoints around scope changes, external writes, and anything the verifier cannot observe. speed comes from shrinking the review surface, not deleting it.
Even if I let the AI do the coding on its own without actively intervening, I don't let my mind wander—I keep checking what’s already been done, the current prompt, the next steps... as long as I’m working on a task, I stay fully focused.
So, unlike you, I can't mentally step away from the development process—though I suppose that’s only natural; men aren't really built for multitasking 😁
I’ve actually found that I don’t spend much time watching the AI code anymore.
My agents are heavily integrated into GitHub, so I tend to watch the development process itself.
Issues get opened, debated, linked to milestones, implemented through PRs, tested, challenged by other agents, revised, and eventually resolved. I can watch that entire lifecycle happen through GitHub without staring at the agent’s terminal output.
I think that’s becoming the more interesting abstraction for me.
The agent transcript tells me what the agent thinks it’s doing.
The issue tracker, tests, commits, and PR history tell me what actually happened.
So while the agents code, I’m usually watching the software organization argue with itself. 😄
And strangely, that feels much closer to managing a really fast engineering team than “using an AI coding assistant.”
I've been meaning to set up something very similar for myself, but haven't gotten around to it yet. I'm still letting Claude and Codex fight it out locally.
I have a mixture of models running through OpenRouter. I even give them common personas based on programmers I’ve worked with. I’ve got Mr. LGTM and Angry Greybeard, who probably should’ve retired a few years ago.
Diversity!!
I love this! I used to do that a lot a while back. I had a cave gremlin writing commits and Dracula reviewing code for me. 🤣
Back in the early days of coding with models, before IDEs really started integrating all this stuff, whenever I got stuck I’d sometimes ask, “What would Jesus do?” 😂🙏
Strangely enough, it worked way more often than it should have. Sometimes the model just needed a completely different way of looking at the problem. 🤣
😆 That's it exactly!
At the mercy of Slack over here 🥲
The basic rule is to keep tasks short and quick. Conversations that go on too long often lead to mistakes.
Yes, but then where do you draw the line at what's too short or too long? I think my 5-20 minutes is probably forgiving a lot of my longer runs, but making the task shorter does not give my ADHD something to occupy itself with while I'm not-watching output.
It is scary to hear that there are software engineers who let the agents work for 20 minutes without ever checking what the agents is doing in the codebase. I cannot imagine how this does ends up not having a massive negative effect on the codebase, product and the companies allowing this.
This can only be fine when working on non-prodution code and side projects.
20 minutes doesn't seem like a very long time. I'll keep push commands gated, but I'll let the agent run as long as it needs to after I've approved the plan and let it commit when it needs to. The biggest bottleneck at work ends up being testing that output.
Tests are extremely important. To start with, you should break them down and keep them simple: security, business impact, and performance. Of course, it all depends on the project.
By short, I'm referring more to the scope than to the time it takes to complete it.
Gotcha. And I agree the tests are just as important as the code itself, if not more so.
By "short," I'm referring more to the scope than to the time it takes to complete it.
take slight break and stretch
Or look at more hardware to buy
I just code more - run parallel sessions and jump between them while they take time to process my asks. I think I developed a lot of anxiety with this, don't recommend to anybody.
Like any technological leap: it doesn't take away our jobs, but transforms them and multiplies the output.
This is so true. I look at it as adding another layer of abstraction on top of the code, like we've been doing for years already. The process changed but the shape has not. It's still problem solving in the end.
We switched the coding language to English (mostly). After all, it really is a form of abstraction. 😀
I do this a lot too, but then I lose track. PRs get opened, commits are made, and I've only got half a clue as to what I was trying to accomplish when I started! 🤣
Foouuurrr!! Yes, definitely agreed "small, focused learning is doable in short intervals". Catching up on emails is also another way I pass the time. Seems like they keep piling up and I can't make a dent on them. Great ask!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.