When we started experimenting with models coding we were looking at the right prompt, later at prompt chaining, then graphs. The higher the autonomy is we see there is the need for loops, both when coding but also when reviewing and releasing code.
Original blog here
Loop diagram with four nodes — act, observe, verify, repair — connected in a cycle
The loop. The interesting engineering lives in the bottom half.
Now multiple models are great on writing code at the act step. What requires further improvement is how the code is self healing, improving performance, take solid architecture decisions. Get real inputs to keep going, better and better each time.
That's the half of the loop Dromeas is built for. Not "write my code for me" — you already have something for that. Verify and repair. We run an amazing experiment: 16 feedback rounds with the same coding agent and a small React/TypeScript repo, building real features with and without the Dromeas MCP help. Btw this was the first time when the actual user is a machine and I have to admit that machines give more structured product feedback allowing a fun iteration until we got something useful.
Below is what actually held up. Including the parts that didn't.
What loop engineering looks like while you're coding
The loop while building a feature is four moves, and only two of them are the fun ones.
Orient. start_task({ repo_full_name, task }) in one call: where the code lives (paths, line ranges, symbols, callers), what's already known-broken in those files, and a token-budgeted read plan.
Act. Read the ranges from disk, make the change, keep the diff scoped.
Verify. Typecheck and lint first — they're free. Then verify_change with the full post-change content of every changed file. It analyses your uncommitted work; nothing needs to be committed or pushed.
Repair. get_findings({ trunk_review_id }) to read the blockers, then preview_fix for a diff or run_finding_fix to push one. Then back to step 2.
The bugs it caught that the agent didn't
This was the most consistent benefit across all 16 rounds, and it's the one worth the money. Not lint noise, not style nits — actual logic errors in code written minutes earlier.
While building a radius-select tool, a new commit() function in useRadiusSelect.ts didn't guard against a null draft. A spurious commit() with draft === null would silently wipe an already-committed selection. get_findings flagged it; the fix was one line — if (!draft) return; — and the agent's own log said it "would probably not have caught that on my own re-read."
Better one: a handlePointerUp click-vs-drag detector whose moved flag was set to true at pointer-down time. Meaning it never measured movement at all, so the comment right above it ("treat as a click if the pointer barely moved") was lying about what the code did. No linter or typechecker catches that. It takes reading code against its own comment — and two independent runs in two different rounds both caught it.
Knowing when to stop searching
Search tools have a failure mode where the agent keeps searching because searching feels like progress. Every code_finder_search and start_task response carries a value_signal, and it's honestly calibrated rather than self-flattering: tested side by side against a 22-symbol repo and a ~3,000-node repo, it rated the small repo's search value low (flat scores, most of the repo returned) and the large one medium. On low signal it returns an empty next_calls list, specifically so the agent doesn't reflexively chain another query.
On the star-map repo, getting_started reported first_move: "read_files" with the reason spelled out: "only 22 indexed symbols — reading the few source files end-to-end beats any search here." Every agent that followed it stopped after one or two orientation calls. That's real credit and context-window savings, from a tool telling you not to use it.
"What else touches this?" in one call
Search results inline the caller/callee graph and blast radius for top hits, not just a path. Searching worldToScreen came back with its file, its line range, its 3 callers (StarMapCanvas, hitTestStar, and the containing file) and a blast radius of 3 — enough to know a signature change ripples into exactly those three places, without opening any of them first. That's a manual grep chase replaced by one response.
Experiment rounds
16
same agent, same repo, with and without the MCP
Real logic bugs
2
caught in freshly written code, pre-commit
Blast radius
1 call
callers + impact inlined with search hits
Findings surfaced at bootstrap
222
60 critical, across two repos
We will cover in a different blog how loop engineering works when reviewing code or releasing products.
New Dromeas Skills
To get started with this we shipped three agent skills you can install straight into your coding tool from Workspace management → Agent instructions & skills
The honest downsides
While our early Loop engineering has been great so far, there are some downsides that you need to be aware.
It costs tokens, and on small codebases the math is worse. Orientation calls, verification payloads and findings all land in the context window. On a 22-symbol repo the agent can just read every file — and, to its credit, our own value_signal and first_move hints say exactly that. The loop earns its keep as coupling and history grow; on a toy repo it's overhead.
It makes tasks take longer. Verification is a real analysis pass, not a lint run — typically 60–120 seconds of polling per loop iteration. If you run it after every micro-edit, you'll feel it. Batch your edits, verify once per meaningful change. We're actively working on cutting that wall-clock time (quick: true already drops compliance for a materially shorter security + quality loop).
It's a loop, which means discipline. The value shows up when you actually read the findings and go back to step 2. An agent that dispatches a verification and then declares victory without reading the verdict has gained nothing. Notably, verdict: "unknown" with analyzed: false, retryable: true is not a pass — and yes, we had to write that in bold in the skill files.
Should I get started?
Actually, yes — especially if you build something robust and you have a sizeable codebase you will get real code context around dependencies, code scope and issues identified. Then your agent will self-heal your code every time it touches components with issues, always with some cost on time&token per task. Just add the new skills and get going.
Top comments (0)