Layered Supervision

Sources#

• From Agent Behaviour to Agent-Friendly Documentation
• When Does AI Augment Work? A Workflow-Level Framework for Human-Agent Collaboration
• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering

Summary#

Stolze & Strässle (OST Eastern Switzerland University of Applied Sciences / smartive AG, arXiv 2608.26316, 2026-08-26, accepted to the ESEM 2026 Software Engineering in Practice track, case-study) interviewed five practitioners about one question: when AI-assisted generation outruns the capacity to review it, what do teams actually do? The answer they report is not "review harder" and not "review less". It is that the supervision function stops being located in one place and gets distributed across three layers:

• Preventive guardrails — architectural intent and conventions externalized into machine-interpretable form (specifications, steering files, architectural plans) so they shape generation before any artifact exists to inspect.
• Executable guardrails — linting, testing, CI/CD and architectural validation, repurposed from quality tooling into scalable supervision infrastructure, with the build system as the arbiter.
• Human oversight — re-scoped away from line-by-line inspection toward architectural reasoning, explainability and long-term maintainability, and moved temporally from post-hoc to concurrent.

The load-bearing claim is the negative one: no layer is sufficient alone. "Preventive guardrails cannot capture all architectural tradeoffs in advance, executable guardrails cannot evaluate contextual appropriateness, and the human guardrail cannot scale to AI-generation throughput." The paper's own framing of what is new is deliberately modest — lint, CI enforcement, fitness functions, policy-as-code and spec-driven workflows all have substantial pre-LLM histories — so "what is changing is not the existence of these mechanisms, but their operational role, relative weight, and configuration."

The evidence is five interviews plus a 50-respondent survey the authors explicitly refuse to treat as inferential. Nothing on this page is measured. See How much weight this deserves.

The distinction that holds the first two layers apart#

The paper's sharpest contribution is not the three-layer list — it is the criterion separating preventive from executable, since both act before a human sees the output. The authors distinguish them by mechanism, not by sequence:

Externalization produces preventive guardrails — specifications, steering files, architectural plans — that guide what an AI system generates but are not themselves automatically checked; their effect depends on whether the generation process actually consults them. Executable guardrails, by contrast, are automatically evaluated against generated output regardless of how that output was produced.

Two consequences follow, and the second is the one practitioners act on.

• The layers run concurrently, not as stages. A steering file encoding a convention and a lint rule enforcing the same convention typically coexist, "so that the executable check still catches violations when the steering artifact is outdated, ignored, or absent from a particular generation trajectory." Duplication between the layers is the design, not redundancy to be cleaned up.
• The preventive layer's efficacy is conditional on an event nobody in this study measures — the generator consulting the artifact. That condition has a name and a number elsewhere in the wiki (see the Harness Activation and Adherence link below), and it is why P4's rule below reads as a hedge rather than a preference.

What each of the five practitioners actually changed#

The paper reports themes, not cases, so the per-participant picture has to be assembled from the attribution tags. Assembled, it is uneven in a way worth recording.

	Role / context (Table 1)	Layer(s) touched	Artifact or practice
P1	Software Architect / CTO, enterprise software, small team (2–9), informal AI-recommended governance	all three	Spec refinement as the dominant activity ("two thirds of the time go into specification refinement"); three planner sub-agents whose proposals are ranked by a further agent, explicitly to detect when "an agent has completely drifted"; extended executable checks for architectural violations; step-by-step observation with early interruption ("no fire-and-forget")
P2	Staff Engineering Manager, energy-utility frontend, large team (10+), clear guidelines	executable, human	Additional build-breaking checks; the build system as arbiter. Supplies the diagnosis (writing is "very cheap", "the bottleneck clearly moving to review") and the failure trajectory below
P3	Engineering Team Lead, construction software, large team (10+), clear guidelines	—	Appears in exactly one finding. P3 is cited only in F5 as a governance-posture data point ("clear, formal AI-tool guidelines and structured review procedures") and was the one participant unavailable for member-checking. No practice, artifact or quote of P3's appears anywhere in F1–F4
P4	Senior Frontend Engineer, digital agency, small team (2–9), informal arrangements — and a co-author of the paper	all three	Longer architectural planning up front, shorter coding; the handoff rule "If a rule is relevant, it must be enforced through linting"; build-as-arbiter; operational explainability (below); architecture-level rather than code-level validation using AI-generated visual overviews. Also names the limits on both automated layers
P5	Senior UI Engineer, industrial technology, small team (2–9), no explicit rules	executable, preventive	His own monorepo, where he consciously declined to relax automated conventions: "as long as I can do it automatically it costs me nothing. .. I really want this convention to be strictly upheld". Reports existing artifacts contradicting each other and evolving independently, creating ambiguity about authoritative guidance; legacy repositories as the hard case

Two things this table makes visible that the themes do not. P3 contributes nothing to the substantive findings — the effective sample for the three-layer model is four, not five. And the two participants who supply nearly every named pattern are the CTO and the co-author, which is exactly where the paper's own conflict-of-interest disclosure lands (§5.7: P4 joined as co-author for the SEIP track's practitioner perspective; the authors mitigated by verifying P4's quotes independently and by finalizing the coding scheme before P4 joined).

Table 1 was reconciled cell-for-cell against pdftotext -f 4 -layout; the ingest table-weld warning on "Staff Engineering Manager" is a wrapped two-line role label, not a merge.

F1: what review-centric guardrails actually fail at#

The failure is not volume alone. It is false correctness — the authors' term for generated artifacts that are "syntactically correct and locally coherent, yet problematic regarding architectural consistency, explainability, or long-term maintainability". P2 reported being unable to change parts of a system because he could no longer trace "why they are now where they are"; P5 had already written the compressed form in his survey response before the interview: "functionally correct, but nobody understands why".

That shifts what validation is for: "away from behavioral testing toward reasoning about architectural intent, contextual consistency, explainability, and long-term maintainability." A passing test suite is not evidence against false correctness, because false correctness is defined by properties tests do not carry.

The one quantity attached to the pressure is P1's, and it needs its qualifier: manual review of an AI-assisted one-shot implementation typically takes "three to four times as long" as the generation itself. The paper is careful — that is a ratio between the review and generation phases of the AI-assisted workflow, not a before/after-AI comparison, so it says nothing about whether review got slower in absolute terms.

The second half of F1 is a reframe rather than a finding, and it is the sharper half. P1's observation is that upstream specification work is not new — experienced teams have always invested in it — but that its consequentiality changed: specification quality now propagates directly into generated code, "with weak input producing weak output that LLMs do not push back against the way an experienced engineer would." The missing pushback is the mechanism. Upstream effort became more consequential, not merely more abundant.

F4: operational explainability, and the stakes calibration under it#

The human layer's re-scoping is stated as a replacement for a requirement teams could no longer meet. In place of full comprehension, P4 described operational explainability: the requirement that generated systems remain diagnosable and reconstructable on demand, supported by abstraction layers, visualization mechanisms, logs and higher-level interpretive tooling "that make the human guardrail effective without line-by-line reading."

The qualifier matters more than the term. P1 reports that organizational tolerance differs sharply by use case: a short-lived UX prototype may require no line-level developer understanding at all, whereas a database migration or a feature in a system with strict recovery-time requirements demands precise comprehension of every statement. Operational explainability is therefore "not a single threshold but a context-dependent capability calibrated to system criticality and longevity" — the same tiering logic the corpus records at the merge gate, applied to comprehension instead of approval.

The other half of the human layer is temporal. Rather than reviewing after completion, P1's team "observe step-by-step. .. interrupt early" when generation diverges. The paper defines intervention narrowly and usefully: an act of supervision triggered when a guardrail — an automated drift-detector or the observing developer — surfaces a problem. That makes the human a second consumer of the automated layers' output rather than a separate pass after them.

The three shifts relative to pre-LLM governance#

The paper's own answer to "what is actually new", and the most transferable part of it:

1. Guardrails move upstream — steering files, structured prompts and specification refinement act as preventive guardrails, against the field's traditional reliance on detective guardrails that inspect finished code.
2. Executable guardrails are promoted in priority — any sufficiently relevant rule becomes a candidate for automatic enforcement, reserving the human layer for what cannot be encoded.
3. Human oversight is redistributed temporally — from post-hoc inspection to concurrent supervision.

None of the three is a new mechanism. All three are changes in weight and position.

F5: configurations vary, and "maturity" is refused#

The five participants combined the layers differently along three named dimensions: governance posture (presence and formality of organizational AI-tool guidelines); system criticality and homogeneity (longevity and consistency of the codebase under AI-assisted modification); and team composition (distribution of senior and less experienced developers, and the resulting supervisory capacity).

The authors refuse the word maturity explicitly, "since it suggests a linear progression that our data does not support." That is a direct rejection of the ladder framing, though on five points it is a design choice rather than a measured result.

Two findings inside the dimension space are worth carrying:

• The mechanisms are codebase-contingent, and the source says so. P1 framed his team's practices as conditional on a modern, low-legacy, highly conformant codebase and was explicit that they "would likely not transfer to grown legacy systems"; P5 described legacy repositories as the hard case because inconsistent patterns and undocumented assumptions increase ambiguity. The three-layer model is reported from the easy end of the codebase distribution.
• The lower bound is named. "Teams that adopt AI tools widely without proportionate senior supervisory capacity may accumulate risk not visible from within the team." P2 and P5 both observed that teams with stronger architectural expertise used executable constraints more extensively — so the layer that scales is the one that requires the expertise in shortest supply to build.

The failure trajectory the layers are for#

P2 supplies the only concrete failure in the paper, and it is the clearest statement of why this is an organizational rather than a technical problem. In a project where AI-generated changes accumulated over several months without proportionate review capacity, a substantive feature had to be discarded and reimplemented from scratch once its architectural problems became visible. P2's own reading:

"had this been done without an AI system, we would not have generated so much code. .. maybe we would have noticed earlier"

The authors are careful with the inference — a failure mode, not an inherent property — and draw the operational lesson: productivity gains and validation infrastructure have to be scaled together, which is "an organizational choice rather than a purely technical optimization." Without sufficient guardrails at all three layers, the gains "were frequently offset by increased review effort, accumulated false correctness, and delayed defect detection."

One inference on the productivity side is flagged by the authors as theirs rather than a participant's: that organizations would not be investing this level of attention if the gains were marginal. They state plainly that this is drawn from observed investment of time and effort, not from anything a participant said.

Four patterns, offered as patterns and not recommendations#

1. Promote recurring review findings into linting rules. Treat each manually-recurring review concern as a candidate for promotion into an executable check, narrowing manual review toward the genuinely contextual.
2. Front-load specification and architectural planning. Effort that sat in implementation migrated upstream; budget for the redistribution rather than compressing planning as overhead.
3. Use sub-agents for concurrent supervision and independent review. P1's three planner sub-agents, ranked by a further agent, with drift detection as the stated purpose — "decoupling architectural-conformance checking from post-hoc review by embedding it concurrently with generation." Note: the heading promises two complementary mechanisms and the paragraph delivers only the first; the "independent review" half is missing from the published text, confirmed against the reference parse, so it is the paper's defect and not a parse artifact.
4. Shift validation toward higher-level abstractions. Architecture plans, visual system overviews, sequence diagrams and other intermediate representations, with the generalization stated as a return: "returns on tooling that makes architectural state and implementation trajectories legible at a glance appear larger than returns on tooling that merely accelerates generation."

Across all four, the authors note that effective application depends on architectural and contextual expertise participants framed as in short supply.

How the survey was used, and what it is worth#

The survey is context, not evidence, and the authors say so. It ran November–December 2025 in the first author's institution's computer-science alumni network; ~100 alumni were personally invited and 50 completed it; the instrument was co-developed by the first author and a colleague, reviewed by one external practitioner for clarity, and not formally piloted. "Because the survey relied on convenience sampling and an unpiloted instrument, we do not interpret its aggregate responses as inferential evidence."

Two structural facts constrain every number below. The five interviewees were selected from the survey respondents, so the interview sample is a subsample of a convenience sample rather than an independent check on it. And the respondent pool is senior and small-team heavy: 26/50 technical leads or architects, 16/50 senior software engineers, 34/50 in teams of 2–9. Read every figure as "among senior practitioners in small Swiss/Central European teams".

Survey item	Figure
Top-selected risks	code quality 43/50; long-term maintainability 40/50
Use steering files (.cursor/config, claude.md)	13/50
Use structured prompt workflows (Requirements → Design → Tasks)	6/50
Want support on review standards for AI-generated code	23/50
Want monitoring and traceability tools	15/50
AI-tool use governed by clear organizational guidelines	24/50
Informal arrangements or no monitoring at all	23/50
Report responsibility for AI-assisted code became more diffuse	8/50

The pair worth keeping is 13/50 on steering files against 43/50 naming code quality as the top risk: in this sample the preventive layer is the least-adopted of the three despite being the one the paper argues is moving upstream. The authors read the externalization figures the same way — "emerging but not yet widespread."

How much weight this deserves#

Low, and the paper does not oversell itself. The specific discounts:

• Nothing is measured. No review time, no defect rate, no escape rate, no before/after, no comparison group. The only quantities in the findings are two self-reported ratios from P1 (3–4× review-to-generation; two-thirds of time in specification refinement) and the survey counts above. The three-layer model is a description of reported practice, and the authors state it: "the study captures reported practices and perceptions rather than direct longitudinal observation."
• n = 5, and effectively 4 (P3 contributes to one theme only), drawn from one convenience-sampled survey, over-representing Swiss and Central European contexts.
• Single-coder analysis with no inter-rater reliability. Mitigated by iterative refinement, written follow-ups and a member-checking session with four of five participants in late March 2026 — where, usefully, several examples and reframings in the findings originate rather than from the original interviews.
• AI-supported analysis, disclosed. ChatGPT for translation of German excerpts, phrasing consolidation and preliminary thematic drafts; Claude, for the camera-ready, to re-verify quotes against transcripts — which "correct[ed] several participant-attribution errors this process identified". A study whose subject is AI supervision used AI in its own analysis pipeline and found attribution errors that way; both directions of that are worth noting.
• One participant is a co-author (P4), and P4 is the most-cited participant in the findings. Disclosed in §5.7 with two stated mitigations.
• Transcripts are not shareable (confidentiality); the codebook, survey instrument and anonymized evidence table are on Zenodo (10.5281/zenodo.21611622).

What survives all of that is a vocabulary and a structural claim, not a result: the preventive/executable/human decomposition, the mechanism-not-sequence criterion between the first two, "false correctness", and "operational explainability". Those are the parts the rest of the wiki can use, and each of them is a hypothesis the corpus's measured sources can be pointed at.

The human layer's missing input, named by a governance framework (CIVIC-AI, September 2026)#

This page's third layer is defined by posture — oversight re-scoped from line-by-line reading to concurrent supervision plus operational explainability — and the source specifies no input to it. When Does AI Augment Work? A Workflow-Level Framework for Human-Agent Collaboration (CIVIC-AI 2026 workshop whitepaper, practitioner-opinion, no measurement; framework carried on Human-AI Accountability Redesign) supplies two pieces that fit the hole, from outside software engineering and with no more evidence than this source has.

The delegation boundary, as three task properties. Where the human layer sits is left to configuration here; there it is a rule — verifiability ("can a qualified person inspect the output and identify failure?"), reversibility ("can an error or action be corrected before serious harm occurs?"), and stakes. Delegation increases when outputs are inspectable, errors recoverable and stakes bounded. This is P1's comprehension tiering (criticality × longevity) and Risk-Tiered Auto-Approval's blast-radius gate stated as one triple, and its interest for this page is that it makes the executable layer a determinant of the human layer: verifiability is not a fixed property of the work, it is partly manufactured by whatever mechanical checking exists, so every promotion from preventive to executable moves the delegation boundary rather than merely enforcing it.

The input the human layer needs and nobody instruments. "Human oversight is meaningful only when the reviewer has the competence, time, information, and authority to understand, challenge and override the evolving system. This competence does not persist automatically. It requires organisations to deliberately assign workers enough substantive review work and enough exposure to AI failure to keep the verification skill current." Read against the five practitioners here: the re-scoping they describe removes exactly the substantive review work that clause says maintains the skill — line-by-line reading is what goes, and what replaces it is supervision of a process whose failures the executable layer is supposed to catch first. The whitepaper's failure mode for this is "human approval becomes ceremonial"; this page's own F1 finding is that review-centric guardrails already fail at the things the human layer is being kept for. Neither source measures whether the re-scoped reviewer stays able to review, and the falsifiable form is close to this page's first open question: attribute caught defects by layer and track whether the human layer's catch rate declines as its share of substantive review falls. See The Tragedy of the Cognitive Commons for the profession-level version of the same depreciation.

The preventive layer's defining property, measured from traces (Gao & Chen, August 2026)#

The preventive/executable distinction above is stated as a definition backed by five interviews. Gao & Chen (Peking University, arXiv 2608.20195, 2026-08-20, empirical) measure the behaviour underneath it across 557 real agentic coding sessions, 94,813 events and 3,033 documentation interactions, and the definition survives in a stronger form than the authors here claim.

"Not themselves automatically checked" is a statement about tooling. The traces make it a statement about the generator: across 3,033 documentation interactions there is no observed instance of documentation used as an oracle against which code is checked. The Validate stage of their candidate cycle has zero events, the Verify interaction type (checking code against documentation) is unattested, and within three events of consulting documentation agents run tests at 0.23× and builds at 0.15× the session base rate (adjusted ORs 0.39 [0.25, 0.60] and 0.25 [0.14, 0.44]). The steering artifact is not merely unchecked by the toolchain; nothing in the observed trajectory checks against it either.

That is direct behavioural support for P4's rule — "if a rule is relevant, it must be enforced through linting" — and for the duplicate-don't-choose posture. It also sharpens this page's second open question rather than answering it: the ablation that would price the preventive layer's residual contribution is still unrun, but the premise it rests on is no longer an inference from an absence of tooling. The paper's own §6.2 draws the conclusion explicitly and names verifiability — "documentation should be written so agents can verify their work against it" — as an implication its data do not support, because it "describes no observed behaviour." Full treatment at Agent Documentation Behavior.

The same corpus supplies a second, less comfortable reading of the preventive layer: agents consult these artifacts self-initiatedly (70.2% of interactions) rather than when something fails (7.5%), and the documentation they consult is overwhelmingly agent-facing — instruction files and the agents' own working notes, 60.5% of interaction, against 1.3% for API references. Whatever the preventive layer is doing, it is doing it during routine progress and mostly on artifacts written for or by agents, not on the human-facing documentation the guardrail vocabulary implies.

Connections#

• Agent Documentation Behavior — the preventive layer's defining property measured rather than defined: across 3,033 documentation interactions in 557 real sessions there are zero events of documentation used as an oracle, Verify is unattested as an interaction type, and testing and building are suppressed after consultation (lift 0.23 / 0.15). Behavioural support for P4's promote-to-lint rule, and the source that names "verifiability" as an implication the data do not support
• Review as the Control Point — the direct structural disagreement, and it resolves into a scope difference rather than a conflict. That page (empirical, 3,100 coded documents, 2.5M+ PRs) locates a coding agent's effect on software at review and makes review depth and reviewer skill the causal core; this source's whole thesis is that review is one layer among three and that the other two act before it exists. The tiers are not close — a 26-construct theory built on a large corpus against five interviews — so where they touch on evidence, that page wins. But they are mostly not contesting the same claim: its three moderators (reviewer expertise, disposition, process adaptation) are properties of the review layer, and this source's F5 dimensions are properties of the configuration around it. The one place they genuinely collide is P4's rule that any relevant rule must move to linting, which is a prescription to shrink the control point that page says decides everything
• Verification as the New Bottleneck — the hub this is a distributed answer to. P2 states the thesis in the practitioner's words ("code writing has become very cheap, with the bottleneck clearly moving to review") and the response reported here is neither "review harder" nor "review less" but "move the supervision function off the review step" in two directions at once, upstream and into the build
• Agent Context Files — the preventive layer, named from the artifact side. What this source adds to that page is a definition rather than a file format: a context file is a guardrail that nothing checks, whose effect is conditional on the generator consulting it — and a field population figure, 13/50 senior practitioners using steering files
• Harness Activation and Adherence — the measured version of the condition this source states in words. "Their effect depends on whether the generation process actually consults them" is the activation gate; P4's rule that any relevant rule must also become a lint rule is a field mitigation for it, arrived at without the measurement
• Deterministic Engineering for Agent Code Review — the executable layer argued from the lab. Determinism-beats-autonomy as a design philosophy there; here it is a practitioner stance ("if a rule is relevant, it must be enforced through linting") and an organizational one (the build system as arbiter, so violations break the build rather than reaching a reviewer)
• Reviving Impractical Quality Tools — the supply side of Pattern 1. That page explains why the gate stack is affordable now (the labor changed, not the tools); this one supplies the promotion rule that decides what goes into it, and P5's stated reason for never relaxing a gate once it is automatic
• Acceleration Whiplash — the pressure this is a response to, with a qualitative instance attached: P2's feature discarded and reimplemented after months of accumulated AI changes without proportionate review capacity. It also complicates that page's maturity framing from a third direction — see its open questions
• Psychological Costs of AI Adoption — the human layer, costed. Where this source says oversight re-scopes toward architectural reasoning, that one measures what the re-scoping costs the people doing it (the verification tax, accountability anxiety) and finds the incidence falls hardest on engineers and not at all on architects — which is the same direction this source's F5 lower bound points, that the layer scaling best needs the scarcest expertise
• Pilot-to-Production Gap — the operators-to-overseers conversion, at a different altitude. That page's blueprint converts an execution workforce into an oversight workforce at the artifact; this source reports the oversight moving up to architecture instead, which is a different destination for the same move
• Standardize the Infrastructure, Not the Tools — the same principle, one layer down the stack. Shopify standardizes the gateway and leaves tool choice free; these teams standardize guardrails (conventions, lint, CI) while AI-tool governance stays informal in three of five cases and 23/50 of the survey. Non-vendor corroboration that the standardization that happens is at the constraint layer, not the tool layer
• Loop Engineering — the paper cites Osmani directly and positions itself one layer above: loop engineering designs self-triggering agent cycles with reduced moment-to-moment human involvement, and this source's human-oversight layer is offered as the answer to the coordination question that raises. P1's step-by-step observation with early interruption is the un-automated version of the same stop-check
• Agent Harness Engineering — the discourse this converges with, and the paper says so. It notes that the Galster et al. configuration study was retitled Harness Engineering for Agentic AI Coding Tools, and that Böckeler's formulation — the harness as an attempt to "externalise and make explicit what human developer experience brings to the table" — "closely echoes our own use of externalization". Independent arrival at the same construct from the empirical-SE side
• Human-AI Accountability Redesign — the org-chart altitude of the same problem, and where the six-condition audit test lives: this page's three layers are a Layer 1 ("workflow integrity") arrangement, and the conditions that expire are the longitudinal ones it does not instrument
• The Tragedy of the Cognitive Commons — what depreciates the human layer's input over a career rather than a quarter: the review competence the layer presumes is regenerated by the execution work the first two layers absorb
• Risk-Tiered Auto-Approval — the same calibration logic on a different object. That page tiers approval by blast radius and reversibility; P1 tiers comprehension by criticality and longevity (a UX prototype needs none, a database migration needs every statement). Both say the supervision budget is set by what the change can destroy, not by its size
• Human-Governed Skill Maintenance — the preventive-guardrail layer's maintenance, measured: 254 substantive SKILL.md edits, every one merged by a named human, 62% AI co-authored, and a powered transfer test finding the maintained version no better than the earliest — the only longitudinal evidence on the layer this paper says "nothing checks"

Open Questions#

• The structural claim is that no layer is sufficient alone, and the paper measures what none of the three layers catches. The falsifiable form is cheap for any team already running all three: attribute each defect found over a quarter to the layer that caught it — preventive (never generated), executable (broke the build), human (caught in supervision or review), or escaped to production — and report the four shares. Until that exists, "layered supervision" is a description of where effort went, with no evidence that the distribution outperforms the review-centric arrangement it replaced.
• Preventive guardrails are defined here as guardrails nothing checks, whose effect is conditional on the generator consulting them — and the practitioner answer is to duplicate every relevant rule into an executable check. Does the steering artifact then contribute anything? The discriminating ablation is one repository and three arms: the rule in the steering file only, in the lint rule only, and in both, scored on violation rate at first generation rather than at merge. If the both-arm matches the lint-only arm, the preventive layer is buying trajectory quality rather than conformance, and should be argued for on that basis instead.
• The authors refuse "maturity" for a three-dimensional configuration space — governance posture, system criticality and homogeneity, team composition — because five points show no linear progression. Is the space genuinely non-ordered, or is the refusal an artifact of n = 5? The survey instrument that produced two of the three dimensions already exists and is published on Zenodo; administering it at a scale that supports ordering, and testing whether guardrail-layer adoption is monotone in any of the three, separates a real finding from a sample-size artifact.

Sources#

• From Agent Behaviour to Agent-Friendly Documentation — Gao & Chen (Peking University), arXiv 2608.20195, 2026-08-20, empirical. Cited here for §4.1.3 and §5 + Table 10 (Validate 0 events, Verify/Compare/Follow-reference unattested), §4.2.2 + Table 3 (test lift 0.23 / OR 0.39, build 0.15 / 0.25), §4.2.1 + Table 2 (70.2% self-initiated vs 7.5% failure-driven), §4.1.2 + Table 1 (60.5% agent-facing) and §6.2 (verifiability as an unsupported implication). All ten tables reconciled against pdftotext -layout; zeros are zeros for the operationally defined patterns, which the authors stress is not evidence that no validation of any form occurs. Full treatment on Agent Documentation Behavior
• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering — Markus Stolze (OST Eastern Switzerland University of Applied Sciences, Rapperswil) & Mirco Strässle (smartive AG, St. Gallen), When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering, arXiv 2608.26316, 2026-08-26, 13 pp, ESEM 2026 Software Engineering in Practice track (DOI 10.4230/LIPIcs.ESEM.2026.89), case-study. Cited here for §4.1–4.5 (F1–F5), §5.1–5.6 (the layer distinction, the three shifts, the four patterns), Table 1, §3.3 (survey context) and §5.7 (limitations and the co-author COI). Parse verdict: clean. The single ingest table-weld soft warning fires on "Staff Engineering Manager" in Table 1 and is the documented wrapped-label false positive — Table 1 reconciles row-for-row against pdftotext -f 4 -layout, and it is the paper's only table. canary-recall passed 7/7. The five image assets are LIPIcs boilerplate (CC-BY badge, Dagstuhl chevron, three section-number tiles) viewed under the image two-pass rule and carrying no content; docling also renders an email-icon glyph as the literal word "envelope" beside each author. A defect in the paper, not the parse: Pattern 3's heading promises "concurrent supervision and independent review" and its paragraph announces "two complementary mechanisms" before describing only the first — confirmed missing in the pdftotext -layout reference parse of page 10. COI: disclosed and material — interview participant P4 is a co-author (SEIP practitioner perspective) and is the most-cited participant in the findings; the second author's affiliation (smartive AG) is a software agency in the population studied. Limits: five interviews from one convenience-sampled alumni survey, Swiss/Central European, single-coder with no inter-rater reliability, reported practice rather than observation, and no measured outcome of any kind
• When Does AI Augment Work? A Workflow-Level Framework for Human-Agent Collaboration — Wu, Ziems et al. (22 authors; NUS, Stanford, A*STAR, NTU, Singapore Ministry of Manpower), CIVIC-AI 2026 workshop whitepaper, arXiv 2609.12482, 2026-09-11, 8pp, practitioner-opinion, no measurement of its own. Cited here for §4 (verifiability / reversibility / stakes as the delegation boundary; the interdependence clauses) and §3 (the competence-maintenance requirement and the "ceremonial approval" failure mode). Not evidence for anything on this page — a second unmeasured framework, useful because it names an input this one leaves blank