Poor Mans Loop Engineering - by Brandon Sovran

Awaiting Input

SubscribeSign in

Poor Mans Loop Engineering<br>Enter the new era of how engineers engineer, without the LinkedIn pandering nonsense

Brandon Sovran<br>Aug 17, 2026

Share

Getting agents to perform all of your tasks for you without getting involved in their interaction cycle sounds like a fairy tale. To burst the bubble right away, agents can’t do this (yet). What they can do is take a scoped task and implement it end to end, without introducing regressions (most of the time, but even your best engineer is never perfect). Even this claim must take insane amounts of effort to achieve, right? Wrong, it doesn’t. The poor man's version requires two things: your agent needs to be able to test its own work, and it needs someone other than itself to review that work. This is the foundation of loop engineering.

What even is Loop Engineering?

Most of you reading this are probably already familiar with Loop Engineering, but a quick back story if you aren’t. Back in June, Addy Osmani from Google coined the term in his tech blog 1 “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead”. But this thesis isn’t new. Devs have been creating loops for their agents since late 2023 to help give more and more work to the agents as the models get better. The goal isn’t quite “press go and come back tomorrow”, although that’s an easy conclusion to draw, the goal is to ask what happens when you automate some of the iteration cycles we normally perform as software developers instead.<br>The poor man’s loop

Test Test Test

The “loop” isn’t that hard to get started; making it truly autonomous is. The first step is, in my opinion, the most important one, give the agent a way to know it’s wrong. Testing has forever been integral to software development, and it’s always been a place developers try to skip. Well, no excuses anymore with AI to help write the tests for you! Having said that, you don’t need to hop on VSCode and churn out PyTests, that’s not the point, the point is setting up a safe way for an agent to run integration/E2E tests (they already write a boatload of unit tests so don’t worry about that, they got it covered). This is critical to the loop. Spend time making the system accessible to an agent, be it solidifying Make commands to reliably spin up the Docker stack or hooking up a UI sandbox for the agent to click around and gather screenshots. You need a way for the agent to know if what it’s doing is right. With a true testing environment, we can get closer to those sweet, sweet benchmarks the frontier labs love to gloat about: in this sandbox, here are the tools, go do the thing.<br># Start the local environment<br>up:<br>docker compose up -d

# Run unit + integration tests<br>test:<br>pytest tests/

# Run end-to-end tests<br>e2e:<br>npx playwright test

# Run linting + type checks<br>check:<br>ruff check .<br>mypy .

# Give the agent one command for everything<br>verify: test check e2e

Get some more eyes on this

Next comes a critical feature in helping the agents bridge a gap in their current intelligence: adversarial reviews. Getting two fresh isolated context sessions using cross model validation is a method I have adopted. I’m not alone here. This was a method used in the controversial post “Rewriting Bun in Rust”2 to help migrate thousands of lines of code. Simply set up a hook in Claude to use fresh agents to perform a review of your current branch/worktree changes against the goal that you set for the session. The reviewers get a clean view of what should have been done and what was actually done. Do the tests pass? Are there gaps in the initial vision that weren’t implemented? Are there clear issues that might arise with scaling or security? They can step through a simple process to perform all of these checks and report back if it is clean to put up a PR. This adversarial review is critical. We use two agents (and, for best coverage, cross model validation 3) because agents aren’t deterministic, and we want to cover as many possible paths, thought processes, and high-level failure points as possible.<br>## Adversarial Review<br>When a task is complete, do not immediately mark it as finished.<br>Run an independent review using fresh agent context.

Review the implementation against:<br>- The original task or specification<br>- The current git diff<br>- Test results<br>- Relevant changed files

The reviewer should look for:<br>- Missing or partially implemented requirements<br>- Logic errors and regressions<br>- Security issues<br>- Edge cases<br>- Weak or missing tests<br>- Unnecessary complexity

The reviewer should actively try to find reasons the change should not be merged.

Return:<br>- PASS if no material issues are found<br>- FAIL with specific findings if problems remain

If the review fails:<br>1. Evaluate the findings<br>2. Fix valid issues<br>3. Re-run tests<br>4. Run the review again

That’s it?

# Task Loop

Given a task and specific goal continue...