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.
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