cs.SEOct 22, 2026
SaveSuperintelligent Software Engineering: Governance That Scales with Capability
Organizations: OSTEON Labs
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 , a consulted knowledge unit is stale with probability , and review capacity is fixed, so once the share of stale-built changes that reading catches falls as , and the escaping number grows linearly with 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 , and its mechanical gates to check every change ( ).
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: against , with , and . Solid lines show three staleness levels under review by reading alone. Below (grey vertical line) every change is reviewed and the escape rate grows at slope times the stale fraction; above it the reviewed fraction falls as and the slope rises to the full stale fraction. Broken lines show the case with governance: decay control lowers to (dashed), and mechanical gates check every change ( ) with detection probability in place of (dotted). All parameter values are illustrative, not measured; the script and parameters ship with the figure.
| Stage | Count |
| Repositories | |
| Matching the search query | 5 346 |
| Returned by search (five pages of 100) | 500 |
| Excluded: no primary language | 47 |
| Excluded: privacy denylist (counted, not named) | 1 |
| Eligible and measured | 452 |
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.
| Measure | Median | P25 | P75 | Min | Max | |
|---|---|---|---|---|---|---|
| Files per sample repository | 220 | 2 | 1 | 2 | 1 | 4 |
| Age | 367 | 220 | 144 | 324.5 | 12 | 689 |
| Days since update | 367 | 48 | 10 | 167 | 1 | 549 |
| Updates | 367 | 5 | 1 | 18 | 1 | 631 |
| Commits since update | 367 | 229 | 49 | 852 | 0 | 91 084 |
| Dangling-reference rate | 269 | 0.2222 | 0 | 0.4231 | 0 | 1 |
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.
| Measure | Pre-specified | A (post hoc) | B (post hoc) |
|---|---|---|---|
| Files with candidates | 269 | 268 | 236 |
| Median rate | 0.2222 | 0.1818 | 0.0952 |
| 25th percentile | 0 | 0 | 0 |
| 75th percentile | 0.4231 | 0.3917 | 0.2857 |
| Files with any unresolved | 192 | 183 | 145 |
| as % of files | 71.38 | 68.28 | 61.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.
| Requirement | OSTEON mechanism | What it is built to prevent | What stays human |
|---|---|---|---|
| R1 One owner per fact | Three tiers (T0 org, T1 project, T2 repository); personal tier outside; reference, never copy | A copied fact decaying in one place and not the other | Placing a contested fact |
| R2 Decisions are records | Numbered decision records; proposed, accepted, superseded; amend, never rewrite | Re-litigated or silently suspended decisions | Accepting or superseding a decision |
| R3 Seams have contracts | Versioned contracts, registry index, same-wave rule | One side of a seam changing alone | Approving a breaking version |
| R4 Gates from the project | Review against the bone layers; invalidation routed to curation | Changes that pass generic review and break a project decision | Approving each change to the knowledge |
| R5 Decay checked at start | Block-level provenance; sealed baseline; Context Decay Index at session start | Work built on a fact whose source has moved | Re-verifying a decayed claim |
| R6 Planned, gated change | Daily cycle; ten-condition start gate; lanes in one session; merge is not completion | Work started on open questions; unproven completion | Answering open decisions |
TABLE IV : Requirements for superintelligent software engineering, the OSTEON mechanism for each, and what stays with a human.
| Heuristic | Statement | Built 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 and supplies its own detection in place of . |
| 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 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.
| Work | Primary object, and the human’s role in it | Relation to this paper |
|---|---|---|
| SE 3.0 [ 7 ] | AI-native, intent-centric development stack; the developer works in partnership with AI teammates | Names 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 teams | Closest 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 repositories | The 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 bar | Same 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 files | Read 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 files | We 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 274 papers