cd /news/developer-tools/three-loops-no-ship · home topics developer-tools article
[ARTICLE · art-40008] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=↓ negative

Three Loops, No Ship

A developer spent three iterations building an auto-fix pipeline that still only works reliably on trivial tickets. The pipeline, which pulls tickets from Azure DevOps, runs them through a local model, and pushes fixes via a coding agent, succeeded 40% of the time initially and only reached 55% after improvements. The developer learned that local models hit working memory limits before quality degrades, and that adding features merely moves reliability gaps rather than fixing them.

read2 min views1 publishedJun 25, 2026

I spent three iterations on an auto-fix pipeline that still doesn't work reliably. Here's what I learned.

Wrote a background script. Pull tickets from Azure DevOps, run them through a local model, hand to a coding agent, push the result.

Poll → triage → fix → push.

Worked 40% of the time on trivial tickets. Anything that crossed file boundaries or needed real context — stalled or hallucinated.

I shipped it anyway. That was naive.

Made it smarter. Pre-selected relevant files. Broke big tickets into subtasks. Turned complex edits into atomic steps with verification between each.

Got it to 55% or so. But every fix created two new edge cases. The complexity was compounding faster than the reliability.

Went all in. Embeddings for dedup. Multi-repo routing. Auto-revert. A learning loop that fed failures back into future runs.

The model server started dying. 890 memory errors in a day.

Root cause: two independent consumers hitting the same local model server, each with its own retry loop. When memory filled up, retries amplified instead of staggering. The system was making itself worse.

Fixes were simple in hindsight — stop retrying OOM, serialize access, use the local binary not npx. But the pattern kept repeating: add more to fix the last thing, break something else.

The pipeline still only works on easy tickets. Hard ones need a human. After three rounds, the main thing I learned is that local models hit a wall before your ambition does — not in quality, in working memory.

And adding features doesn't fix reliability gaps. It just moves them around.

The 507 retry spiral taught me more than any successful deploy this year. Because it was entirely my fault. Not the model's, not the framework's. I built concurrent consumers with independent retry loops and expected them to coordinate. They didn't.

I'll do a fourth loop. Smaller. A dedicated fast model for cheap work, the big model only for editing. One consumer at a time.

Might work. Might be loop 5's prologue.

I'm looking for people building similar things. Local agent pipelines, auto-fix loops, small-model orchestration — the stuff that's not quite working yet but you keep iterating on.

No Slack. No Discord. No newsletter. Just people who build this stuff and want to compare notes.

What media would you gravitate around? A private GitHub org? A Telegram group? Occasional calls? Reply or find me — curious what works.

Failure post, not a success story. If you're building something similar — don't retry OOM, serialize your consumers, and measure what your model server can actually hold.

── more in #developer-tools 4 stories · sorted by recency
── more on @azure devops 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/three-loops-no-ship] indexed:0 read:2min 2026-06-25 ·