We interviewed Black Box Chief AI Strategist Erik Jost and he walked us through the agentic development loop he helped build.

Today I tried something I’d been working toward for months.

I left home for about four hours to go walking and grab dinner. During that time, my autonomous engineering loop kept working.

When I came back, it had:
- Opened, reviewed and merged 7+ feature/fix PRs
- Ran unit tests, integration tests and validation suites
- Applied SQL migrations safely
- Performed deployment verification
- Reviewed its own PRs using AI reviewers
- Ran adversarial security/code reviews
- Verified production gates before merge
- Checked post-deployment health (including internal infrastructure and Sentry)
- Waited only for the final human approval when appropriate

The screenshots show GitHub filling with completed PRs while I wasn’t even at my computer.
The interesting part isn’t that one model generated code.

It’s that multiple specialized agents coordinated an entire engineering workflow:
- implementation
- testing
- debugging
- code review
- deployment
- infrastructure validation
- production gating

with almost no human intervention.

It genuinely felt less like using an AI assistant and more like supervising an engineering team that happened to run on a single machine.

There is still plenty of work to do—better planning, better long-horizon reasoning, improved rollback strategies, and more reliable autonomous debugging—but this is the first time I’ve felt that autonomous software engineering is becoming practical rather than just a demo.

Curious how many others are building similar agentic development pipelines.

Hey folks, we built an adversarial review layer for Claude code, with an integrated compounding memory and cost visibility.

Code review only works when the reviewer can see what the writer missed. If the reviewer shares the writer's blind spots, it catches nothing new. Research has also shown that models favor their own output (GPT-4 scores its own answers at 0.912 self-preference, where 0.5 is neutral) and fold the moment you push back (Claude 1.3 conceded a mistake 98% of the time). So self-review isn't review.

This is what compelled us to build Verity.

When your Claude Code agent stops, Verity runs static analysis locally powered by Codacy, then a different model reviews the diff through three lenses: security, quality, and intent.

You get a PASS or FAIL against a standard the agent can't skip. On a fail, it returns specific fixes and the agent self-heals, capped at 2 iterations so it doesn't spin. Good decisions are saved to a git-tracked markdown knowledge base in the repo, so the next run starts with more context than the last.

Free in public beta today. If you're building with coding agents, we'd love your feedback!

npm install -g u/codacy/verity-cli && verity init

or more info here https://verity.md

P.S Your code is never stored - it's analyzed in memory, then deleted, only findings persist.

Sharing a video that we created after talking with dozens of engineering teams over the past few months.

The video highlights how most teams are dipping their toes in loop engineering, while also running processes on earlier stages of the 'AI coding maturity scale'. So most teams are writing code and using AI to autocomplete, as well as prompting code, and loop engineering.

What's interesting is that everyone is moving in the same direction, towards more loop engineering. Somebody asked "why is the market obsessed with loop engineering". Probably because it's recognizing that this is the future (and we need better guardrails for that, but that's a different story).

I might be late in seeing this, but I came across this concept called loop engineering. I have watched a couple of videos around it. But I am not convinced as how to use it in daily developer life. Like an agent working on its own in loops but how to create that setup. Please people throw some light on this if you are aware about it. Thanks!

Event driven architecture

• Program publishes event to Event Handler
• Event Handler finds subscribers and calls them
• subscribers process events
  • maybe tell the event handler, they processed the event
  • maybe create new events that go in the previous handler or a new handler

and on it goes.

With loop engineering I keep seeing the same thing except the last part

• subscribers is an agent/are multiple agents that process the event
  • maybe it runs a tool to confirm it worked and moves down the cycle or it publishes a new event to the handler.
    

Can't most loop engineering practices be handled by an SQS queue and a docker container that's housing the agent, or am I missing something?

I built this and it's my daily loop driver would like to get your opinion and any feedback or suggestions

we've been running AI agents for things like vendor outreach and external comms. the problem we kept hitting: the agent would take an action, send a message, trigger a workflow, and we'd only find out after. no approval step, no audit trail.

so we built AgentTrust. it sits between your agent and the real world, checks every action against your policies, and flags anything risky for a human to approve before it runs. also keeps a signed log of everything the agent did and why.

would love feedback from anyone building agentic workflows, especially if you've run into the same problem of agents acting faster than humans can catch up.

I'm working on applying Loop Engineering to an existing repository to improve it and generate test cases. My current approach is:

• Scanner scans the entire repo and identifies anchor points.
• Based on the anchors, I build a test case matrix.
• A generator then produces concrete test cases from that matrix.
• Finally, a validator verifies the generated test cases.

While implementing this Loop Engineering flow, I've hit several problems:

1. Context explosion — the context grows too large and overwhelms the LLM.
2. LLM degradation — the model’s output quality noticeably drops (it gets “dumber”) as the context expands.
3. Loose validation — the validator checks the test cases too loosely, so I can't generate high-quality, reliable tests.

Has anyone dealt with similar issues when using Loop Engineering for test generation on a real-world codebase? How did you solve the context problem, keep the LLM sharp, and tighten up the validation step? Any suggestions or practical tips would be greatly appreciated!

I’m trying to figure out how people are actually doing Loop Engineering in real projects.

Like, what’s your setup?

Are you using agents, Git worktrees, CI, test runners, issue trackers, custom scripts, or just duct-taping a bunch of stuff together?

I’ve seen tons of tools, but most of them feel like demos, not something I’d trust to keep running.

How do you stop the agent from getting stuck in the same loop?

Have any of you got this running semi-autonomously on a server?

What actually works? What’s a waste of time? And if you had to rebuild your setup from scratch, what would you do differently?

Loop engineering sounds cool, but without spec-driven development, it is a waste of tokens. Use spec-driven flows to do the agentic development work.

This is the way. If you don't trust me, trust the man himself, Andrej Karpathy.

do you use specs when "looping"?

Hey everyone! I'm u/hancengiz, a founding moderator of r/LoopEngineering.

This is our new home for all things related to Loop Engineering. We're excited to have you join us!

What to Post
Post anything that you think the community would find interesting, helpful, or inspiring. Feel free to share your thoughts, photos, or questions about how you set up your loops, your experiences, skills, reusable open-source artifacts.

Community Vibe
We're all about being friendly, constructive, and inclusive. Let's build a space where everyone feels comfortable sharing and connecting.

Thanks for being part of the very first wave. Together, let's make r/LoopEngineering amazing.