A question on Hacker News this week cut to the awkward reality of working with AI coding assistants: what do you do while they work? The thread is short, just three responses, but the answers reveal how developers are adapting their workflows to a world where the bottleneck has shifted from writing code to waiting for code to be generated.
The original post by theletterf mentions a few options already in circulation. Anthropic's Claude has a Doom plugin that lets you play the classic shooter while your agent grinds through a task. Kickback pays you to watch ads during idle time. Some developers spin up additional agent sessions, running multiple tasks in parallel to fill the gap. The question is not rhetorical. It reflects a real change in how development time gets allocated.
The senior-watching-juniors model
The most substantive response came from absynth, who framed the wait time as a supervision role. When LLMs generate code, the developer becomes a senior engineer looking after junior contributors. The AI is book-smart and capable but still makes mistakes that require human judgment. The wait time becomes review time: checking output against requirements, verifying edge cases, and catching logical errors that the model missed.
This framing matches what the industry is already seeing. Verification has replaced writing as the primary bottleneck in AI-assisted development. The model produces code quickly, but someone still needs to confirm it is correct, secure, and aligned with the intended behavior. That someone is the developer, and the work does not stop just because the model is processing.
Absynth's comment also highlights a心态shift. Developers who use AI assistants are not outsourcing their judgment. They are outsourcing their typing. The model handles the mechanical work of translating intent into syntax, while the human handles the higher-level work of determining whether the intent was correctly understood and appropriately implemented.
The parallel-processing approach
jrobertgardzins described a different strategy: running two or three tasks at once and walking away from the keyboard when all are being processed by Claude. This is the parallel-processing model, where the developer maximizes throughput by keeping multiple agent sessions busy simultaneously.
The approach makes sense for certain kinds of work. If you have a list of independent tasks, each requiring the model to generate code without much back-and-forth, you can queue them up and let them run. The developer steps away, grabs coffee, or handles something else entirely. When the tasks finish, the developer reviews the output and decides what to do next.
The limitation is that this works best for isolated tasks. If the tasks depend on each other, or if they require careful review between steps, parallel processing breaks down. The developer cannot walk away from a task that might need immediate correction. And walking away from multiple tasks at once means the review queue builds up, which creates its own bottleneck.
The loneliness problem
The third comment is the one that says the most about where the industry is heading. celadonuproot wrote that they talk to their AI agent and have it act as if it loves them back. This is not a joke response, or at least not entirely. It reflects something real about the isolation that comes with AI-assisted development.
Traditional software development is collaborative. You work with other engineers, discuss approaches, argue about architecture, and share the satisfaction of solving hard problems. AI coding assistants are powerful but solitary. The model does not care about your code. It does not have opinions about your architecture. It does not celebrate when you ship a feature. You interact with it, it produces output, and you move on.
When the model is doing most of the actual code generation, the developer spends more time waiting and less time engaging with the work. The social dimension of programming, the part that makes it enjoyable for many people, gets squeezed out. Having the agent perform affection is a coping mechanism for that loss.
What this tells us about AI tooling
The thread exposes a gap in current AI development tools. The waiting problem is real, and the solutions are ad hoc. Playing Doom, watching ads, or talking to your agent about feelings are not workflows. They are workarounds.
What developers actually need is tooling that fills the wait time productively without requiring them to context-switch away from the task at hand. Some tools are moving in this direction. Code review assistants that analyze AI-generated output while it is being produced. Testing frameworks that run automatically against generated code. Documentation generators that draft explanations alongside the implementation.
The better AI tools will not just generate code faster. They will give developers something meaningful to do during the generation phase, turning idle time into review time, test creation time, or documentation time. The developer stays engaged with the work instead of stepping away from it.
The new rhythm of development
The old rhythm of software development was write, test, debug, repeat. The new rhythm is prompt, wait, review, correct, repeat. That wait step is the one nobody has figured out how to optimize yet. The Hacker News thread shows developers improvising solutions: playing games, running parallel tasks, or seeking emotional connection with the model.
None of these are sustainable long-term. The parallel-processing approach works until the review backlog becomes overwhelming. The supervision model works but does not address the isolation problem. And having the model perform emotional labor is a stopgap that papers over a real change in how it feels to do this work.
The developers who will thrive in this environment are the ones who figure out how to stay productively engaged during the wait without burning out on the review load. That probably means investing in better tooling, building review workflows that scale with the number of parallel tasks, and finding ways to keep the collaborative and social aspects of development alive even when the code is being written by a machine.
The question "how do you kill time while LLMs work for you?" is really a question about what developers are for in an age of AI-generated code. The answer, as the Hacker News thread suggests, is still being figured out one Doom session at a time.