How I built an AFK coding-agent loop to ship HeyNews (issue to merge, without babysitting)
I spent most of my career doing non-technical work, and I now build our product, @HeyNews. I got there by talking to AI coding agents night after night. The catch: the agents are good company right up until 4am, when you're still hitting approve every thirty seconds and what you actually want is sleep.
So I built a loop I can walk away from and wrote up exactly how it works: https://blog.heynews.co/afk-coding-agent-loop/
The short version: I fill a queue of GitHub issues during the day, each with enough context that an agent can finish one without coming back to me for a product decision. The ready ones get a label. From there, the agents carry each issue through implementation, review, fixes, merge, and deploy checks, then unblock the next one. I stay in charge of what gets built. They do the rest.
A few things that made it work, not just demo:
The decision of what to build stays human. Only the labor moves to the agent.
Labels are the state machine, so I can read the status of any work at a glance.
Review runs as a separate loop with fresh context, not the same agent that wrote the code and is now sure it's right.
A host-side gate checks GitHub's review threads directly instead of trusting the agent's "I handled it."
Nothing reaches staging without a PR, ever.
The real lesson wasn't about code. Getting an agent to write code was the easy part a year ago. The hard part is the structure around it: enough that the work stays legible and safe to leave running while you're not watching. That structure is the moat, not the model. It's the same instinct behind HeyNews itself, just pointed at newsletters instead of pull requests: say what you want once, and let the system handle the repetitive parts.
If you're building with agents, I'd genuinely like to hear where you keep yourself in the loop versus letting the system run.
Replies
It might be useful to add a visibility layer showing “why this issue was safe to auto-run” so humans can trust the system at scale.
HeyNews
@iris_carr That’s a good point. The version I trust most has a pretty explicit “why this can run” trail: issue context, labels, scope boundaries, reviewer gate, and the final test plan. I think the next layer is making that visible
in one place so a human can quickly see why the system considered the work safe, not just its status.
the decision of what to build stays human, only the labor moves to the agent" is the clearest way I've heard anyone frame the agent workflow. also came from a non-technical background and the hardest part was never getting the agent to do the work, it was building enough structure around it that you could actually trust the output without checking every line. that separation between review and implementation being two different agents with fresh context is smart
HeyNews
@tina_chhabra Exactly. The agent writing code is only one piece. The bigger unlock for me was treating the surrounding workflow like the product: clear inputs, separate review, visible state, and hard gates where trust should not be delegated. Fresh-context review has been one of the biggest improvements because it stops the implementer from grading their own homework.
The separate review loop with fresh context is the key insight here. I've found agents are much better when they're challenged by another agent (or process) than when they're asked to critique their own work. The workflow and guardrails are becoming a bigger differentiator than the underlying model