1 Introduction↩︎

Generative AI is changing the economics of software engineering [@amodei2026policy]. Recent coding agents let us trade human time for LLM tokens [@jimenez2024swe]. Software engineers must steer and validate unreliable, non-deterministic agents [@he2025llm]. The central problem is identifying engineering methods to make AI-mediated implementation governable at speed.

Prior work on AI-assisted software engineering has largely studied models, agents, and tools on bounded tasks such as code generation [@dong2025survey], debugging [@roy2024exploring], and repair [@rondon2025evaluating]. These studies show that agents can perform useful programming tasks and reshape developer workflows but provide limited evidence about end-to-end agentic software engineering processes. Meanwhile, industry reports show that software engineers are using AI agents [@anthropic2026compiler; @cloudflare2026nextjs], sometimes resulting in major production outages [@moonka2026amazon_sev1_ai; @ft2026amazon_ai_outages]. Existing accounts do not explain how agentic development can sustain governable velocity: human-supervised workflows preserve oversight by making human attention the bottleneck, while multi-agent workflows accelerate implementation with underspecified quality control. We study this problem through a 12-week first-person case study [@runeson2009guidelines; @runeson2012case] of agentic development. Here, the phenomenon of interest is not only the code produced by AI agents, but the situated sequence of judgments, controls, failures, and feedback loops through which agent-produced work was accepted, rejected, redirected, or converted into changes to the engineering environment. During the study period, a single expert software engineer used frontier AI coding agents to build a document accessibility remediation system. The empirical record includes 88 contemporaneous field notes, as well as design records, deployment data, and repository history. We analyze this record to learn: Can AI-mediated implementation be converted into governable software engineering progress?

From this case, we develop a candidate middle-range theory [@merton1968social] of governance conversion in agentic software engineering. The theory explains how high-velocity AI-mediated implementation can become governable software engineering progress. Its central process is failure \(\rightarrow\) governance: agentic velocity exposes structural failure classes, engineering judgment interprets those failures, and new governance mechanisms encode that judgment into the engineering environment to constrain subsequent agent work. The theory extends governance-centric accounts of agentic software engineering. Prior governance work emphasizes ex-ante governance: deriving controls from obligations known before agents act. We identify a complementary ex-post process: inducing controls from failures discovered during agentic work. In this account, the scarce human work is not implementation-level review, but recognizing which failures reveal missing governance and converting them into architecture and controls.

This paper contributes:

• A process model of governance conversion in agentic software engineering, specifying its stages, outcomes, and influencing factors, along with testable propositions to inform future empirical research.

• Empirical evidence from a sustained first-person case of agentic development: a 12-week, richly instrumented case involving frontier AI coding agents, contemporaneous field notes, and repository history.

• A catalog of governance mechanisms for agentic software engineering, including recurring governance patterns and concrete examples from the development harness.

Significance: This paper contributes an empirical and theoretical account of agentic software engineering from sustained firsthand participation in the development process. The central lesson of the case is that AI-mediated implementation changes the bottleneck of software engineering: when implementation becomes abundant, sustainable progress depends on the governed engineering environment and on the human capacity to supply direction, interpretation, and abstraction. These findings inform several research agendas: empirical work to test and refine our theory; capability-building research on architectures, tools, and governance mechanisms for agent work; and educational work to train engineers to exercise architectural-contextual judgment at agentic speed.

2 Background↩︎

This section motivates the need for a process account of governable agentic development. 2.1 defines agentic software engineering. 2.2 describes associated process models. 2.3 articulates the knowledge gap.

2.1 Agentic Software Engineering↩︎

Generative-AI coding systems have shifted from assistance-oriented tools toward agentic implementation systems. Earlier systems primarily supported localized tasks, such as code completion [@dong2025survey], code optimization [@peng2026sysllmatic], code repair [@rondon2025evaluating], and unit test generation [@schafer2024LLMUnitTest]. Although useful, these systems still required a human engineer to decompose the task, guide implementation, and integrate the suggested changes. More recent systems are increasingly agentic [@sweagent; @zhang-etal-2024-codeagent; @autocoderover]: they can use repository context, invoke tools, and choose actions. This shift expands the scope of AI-supported development from localized edits to larger implementation tasks, including the construction of non-trivial software systems through natural-language interaction alone [@deng2025swebenchproaiagents; @ding2026nl2repobenchlonghorizonrepositorygeneration; @yang2026programbenchlanguagemodelsrebuild].

However, agentic software engineering also introduces new sources of failure and inefficiency. First, agent behavior is highly sensitive to its context, including the task prompt, repository instructions (e.g.,AGENTS.md), tool descriptions, available files, and conversation history [@mohsenimofidiContextEngineeringAI2026; @liuLostMiddleHow2024]. Changes to this context can alter the assumptions available to the agent and therefore the implementation it produces [@zhuoProSAAssessingUnderstanding2024]. Second, agents are stochastic systems operating over underspecified requirements. When constraints are omitted or ambiguous, the agent may infer requirements that were never intended, leading to unexpected or faulty behavior [@yangWhatPromptsDont2026; @yangAssessingImpactRequirement2026]. Third, agentic implementation introduces operational cost: each model interaction consumes tokens and latency [@anthropic2026claudepricing; @openai2026apipricing]. Thus, the shift to agentic software engineering creates a need for mechanisms that provide agents with better context and clearer constraints, so that increased implementation velocity does not come at the expense of quality, predictability, or cost.

2.2 Process Models for Agentic SE↩︎

The main challenge of agentic software engineering is to ensure quality using fast, unreliable tools (i.e., LLMs). This has led to different accounts of how to organize agentic software engineering. We organize prior accounts into three process models based on what they prioritize (1).

2.2.1 Velocity-Centric [@yegge2026gastown; @qianChatDevCommunicativeAgents2024; @hongMetaGPTMetaProgramming2024]↩︎

This model gives agents autonomy, and may orchestrate multi-agent workflows to increase throughput. For example, agents may be assigned engineering roles: planner, developer, and tester [@yegge2026gastown]. This increases velocity, but process resemblance is not control. Agents can imitate the form of software work without producing quality output, and lack accountability, organizational context, and professional judgment.

2.2.2 Oversight-Centric [@bender2021parrots; @chouBuildingSoftwareRolling2025; @tangStudyDeveloperBehaviors2024]↩︎

In this model, agents are useful but unreliable assistants, so human engineers remain near the implementation loop. Humans prompt bounded work and inspect output. This view recognizes that agentic output requires oversight. Its limitation is that the control mechanism is human attention. At high implementation volume, oversight becomes the throughput bottleneck. A related line is trace-based agent improvement, in which execution histories are manually or automatically analyzed to distill reusable lessons into skills and harness changes [@shinn2023reflexion; @barke2026agentrx; @ni2026trace2skill; @lin2026agenticHarnessEngineering; @chen2026harnessfix].

2.2.3 Governance-Centric [@rahimi2026agentic; @kaptein2026runtime; @koch2026governance]↩︎

This emerging model holds that agents create product, organizational, and legal risks as they act [@kraprayoon2025ai]. The literature proposes policy-to-control methods. Its techniques start from known ex ante obligations (e.g., regulations) and deduce corresponding agent controls [@ait2025towards], e.g., as runtime guardrails.

2.3 Knowledge Gap↩︎

Together, these bodies of work expose a gap in software engineering process knowledge. Conventional software engineering has processes for controlling change throughout the development lifecycle [@royce1970managing; @beck2001agilemanifesto]. Agentic software engineering changes the calculus: the potential rate of change skyrockets.

The open question is whether AI-mediated implementation can remain governable at speed. The dominant process models trade off velocity and quality. Although the emerging governance approach is promising, we do not yet know what controls become necessary beyond ex-ante ones, nor how engineers revise the control environment when agent-produced failures reveal obligations not specified in advance. Existing work on control induction improves agent skills and harnesses from traces, but does not explain how observed failures harden the broader engineering environment. We call this process governance conversion: the conversion of observed agentic failure patterns into explicit, durable governance that constrains subsequent agent work. This paper studies governance conversion during a sustained agentic development effort.

3 Methodology↩︎

3.1 Research Question↩︎

Given this gap in process knowledge, we ask:

3.2 Study Design↩︎

We address this question through a case study. This design follows from the character of the research question. First, case study research is appropriate when a phenomenon must be understood in its real-world context, especially when the phenomenon and context are difficult to separate [@yin2018case; @runeson2009guidelines]. Here, the object of study is not AI-generated code, but the process through which an engineer delegated work to agents, interpreted their outputs, and adapted the development environment over time. Second, case studies are suitable for theory development: they can identify constructs, relationships, and candidate mechanisms before those constructs are mature enough for population-level measurement [@george2005caseStudies; @eisenhardt1989building; @eisenhardt2007theory].

We used a first-person case design because it made the target process unusually observable. This design provides access to situated decisions and co-analyzable engineering artifacts that are difficult to recover through post-hoc reconstruction [@seaman1999qualitative; @dittrich2007cooperative; @runeson2009guidelines]. The bounded case is the 12-week development effort described in 4: one expert engineer (“Subject”) using frontier coding agents to develop a greenfield software system. This case exposed repeated decisions about what to delegate, what to trust, what to inspect, and how to revise the engineering environment as failures appeared.

Our study design supports theory building rather than prevalence estimation. A single case cannot establish prevalence. Its value is analytic: it provides a richly instrumented account from which constructs, candidate mechanisms, and failure modes can be identified [@yin2018case; @george2005caseStudies]. Once specified, other empirical methods can test such constructs. We contribute the prerequisite step, by characterizing a sustained agentic development process to articulate those constructs.

3.3 Data Sources and Analysis↩︎

3.3.1 Data sources↩︎

We draw on two sources of evidence. First, the Subject maintained contemporaneous field notes during the 12-week study period, written as 88 episode-bounded entries. Second, we analyzed engineering artifacts from the project repository, comprising 18,662 commits and approximately 1.6 million lines of active artifacts. The two sources triangulate: the field notes record what the Subject perceived as salient, while the repository history is an independent trace of what actually changed—we used it to trace the governance mechanisms and themes that emerged from the field notes back to the commits that underpinned them.

3.3.2 Incident construction↩︎

We analyzed the 88 episodes using structured analytic memoing [@saldana_coding_2013]. Each episode was treated as a critical incident [@flanagan_critical_1954; @butterfield_fifty_2005; @gremler_critical_2004], an event that the Subject judged salient enough to record during the study period, including failures, architectural decisions, and changes in engineering process. For each incident, we made an analytic memo recording the triggering condition, relevant inputs, the Subject’s interpretation, the engineering response, the observed outcome, and the apparent effect on subsequent agent-mediated work. Below, the beginning of a May 28 incident:

3.3.3 Codebook development↩︎

The Subject led codebook development through iteration over the incident corpus. In each pass, the Subject tested candidate taxonomies and revised category boundaries to better fit the data. LLMs were used as qualitative-analysis instruments: normalizing field notes, comparing incidents against candidate codebooks, identifying provisional themes, and locating corroborating repository evidence. LLM-generated summaries, labels, and mappings were treated as analytic aids, with interpretive authority remaining with the author team. The codebook stabilized in 11 iterations.

As a validity check, a second author independently re-coded a stratified sample of 10 incidents, together with the emergent themes, working from the codebook without the Subject’s labels. Agreement was high: 10/10 on incident class, 6/7 on category, and 5/7 on the third coding layer. The second author judged all 10 incident summaries supported by the underlying evidence. The few category and third-layer differences were deemed boundary cases rather than errors.

3.3.4 Reflexivity↩︎

Because the Subject was both practitioner and analyst, the account is shaped by his situated judgment. Following first-person research practice [@finlay2002reflexivity; @tracy2010qualitativeQuality], we embedded several reflexive moments of forced articulation. Across 6 weeks of the study period, the Subject prepared and delivered four talks about the project to institutional, research, and teaching audiences. External response was uncritical, so the value of these checkpoints lay not in peer feedback but in the articulation itself. Repeatedly explaining the work to outsiders forced the Subject to convert his intuitions into explicit constructs. This articulation informed the codebook and final interpretation of the case.

3.3.5 Nature of result↩︎

Our analysis is interpretive and theory-building (6). We contribute a process model and accompanying theory that future work can refine, challenge, and test.

3.4 Researcher and Participant Role↩︎

This is a first-person case study of expert agentic software engineering. The primary practitioner in the case is called the Subject: a software engineering professor at a U.S. research university who is also an author of this paper. The other authors’ role was to help analyze the empirical record, challenge interpretations, and refine constructs.

The Subject needed engineering expertise to undertake the case. The Subject has sixteen years of professional experience, as a software engineer (5 years), PhD student (5 years), and professor (6 years). His engineering experience was prior to the GenAI era, involving his development of \(\sim\)​100,000 lines of code in C/C++, Perl, and Python. His research has contributed to major software infrastructure, e.g., programming language runtimes. His group has published several agentic systems.

4 Case Description↩︎

This section defines the case boundary and engineering context needed to interpret the incident analysis.

4.1 Regulatory Context and System Requirements↩︎

The case was in the context of U.S. public-sector digital-accessibility regulation. This sector is governed by the Americans with Disabilities Act (ADA) [@ada1990]. In 2024, the U.S. Department of Justice updated the ADA guidance for digital content [@doj_titleii_finalrule], requiring that the digital content of public entities communicate “equally effective[ly]” to people with and without disabilities [@doj_effective_communication], operationalized as WCAG 2.1 Level AA [@wcag21]. The obligation applies to electronically distributed materials, e.g., slide decks (PPTX) and readings (PDF). For large entities (e.g., NC State, Penn State), DOJ set an April 2026 compliance deadline. Many public universities, including the authors’, did not license commercial remediation services.¹ Instructors remediated by hand.

The ADA informs the system requirements \(\mathbf{R}_{\mathbf{i}}\):

1. \(\mathbf{R}_{\mathbf{1}}\): An automated system’s inputs are educational documents, e.g., Office (PowerPoint, Word, Excel) and PDF.

2. \(\mathbf{R}_{\mathbf{2}}\): Those inputs must be transformed for accessibility. Some WCAG transformations are syntactic and deterministic, e.g., text size and color contrast (Criterion 1.4.3). Other transformations are semantic. Some can be done by dispatch to a multimodal model, e.g.,“alt-text” (Criterion 1.1.1: non-text content needs an equivalent text alternative). Others require document-structure remediation that can use generative AI as an algorithmic component, e.g., that (Criterion 1.3.1) information, structure, and relationships conveyed through presentation must be programmatically determinable or available in text, and (Criterion 1.3.2) content whose sequence affects meaning must have a programmatically determinable reading sequence. Accessibility itself is an underspecified construct [@kelly2021accessibility], dependent on audience, instructional purpose, and faculty preference.

3. \(\mathbf{R}_{\mathbf{3}}\): System outputs must be auditably traceable to compliance requirements. The system must record what accessibility requirement motivated each change, and what evidence supports the resulting document state. This excludes the black-box whole-document use of frontier models.

4. \(\mathbf{R}_{\mathbf{4}}\): The system should scale: to thousands of faculty at the authors’ institution, and preferably nationwide.

This setting posed two engineering challenges. First, the time pressure made a conventional (non-agentic) engineering approach infeasible. Second, the Subject could not assemble a remediation pipeline from existing components. The document-accessibility ecosystem contains many checkers to facilitate manual remediation [@verapdf_home; @adobe_acrobat_accessibility; @libreoffice_accessibility; @microsoft_accessibility_checker]. There are no mature open-source tools for end-to-end remediation of documents. Hence, the Subject and his AI agents operated in a weakly templated domain. The system required file-format manipulation, reasoning about accessibility semantics, expressing changes as sequences of auditable generative-AI queries, validation, and deployment in a space with few mature remediation exemplars.

Together, the deadline pressure, weak tool ecosystem, semantic remediation burden, auditability requirement, and SaaS deployment target made the project a substantial engineering effort — and a suitable setting for our research question.

4.2 Engineering Approach↩︎

The Subject undertook this project as his primary work activity for the 12-week study period. 2 shows the achieved implementation velocity, and 3 shows his process.

4.2.1 Iterative Capability Development↩︎

Given the greenfield nature of the project, the lack of mature approaches, and the uncertainty regarding feasibility and user needs, the Subject selected an iterative development process, with six stages:

1. Stage 1: Feasibility Probe (Mar. 2026): Queried ChatGPT with mathematics and figures to assess alt-text viability.

2. Stage 2: PowerPoint Remediation Prototype (Mar.–Apr.): Converted the feasibility probe into a command-line tool for PowerPoint: walk slide content and query OpenAI for figures and equations. Colleagues requested PDF support.

3. Stage 3: Format Expansion (April): Generalized PowerPoint support to Word and Excel. Prototype support for PDF. Documents from many sources exposed assumptions.

4. Stage 4: SaaS (April): Added service capabilities for institutional use, e.g., a website, Cloud deployment, and authentication. Feedback from users at multiple institutions exposed requirements that had not appeared locally. One user remediated his course’s slide decks with minimal concerns. Users also reported cases where outputs passed accessibility checkers but lost semantic equivalence.

5. Stage 5: Standards Conformance (April–May): Shifted validation from external syntax-style accessibility checkers to a custom, standards-grounded approach. Existing checkers ignore many semantic obligations of WCAG.

6. Stage 6: Hardening (May–June): The DOJ extended the deadline by one year [@doj2026adaComplianceExtension]. Project shifted from emergency deadline response to production hardening, incorporating more disciplined architecture and expanded tests.

4.2.2 Tools↩︎

As an AI tool, the Subject used Anthropic’s Claude. He used the “Claude for VSCode” plugin, interacting entirely through that chat interface. The Subject was responsible for goals, acceptance criteria, architectural direction, validation, and deployment decisions. Claude implemented.

The Subject inspected almost no agent-produced code. He deliberately departed from the oversight-centric model of agentic quality (2.2), under which high-velocity agentic development depends on continuous human inspection of agent-produced code. The case tested whether quality could be sustained without ongoing inspection (cf. 3).

4.2.3 Cost↩︎

The development cost was \(\sim\)$60K USD: $50K for the Subject’s salary (paid by research grants), $2K for inference (OpenAI API, Google Vertex), $6K for Google Cloud (SaaS hosting), and $2K for Claude subscriptions.²

4.2.4 System State↩︎

Currently, the system can process Office and PDF files to pass or substantially improve performance on accessibility checks. Slide decks for the Subject’s courses process in approximately 60 seconds, costing \(\sim\)$1 per deck.

5 Results↩︎

This section reports the empirical findings from the incident analysis. We first characterize the coded incident corpus to explain the analytic focus of the results (5.1). We give examples of the recurring failure-to-governance pattern (5.2), and describe the governance mechanisms that accumulated (5.3).

5.1 Incident-Level Coding↩︎

Our unit of analysis is the critical incident: an episode of failure, decision, acceleration, or reframing that the Subject felt salient to capture. 1 reports their distribution by class and category. Layer 1 (class) separates incidents that yield a software-engineering insight (engineering-reflection) from those concerning people, institutions, and the engineer’s experience (context-and-relational), and project chronology (temporal-narration). Layer 2 (category) names the locus of the insight. For example, for engineering reflection, categories include controls, architecture, and economics. For the primary class, engineering reflection, we subdivided categories into “process” and “product”. For control incidents, we recorded the resources each control made more governable. These incident codes anchored subsequent thematic analysis (6).

The corpus is dominated by engineering-reflection (72 of the 88 incidents). Its two largest categories name two ways the Subject made a recurring failure governable. Controls (35 incidents), i.e., checks such as lints, tests, validators, gates, and mediators, detect a failure once an agent commits it. Architecture (20 incidents), such as typed models, bounded seams, and closed vocabularies, eliminates the failure class by construction, so an agent can no longer express it.³ Together these categories are the analytic center of gravity of the study: 5.2 illustrates both modes, one architecture episode and one control episode, and 5.3 characterizes the resulting repertoire, which spans construction and detection.

5.2 Examples of Architecture and Control Incidents↩︎

Most engineering-reflection episodes show a repeated pattern. The Subject interpreted failures as structural problems rather than isolated defects, and made each failure class governable. He either changed the architecture so the failure class could no longer arise, or added a control to detect it.

We illustrate both with two linked incidents: the first eliminates a failure class by construction (architecture), the second detects failures earlier with a control.

5.2.1 Architecture: Modeling the system so enforcement can scale↩︎

The recurring failure class was architectural enforcement that did not scale with the codebase. The Subject initially relied on agents to check agent work, encoding the system’s structural invariants (e.g., which components may cross which boundaries) as agent briefs and running an “agent audit crew” to validate those properties. As the codebase grew, a whole-repository audit no longer fit an agent’s context, and audits were scoped by architectural “zone.” The audits were expensive and non-deterministic, and structural drift accumulated.

The resource at risk was architectural integrity: component boundaries and cross-cutting invariants eroded, and the enforcement mechanism grew more costly as the system it governed grew. The Subject interpreted this as a modeling problem, in the sense of model-based software engineering (MBSE). The architecture itself existed, but had no durable representation. The Subject therefore reified the audit zones through the mechanism of a typed component catalog, in which each zone became an object naming its filesystem scope, its boundary kind, and relevant checks. This architectural change converted agent-mediated audit into deterministic enforcement. At first, the component model scoped the audit crew’s sweeps. Then, zone by zone, the audit crew was replaced by static and dynamic analyses using the model.

5.2.2 Control: Shifting left on failures via dynamic context injection↩︎

The recurring failure class was constraint under-specification at agent dispatch time. A coding agent lacked the Subject’s tacit knowledge of which lints, conventions, tests, and component boundaries applied to a target change. Agents therefore made plausible edits that violated those constraints. This created a throughput problem: agents eventually resolved their errors but wasted time and tokens doing so. The existence of a validation hierarchy (lightweight git precommit, medium merge check, strong deployment gates) exacerbated the problem, with context loss between authoring and repair.

The resource at risk was productive agent throughput: the time and tokens an agent spent discovering and repairing constraint violations it could have been told to avoid. The relevant context already existed in the repository, but it was distributed across component models, lint declarations, repair documentation, and project conventions. The engineering problem was to make that context selectable and inject it before work began. The Subject installed a new mechanism: the dynamic context injection control. Building on the repository’s system models, the Subject designed a dispatch-time constraint slicing mechanism to map a change’s intended files to the precise constraints that govern them, and inserted that subset into the agent’s task brief before the agent edited code. This moved detection “left” of the cheapest traditional gate: rather than waiting for an agent to violate a lint and then repair the failure, the orchestrator briefed the agent on applicable rules.

5.3 The Governed Engineering Environment↩︎

As we saw in the example incidents 5.2, the Subject repeatedly introduced mechanisms to provide governance. We catalogued ten distinct families of governance mechanisms from the incidents and repository records (2). To do this, we used the incident data to identify candidate mechanisms, then analyzed the repository’s governance substrate (e.g., the agent-legible system models and the static-analysis registry) to corroborate and categorize them. The same legibility that makes these mechanisms usable by agents also made it tractable to identify and categorize them for analysis.

Many mechanisms were layered. When a failure recurred across one mechanism, the Subject’s response was to add a complement. The deepest stack, 14 complementary mechanisms, accreted around high-frequency failure classes in Orchestrator/Sub-agent interactions. These defenses were tailored to the nature of the agents’ errors, and produced a belt-and-suspenders governed engineering environment.

The governed environment is large relative to the product. The catalog records 41 representative mechanisms across ten families. Measured by source size, the support apparatus comprises 1.16 MLOC, or 2.75\(\times\) the production code — static and dynamic analyses (238 KLOC and 405 KLOC, respectively), agent-referenced documentation (247 KLOC), agent infrastructure (110 KLOC), and tooling (162 KLOC). The static-analysis controls include custom and standard checks: 577 project-specific analyses supported by commodity analyzers provided through community rules for Roslyn/.NET, Pyright/Python, and ESLint/TypeScript. For dynamic analysis, there are over 13,000 C# test methods and roughly 1,500 Python test files, including more than 300 property-based tests and 90 fuzz harnesses. These mechanisms enforce quality without the Subject’s implementation-level oversight.

6 A Middle-Range Theory of Governance Conversion in Agentic Software Engineering↩︎

This section synthesizes the case into a candidate middle-range process theory of governance conversion: a process by which sustained agentic velocity becomes governable software-engineering progress.

6.1 Middle-Range Theory↩︎

We frame our synthesis as a middle-range theory [@merton1968social], i.e., an explanation somewhere in the “middle” between a working hypothesis and an all-encompassing general theory of software engineering. Much engineering knowledge has this character. Brooks’s Law [@brooks1995mythical], Conway’s Law [@conway1968committees], Hyrum’s Law [@winters2020software], and Cunningham’s technical-debt metaphor [@cunningham2009debtmetaphor] all emerged from expert interpretation of situated experience [@schon2017reflective]. We do not assert prevalence from one case. We propose a process with its constructs and relationships so that researchers can test its boundary conditions (6.3), tool builders can design for it, and practitioners can be trained in it (7).

6.2 The Theory: Cheap Code, Costly Judgment↩︎

6.2.1 Empirical Grounding↩︎

This theory is the engineering framing of our thematic analysis of the corpus. We identified thirteen cross-incident themes, grouped into four clusters. Three clusters directly ground the theory: abundant implementation but scarce judgment grounds the human judgment thesis; governance relocated to the substrate grounds the engineering governance thesis and conversion loop; and engineering an agent-legible system grounds the governance-substrate construct and capability-fit moderator. The fourth cluster, the reflexive build and the evolving engineer, characterizes the study’s first-person method. That cluster informed our Method rather than the theory.

6.2.2 Theory↩︎

4 maps the theory we induced: the process ([fig:theory:mechanism]), constructs and scope ([fig:theory:constructs]), propositions and moderators ([fig:theory:propositions]), and indicators and outcomes ([fig:theory:indicators]). We do not claim it is universal, but we assert it captures a distinct and useful perspective.

6.2.3 The Cheap-Code, Costly-Judgment Loop↩︎

As implementation becomes abundant, judgment becomes relatively scarce. The relevant judgment is not only whether an agent-produced change is acceptable, but whether a failure reveals missing governance. Engineers must decide what and how to build, interpret failures, and design the governance under which fast code can be trusted. The process is a loop ([fig:theory:mechanism], cf. 3): velocity exposes a failure class, the architect classifies it as local or structural, structural failures convert into governance, and subsequent agents inherit a narrower action space. The loop is non-terminating, as increasing velocity surfaces failure classes prior governance did not address. The governed engineering environment emerges iteratively, shaped by joint human-agent capability.

6.2.4 Two Dual Theses↩︎

The loop yields two linked theses.

(a) The engineering governance thesis: Agentic velocity is possible, but is sustainable only when governance is relocated into the engineering environment rather than resting on human review. Under agentic velocity governance must become machine-actionable enough to shape agent work lest human review become the bottleneck.

In the case, we observed that weak forms of governance fail with project and agent scale. The Subject’s environment does encode “soft” probabilistic controls, such as templates that an Orchestrator should follow when preparing agent briefs and work Epics. But it was necessary to mate these to deterministic controls, such as typed enumerations the compiler checks and static and dynamic analyses gating commits. At velocity, a low-probability agent harness violation becomes a certainty. Perhaps counterintuitively, stronger controls do not always tax agentic velocity; they can compound it. (b) The human judgment thesis: When implementation becomes abundant, human work shifts toward problem framing, abstraction discovery, architectural judgment, and governance [@thawar2026whatjobnow]. Better agents make this work more consequential, not less, because these decisions determine whether throughput becomes durable progress or churn. On this, the Subject wrote: “Now I feel like an engineer, and more than an engineer.”

Governance does not design itself. Each element required Subject to distinguish local defects from structural failures and propose an intervention. Two moderators bound this thesis ([fig:theory:propositions]): capability-fit, as agents must be matched with suitable human judgment, and authority, as the human must be able to alter the engineering environment.

Synthesis.Together, the theses are duals: governance makes velocity sustainable, and judgment determines which governance should exist. Agents’ current implementation capabilities do not supply the structural interpretation needed to convert recurring failures into durable governance.

6.3 Testable Propositions from the Theory↩︎

Because this study is theory-building rather than theory-testing, we describe candidate constructs and relationships but do not estimate their prevalence or effect sizes. To make the theory empirically accountable, we articulate falsifiable propositions for future work [@popper2012science] ([fig:theory:indicators]), including:

Does velocity expose structure? Higher agentic velocity should surface a structural failure class in fewer calendar days than lower-velocity development. Repository mining across projects of varying throughput could measure the lag from a class’s first instance to its structural fix. The case grounds the premise but cannot parameterize velocity models. Do soft controls saturate? As agent velocity increases, review-based quality regimes should show rising escaped-defect rates while control-based regimes do not. Controlled experiments could establish this relationship. Does conversion compound? Teams that convert failures into deterministic controls should sustain velocity, and teams relying on inspection should not, as work repeats failures. A longitudinal comparison could test this, though note that we found compounding to be a tendency, not strict monotonicity. Do judgment and authority shape outcomes? Holding agent capability fixed, outcomes should depend on human judgment and on the authority to modify the environment, with structural failures persisting where engineers can only request local patches. This prediction might be most amenable to human factors methods such as interviews and surveys. Scope: These propositions pertain to agentic work on systems where correctness and maintainability matter ([fig:theory:constructs]).

7 Discussion↩︎

7.1 What Does our Theory of Governance Conversion Add?↩︎

7.1.1 Beyond ex-ante governance↩︎

Our study provides a worked example of governance-centric agentic software engineering, but also revises that model. Existing governance-centric accounts emphasize ex-ante governance: known obligations are identified in advance and translated into controls before agents act (2.2). The Subject did use ex-ante governance, such as WCAG 2.1 AA conformance checkers (\(\mathbf{R}_{\mathbf{2}}\)), content preservation and provenance for auditability (\(\mathbf{R}_{\mathbf{3}}\)), and commodity lints (e.g., pyright, ESLint). We found these controls necessary but not sufficient.

7.1.2 Failure as discovery↩︎

The theoretical delta is not simply that agent work needs controls. All approaches agree on that (2). The new claim is that, under agentic velocity, many necessary controls cannot be fully specified before work begins. The necessary controls are discovered through failure: agents make plausible but wrong changes. To sustain velocity, an engineer must interpret those changes as ambiguities, missing abstractions, underspecified interfaces, and coordination gaps, and convert them into new architecture and controls. Our theory of governance conversion extends governance-centric accounts from known-obligation enforcement to failure-induced control discovery.

7.1.3 Contrast with the Velocity and Oversight Models (2.2)↩︎

The velocity-centric view provides agents with soft guardrails. Our case suggests that without a stronger governed engineering environment, agent velocity will not yield progress. The oversight-centric view recommends that humans supervise agent changes. The Subject instead analyzed agent failures. Work that produced no failure signal was admitted; work that exposed a recurring failure class led to new governance. Our contribution is to describe this process mechanism: at velocity, engineering leverage comes from converting a failure mode once so that future instances of its class require less oversight.

7.2 Software Engineering is Old and New Again↩︎

7.2.1 Repertoire, not Recipe↩︎

The Subject’s high-velocity AI-mediated implementation depended on familiar methods, including requirements analysis, architecture, validation, infrastructure-as-code, documentation, and process control. What changed was where those methods had to reside. In conventional development, engineering discipline can remain tacit or social [@bjornson2008knowledge; @anandayuvaraj2026learning]. Under agentic velocity, the Subject’s engineering judgment became effective only when externalized into an agent-legible and machine-actionable governance substrate. In this sense, “conventional engineering” was enough, but only when converted into durable mechanisms that constrained subsequent agent work.

But if classical SE is enough, why not simply encode it into the ex-ante governance model? We suggest that both ex-ante and ex-post governance are needed. The Subject applied the lessons from this case as ex-ante governance on two subsequent projects (50 KLOC and 36 KLOC), obtaining faster initial progress. Even so, ex-post governance remained necessary: new failure modes appeared as each project and its development substrate evolved. The precise governance required therefore depends on the product, its trajectory, and the changing failure modes of the agents that act on it.

7.2.2 Agents Change the Marginal Cost of Quality↩︎

Agentic velocity reduced the cost of refactoring and architectural improvement, making quality-improving changes feasible at scales that would normally be deferred. In one incident, over two days the Subject refactored an entire web front-end to TypeScript (\(\sim\)​100 KLOC), with no defects observed under the project’s checks; and induced a type system supported by a lint for excessive primitive density. In another incident, agents surfaced related failures in dense succession, which would conventionally surface far apart in time. Their proximity allowed the Subject to perceive an architectural gap. He introduced a new system model enabling new static analyses, closing several classes of failures. The same speed that can cause agentic technical debt [@EhsaniDebt2026; @agarwal2026ai] can also make quality-improving changes more affordable and visible.

7.3 Implications for Software Engineering↩︎

Agentic tools compress team-scale coordination problems into individual workflows. In the case, a single human architect produced enough change through agents to require artifacts normally associated with team coordination, such as architectural models, task contracts, and staged incorporation. This compression makes authority central. Governance conversion requires the person who observes recurring failure to alter the engineering environment. In organizations, where authority may be divided across teams, owners, review boards, and deployment processes [@conway1968committees], the same failure signal may produce only local patches unless there is an organizational path for converting it into shared governance.

Our case suggests that the relevant productivity metric is governed throughput, not implementation volume (e.g.,“tokenmaxing”). Commits landed, lines changed, and agent tasks completed measure activity, but not whether that activity becomes durable progress. Organizations should therefore ask whether agent-produced failures are converted into reusable governance, and whether later work benefits from those conversions without degrading coherence.

7.4 GenAI Paradox: Agentic Velocity by Reduced Reasoning↩︎

Generative models are valuable because they operate over open-ended inputs, yet Subject’s method was to use governance to systematically reduce the opportunities for unconstrained reasoning. His method can be understood as a response to the long-horizon problem [@kwa2026measuring]. Software agents perform complex tasks [@jimenez2024swe], with a per-step probability of error [@sinha2025illusion]. The Subject’s response was not to exclude probabilistic model behavior, but to bound it: agents received soft guidance in their briefs, faced deterministic guardrails on their actions, and their outputs were admitted only through a deterministic control envelope.

A corollary concerns how engineers should read model failure. When a delegated task fails, the tempting inference is that the model is incapable of it. The case repeatedly suggests another interpretation: the task may not yet have been framed as an inspectable, controllable process. The Subject’s approach was, in one incident, to “assume that you are the problem”. We advance this as an engineering disposition: engineers must relocate the locus of difficulty from model competence to their own capacity to frame, decompose, and constrain.

7.5 Implications for Research and Education↩︎

The case demonstrates that current models change the cost calculus of software engineering. In the Subject’s expert hands, agents produced a deployed product at agentic speed. The research community should attend not only to raw agent capabilities on benchmarks, but also to changes in the surrounding software engineering process [@gao2025SELLMChallenges; @sarkar2025vibecoding]. Future research can treat human-agent interaction and the engineering substrate as first-class parts of the process. We know agents can generate. What engineering environments make that generation governable? Can agents discern inadequate governance, and would this improve with better architectural awareness [@peng2026beyond]?⁴ What tools help engineers distinguish local from structural defects?

As software agents commoditize implementation, our study points to a shift in the software engineer’s role toward architectural and contextual judgment [@sarkar2025vibecoding]. The Subject provided abstraction design, requirements clarification, validation, and process evolution. He inspected little agent-produced code, but his supervision depended on accumulated software-engineering knowledge about design, architecture, validation, and process. This interpretation is consistent with emerging discussions in software engineering education and workforce development, which similarly emphasize specification, validation, and AI use over syntax-level implementation [@kirova2024SEShouldAdaptLLM; @randall2024AISECurriculum].

8 Threats to Validity↩︎

8.1 Construct Validity↩︎

Our primary constructs were agentic governance and velocity. Governance is an emerging paradigm with under-determined constructs. We interpreted but did not measure this construct, rather offering an alternative view on the constructs and mechanisms that underpin it. For velocity, we reported conventional software metrics (2), but these are hard to interpret. Code is only a proxy for complexity, and documentation is a probabilistically executable agent constraint, blurring typical distinctions between code and documentation.

8.2 Internal Validity↩︎

This study examines a single Subject (N=1) using one agentic engineering toolchain. The resulting observations may reflect characteristics of the subject and the particular toolchain employed rather than universal properties of agentic software engineering. In addition, the Subject participated in the retrospective interpretation of development artifacts, introducing the possibility of selective memory and confirmation bias. Interpretive factors are mitigated by multi-author review (3).

A first-person method is both a strength and a limitation. It provides direct access to experiences and rationales that are invisible in other methods. It also risks selective memory, retrospective rationalization, and overinterpretation. We mitigated these risks by grounding the analysis in contemporaneous field notes, repository evidence, and with a critical author team.

8.3 External Validity↩︎

As discussed in [sec:sec:Method:Participant], the Subject possessed substantial prior software engineering experience. Whether comparable outcomes could be achieved by non-experts, domain specialists, or larger teams remains an open question. Future advances in model capabilities may alter the expertise requirements and coordination patterns identified here. Our theory deliberately frames the outcomes as mediated by human-agent capability fit, which should insulate it from incremental improvements in agent performance but not from substantial ones. This case study should be interpreted as characterizing contemporary agentic software engineering.

The case involved a one-subject development process, not a conventional software team. Large organizations introduce additional coordination problems, including ownership boundaries, divided authority and decision-making hierarchies, and regulatory requirements, handoffs, and review obligations. We therefore expect the mechanism of governance conversion to remain relevant in teams, but its realization would likely require organizational processes for assigning authority, resolving conflicting judgments, and incorporating new controls into shared engineering infrastructure.

9 Research Ethics↩︎

This study involved self-experimentation by an author (Subject). Sustained agentic development was harmful: obsessive tool use caused degraded attention to personal relationships and physical strain from prolonged work sessions. High-velocity agentic tools make extreme work patterns practically sustainable for longer than is healthy.

10 Conclusion↩︎

This case study provides a view on the changing nature of software engineering in the agentic era. In industry and the academic literature, it is unclear whether and how agentic velocity can be governably sustained. Our study suggests an answer: Agentic velocity can be sustained when agents operate within a governed engineering environment, and the achievable velocity depends on the maturity of the governance. We present a candidate middle-range theory articulating the relevant constructs and mechanisms. Our theory is cheap code, costly judgment — the future of software engineering lies in judgment that informs product direction and becomes embodied in the architecture and controls necessary for agents to make progress. The research community is at an early stage of characterizing agentic software engineering. Public, long-running accounts of the process by which human judgment and AI capability interact in real engineering work are the basis from which mature theory can be built.

---

1. The reason may be cost: communication with university acquisition staff indicates pricing of \(\sim\)$3 per page or slide, or $10-15K for a semester-long course’s slides and readings; universities have thousands of courses.↩︎

2. The Subject saturated between two and four Claude Max 20x accounts each week. Anthropic has opaque usage data [@anthropic2026UsageLimitBestPractices], but estimates [@tbuckworth2026ClaudeCodeMax20xLimits] suggest this project consumed 9–18M tokens per week during the study period.↩︎

3. Some mechanisms involve both elements, and these were coded by their primary function. For example, a typed model with lint support for violations.↩︎

4. In the case, Claude did not initially offer governance responses, but began suggesting plausible interventions as the codebase accumulated examples.↩︎