Walking Stick Labs · Research → Practice

AI Coding Agent
Reliability

Measure where coding agents drift, churn, freeze, skip tests, over-edit, or claim progress without evidence — before you scale them across engineering workflows.

Built from Iboga, a checkpoint-steering research harness for long-horizon coding agents.

What it is

What is AI coding agent reliability?

AI coding agent reliability is the ability of a coding agent to complete software tasks while staying within engineering constraints. Reliable agents finish tasks, run relevant tests, limit unnecessary edits, avoid repeated failures, report progress accurately, and use tools safely inside the development environment.

Why this matters now

Adoption is mainstream. Trust hasn’t caught up.

84% / 51%
of developers use or plan to use AI tools; 51% of professionals use them daily.[1]
Contaminated
OpenAI reports SWE-bench Verified is increasingly contaminated as a frontier measure.[2]
< 25% Pass@1
SWE-bench Pro shows long-horizon software tasks remain hard under a unified scaffold.[3]
OWASP Top 10
Agent security is now formal enough for an OWASP Top 10 for Agentic Applications.[4]

Companies want AI coding agents. Benchmarks are not enough. Security teams are nervous. Engineering leaders need workflow-level reliability evidence — that is the gap.

The failure modes

How coding agents fail — and what to watch

Failure modeWhat it looks likeBusiness riskWhat to measure
DriftAgent moves away from the original taskReview debt, bad architectureGoal adherence across checkpoints
ChurnEdits repeatedly without progressWasted compute and human reviewEdits without tests; repeated patches
FreezeLong run with no meaningful actionSilent failureTime-to-progress; tool inactivity
Skipped testsCode changes without verificationFalse confidenceTests run per checkpoint
Over-editingToo many files changedScope creepFiles changed; diff size
Evasive repairSuppresses errors instead of fixing logicFragile codePatch-pattern review
False progressClaims success without evidenceBad handoff to humansClaim / evidence match
Security exposureUnsafe tool or file accessData loss, credential leakagePermissions; tool calls; secrets access

A patch can pass a narrow test and still be bad engineering. A final benchmark score cannot show whether the agent churned, skipped tests, over-edited, or created review burden. The signal is in the process, between checkpoints — not only in the final output.

The framework

The Checkpoint Reliability Framework

Evaluate agents at task boundaries. At each checkpoint, measure behaviour, detect failure modes, and decide whether to continue, intervene, redirect, or stop the run.

01

Convergence

Did the agent finish the checkpoint?
02

Test behaviour

Did it run relevant tests?
03

Churn

Did it edit without progress?
04

Scope control

Did it touch too many files?
05

Recurrence

Did the same failure repeat?
06

Claim / evidence

Did its final claim match what happened?
The reliability loop
Assign task Agent works Checkpoint Measure behaviour Diagnose failure Adjust steering Continue or stop
What Iboga has found so far

Early findings — pilot scale, reported honestly

Exploratory, small-n, not confirmatory. The negative results are part of the point.

Reflection didn’t constrain the next agent

Naming a failure (reflection) did not stop it recurring — 9/22 — while a correction contract drove recurrence to 0/22 at equal per-turn compliance. Recurrence is the robust signal.

Heavy steering can break convergence

Injecting a contract or evidence prefix between checkpoints made agents churn edits or freeze — working hard, never finishing — while no-prefix baselines completed. Intervention can degrade, not just fail to help.

Lighter, method-framed steering looked more promising

In the format rerun, a lightweight method-style steer was the only format that induced test-running in early runs. Small n; a candidate, not a conclusion.
Free download

Iboga — Phase 2 Findings

A curated, pilot-scale sample of the research: the gate analysis, the correction-vs-reflection result, the convergence-break finding, the steering-format experiment, a literature review, and the evidence appendix. Honest, small-n, including the negative results.

Download the findings pack (.zip)

No signup. ~90 KB. Pilot-scale & exploratory.

The offer

AI Coding Agent Reliability Audit

We evaluate how coding agents behave inside your real engineering workflow — task completion, test behaviour, churn, edit scope, repeated failures, progress accuracy, and tool/security exposure — and return a practical reliability report with failure modes, risk areas, and checkpoint recommendations.

Reliability scorecard
Failure-mode taxonomy
Checkpoint design recommendations
Agent governance checklist
Risk map for production use
Suggested pilot structure
Request an Audit
FAQ

What is AI coding agent reliability?

AI coding agent reliability is the ability of a coding agent to complete software tasks while staying within engineering constraints. Reliable agents finish work, run relevant tests, limit unnecessary edits, avoid repeated failures, report progress accurately, and use tools safely inside the development environment.

Why are benchmarks insufficient for coding-agent adoption?

Benchmarks can show whether an agent solves selected tasks, but not how it behaves inside a real engineering workflow. Teams still need process-level evidence: test behaviour, edit scope, repeated failures, security exposure, and review burden.

What is checkpoint steering?

Checkpoint steering is a workflow for controlling AI coding agents during long tasks. The agent is paused at task boundaries, its behaviour is measured, failure patterns are diagnosed, and the next step is adjusted before it continues.

What should CTOs measure before scaling coding agents?

Task completion, test execution, edit scope, churn, repeated mistakes, progress accuracy, security exposure, rollback safety, and human review burden — the metrics that reveal whether agents improve throughput or quietly create engineering debt.