cs.SEOct 22, 2026

Superintelligent Software Engineering: Governance That Scales with Capability

Authors: Mohammad Mehdi Gholinejad

Organizations: OSTEON Labs

Read PDF
Ask AI
Cite

Copy citation

DOINot available for this paper

Abstract

Software agents are being trained to exceed human engineers; we argue that capability alone does not produce better software engineering. We define superintelligent software engineering as the discipline of building and evolving software with agents whose capability exceeds that of human engineers, in which governance (gates, contracts, decisions and decay control) scales with capability. The argument rests on three claims. First, correctness in a project rests on decisions and contracts that the code does not carry. Second, knowledge decays. Third, once an agent outpaces its reviewers, reading catches a shrinking share of the changes built on stale knowledge. A simple model shows that, past a fixed review capacity, escaping changes grow linearly with throughput while the share that reading catches falls toward zero; governance can lower the slope, capability alone cannot. An exploratory snapshot of 452 of the most-starred public GitHub repositories finds a root-level or .github agent context file in 48.67% (95% confidence interval 44.1 to 53.3); in the median file that names repository paths, 9.5% to 22% of those paths do not resolve, depending on how a reference is read. We then present OSTEON, a discipline for the regime, released with a DOI (10.5281/zenodo.23436020): each project gets a governed knowledge repository of decisions and contracts, every change is checked mechanically against it, and the knowledge itself is checked for decay at every session start; planning is gated, and sessions record what they learn without writing rules. We report no measured effect of OSTEON, mark claims about its mechanisms as opinion and the author's practice heuristics as design rationale, and state the questions that would falsify the thesis.

Figures & tables

Fig. 1 : Why capability is not enough (Section III ). Capability raises throughput rr , a consulted knowledge unit is stale with probability ss , and review capacity cc is fixed, so once r>cr>c the share of stale-built changes that reading catches falls as c/rc/r , and the escaping number grows linearly with rr at the full rate of stale-built change (Eq. ( 2 ); a model, not a measurement). OSTEON acts on the two factors governance acts on: its session-start decay check is built to lower ss , and its mechanical gates to check every change ( ρ=1\rho=1 ).
Fig. 2 : The three regimes, separated by who can verify a change. In the assisted and delegated regimes a human verifies by reading the change (thick blue arrows mark where verification sits); in the delegated regime review is the binding constraint. In the superseded regime the agent’s output exceeds what the humans responsible can read in the time they have, so reading at best samples (dashed arrow); human verification moves to the decisions and contracts, and the step from that knowledge to the change is mechanised (Section III-D ). The shaded area is the scope of superintelligent software engineering: the superseded regime and the transition into it.
Fig. 3 : The escape model of Eq. ( 2 ), normalised by review capacity: Eescape/cE_{\text{escape}}/c against r/cr/c , with ρ=min⁡(1,c/r)\rho=\min(1,c/r) , k=5k=5 and d=0.8d=0.8 . Solid lines show three staleness levels ss under review by reading alone. Below r=cr=c (grey vertical line) every change is reviewed and the escape rate grows at slope (1−d)(1-d) times the stale fraction; above it the reviewed fraction falls as c/rc/r and the slope rises to the full stale fraction. Broken lines show the s=0.05s=0.05 case with governance: decay control lowers ss to 0.010.01 (dashed), and mechanical gates check every change ( ρ=1\rho=1 ) with detection probability g=0.9g=0.9 in place of dd (dotted). All parameter values are illustrative, not measured; the script and parameters ship with the figure.
StageCount
Repositories
Matching the search query5 346
Returned by search (five pages of 100)500
Excluded: no primary language47
Excluded: privacy denylist (counted, not named)1
Eligible and measured452
TABLE I : Collection funnel. Every count is read from the study’s funnel record; counts that are zero (duplicates across pages, trees unavailable, files unreadable or without path history) are stated in the text.
Fig. 4 : Currency of the 367 context files: commits to the repository since the file’s last update, against days since that update. Both axes are logarithmic; the vertical axis is linear below 1 because zero counts occur. Filled markers are files with at least one path-like candidate, shaded by dangling-reference rate; hollow markers are files with none. The plot is descriptive.
MeasurennMedianP25P75MinMax
Files per sample repository22021214
Age367220144324.512689
Days since update36748101671549
Updates36751181631
Commits since update36722949852091 084
Dangling-reference rate2690.222200.423101
TABLE II : Per-file summary statistics (pre-specified protocol). Age and days since update are in days at the snapshot date; files, updates and commits are counts; the dangling-reference rate is a fraction of a file’s candidates.
Fig. 5 : Empirical cumulative distribution of the dangling-reference rate over the 269 context files with at least one path-like candidate (pre-specified reading). The dashed line marks the median. The step at zero is the share of files whose candidates all resolve.
MeasurePre-specifiedA (post hoc)B (post hoc)
Files with candidates269268236
Median rate0.22220.18180.0952
25th percentile000
75th percentile0.42310.39170.2857
Files with any unresolved192183145
as % of files71.3868.2861.44
TABLE III : Dangling-reference measures under the pre-specified reading and two post hoc readings. A: without bare extensions and conventionally untracked build or local paths. B: as A, and only candidates that contain “/”. B also leaves out the three withheld candidates, whose form is unknown.
Fig. 6 : OSTEON as described in Section VI . Every fact sits at one of three tiers. The project tier is the bone , a knowledge repository with four layers and a manifest. Agents and humans both read the bone . When watched sources change, the session-start decay check compares each unit’s provenance with a sealed baseline and flags decayed units for curation. Ossification (planned, gated change) produces a change; the review gate checks it against recorded decisions and contracts before it merges, and routes any invalidation to curation. Curation applies only the items a human approves. Capture records what a session learns in a ledger that governs nothing, and a rule enters the register only when a human admits it. Solid arrows carry knowledge or change, dashed arrows mark checks and routing, and thick blue arrows mark human approval.
RequirementOSTEON mechanismWhat it is built to preventWhat stays human
R1 One owner per factThree tiers (T0 org, T1 project, T2 repository); personal tier outside; reference, never copyA copied fact decaying in one place and not the otherPlacing a contested fact
R2 Decisions are recordsNumbered decision records; proposed, accepted, superseded; amend, never rewriteRe-litigated or silently suspended decisionsAccepting or superseding a decision
R3 Seams have contractsVersioned contracts, registry index, same-wave ruleOne side of a seam changing aloneApproving a breaking version
R4 Gates from the projectReview against the bone layers; invalidation routed to curationChanges that pass generic review and break a project decisionApproving each change to the knowledge
R5 Decay checked at startBlock-level provenance; sealed baseline; Context Decay Index at session startWork built on a fact whose source has movedRe-verifying a decayed claim
R6 Planned, gated changeDaily cycle; ten-condition start gate; lanes in one session; merge is not completionWork started on open questions; unproven completionAnswering open decisions
TABLE IV : Requirements for superintelligent software engineering, the OSTEON mechanism for each, and what stays with a human.
HeuristicStatementBuilt into, and where the paper describes it
1. A correction is a propagation problem [Experience]A correction reaches the artifact that owns a fact more reliably than the artifacts that repeat it. Writing the lesson down does not stop the same failure from coming back; a mechanical check does.R1, under which a fact has one owner and every other place references it; Eq. ( 2 ), where a mechanical gate sets ρ=1\rho=1 and supplies its own detection gg in place of dd .
2. A gate decays too [Experience]A gate is an artifact and goes stale like any other. A stale gate is worse than no gate: it still runs, no longer tests what it claims, and turns a deliberate check into a false confirmation.The review factor of Eq. ( 2 ), whose detection term is only as good as the gate that supplies it (the model has no term for a gate that has itself decayed); the capture skill, which records a check that passes on an input that should fail; the self-test shipped with the lints.
3. Mirrors of external state decay first [Experience]Knowledge that mirrors external, mutable state goes stale fastest. Its staleness is driven by events, not by elapsed time, so a review on a calendar misses it.Eq. ( 1 ), where ss is defined by a change to the source, not by age; the decay check, which flags a unit when its source moves; the stale state record scenario.
4. Errors at a high tier are amplified [Experience]An error in high-tier knowledge is not repeated once; every dependent inherits it. Repair has to happen at the source, because repairing the dependents one by one leaves the source free to seed the error again.The tiers, with reference instead of copy; block-level provenance, under which one changed source decays every block that cites it; the escape model, where one stale unit makes every change that consults it stale-built.
5. Versioned references carry retractions [Experience]When a dependency between artifacts is a first-class, versioned reference, an assertion and its retraction both travel along it quickly and visibly, even across repositories.The drifting seam scenario, where the version bump marks the change as breaking and the consumer is flagged; provenance tokens, which may name a file in another declared repository.
6. A decision ledger can run at experiment speed [Experience]Decision records need not be slow. A ledger can keep pace with experiments and record what they refute, provided an amendment is cheap and is recorded apart from the decision it changes.R2 and the amend-or-supersede lifecycle, under which the reason a project once had survives the decision that replaced it.
TABLE V : Design heuristics from the author’s practice, each marked [Experience] , and the OSTEON mechanism built to each. The right column says where the paper describes the mechanism; it is not evidence for the heuristic.
WorkPrimary object, and the human’s role in itRelation to this paper
SE 3.0 [ 7 ]AI-native, intent-centric development stack; the developer works in partnership with AI teammatesNames the era; we name the discipline for the regime past delegation
Agentic SE [ 8 ]SE for Humans and SE for Agents, with command and execution environments; humans orchestrate and mentor agent teamsClosest vision; we make governance scaling the defining property and supply a released discipline
Self-play SWE-RL [ 2 ]Agent training by self-play bug injection and repair; humans supply sandboxed repositoriesThe capability route; we argue it does not act on knowledge decay
Programming with trust [ 9 ]Trust in agent-written code via analysis evidence; humans set the trust barSame premise; we attach verification to recorded decisions and contracts rather than to the change
Evaluating AGENTS.md [ 16 ]Effect of context files on agent task success; humans write the filesRead by us as evidence that more ungoverned context is not the lever
Context-file studies [ 20 , 21 , 22 , 26 ]Content, adoption and evolution of context files, and their effect on agent efficiency; humans write and maintain the filesWe check whether the paths a file names resolve in its repository’s tree
TABLE VI : Positioning against related work.
More in this topic

Software Engineering

Software engineering studies how to design, build, test, deploy, and maintain reliable software systems and the processes behind them.

See all 270 papers

Explore similar work

CardsList
Sep 24, 2026

SWE-Prometheus: Measuring Engineering Governance Improvements in Real-World Repositories

Large language model based coding agents have made substantial progress on repository-level software engineering tasks. Existing repository benchmarks, however, usually start from a human-identified issue and evaluate whether a patch satisfies a functional signal. We present SWE-Prometheus, a benchmark for the broader task of improving repository engineering governance. Each task provides a fixed snapshot and an open-ended objective, requiring the agent to identify risks, prioritize interventions, and verify the resulting changes. SWE-Prometheus evaluates six governance dimensions through paired evidence, clean-environment probes, behavior gates, and two independent teacher ratings of the same evidence. The benchmark contains 60 repositories; ten models are evaluated on a shared 22-repository public subset, where mean Normalized Governance Improvement ranges from 0.0568 to 0.5760 and observed behavior-breakage rates range from 0% to 23%. On a frozen ten-repository batch, a repository-blind template obtains mean NGI 0.272, but its gains concentrate in Tests & CI, Quality Gates, and Documentation; it improves Reproducible Environment and Dependency & Security on none of the repositories. This baseline makes the distinction between adding governance artifacts and producing execution-backed improvements measurable. The no-op condition has median NGI zero and standard deviation 0.073; two teachers agree exactly on 57 of 60 dimension scores for the same no-op evidence. For the two highest conditional-mean systems, common-valid NGI is similar, while full-pool comparisons that include behavior failures favor Kimi-K3. These results show why repository-governance evaluation should report improvement, behavior preservation, evidence quality, and coverage together.

Jiajun Wu, Leixin Sun, Zihan Tan +10

CosmosMind · ModCraft · Peking University

Software EngineeringSoftware Engineering AgentsSoftware Engineering Benchmarks
AskPDF
Jul 1, 2026

Cheap Code, Costly Judgment: A Case Study on Governable Agentic Software Engineering

Generative AI is shifting software engineering from a practice organized around scarce implementation effort toward one organized around abundant, low-cost code production. This shift changes the central engineering problem: not whether AI can generate useful code, but how engineers organize architectures, tools, evidence, and feedback loops so that AI-mediated development remains inspectable, correctable, and maintainable. We study this problem through a first-person case study: a 12-week development effort in which a single expert software engineer used frontier AI coding agents to build a document accessibility remediation system. The empirical record comprises 88 contemporaneous field notes, 420 KLOC of production code, and 1.16 MLOC of tests, lints, supporting documentation, and agent tooling. From this record, we develop a candidate middle-range theory of governance conversion, expressed as a process model explaining how high-velocity agentic implementation becomes governable. The model explains how agentic implementation velocity surfaces recurring structural failure classes, and how engineering judgment sustains velocity by converting those failures into durable governance mechanisms. In contrast to existing governance models that derive controls from known obligations, governance conversion explains how controls are discovered from failures that become visible only during agentic work. We use our model to make testable predictions and to describe implications for software engineering research and practice.

James C. Davis, Paschal C. Amusuo, Tanmay Singla +2

Purdue University

Software Engineering AgentsAI Agent GovernanceHuman-AI CollaborationAI-Assisted Software Development
AskPDF
Sep 3, 2026

SWE-Gate: Passing Functional Tests Is Not Enough for Software Engineering Agents

Repository-level software engineering benchmarks have significantly advanced the evaluation of coding agents, but existing benchmarks primarily measure whether generated patches pass functional tests and overlook review-derived acceptance constraints (review constraints) that often influence whether a patch is acceptable in real-world software development. We introduce SWE-Gate, a repository-level benchmark for software engineering agents that explicitly evaluates review constraint compliance alongside functional correctness. SWE-Gate derives review constraints from real pull request review comments and synthesizes repository-level repair instances around these constraints. Each instance provides separate functional and constraint tests, together with non-compliant and gold patches, enabling explicit separation between issue resolution capability and review constraint compliance. We construct SWE-Gate with 303 repository-level repair instances spanning 75 open-source Python repositories across diverse software domains. Experiments with four LLM backends spanning different capability levels under a common coding-agent scaffold reveal a substantial gap between functional success and success under the complete repair specification: among 644 repairs that pass the functional tests, 221 fail to satisfy the provided review constraints. These findings show that functional-only evaluation overestimates agents' ability to satisfy the full requirements of repository-level repair tasks. The replication package including code, data, and experimental results is available at https://github.com/DeepSoftwareAnalytics/SWE-Gate.

Xin He, Yanlin Wang, Mingwei Liu +3

School of Software Engineering, Sun Yat-sen University · College of Computer Science and Technology, Zhejiang University · School of Big Data and Software Engineering, Chongqing University +1

Software Engineering AgentsAutomated Program RepairSoftware Engineering BenchmarksLLM Agent EvaluationRepository-Level Program Repair
AskPDF