Abstract. mini-SWE-agent is a deliberately small coding-agent harness — roughly 100 lines of Python, bash as its only action space, linear message history, and no custom Agent-Computer Interface — that approaches the SWE-bench Verified scores of much heavier frameworks when paired with frontier models. Its importance is methodological rather than architectural: it converts scaffold complexity from a default assumption into a measurable burden of proof, and supplies a controllable baseline against which richer harnesses must defend their marginal value. The bounded reading of the result is that some scaffolding that mattered for earlier models has lower marginal value on this benchmark for stronger 2025–2026 models; the stronger reading — that agent engineering is generally obsolete — is not supported by the evidence and ignores production requirements the benchmark does not score.

Coverage note: verified through May 2026.

mini-SWE-agent: When Minimal Scaffolding Matches Heavy Frameworks

1. The artifact

mini-SWE-agent is a sibling project to SWE-agent, maintained in the same GitHub organization, and presented as a stripped-down alternative rather than a successor. The README describes the agent class as roughly 100 lines of Python, with no specialized tools beyond the shell, no required tool-calling interface, no retrieval-augmented context manager, and a linear conversation history that is never truncated by a separate state manager. Actions are executed as independent subprocess.run calls; the agent does not maintain an interactive shell session, so each command runs in a fresh environment that the model must explicitly re-establish if state is needed. (mini-SWE-agent README; mini-SWE-agent docs)

The framing in the project's own documentation is unusual for an agent system: it advertises what it omits. It omits the bespoke file viewer, structured edit primitives, and search commands that earlier Harness Engineering work on SWE-agent argued were necessary to keep frontier models on track. It omits the conversation-state machinery (history truncation, demonstration injection, reflection loops) that has accumulated in heavier frameworks. It omits any specialized Agent-Computer Interface in the strict sense: the only affordance the model has is a shell. (mini-SWE-agent README)

The system retains four things, and the article should be careful not to call any of them "no scaffold":

A configured environment. mini-SWE-agent runs inside a sandboxed execution context (Docker, an SB-CLI cloud runner, or a local sandbox) and exposes the working directory of a SWE-bench task. The benchmark provides the repository at the right commit and the test oracle; the agent does not have to discover them. (SWE-bench Verified; mini-SWE-agent docs)
A SWE-bench-specific prompt and configuration. The benchmark configuration includes a task framing, a command vocabulary description, and a submission protocol. This is light by framework standards but it is not absent. (mini-SWE-agent docs)
A linear ReAct-style loop. The agent emits a thought and a command, observes the output, and continues. The loop terminates on a submission command or on exhaustion of a step or cost budget. This pattern itself is a scaffold — a particular theory of how software work should proceed. (mini-SWE-agent README)
A submission and grading pipeline. Patches are extracted from the working tree, applied to the benchmark environment, and graded by the SWE-bench test runner. (SWE-bench Verified)

"Minimal" therefore names a layer — the agent–environment interface — not the entire stack. The right contrast is not "raw model versus agent." It is "thin, bash-first agent loop versus richer agent framework under matched evaluation constraints."

2. Why this design was a provocation

The provocation lands against a specific argument in the original SWE-agent paper. Yang et al. introduced the term Agent-Computer Interface precisely to argue that language-model agents are "new end users" of computers, and that giving them human-style shells produced worse benchmark results than giving them tools designed for token-budget, line-anchored, parseable interaction. The paper supported this with ablations: a bounded file viewer, a structured edit primitive, and a summarized search interface each carried measurable gains on SWE-bench Lite, and removing them dropped scores by several points. (NeurIPS 2024 — Yang et al.)

mini-SWE-agent's design directly contradicts that thesis. Its action space is the shell, with no file viewer, no line-replacement edit command, no specialized search affordance. If the SWE-agent thesis had remained tight, this configuration should have lost substantial benchmark ground to a richer harness running the same model. The empirical surprise is that, on SWE-bench Verified with frontier models, it largely does not. The official SWE-bench site reflects this by exposing mini-SWE-agent as a selectable agent in its leaderboard interface, framing it as an apples-to-apples way to compare language models in a minimal bash environment rather than as a defective baseline. (SWE-bench leaderboard; SWE-bench Verified)

That move — making the minimal harness a first-class comparison condition rather than a control variable — is the conceptual contribution. It shifts the burden of proof. A richer scaffold no longer wins by default for being richer; it has to outperform the bash-only baseline by a margin that survives matched conditions.

3. SWE-bench Verified as the evaluation setting

The result derives most of its force from being measured on SWE-bench Verified, a 500-instance human-curated subset of the original SWE-bench benchmark. OpenAI and the SWE-bench authors filtered out instances with ambiguous issue statements, overly restrictive hidden tests, or unreliable execution environments, producing a benchmark whose unresolved scores are more likely to reflect agent capability rather than oracle pathology. (OpenAI — Introducing SWE-bench Verified; SWE-bench Verified)

Two properties of Verified matter for the mini-SWE-agent reading.

First, Verified is cleaner but not different. It uses the same task format, the same Python repositories, the same hidden-test oracles, and the same Dockerized execution as the parent benchmark. A model that does well on Verified did not enter a new evaluation regime; it entered a less noisy version of the existing one. Whatever mini-SWE-agent's result means for "software engineering," it means it through this 500-task slice of twelve Python repositories. (SWE-bench Verified)

Second, Verified is public, well-instrumented, and increasingly saturated. Frontier models trained through 2025–2026 have substantial exposure to the relevant repositories, related issues, common fix patterns, and even prior SWE-agent trajectories that appear in public corpora. A December 2025 contamination critique reported large gaps between SWE-bench Verified scores and scores on newer, contamination-resistant benchmarks built from the same model families, and argued that Verified scores may partially reflect task familiarity or memorization rather than live issue-resolution ability. (Contamination critique — arXiv 2512.10218)

This is not a reason to discard Verified, but it is a reason to discipline interpretation. A bash-only agent that does well on Verified may be revealing how much of the task can be solved when the model has prior exposure to the codebase, the test conventions, and even the typical fix shape. That is consistent with the mini-SWE-agent surprise; it is not, by itself, a generalization to engineering tasks the model has never seen.

4. The empirical surprise

The single observation that carried the project into wide discussion was that mini-SWE-agent, at roughly 100 lines of Python and with bash as its only tool, posted a SWE-bench Verified score competitive with full SWE-agent and other heavier systems when paired with a frontier model. The project's own news entry recorded 65% on Verified with about 100 lines of Python in mid-2025, and the docs currently report results above 74% with stronger frontier models. (mini-SWE-agent docs; SWE-bench leaderboard)

The most controlled public evidence comes from the Lita paper, which compares OpenHands and mini-SWE-agent on Verified across the same model family. Two rows from its Table 2 are decisive:

Model	OpenHands (Verified)	mini-SWE-agent (Verified)	Reported gap
Claude Sonnet 4	68.0	64.8	3.2 pp
Claude Opus 4	67.8	67.6	0.2 pp

Source: Lita Table 2. (Lita — OpenReview)

The pattern is a shrinking-gap result, not a no-gap result. Heavier harnesses retain a margin on weaker models in the same family; on the strongest model, the margin collapses to essentially zero. This pattern is what the project's writeups and the wider commentary refer to when they describe mini-SWE-agent as "matching" heavier scaffolds: not that the gap is zero everywhere, but that it shrinks fast enough as model capability rises that scaffolding's marginal contribution becomes hard to defend on benchmark grounds alone.

The shape of the result is more important than the exact numbers, because the exact numbers move. SWE-bench Verified leaderboards drift with each model release, each harness version, and each retry-policy change. The article's claim is about the trend — heavier frameworks lose their lead as models improve on this benchmark — not about a fixed scoreboard. A reader interpreting a current leaderboard should therefore check the date, model snapshot, harness version, and run budget of each entry before treating any specific row as comparable.

4.1 A comparison snapshot

The honest version of the comparison is a dated audit table rather than a narrative scoreboard. Below is one such snapshot, drawn from sources as of May 2026; numbers in this table should be treated as historical, not live.

System	Model	SWE-bench Verified	Date / source	Notes
OpenHands	Claude Sonnet 4	68.0	Lita Table 2 (OpenReview)	Same-budget comparison reported in Lita
mini-SWE-agent	Claude Sonnet 4	64.8	Lita Table 2 (OpenReview)	3.2 pp gap
OpenHands	Claude Opus 4	67.8	Lita Table 2 (OpenReview)	Same-budget comparison reported in Lita
mini-SWE-agent	Claude Opus 4	67.6	Lita Table 2 (OpenReview)	0.2 pp gap
mini-SWE-agent (mid-2025)	Frontier model, ~July 2025	65	SWE-bench news entry (SWE-bench leaderboard)	"~100 lines of Python" framing
mini-SWE-agent (current docs)	Strong frontier model	74+	mini-SWE-agent docs (mini-SWE-agent docs)	Higher with newer frontier model; configuration details in repository

This table is partial by design. A more complete comparison — including SWE-agent proper, OpenHands, Aider, and other harnesses — would have to pin down run budget, prompt configuration, retry policy, environment image, and patch-extraction logic per row. Public leaderboards rarely expose all of these uniformly. The article's empirical claim survives this incompleteness because it depends on the trend across matched-model rows, most cleanly seen in the Lita table.

5. The pruning principle as a bounded hypothesis

The interpretation usually attached to this result is what its commentators call the pruning principle: as base models improve, some scaffolding that previously raised benchmark performance becomes redundant, and the right design move is to strip the harness back and re-add components only when they demonstrably fix a measured failure. The Lita paper formalizes a version of this as an "Agent Complexity Law," arguing that the gap between simple and complex agents on SWE-bench-style tasks shrinks as model capability improves. (Lita — OpenReview)

Stated as a bounded hypothesis, the principle is well-supported. The Lita table is itself evidence: for stronger models in the Claude 4 family, a thin scaffold reaches near parity with a richer one on Verified. The mini-SWE-agent's headline numbers reinforce the same pattern. And the ablations in the original SWE-agent paper, when re-read alongside these results, are no longer evidence that bespoke file viewers and structured edit commands are necessary; they are evidence that those affordances were useful for the models available in 2024. Some affordances may have been compensating for limitations frontier models have since closed.

Stated as a law, the principle is overstated. There are at least four reasons the bounded version is the most the evidence supports.

The Lita evidence is mixed across model strengths. The same paper that frames the complexity law reports larger gaps for weaker models and notes that terminal-only agents place greater demands on model robustness; explicit tools remain useful for weaker models in the table. The result is not "minimal is always enough." It is "minimal is enough for the strongest models on this benchmark." (Lita — OpenReview)

The benchmark may be doing some of the work. SWE-bench Verified is a constrained slice of public Python repositories with deterministic tests. Frontier models have heavy training exposure to those repositories and to common fix patterns. A bash-only loop can succeed on this distribution by leaning on prior knowledge of file layouts, idiomatic edits, and typical pytest invocations that less-trained models would have to discover through scaffold-mediated search. The same scaffold-free configuration may not survive on private repositories, languages with thinner training coverage, or fresh tasks the model has not seen. The December 2025 contamination critique gives empirical weight to this concern. (Contamination critique — arXiv 2512.10218)

Pass/fail scoring undercounts scaffolding's job. A patch that passes hidden tests after a chaotic trial-and-error trajectory scores the same as a patch derived from clean localization, careful inspection, and a principled fix. AgentLens, which scores agent trajectories along process-quality axes rather than only outcome, finds that a meaningful share of passing SWE-bench trajectories exhibit "Lucky Pass" behavior — patches that succeed through high-variance attempts the system would not be expected to repeat in production. Process-aware reranking shifts the leaderboard order from outcome-only rankings. (AgentLens — arXiv 2605.12925)

If process quality is part of what scaffolding buys, then a benchmark that scores only outcome can systematically undercount the value of richer harnesses. A bash-only agent may match a structured-edit agent on percent resolved while producing trajectories that would be harder to ship, harder to audit, and harder to debug.

Bash is still an interface. A shell is a rich action space — process control, file system, network, package manager, language runtimes, test runners — that the model has extensive training exposure to. Calling this "no Agent-Computer Interface" understates what is happening. The model is using an interface; the interface happens to be one its training distribution already includes. That is a powerful thing for a frontier model and a less powerful thing for a model with less terminal exposure. The pruning principle should be read as "you may be able to drop the bespoke ACI in favor of the shell," not "you may be able to drop the interface."

Taken together, these qualifications do not refute the pruning principle. They re-shape it. The principle is best stated as: some scaffolding accumulates to compensate for model limitations; as models improve, that scaffolding's marginal value falls; a thin harness is therefore a defensible default starting point, with each added component required to justify itself against a measured failure. That is a methodological claim, not a law of agent architecture.

6. Methodological contribution: ablation by subtraction

The deepest contribution of mini-SWE-agent is procedural. It demonstrates that for at least one influential benchmark and at least one class of frontier models, the entire agent scaffold above the shell can be treated as an ablation candidate. Previous coding-agent research generally took the harness as fixed and varied components within it. mini-SWE-agent inverts that: the minimum viable harness is the baseline, and richer frameworks are the experimental conditions.

This recasts a long-running debate in Harness Engineering. The SWE-agent line of work argued that the harness is part of the intelligence system — that benchmark scores reflect a model–scaffold joint, and that designing for token-budget, parseable, line-anchored interaction can change scores by single-digit percentage points. The mini-SWE-agent line of work agrees that the harness is part of the system but argues that the content of the harness is now contestable: most components added in the 2024 generation can be removed and re-added one at a time, with the burden of proof on inclusion rather than removal.

That reframing is closer in spirit to ablation by subtraction than to a stylistic preference for minimalism. The right form of the question is no longer "what should we add to the harness?" but "what does this component buy when the bash baseline is already this strong?" A research program built around that question produces different artifacts: small, named variants of mini-SWE-agent that each add a single affordance (a structured editor, a summarized search tool, a retry policy, a planner) and report the marginal effect on Verified, on a held-out repository set, on cost per resolved issue, on trajectory inspectability, and on safety event rates.

The most honest version of the article's claim therefore lives at this layer. mini-SWE-agent is not a proof that scaffolding is unnecessary. It is a measurement-grade baseline — a comparison condition cheap enough and transparent enough that future harness work can be conducted as a series of small, defensible additions rather than as design-by-aggregation.

7. What minimal does not mean

Several common readings of mini-SWE-agent overshoot what the evidence supports, and the article should be explicit about each.

Minimal does not mean "raw model." The model in mini-SWE-agent is wrapped in a benchmark-specific prompt, a ReAct-style loop, a submission protocol, a sandboxed execution environment, and a grading pipeline. Compared to issuing a single API call with the task description in the prompt, mini-SWE-agent is still a scaffold. The right comparison is to other harnesses, not to no harness at all.

Minimal does not mean "no interface." The shell is an interface. It happens to be the interface software engineers built for themselves and that frontier models have extensive training exposure to. That training exposure is doing real work in the result. A model with sparse terminal exposure would not be expected to reach the same scores with the same configuration.

Minimal does not mean "production-ready." A bash-only agent with no observability layer, no command policy, no permission boundaries, no resumability, and no audit log is appropriate for a sandboxed benchmark and inappropriate for a code repository with real consequences. Production AI Coding Agents need most of what mini-SWE-agent omits, for reasons the benchmark does not score: recovery from partial failures, sandboxing of destructive commands, separation of secrets, auditable trajectories, and human-readable diagnostic surfaces.

Minimal does not mean "instrumentation-free." Reproducibility metadata, trajectory logs, dated configs, and failure taxonomies are observation-only additions that improve scientific value without changing the agent's policy. They preserve mini-SWE-agent as a comparison baseline rather than degrade it. The line that matters is between observation and intervention: anything that changes the prompt, the context, the action space, or the retry loop turns the baseline into a different agent and should be split into a named variant rather than added to the core.

Minimal does not mean "the right default for all tasks." SWE-bench Verified is a constrained slice. Multi-repository tasks, long-horizon maintenance, security-sensitive changes, UI work, infrastructure operations, and tasks involving private codebases are not measured here. The pruning principle's strength on Verified does not transfer automatically. A team adopting a thin harness for these tasks should treat it as a baseline to beat, not a finished product.

These distinctions are load-bearing. Without them, the article reduces to "minimalism wins," which would be both wrong as a generalization and dangerous as design advice for production deployments.

8. Harness-design implications

Read carefully, the mini-SWE-agent result rewrites the default architecture for new coding-agent work along three dimensions.

Baseline. A thin, bash-first harness is now a credible baseline — not a control condition that obviously underperforms. New research, new frameworks, and internal evaluation programs should run this baseline alongside their proposed system on every benchmark slice. A harness that cannot beat mini-SWE-agent on Verified at matched model and matched budget needs to justify itself on dimensions Verified does not score, not on Verified itself.

Accretion. Components should be added one at a time, with named variants. The mini-SWE-agent repository's small core makes this tractable: a "mini-SWE-agent + structured editor" variant, a "mini-SWE-agent + summarized search" variant, and a "mini-SWE-agent + retry policy" variant are each cheap to build and easy to compare. The Lita-style controlled comparison is the right shape: same model, same budget, randomized task order, multiple seeds, and metrics beyond percent resolved. Without controlled variants, the field defaults back to design-by-aggregation, which is what produced the overbuilt harnesses mini-SWE-agent is provoking against.

Operational separation. Production-readiness features should live outside the comparison baseline. Logging, command policy, sandboxing, audit trails, resumability, and human-readable diagnostics should wrap the agent rather than enter its decision loop. This preserves the baseline's value as a measurement instrument while still letting the deployed system carry the engineering it needs.

A practitioner taking this seriously ends up with a stack that looks different from the 2024 default. The agent core is small and explicitly thin. The richer scaffolding lives in named, optional variants that can be enabled per task and benchmarked against the core. The production layer wraps the core for deployment and is evaluated separately on operational metrics: cost per resolved issue, invalid-patch rate, timeout rate, unsafe-command attempts, human-time to diagnose a failed run.

This is closer to how interface ablations have always worked in well-instrumented research areas. The novelty in coding agents is not the discipline; it is the realization that the agent interface itself is the thing being ablated.

9. The production critique

A bash-only loop is not a production architecture, and saying so is the most important practitioner correction the article makes.

A short list of what production AI Coding Agents need, that mini-SWE-agent omits:

Command policy. Unrestricted shell access in a repository with real consequences invites accidental data loss, secret exfiltration, package-manager surprises, and destructive git operations. Production agents need command allowlists, dry-run modes, and rollback affordances.
Sandbox boundaries that match the deployment. SWE-bench runs in Docker containers with disposable state. A production coding agent operates in a developer's working tree, a CI runner, a staging environment, or a customer system. Each has different blast radii and different recovery affordances. None of them are well-modeled by the benchmark sandbox.
Observability. A trajectory log that a human can read after a failure, with structured stages, command outputs, and timing, is the difference between a tool that can be debugged in production and a tool that can only be re-run. Mini-SWE-agent's linear history is observable to whoever reads its stdout; that is the floor, not the ceiling.
Recovery and resumability. Production runs are interrupted by token-limit hits, network failures, sandbox restarts, and policy violations. An agent that cannot resume from a checkpoint cannot be deployed in long-running workflows.
Test discovery and policy. Real codebases have test selection, slow integration suites, flaky tests, and environment-specific test commands. A harness that runs the canonical benchmark test command is not the same artifact as one that must navigate pytest markers, nox sessions, cargo integration tests, or make test-fast.
Patch hygiene and review. Production patches need to pass linting, formatting, and code-review heuristics that hidden-test grading does not measure. Heavier frameworks often carry these affordances; mini-SWE-agent does not.
Multi-repo coordination, secret handling, audit logging, permission boundaries, human approval flows. Each of these is a real production requirement and a real source of harness complexity that the benchmark cannot reward.

The honest reading is that the bash-only baseline is appropriate for what it measures and inappropriate for production, and these are not the same artifact. Heavier frameworks like OpenHands and SWE-agent proper carry value along the production dimensions that benchmark scores undercount. A practitioner choosing between systems should weigh the SWE-bench scoreboard alongside the operational surface, not as a substitute for it.

This is also where the bounded pruning principle bites in a useful way. Some of what heavier frameworks add is operational; some of it is benchmark-era scaffolding that the model no longer needs. Production engineering should keep the former and drop the latter, not preserve both because removing them feels risky. The right artifact is a small, transparent agent core (mini-SWE-agent's contribution) wrapped in a production layer that is itself measured (cost, recovery, safety, observability).

10. Counter-readings the article should not flatten

Several counter-readings deserve sharper treatment than they usually receive in coverage of the mini-SWE-agent result. They are not refutations; they are interpretations the evidence equally permits.

Evaluation phase transition. The cleanest counter-reading is that the result reveals something about the benchmark rather than the architecture. SWE-bench Verified is a public, constrained, deterministic-test benchmark over Python repositories with substantial public history. Frontier models trained through 2025–2026 have seen the relevant code, the relevant issue patterns, and likely some prior SWE-agent trajectories. The contamination work in late 2025 supports the view that performance on Verified increasingly reflects familiarity rather than fresh capability. (Contamination critique — arXiv 2512.10218)

Under this reading, mini-SWE-agent's competitiveness is real but local: a bash-only loop is enough when the model already knows the territory. The same configuration on private repositories, on newer languages, on tasks built after the model's training cutoff, may regain a substantial scaffold gap. This does not invalidate the pruning principle; it bounds its claim to "settings the model has been trained heavily on."

Process versus outcome. The AgentLens "Lucky Pass" finding is uncomfortable in a different way. If a meaningful share of passing trajectories on SWE-bench Verified are high-variance trial-and-error successes, then outcome-only scoring conflates scaffolding's effects on solve rate with its effects on solve quality. A heavier framework that produces cleaner trajectories at the same solve rate looks identical to a thinner framework on the leaderboard and substantially different in production. (AgentLens — arXiv 2605.12925)

The conservative move is to score process alongside outcome. The article's claim about mini-SWE-agent matching heavier frameworks is robust on outcome; whether it holds on process-quality measures (trajectory clarity, principled localization, edit precision, low-variance success) is an open empirical question. A bash-only agent that passes the same tests through a more chaotic path is not the same artifact and should not be treated as one.

Hidden budget asymmetries. "Same model" is the loudest control in the comparison, but it is not the only one that matters. Harnesses differ in retry policy, step budget, cost budget, temperature, prompt templates, test selection, and patch-extraction logic. Even nominally same-model comparisons can hide budget differences that swamp the architectural effect. The Lita table is unusually clean for this reason — it pins down budget alongside model — but most leaderboard comparisons are not. (Lita — OpenReview)

A reader interpreting a current Verified leaderboard should treat scores without explicit budget reporting as suggestive, not conclusive. The mini-SWE-agent surprise survives because it is corroborated by controlled comparisons; an arbitrary leaderboard pair might not survive the same scrutiny.

Scaffolding-as-reliability-engineering. A final counter-reading is that the entire framing — thin harness versus heavy harness — privileges the dimensions benchmarks score and ignores the dimensions reliability engineering cares about. Heavy frameworks often look bloated because they carry features the benchmark does not reward: typed action interfaces that prevent malformed commands, observability layers, sandbox declarations, secret handling, command policies, and multi-repo coordination. Under this reading, the heavy frameworks are not competing with mini-SWE-agent on Verified; they are running on a different value function and happen to also be scored on Verified.

This reading does not refute the empirical surprise. It rejects the inference that frameworks should be pruned toward the mini-SWE-agent shape. The right inference, in this view, is that the mini-SWE-agent core should be extracted as a reusable component and embedded in frameworks that retain the reliability layer. Several of the deployed frameworks have begun moving in roughly this direction, treating thin agent cores as composable units inside richer operational stacks.

None of these counter-readings is decisive. Taken together, they bound the claim. mini-SWE-agent's result is robust as a measurement — a thin harness can match heavier scaffolds on Verified with strong models, under controlled conditions. It is contestable as a design lesson, and the contest is mostly about which dimensions matter once you leave the benchmark.

11. How mini-SWE-agent should evolve

The open question the article should treat carefully is what mini-SWE-agent itself should become. There are two failure modes for the project, and one defensible path.

The first failure mode is feature accretion into the core. If mini-SWE-agent adds prompt-visible retry policies, command classifiers, structured editors, retrieval layers, or planner modules to its main agent class, it stops being a measurement-grade baseline. It becomes another mid-weight harness whose comparison value erodes with each release. The very thing that made it influential — a transparent floor against which other systems must justify their additions — disappears.

The second failure mode is staleness. If the project freezes its agent core but never adds reproducibility metadata, trajectory logging, configuration manifests, or task-set provenance, then comparisons across releases lose precision. A leaderboard row that says "mini-SWE-agent 65%" without specifying the model snapshot, the date, the step budget, the prompt version, and the sandbox image cannot ground the kind of controlled comparison the project's value depends on.

The defensible path runs between these. The agent core — the bash loop, the linear history, the absence of specialized tools — should stay roughly fixed, perhaps versioned at major changes only. Around the core, the project should accumulate:

Versioned configurations. Each leaderboard submission should be tied to a config file recoverable from the repository at the cited date. Prompt changes, sandbox images, step budgets, and submission protocols should be diffable.
Trajectory metadata. Each run should emit a structured log: model snapshot, step count, token usage, command invocations, exit codes, test runs, and submission patch. Observation-only logging does not change the agent's policy and substantially raises the project's scientific value.
Failure taxonomies. Aggregated failure modes (timeout, malformed patch, test regression, sandbox error, command policy violation) should be reported per leaderboard entry. This makes comparisons across harnesses more substantive than a single resolved-percent number.
Safety and event logs. Records of unsafe-command attempts, destructive-operation invocations, and unintended file system changes belong in the public artifact, even when the sandbox absorbs them. Production readers need this signal even if the benchmark does not.
Named variants for additions. Any affordance someone wants to test — a structured edit primitive, a retrieval layer, a planner, a recovery policy — should live as a named variant outside the core. Comparison work then becomes a controlled study of variants against the unchanged baseline.

This is the operationalization of the project's methodological contribution. The core stays small. The measurement infrastructure grows. The variants proliferate. Heavier frameworks justify their layers against the unchanged baseline, and mini-SWE-agent serves the field as a controllable ablation target rather than as a competitor.

If the project drifts toward feature accretion, the wiki's appropriate response is to treat the early thin variant as the historical artifact of methodological interest and the later versions as a separate, richer system that loses the original's comparison value. If it stays disciplined, mini-SWE-agent has a long useful life as the floor of the leaderboard — the system every richer harness must defeat under controlled conditions, on dimensions the benchmark scores and on dimensions it does not.

12. What the result does and does not establish

A summary that respects the evidence is shorter than a summary that overshoots it.

The result establishes that on SWE-bench Verified, with frontier models in the Claude 4 family and others of comparable strength, a bash-only agent with no custom Agent-Computer Interface and no specialized tools can approach the scores of much heavier frameworks at matched model. The gap is large on weaker models in the same family and small on the strongest models. The pattern is consistent across the project's own writeups, the controlled Lita comparison, and the official leaderboard's adoption of mini-SWE-agent as a comparison harness. (mini-SWE-agent docs; Lita — OpenReview; SWE-bench leaderboard)

The result supports a bounded pruning principle: some scaffolding accumulates in agent frameworks to compensate for model limitations; as models improve, that scaffolding's marginal value falls; a thin harness is therefore a defensible default starting point, with each added component required to justify itself against a measured failure on a comparison the baseline cannot win.

The result does not establish that scaffolding is generally obsolete, that bespoke Agent-Computer Interfaces were overbuilt at the time they were designed, that heavier frameworks lack value on dimensions the benchmark does not score, or that the same pattern would hold on private repositories, fresh tasks, multi-repo workflows, or production deployments where recovery, observability, and safety are scored alongside outcome.

The result opens a research program — controlled, same-model, same-budget comparisons across mini-SWE-agent, full SWE-agent, OpenHands, Aider, and others on Verified plus contamination-resistant benchmarks, with metrics including cost per resolved issue, invalid-patch rate, recovery events, unsafe-command attempts, and trajectory inspectability — that would either consolidate the pruning principle into a stronger empirical claim or bound it more tightly than current evidence permits.

The honest article on mini-SWE-agent ends here, not in a slogan. The contribution is real and methodological: it puts the burden of proof on the scaffold rather than on the baseline, and it gives the field a small, transparent, controllable artifact to run that ablation with. The danger is treating that contribution as a finished argument against agent engineering. The minimal harness wins benchmarks because the frontier model can carry the task; production systems must still carry everything the benchmark does not test.

Companion entries

Core theory: - Agent-Computer Interface - Agent Scaffolding - Agent Harness - Pruning Principle - Harness Engineering - SWE-bench - SWE-bench Verified - Execution-Based Evaluation

Practice: - SWE-agent - OpenHands - Aider - AI Coding Agents - Thin Harness Design - Coding Agent Observability - Test-Driven Agent Loops - Structured Code Editing - Repository-Level Code Repair

Counterarguments: - Benchmark Contamination - Benchmark Overfitting - Benchmark Saturation - Leaderboard Drift - Process vs Outcome Evaluation - Scaffolding as Reliability Engineering - Production Agent Safety