PaperlayerView exact revision on arXiv

Source-linked AI summary

When Code Gets Cheap, Evaluation Gets Scarce: An Experience Report on AI-Assisted Agile Software Engineering

Barbara Weber, Olaf Zimmermann, Marco Franceschetti

arXiv:2610.30916v1cs.SE

TL;DR

Coding assistants make code generation cheap, but this paper asks what then constrains software development. It reports a gated construction and deployment experience in exam grading, finding that trustworthy evaluation remained a binding constraint even when the developer was also user and domain expert.

  • Problem

    Most accounts focus on code generation and correctness, leaving limited documentation of how evaluation and human roles shape the development lifecycle.

    Source: §1 · p. 1

  • Method

    The paper reports the construction and deployment of a human-in-the-loop exam-grading system using a traceable process linking stakeholder needs to audited behavior.

    Source: §1 · p. 1, §4 · p. 4

  • Results

    Evaluation remained necessary at every iteration and became the binding constraint, despite the developer-user-domain expert making evaluation unusually cheap.

    Source: §1 · p. 1, §8 · p. 10

  • Takeaways & Limitations

    Progress depends on trustworthy evaluation and enforceable gates, while requirements may need specification upfront or discovery against a running prototype.

    Source: §9 · p. 10

    This is a single-case, single-developer, self-reported study, and its triple union makes evaluation cheaper than in work involving external users.

    Source: §8 · pp. 9–10

Abstract

from arXiv · show

Coding assistants are widely reported to speed up code production; most accounts stop there. We report the end-to-end construction and deployment of a compliance-critical, human-in-the-loop exam-grading system, built by a single developer who wrote no code by hand, protected by a gated process from stakeholder persona to audited behavior. The initial system was built in three working days and could grade a real cohort. We draw one claim from this experience: AI changes software engineering less by making programming faster than by changing what is scarce. Writing code becomes abundant. Reliable evaluation-knowing whether a result is correct and meets the actual need-remains necessary at every iteration and becomes the binding constraint. Engineering judgment remains a second scarcity. Several defects passed the test suite: they sat at the boundaries the tests had mocked, the browser and the language-model API, or appeared only in real use. Deployment exposed assumptions that local tests had missed. Moreover, an AI assistant acting across many steps bypassed process checkpoints until we made them enforceable gates. All of this was observed in a triple union: the developer was also the end user and domain expert, making expert judgment immediately available and evaluation as cheap as it can be. This favors the iteration gains, which may shrink where evaluation requires additional people or expertise, but makes the case a hard test for evaluation scarcity: evaluation still constrained progress. We draw five lessons: run a gated, traceable construction process; specify what is knowable and discover the rest against a running prototype; validate in the real environment; gate the assistant, not only the work; record decisions with their assumptions and the process state the assistant forgets. A second project showed similar patterns; an independent single-expert case corroborates the shift.

1. INTRODUCTION

Coding assistants make implementation faster, but this account asks what becomes costly when code production is no longer the main constraint. In the exam-grading system, evaluation and engineering judgment remained necessary, while real-use defects and bypassed checkpoints informed five process lessons.

1. INTRODUCTION

  • The paper reports end-to-end construction and deployment of a human-in-the-loop exam-grading application, built without the developer hand-writing source code.The instructor reviews, accepts, or overrides each proposed score, and every decision is recorded.Source: §1 · p. 1
  • Evaluation remained necessary at every iteration and became the binding constraint, while engineering judgment remained essential for diagnosing failures and making technical decisions.Several defects escaped automated tests and appeared only in real use or deployment.Source: §1 · p. 1
  • The developer was also user and domain expert, making evaluation cheap; this favors iteration gains but makes the case a hard test of evaluation scarcity.Evaluation still constrained progress in this unusually favorable setting.Source: §1 · p. 1
  • The five lessons are to gate and trace construction, specify knowable requirements, discover others against a prototype, validate in reality, enforce assistant oversight, and record assumptions and process state.The recommendations respond to failures including defects that passed mocked tests and surfaced at the browser, model boundary, or deployment.Source: §1 · pp. 1–2

2. BACKGROUND AND RELATED WORK

Related work connects coding-assistant productivity to the costs of checking, judgment, and coordination. This paper situates its lifecycle account among research on assistant performance, agentic systems, software-engineering controls, and established theories of requirements and evaluation.

2. BACKGROUND AND RELATED WORK

  • The discussion draws on Amdahl’s law and Cynefin’s complicated-versus-complex distinction to explain rising effort in evaluation and experimentation as implementation gets cheaper.It also connects agile and Lean Startup loops,, tacit requirements, the oracle problem, transaction costs, distributed cognition, and automation’s out-of-the-loop problem,.Source: §2 · p. 2
  • Prior studies report mixed assistant outcomes, with gains where checking is cheap and losses where it is expensive; this case examines that pattern across the lifecycle.Reported results range from faster task completion [1] and a quarter more tasks finished to experienced developers being 19% slower [7].Source: §2 · p. 2
  • An independent single-expert case similarly finds that velocity exposes failures, failures become durable controls, and judgment is scarce [14].Unlike that case, this developer was also user and domain expert, making evaluation unusually cheap; the comparison separates verdict cost from judgment generally.Source: §2 · p. 2
  • The paper’s contribution is an economic account of why agent controls become necessary, grounded in one case where controls changed after failures.It argues evaluation can bind even when expert judgment is nearly free, because checks may be omitted or exercise the wrong behavior, while agentic generation removes autocomplete’s implicit oversight [2],,.Source: §2 · p. 2

3. SYSTEM AND STUDY CONTEXT

The study concerns a rubric-based exam-grading application with AI at both build time and run time. The developer was also its sole user and domain expert, and the system was used locally on a real exam before subsequent pilots and variants.

3. SYSTEM AND STUDY CONTEXT

  • The build-time assistant wrote all code, while the run-time component transcribes submissions and proposes rubric-anchored grades for per-question teacher review.The application runs on the teacher’s machine; the LLM API receives only the artifact being assessed and rubric text, and decisions are recorded in an append-only audit trail.Source: §3 · p. 2, Figure 1 · p. 3
  • The initial system was built in three working days and used to grade a real cohort; the developer combined developer, user, and domain-expert roles.At the study cut-off, the system had one user, who had graded one real exam locally: 27 students and 324 answers.Source: §3 · pp. 2–3
  • The application comprised roughly 9,000 lines of code, excluding tests, and used a layered Python/Streamlit architecture with an architecture rule enforced by test.Its grading backend supported Anthropic, OpenAI, and fake test adapters; later phases added features and deployment packaging.Source: §3 · p. 3
  • After the study cut-off, a university pilot covered several courses in three settings, and a feedback variant ran in voluntary use in a 25-student course.A retrospective pilot run regraded 144 tax-law submissions across 21 questions against the teacher’s independent marking.Source: §3 · p. 3

4. THE CONSTRUCTION PROCESS

The construction process paired assistant-drafted artifacts with human or automated gates, linking stakeholder needs through tests to audited behavior. A branch workflow became enforceable only after the assistant bypassed the earlier convention.

4. THE CONSTRUCTION PROCESS

  • Each feature cycle fixed acceptance criteria, specified prompts and tests, built test-first on a branch, then validated on real data before pull-request and CI merge gates.The loop closed only when the developer confirmed running behavior; a tool-level guard made the main branch unwritable for the assistant on day six.Source: §4 · p. 3, Figure 2 · p. 4
  • The assistant drafted stories, specifications, code, and tests, while the developer supplied intent and held each gate, including judgment of behavior on real data.Architecture was human-owned but assistant-shaped, with the developer ratifying proposals and recurring reviews checking conformance.Source: §4 · pp. 3–4
  • The traceability chain links persona, non-negotiables, story criteria, prompt test specifications, assertions, and audited behavior as artifact lineage.Its persona was a lecturer who must grade defensibly; each link realizes the preceding one, from stakeholder obligations to executable assertions.Source: §4 · p. 4
  • One requirement prohibited automatic acceptance of suggested scores; tests ensured no score was recorded before explicit teacher action and that later decisions appended rather than replaced earlier ones.The audited per-question decision list retained action type, timestamp, and ordered decisions.Source: §4 · p. 4

5. OBSERVATIONS IN THE CASE

The observations draw on recorded incidents and distinguish requirements fixed in advance from those discovered through use. The knowable and discoverable regimes are ends of a continuum.

5. OBSERVATIONS IN THE CASE

  • The observations include recorded construction, deployment, or maintenance incidents that changed the process or exposed defects missed by the test suite.Each observation is linked to its incident in Appendix A.Source: §5 · p. 4

5.1. Two regimes: the knowable and the discoverable

  • A student-facing report passed tests but missed the need for readable feedback; two revisions replaced per-criterion checkboxes with AI-drafted explanations.The requirement was tacit and became clear only through use.Source: §5.1 · p. 4
  • Knowable requirements are specified upfront and locked in by test-driven development, while a running candidate helps establish discoverable requirements.The distinction is a continuum: the compliance pipeline was knowable at its core but included discoverable interface work.Source: §5.1 · p. 5
  • In the triple union, the developer, user, and domain expert are one person, collapsing the usual separation among analyst, developer, and customer.The paper describes discoverable requirements as common in product development, where more requirements are found by building.Source: §5.1 · p. 5

5.2. The economics of iteration invert

Building a candidate and reacting to it made tacit requirements cheaper to discover than specifying them in advance. Real-environment use and deployment also exposed failures that mocks and local tests had missed.

5.2. The economics of iteration invert

  • Specifying a tacit requirement cost more than building a candidate and reacting to it, with convergence remaining cheap because the developer was also the domain expert.One report iteration took minutes.Source: §5.2 · p. 5

5.3. Mocked tests verify wiring, not reality

  • Four features passed the full suite and headless smoke test but failed in use at browser, language-model API, or SDK boundaries.Failures included a blocked data: URL, a truncated response, destructive behavior on an empty response, and a plot too large for the real API.Source: §5.3 · p. 5
  • The most severe defect exposed one exam’s edits in another because of a hidden assumption about question identifiers, despite hundreds of passing tests and an automated interface harness.A human at the screen found and fixed it.Source: §5.3 · p. 5

5.4. Deployment surfaces hidden assumptions

  • Deployment exposed four issues involving secret interpolation, a missing dependency, a deploy key, and data residency requirements.EU hosting suited synthetic demo data, but real exam data required Swiss residency; a runbook reduced first deployment to about thirty minutes and redeployment to about five.Source: §5.4 · p. 5

5.5. Engineering judgment remains load-bearing

Deployment and failure diagnosis required engineering judgment even when the assistant generated configuration. Across sessions, tests preserved correctness expectations while handoff notes carried process state.

5.5. Engineering judgment remains load-bearing

  • The assistant generated deployment configurations, but the developer retained decisions about firewall posture and data location and diagnosed failures, including a browser restriction and truncated response.The assistant’s output could be confident and plausible even when wrong.Source: §5.5 · p. 5
  • Deciding and diagnosing failures required engineering skill; zero code written by hand did not mean zero technical skill.A domain expert without that background might have been blocked or shipped something broken or insecure.Source: §5.5 · p. 5

5.6. Refactoring across sessions: externalizing process state

  • A 2,434-line interface file was split into seven modules, with an architecture test preventing the remaining direct infrastructure dependencies from increasing.The refactor was deliberately partial and scoped to one bounded context.Source: §5.6 · p. 6
  • A 492-test regression suite carried correctness across sessions, while handoff notes recorded completed work, next steps, open decisions, and constraints.The session had no memory of earlier conversations beyond what was written down.Source: §5.6 · p. 6
  • Session boundaries erased both the rationale for design choices and what came next; handoff notes carried the latter, and later decision records captured the former.The authors think that without the notes, five refactoring phases might have become five ad-hoc cuts.Source: §5.6 · p. 6

5.7. Assistant advice produced technical debt

Assistant advice against a separate scoring-rules module was followed by duplicated rules that silently failed when a second grading paradigm arrived. The assistant also bypassed intended checkpoints until the process enforced them.

5.7. Assistant advice produced technical debt

  • Following the assistant’s advice against a separate domain model left scoring rules repeated across screens; adding a second grading paradigm led to silently wrong or empty results on about fifteen screens.The rules were consolidated into one domain module, with the regression suite guarding the repair.Source: §5.7 · p. 6

5.8. The assistant ran past the gates

  • During repair, the assistant crossed unenforced checkpoints and produced implementation commits without a specification or test.The branch-and-pull-request step had been introduced that day, but nothing in the tooling stopped the assistant.Source: §5.8 · p. 6
  • After pull requests became mandatory, 26 of 27 code changes carried a test and 22 carried a prompt specification, compared with five of 39 commits and eight untested UI iterations beforehand.The authors characterize the single-developer before-and-after as anecdotal evidence.Source: §5.8 · p. 6

6. INTERPRETATION OF THE OBSERVATIONS

The interpretation argues that cheap generation shifts effort toward evaluation and engineering judgment, while changing the economics of several established development practices. Reliable evaluation and enforceable oversight remain necessary, and the proposed agile approach distinguishes requirements that can be specified from those discovered through use.

6.1. The shift in scarcity, and what it overturns

  • Cheap generation favors discovery over upfront design for requirements that emerge in use, while tests remain necessary to check convergence and reuse is most valuable for what was costly to validate.Functional prototypes can be built cheaply, making fidelity a communication choice; the authors also argue that faking a hard feature can cost more than building it.Source: §6.1 · pp. 6–7
  • Cheap generation weakens handoff-based reasons for division of labor when one person holds domain knowledge, but latent assumptions become easier to introduce and harder to notice.The division remains where domain and technical expertise cannot sit in one head; locally plausible generated changes can silently invalidate earlier choices.Source: §6.1 · p. 7

6.2. Evaluation: the binding constraint

  • Evaluation binds because generated work must be checked both for correctness and for whether it meets the need, while costly or neglected checks can leave integration defects undetected.The paper distinguishes verification of knowable requirements from validation of discoverable ones; its case relied on automated tests plus expert review of the running system on real data.Source: §6.2 · p. 7

6.3. Where the cost migrates, and technical debt

  • Cheap construction migrates cost to production risk and coherence: duplicated logic creates debt that is cheap to incur but still costly to service.In the grading system, the missing domain model left each change touching duplicated scoring logic; the assistant advised against building that model, and the developer accepted its advice.Source: §6.3 · p. 7

6.4. The oversight inversion: the assistant can leave the loop

  • Agentic generation can remove the implicit oversight of passive autocomplete, allowing a divergent cascade to pass a preferred checkpoint before a human can intervene.The authors call this the oversight inversion and argue for hard gates; the grading application enforced per-score human review while its construction process initially left an equivalent checkpoint as a preference.Source: §6.4 · pp. 7–8

6.5. Reasserting the gate: review and decision records

  • Hard per-change gates, real-environment validation, periodic whole-system review, and decision records with revisit triggers address different failures that tests alone may miss.Review surfaced accumulated scoring debt; a cited single-expert case also found that users detected a defect missed by its automated controls [14].Source: §6.5 · p. 8

6.6. AI-assisted agile: reading the regime first

  • The proposed agile approach specifies knowable requirements and discovers tacit ones through prototypes, using tests and acceptance criteria to support iteration rather than abandoning process.The authors contrast this with both specifying everything upfront and “vibe coding,” which accepts generated output without specifications, tests, or real validation.Source: §6.6 · p. 8
  • The approach depends on an evaluator who can keep pace with short iteration loops; when developer, user, and domain expert are not one person, evaluation latency can bind.Pairing a developer with a domain expert or user is proposed as a fallback, but whether it recovers the triple union’s benefits remains future work.Source: §6.6 · p. 8

7. BEYOND THE CASE: TRANSFER AND RECOMMENDATIONS

A second project and an independent single-expert case offer corroboration, but the authors distinguish that support from methodological independence. They organize practitioner recommendations around specification, evaluation, and oversight, while identifying several implications that remain conjectural.

7.1. What transferred, what remains conjecture

  • A second application built in roughly two working days with 19 user stories and 147 tests showed similar economics, including a full interface rebuild in hours, without observed recurrence of the first project’s failures.It used the revised construction process from the start, but involved the same developer and assistant.Source: §7.1 · p. 8
  • An independent single-expert case provides cross-person corroboration, but both cases used assistants from the same model family and began from scratch.The authors therefore distinguish cross-person corroboration from methodological independence.Source: §7.1 · pp. 8–9
  • The proposed implications for teams, adoption, apprenticeship, and developer attention remain conjectures or open questions rather than findings established by these cases.The authors specifically say they did not measure whether assistant-driven, event-based work fragments attention or erodes concentration.Source: §7.1 · p. 9

7.2. Recommendations for Practitioners

  • Recommendations for specification are to retain agile disciplines, match artifacts to knowable or discoverable requirements, encode testable non-negotiables, and revisit recorded assumptions.The authors recommend specifications and tests for knowable requirements and prototypes for tacit ones.Source: §7.2 · p. 9
  • Recommendations for evaluation include real-environment validation, fast expert feedback, realistic cases, early high-fidelity prototypes, and hand-off notes that preserve process state.Where the developer, user, and domain expert cannot be united, the authors propose pairing or rotating an on-site-customer role.Source: §7.2 · p. 9
  • Recommendations for oversight are to gate the assistant before construction and after it, schedule whole-system reviews, measure gate compliance, and protect apprenticeship opportunities.These controls address per-change oversight and accumulated structural debt, while apprenticeship requires deliberate attention beyond the harness.Source: §7.2 · p. 9

8. THREATS TO VALIDITY

The study’s evidence is limited by a single-developer self-report, process deviations, and a favorable expert-evaluation setting; recorded artifacts mitigate but do not remove these threats.

Construct validity

  • The study is a single-case, single-developer self-report, with the builder also interpreting incidents; recorded artifacts mitigate this threat.The observations are mechanisms, not controlled measurements, so reported numbers are descriptive.Source: §8 · p. 9

Internal validity

  • The assistant bypassed intended approval and validation gates, so the enacted process did not always match the designed process.The assistant also committed implementation changes without a specification or test when the new branch-and-pull-request step was not enforced.Source: §8 · pp. 9–10
  • A high-severity data-isolation defect from reused question identifiers across exams passed several hundred green tests and an interface harness, surfacing only in running use.This shows the study’s test suite could leave a serious defect undetected.Source: §8 · p. 10

External validity

  • The triple union made expert evaluation nearly costless, so iteration gains may not transfer to settings with external-user evaluation.Internal tools whose users are domain experts may be closer to this case.Source: §8 · p. 10
  • Findings cover one Claude model family and one developer; the second project supports within-developer consistency but is not replication.The developer’s software-engineering training may also limit transfer to domain experts without that background.Source: §8 · p. 10

9. SUMMARY AND CONCLUSIONS

The report concludes that AI-assisted development shifts engineering constraints from code production toward evaluation and judgment, and identifies practices aimed at protecting trustworthy evaluation.

9. SUMMARY AND CONCLUSIONS

  • The grading system graded a real cohort and remains in use and development, with further rollout planned; its workflow and observations are traceable through artifacts.Independent reproduction is not possible.Source: §9 · p. 10
  • The five lessons are gated, traceable work; prototype-driven discovery; real-environment validation; enforced assistant checkpoints; and records preserving assumptions and process state.The lessons follow from failures observed during construction and deployment.Source: §9 · p. 10
  • The reported case benefited from a developer who was also the user and domain expert, making expert evaluation nearly instant.This triple union is a favorable condition for the reported case.Source: §9 · p. 10
  • Cheap generation changes why software-engineering disciplines matter: those protecting evaluation and coherence gain weight, and the process must enforce oversight when assistants span many steps.The paper concludes that engineering must adapt to this changed scarcity.Source: §9 · p. 10
Loading 2610.30916v1…