Agentic Software Engineering: Foundational Pillars and a Research Roadmap — Ahmed E. Hassan, Hao Li, Dayi Lin, Bram Adams, Tse-Hsun Chen, Yutaro Kashiwa, Dong Qiu, arXiv:2509.06216v3 (cs.SE), September 2025 (v3 June 2026), submitted to ACM.
The vision paper at the center of the trilogy
This is the third leg of a trilogy this blog has been reviewing in reverse order. The Inside the Scaffold taxonomy (April 2026) mapped what coding agent harnesses are made of at the source-code level. Don't Blame the LLM (July 2026) measured how those harnesses' quality evolves as they ship at hyper-churn velocity. This paper — the oldest of the three (September 2025) — is the vision that frames both: Structured Agentic Software Engineering (SASE), the argument that agents are not a faster way to write code but a new actor in a reimagined engineering discipline, and that the SE field's foundational pillars — actors, processes, tools, artifacts — must be rebuilt around human-agent collaboration.
It is written by the same Queen's University group, and reading the three in order shows the arc: first the call to structure, then the map of the scaffold's design space, then the clock proving the scaffold moves quality. The vision paper is the least empirical and the most ambitious of the three, and it is best reviewed on its own terms: as a deliberate attempt to build a structured vocabulary for a field that does not yet agree on what its objects are called.
The duality: SE for Humans, SE for Agents
SASE's core thesis is that agentic SE requires two symbiotic modalities. SE for Humans (SE4H) redefines the human's role from implementer to Agent Coach: high-level intent, strategy, and mentorship. SE for Agents (SE4A) establishes a structured, predictable environment where fleets of agents operate effectively. Every pillar of SE manifests differently across the two: actors expand from human developers to hybrid teams of coaches and specialized agents; processes replace ad-hoc prompting with repeatable engineering activities; artifacts replace transient prompts with durable machine-readable contracts; tools replace the all-in-one human-centric IDE with two purpose-built workbenches.
The duality is the paper's cleanest contribution. It names something every practitioner has felt: the tool that is optimized for human cognition (an IDE with visual debugging, autocomplete, hover docs) is often the wrong tool for an agent, which has no cognitive overload and thrives on raw, structured, machine-readable interfaces — "that many of today's autonomous coding agents still rely on basic utilities like grep exposes this fundamental mismatch." The paper's proposed split — an Agent Command Environment (ACE) for humans and an Agent Execution Environment (AEE) for agents — is the architectural form of this realization, and it is a system-of-systems design in the Maier sense this blog covered in the systems-of-systems post: an acknowledged SoS with a designated integrator (the coach), managerially independent elements (the agents), and the interfaces between them as the primary architectural surface. SASE's insistence that the human-agent dialogue be carried by version-controlled artifacts is, precisely, Maier's leverage-at-the-interfaces principle.
The autonomy ladder
To situate the vision, the paper adapts the automotive SAE autonomy levels into a six-rung ladder for AI in SE:
- SE 1.0 (Level 0) — manual coding; notepad/vi/emacs.
- SE 1.5 (Level 1) — token assistance; autocomplete.
- SE 2.0 (Level 2) — task-agentic; Copilot-style generation of a planned change; human supervises.
- SE 3.0 (Level 3) — goal-agentic; the agent takes a technical goal ("add a caching layer") and executes a multi-step plan; Devin, Claude Code, Jules, Codex.
- SE 4.0 (Level 4) — specialized domain autonomy; high autonomy within a technical domain (a stack or a quality attribute, e.g., a security agent).
- SE 5.0 (Level 5) — general domain autonomy; conceptual, does not exist.
The ladder comes with a crucial conceptual distinction between agency (executing a given plan) and autonomy (formulating the plan): workflow agents are systems of agency, hardcoded orchestration that requires manual updates; autonomous agents are self-governing and adapt through natural language. The paper's sharp observation is that the industry's defining challenge is not Level 5 — it is mastering Level 3, because the transition from task-agentic to goal-agentic changes the human-computer relationship in kind, not degree. The ladder is a genuinely useful calibration device, and it will age well even as the specific systems sitting on each rung change.
The speed-versus-trust gap
The paper's diagnosis is the strongest part of its evidence base, and it is worth quoting because it is now corroborated by the group's own later study. The motivating data: 29.6% of "plausible" SWE-bench fixes turned out to be incorrect or regression-inducing on rigorous retesting; GPT-4's apparent SWE-bench solve rate collapsed from 12.47% to 3.97% after manual audit, revealing widespread cosmetic fixes; agents produce superficial single-file patches; patches that pass unit tests fail broader CI on style and hidden regressions. The pattern: passing tests is not the same as being merge-ready, and at agentic scale, the verification work that catches the gap can overwhelm the humans it is supposed to save.
This is the paper's intellectual bridge to the group's later work: "Don't Blame the LLM" showed empirically that 300+ tests and green CI do not catch resolve-rate or token-cost regressions, and SASE's prescription — the Merge-Readiness Pack (MRP) — is the artifact-level answer. An MRP is not a pull request; it is an evidence bundle demonstrating five criteria: functional completeness (end-to-end proof the feature behaves as specified), sound verification (the agent's test plan and new tests, not just passing logs), exemplary SE hygiene (static analysis, linting, complexity reports), clear rationale (a human-readable synthesis of approach and trade-offs, instead of a verbose trajectory dump), and full auditability (a frozen trail: versioned links to the exact brief, mentorship rules, tools, and trajectory used). The MRP's "progressive disclosure" — a summary that can be drilled into — is the right answer to the review-overwhelm problem, and it is the artifact this blog's harness-patterns series has been circling from the pattern side.
The artifacts as the interface
SASE's vocabulary is its deliverable, and the version-controlled artifacts are its spine:
- BriefingScript — the mission brief: what & success criteria (enriched with invariants and pre-conditions), architectural context, strategic advice, and known gotchas. A living, versioned document, iteratively refined — "literate programming" inverted so the intent document is the primary artifact and code is derived from it. It is the formalization of what the 100x developers do when they treat an agent as a junior teammate rather than a magic tool.
- LoopScript — the declarative workflow playbook: task decomposition and parallelization (assign a brief to multiple agents, run N-version programming), workflow strategy (full autonomy for a trivial fix, strict multi-stage review for a security patch), and evidence-based acceptance criteria. The paper's answer to Karpathy's observation that agents cannot infer the "stakes" of a task and will overthink or under-deliver.
- MentorScript — mentorship-as-code: the version-controlled rulebook of team norms, from granular checks ("all new functions must have deterministic tests") to architectural principles, subject to their own quality gates (linting, unit tests, conflict detection). The paper's sharpest idea: guidance should be treated as first-class code, with every agent action traced back to the rules that were considered, enabling root-cause analysis when behavior deviates. This is CLAUDE.md/AGENT.md elevated from a grassroots convention to an engineered artifact — the paper explicitly acknowledges the precursor.
- Consultation Request Pack (CRP) — the agent-initiated human callback: an agent facing ambiguity or a complex trade-off packages the decision point, routes it to the right specialist, and the ACE treats humans as callable expertise endpoints. This is the artifact that makes the collaboration genuinely bidirectional — it is also, notably, the thing that the always-on agents governance discussion has been missing: a structured, auditable escalation channel.
- Merge-Readiness Pack (MRP) — described above; the target deliverable of the loop.
- Version Controlled Resolution (VCR) — the human's formal, versioned response to a CRP or MRP, linked to the artifact it addresses, preserving traceability for downstream auditing and learning.
The engineering activities that produce these artifacts — BriefingEng, Agentic Loop Engineering (ALE), AI Teammate Mentorship Engineering (ATME), Agentic Guidance Engineering (AGE), AI Teammate Lifecycle Engineering (ATLE), AI Teammate Infrastructure Engineering (ATIE) — read like a department chart for a future that does not exist yet, which is the point: the paper is deliberately scaffolding the discipline before the practice settles.
What the paper gets provocatively right
Three ideas are worth singling out because they contradict received wisdom.
The revival of N-version programming. The paper's motivating workflow — one developer writing specs for seven tickets, a team of agents generating 28 candidate pull requests in parallel, the developer selecting and mixing — reframes N-version programming (the old fault-tolerance technique of generating multiple independent implementations) as an inference-time compute strategy: sample broadly, then select or synthesize. The blog's sampling-vs-iteration discussion and the harness-patterns voting ensembles are the same idea from the pattern side; SASE makes it a first-class engineering activity with explicit tooling needs (comparing, mixing, and combining components across N versions).
Agent-first code practices. Some principles invert when the primary reader is a model. DRY, the paper argues, may be worth reversing: code duplication is cheap for an agent to update consistently (the GitClear data on post-Copilot duplication is cited as industry evidence), while the ROI of clean code — high cohesion, low coupling, comprehensive docs — becomes crystal clear because a well-structured codebase is a more fertile environment for agents to inhabit. Strong type systems (Rust, TypeScript) gain value because expressive compiler feedback is how agents learn from failures; the precision target shifts from precision@K (human time is precious) to precision@100 (a subordinate agent post-processes the flood). These are hypotheses, and the paper says so — the economics need empirical models, not anecdotes — but they are the right hypotheses to be testing.
Lifetime teammates and proactive maintenance. SASE's ATLE envisions agents as persistent partners with memory and decision logs, and — in a genuinely forward-looking passage — the ACE scheduling agents during idle cycles to scan for technical debt and file their proposals as new BriefingScripts, entering the normal workflow. This is durable daemons and always-on agents written as a research program: the transition from stateless contractors to evolving collaborators, with persistent memory and observability as the enabling infrastructure.
What's missing
A vision paper should be judged on whether its vocabulary names real problems, not on whether its solutions exist. By that standard SASE mostly succeeds — but the review should name the gaps.
It is entirely unvalidated, by design. Not a single artifact, workbench, or activity in the paper is implemented or tested. The paper is honest about this — "our goal is not to offer a definitive solution" — but the honesty cuts both ways: the vocabulary is untested against the one force that will shape it, which is what real teams do when the artifacts get in the way. The history of software engineering is littered with rigorous process formalizations that rotted on contact with practice. Version-controlled BriefingScripts sound excellent; the risk is that they become SRS documents — written once, ignored, and out of date — unless the tooling makes maintaining them cheaper than not.
The acronym burden is real. SASE, SE4H, SE4A, ACE, AEE, and six engineering activities with four-letter names, plus six artifacts, plus VCRs: roughly twenty new terms in thirty pages. Some deserve to stick — MRP, CRP, and MentorScript name things practitioners already half-build. Others are taxonomy in search of a practice. The paper's own related-work section shows the grassroots artifacts already exist (CLAUDE.md ≈ proto-MentorScript, PRPs ≈ proto-BriefingScript, PDAR ≈ proto-LoopScript, BMAD ≈ proto-multi-agent); the open question is whether formalizing them adds value or ceremony. The paper's answer — versioning, traceability, auditability — is plausible but unproven.
The Bitter Lesson tension is unresolved. The paper devotes a section to reconciling SASE's structure with Sutton's Bitter Lesson, arguing that structure wins where data is scarce and autonomy where it is abundant. This is the right hedge — the paper's image of the modern engineer as someone who "masters the duality of control," deciding when to impose a workflow and when to let the agent loose, is genuinely good — but as stated it is unfalsifiable. The empirical question of where the boundary between structured and autonomous actually falls is exactly what the group's own longitudinal study begins to answer, and the answer is sobering: at hyper-churn release velocity, feature additions and structural growth moved quality sideways while doubling token costs. SASE's N-version programming revival carries the same risk profile — 28 candidate PRs for seven tickets is a token budget story that the paper does not tell, and the economics of broad sampling deserve the same empirical treatment the paper demands for DRY.
The sharpest diagnosis is the observability gap. The paper's best passage argues that today's tooling manages neither the conversation nor the mentorship with the rigor applied to code: CLI interactions are ephemeral terminal scrollback, Copilot anchors results to PRs without linking them causally to the mentorship that produced them, and no system version-controls code, prompts, and conversational context as one interlinked artifact. This is true, it is rarely said this clearly, and it connects directly to the Inside the Scaffold finding that state management is one of the most divergent scaffold dimensions — with event sourcing on one end and destructive overwrite on the other. SASE's artifact layer is the proposed answer; the empirical work of building it has not begun.
Bottom line
SASE is a scaffolding paper in both senses: it builds scaffolding for the field, and its own construction is provisional. Read as a survey of the problems — the speed-trust gap, the epistemic mismatch between human- and agent-optimized tools, the missing observability and revision control, the redefinition of the engineer as coach — it is the clearest statement this blog has reviewed of why the harness is the product. Read as a proposed solution, it is a vocabulary waiting for evidence.
The trilogy is the story of that evidence arriving. The vision paper says the field needs structured artifacts and merge-readiness as the bar; the taxonomy paper maps the design space the vision would standardize; the longitudinal study shows why the vision's core demand — measure agentic quality, not just functional correctness — is not optional. What the vision contributes that the empirical papers cannot is the vocabulary for the destination: agentic software engineering, not agentic coding; mentorship-as-code; merge-readiness as the unit of trust; humans as callable experts. Whether the acronyms survive contact with practice is an open question. The problems they name will not be going away.