The most honest question a developer can ask in 2026 is not “which model is best?” or “how do I prompt better?” It is the question that sits underneath all the hype: what am I supposed to do while the AI writes my code?
Five separate Hacker News threads this week — each with a different angle — paint a picture of the new developer role that no product announcement or tutorial covers. From people running four AI agents in tmux panes to a developer who lost all interest in technology because AI took over the thing they loved most, the conversation is raw, contradictory, and more useful than any benchmark.
If you build software with AI tools, or you are deciding whether to start, these are the conversations developers are actually having when nobody from a vendor is watching.
The new workflow: four agents, four panes, shared memory
Ask HN threads about how many AI agents developers actively use reveal a pattern that would have sounded insane two years ago. One developer described their daily setup: a tmux session split into four panes, each running a separate coding agent on a separate workspace, all sharing memory between them. They typically use two agents concurrently but spin up extras for code reviews and research tasks.
Another developer who builds collaborative coding workspaces described watching people’s sessions daily. Between meetings, most people run one to two agents max. But when they are actually coding and in the zone, it jumps to four or five workspaces with one to three agents per workspace.
This is not science fiction. It is a Tuesday morning for a growing number of developers. The tmux pane layout that was once used for monitoring log files and database connections now shows four AI agents writing different parts of the same application in parallel.
The pattern is consistent across comments: developers have discovered that the bottleneck is not generating code but reviewing code. Running one agent fast creates a firehose of pull requests you cannot process. Running multiple agents requires you to manage attention, not write syntax.
“What do you do when your agents are working?”
This question, posted as an Ask HN thread, got answers that reveal the practical reality of the new workflow. The responses cluster into three camps.
Camp 1: Orchestrate more agents. Some developers fill the waiting time by spinning up additional agents on different repositories or projects. But several commenters pushed back hard on this approach. One described feeling “like Lucille Ball wrapping chocolates” on a factory line — constantly context-switching between agents, never deeply focused on anything.
Camp 2: Read, learn, and prepare. Several developers described using AI downtime productively. One reads technical books. Another collects programming keywords to improve their future AI prompts. A third does code reviews of what other agents produced. The most thoughtful response came from a developer who described staggering tasks: big architectural decisions while agents run on smaller tasks, then switching focus when the agents finish.
Camp 3: Do the human work. One developer described using Claude Code to handle their coding tasks while they handle everything else: discussions, answering questions, reviewing colleagues’ work. The agent runs asynchronously while they do the coordination work that machines still cannot do well.
The common thread across all three camps is that the developer role has shifted from “person who writes code” to “person who manages code-writing.” The idle time is real, and how developers choose to spend it reveals what they think coding actually is.
The identity crisis nobody expected
Two threads struck at something deeper than workflow. In one thread titled “What verb best describes what a developer does in 2026?”, the answers were telling. One developer suggested the verb is now “contextualize.” Another said “to LLM” — as in, “Dilbert LLMed the new landing page yesterday afternoon and the PR is already up.” A third argued that the word should simply be “develops” because the verb does not imply any particular method.
But the most provocative answer came from a developer who argued that the role of “developer” will be redundant in any traditional sense by late 2026. There will just be builders — people who use tools to create software. The distinction between someone who writes code by hand and someone who directs AI agents to write it will blur until it disappears entirely.
The second thread was more personal. A developer posted: “I lost any interest in technology. What do I do?” They described how coding was not just their job but their passion — they coded during work hours and then coded on evenings and weekends. When someone suggested they explore other interests, the developer replied: “That’s the problem — nothing. I was loving the profession so much.”
The responses ranged from practical to emotional. One suggested 3D printing and Raspberry Pi projects. Another said to go fishing. But the most revealing response came from someone who shared that Boris Cherny, the creator of Claude Code at Anthropic, has stated in interviews that he no longer codes. “This is a massive step forward and a promotion of sorts for those who can code,” the commenter wrote. “Step into it.”
This is the emotional center of the AI coding revolution. The tools are getting better, the workflows are becoming more efficient, but some developers are grieving the loss of the craft itself. The skill that defined their identity is becoming optional — and not everyone is ready for that.
Model expertise is the new skill
A thread about preferring Opus 5 over Fable 5 — two competing frontier models — revealed that model knowledge is becoming a professional skill in its own right. Developers are forming strong opinions about which model works for which task, and those opinions matter more than they used to.
One developer described using Sonnet 80% of the time on Claude.ai but Opus as the main agent on Claude Code, with sub-agents running Sonnet. Their reasoning: they do not know if their task is complex enough to warrant Fable, and using it feels like “trying to kill a gnat with a sledgehammer.” At work, Haiku almost always works as well as Sonnet and is cheaper and faster.
Another developer reported the opposite experience: Fable managed to build a complex systems project end to end while Opus kept getting stuck on the overall architecture. “Opus was easier to steer, but Fable was much better at actually finishing the thing,” they wrote.
A third developer described mixing models intentionally: Fable for analysis, GPT o3 for reasoning, and Opus or Sonnet for implementation. This is not just preference — it is an emerging discipline of model orchestration where knowing which model to assign to which subtask is a core engineering competency.
The most interesting comment came from someone who pointed out that without discussing the specific task, model comparisons are meaningless. “Coding small problems in Python works on low effort with older models. Less common languages on harder problems needs more,” they wrote. The implication: developer expertise in 2026 is less about knowing a programming language and more about knowing which model to throw at which problem.
The vibe coding backlash is a proxy war
The thread with the most comments — “How do we stop vibe coding?” with 75 responses — revealed that the real fight is not about AI coding at all. It is about whether developers are losing the ability to do their jobs.
One developer wrote that they had never been more informed about their own code since using AI agents. “It’s not some intelligence dementor,” they argued. “If your brain turned off while you were vibe coding, that’s honestly just a you problem.”
Another shot back that the companies pushing AI tools want them to replace people entirely. “So the software around it is designed with that mindset,” they wrote. “I’d really like something that works more like pair programming — where you share an editor session with the AI and it says ‘I’m thinking about doing X here, what do you think?’”
A third developer, later in their career, offered perspective that resonated with many: skills atrophy is real, but it is also a natural consequence of focus. “If you want to stay a master juggler, keep juggling. But you can also ask yourself, do I need to be a master juggler?” The analogy is powerful because it acknowledges that losing a skill to automation is not inherently bad — as long as you choose deliberately rather than drift into irrelevance.
The most practical suggestion came from a developer who wants new programming languages designed for the AI era. Their point: LLMs allow you to program at a higher level of abstraction. Instead of fighting that trend, we should build languages that lean into it — the way Python freed developers from the verbosity of C++ type declarations.
What this means if you write code for a living
The five threads, taken together, describe a profession in transition. Here is what they reveal:
The daily workflow has changed. Running multiple agents in parallel is no longer experimental. Developers are building tmux layouts, orchestration scripts, and review processes around multi-agent setups. If you are still using one agent in one terminal, you are leaving productivity on the table.
The idle time is real and valuable. Developers are using AI downtime for code review, reading, prompt refinement, and coordination work. The developers who struggle most are the ones who try to fill every idle second with more agent orchestration instead of using the time for thinking.
Model knowledge is a skill, not a preference. Knowing when to use Sonnet versus Opus versus Fable, and how to route tasks across models, is becoming as important as knowing a programming language. The developers who are best at this are the ones who get the most out of their tools.
The emotional cost is real. Some developers are grieving the loss of coding as a craft. This is not melodrama — it is a natural response to a fundamental shift in what it means to be a programmer. Acknowledging it is healthier than pretending it does not exist.
The role is shifting from writer to director. The most successful developers in the new paradigm are not the ones who write the fastest code. They are the ones who review the most code, make the best architectural decisions, and coordinate the most agents effectively.
The developers who thrive in this transition are not the ones who refuse AI or the ones who surrender to it entirely. They are the ones who figure out what is uniquely human about their role — and double down on that.