Elements of Scalable Web Development

Chapter 2

How can coding agents support scalable development?#

Created
Updated

Coding agents increase the rate at which requirements become candidate implementations. Development scales when people can understand, validate, integrate, and maintain those changes as the project evolves.

2.1 What is an agent?#

In classical AI, an agent observes an environment, chooses an action, and uses its effects to decide what to do next. The model applies both to physical robots and to programs acting in information environments (Poole & Mackworth, 2023).

In this book, a coding agent repeatedly observes a development environment and acts through tools to pursue a requested outcome. LLM practitioners vary in whether predefined workflows count as agents; this book uses the model-directed action loop as its working definition. Its Large Language Model (LLM) operates inside an agent harness that assembles context, exposes tools, carries state, invokes the model, and returns action results as feedback. Software-engineering agent research describes related perception, memory, and action modules around the LLM (Wang et al., 2025).

The table below shows the parts a developer can tune.

Table 2.1. Parts of a coding agent and the development choices that shape them. #
Agent concept Coding agent What to tune
Goal Requested outcome and acceptance criteria Task examples, priorities, budgets, and stopping rules
Environment Repository, terminal, browser, and services Workspace setup, sandbox, and available services
Perception Instructions, file reads, tool output, and images Retrieval, provenance, and feedback quality
Controller LLM and its observe–decide–act loop Model configuration, context assembly, and orchestration
Memory Session state and durable project knowledge Selection, freshness, retention, and source authority
Actions Edits, commands, API calls, and messages Permissions, validation, rollback, and rate limits

Observations can be incomplete, tools can fail, and the stated goal can omit something the user needs. Improving an agent therefore involves its environment and feedback as well as its model and prompt.

2.2 What changes when agents implement code?#

Specifications, executable tests, and iterative feedback predate coding agents. The change is that a probabilistic tool-using system can perform more of the implementation loop. The table below compares three composable patterns, not stages in a maturity ladder.

Table 2.2. Three development patterns that can coexist in one project. #
Pattern How implementation proceeds Where control lives
Human implementation People translate requirements into code through planned stages or short iterations Design decisions, executable examples, and review
Deterministic generation Generators transform declared models into implementation artifacts Model definitions, transformation rules, and supported escape paths
Agent execution A model interprets context and chooses tool actions through a harness Maintained instructions, scoped tools, checks, and acceptance decisions

Iterative development, model-driven generation, and executable behavior examples can all contribute to an agent-assisted workflow. The event tracker could use BDD scenarios to define acceptance, generate an API client from a schema, and delegate implementation to an agent. Across these patterns, a requested outcome still has to become a checked change someone can maintain.

2.3 Loop engineering#

Loop engineering is the design of control structures that repeatedly direct agent work toward a declared goal, using observations, retained state, bounded actions and resources, and explicit acceptance, stopping, and escalation rules. A feedback loop describes how effects influence subsequent behavior. An agent harness runs the model-and-tool cycle; a project harness supplies maintained project knowledge and checks. Loop engineering connects these controls to decisions about starting work, continuing after an observation, retaining progress, and returning a result for acceptance.

Osmani's practitioner account and IBM's industry explainer frame the practice around systems that direct agent work with less repeated human prompting (Osmani, 2026; Belcic & Stryker, 2026). An exploratory research preprint uses a narrower definition requiring scheduled or event-triggered recurring runs (Lulla et al., 2026). Here, the term also covers bounded goal-driven iteration within a session, with people participating in feedback and acceptance. Schedules and fleets are optional choices; neither establishes that a loop is useful.

For each loop, name its trigger, goal, allowed actions, state owner, evidence, resource budget, and conditions for success, unsuccessful termination, or human escalation. Retained progress should distinguish attempted work from verified outcomes so another iteration does not silently repeat a failed approach or treat an unchecked patch as complete. The research discussion in Appendix A separates adoption evidence from experiments on refinement and repair.

2.3.1 Constrain, generate, validate, revise#

Agentic development follows a repeated loop: constrain the task, generate a candidate, validate it, and revise both the result and the project's durable knowledge. This is a corrective feedback loop: evidence of a deviation informs the next revision. Feedback can also reinforce a change, as when timeouts trigger retries that increase load and cause more timeouts; the Scaling chapter examines that case. Useful throughput is accepted change: work that someone can explain, validate against the intended behavior and architecture, integrate, and remain willing to own.

For the event tracker, consider adding CSV export. The task must settle which events are included, which fields may leave the application, and how the exported values are checked. A working download button alone leaves those decisions unresolved.

The table below identifies the evidence needed to advance each stage.

Table 2.3. The constrain–generate–validate–revise loop and the evidence that advances each stage. #
Stage Governing question Main action Exit evidence
Constrain What outcome is wanted, and what may vary? State the goal, context, boundaries, budget, and stopping or escalation rule A bounded task and explicit acceptance criteria
Generate Which candidate might satisfy those limits? Let a chosen model and agent harness act with relevant context and tools A candidate artifact plus its trace, cost, and attempts
Validate Does the candidate satisfy the real need? Apply independent checks and inspect the artifact a user will consume Acceptance evidence and known unverified properties
Revise What should change before the next attempt? Correct the result and codify learning in durable project material An improved artifact and better starting constraints

Constrain. State the outcome, relevant context, allowed variation, budget, forbidden effects, acceptance criteria, and escalation rule. Preserve recurring constraints in project instructions such as AGENTS.md. Treat initial requirements as hypotheses that interaction with a prototype may refine (Brooks, 1987). Programming also builds the understanding needed to explain and change the system (Naur, 1985).

Generate. Choose the model and harness using evidence from representative work. Runtime configuration, context, tools, hardware, routing, and fallback can change the outcome, cost, and data exposure. Appendix A explains how to identify the configuration that actually served a task. Focused retrieval can reduce irrelevant context, but lossy views can hide decisive facts; keep important raw output retrievable and test the reduction policy.

Validate. Check the candidate against the intended behavior and inspect the artifact the user will consume. The Webernetes case compares behavior with an independent implementation; Slideotter checks geometry and rendered output. Agent-generated checks need scrutiny too. In one workshop report, screenshot tests did not exercise the application, supposed passkey authentication accepted a username, and stored data disappeared after restart (Talwar, 2026). Those failures suggest concrete checks: launch the real application, challenge authentication, and verify persistence across restart.

Two recent preprints distinguish tests that miss a defect from tests that preserve it. In a coverage-guided regression-testing study, some generated tests passed an implementation with a seeded fault and failed the reference implementation: the assertion encoded the faulty behavior (Charoosaei et al., 2026). The study selected artificial faults that survived existing tests and rewarded generated tests for passing the faulty implementation; its results do not estimate how often production bugs are preserved by all test-generation methods. TestSuiteBench instead generated tests from detailed specifications and found valid tests that missed targeted defects, including a multiple-file requirement tested with only one file (Egashira et al., 2026). A test can therefore have a wrong expectation or an expectation that never distinguishes the defect. Inspect both what it asserts and which wrong behavior it rejects.

A reversible mutation can strengthen this relationship by checking that a test distinguishes the accepted implementation from one named fault. That contrast does not prove the mutant is realistic or the broader requirement is satisfied, but it is stronger than coverage alone. Tests must also tolerate correct changes. Bromley (2026) illustrates generated tests that copy implementation logic or accept either outcome; a complementary check is whether the same tests accept a behavior-preserving refactor. The concern-directed mutation lab lets you apply both checks to authorization, retry, or archived-state behavior: pass the baseline, fail the selected fault, and pass a variant that stores the events differently. Open concern-directed-mutation/README.md in the course workspace, or study its source.

Revise. Correct the candidate and preserve the lesson in requirements, tests, architectural decisions, or project instructions. The next attempt should begin with better information about the failure.

2.3.2 Engineer the verification loop#

In a practitioner essay, Osmani (2026) emphasizes giving agents executable feedback during implementation. Verification is one part of loop engineering: decide what evidence justifies accepting the result.

For CSV export, observing a download establishes less than inspecting its rows against the permitted events and fields. An agent that writes both the exporter and its checks can repeat the same mistaken access rule in both. Ground expected results in the agreed contract and ask which plausible wrong outcome each check would reject. Keep failures reproducible, use focused checks during repair, and run broader checks before integration.

Passing checks still leaves ownership, dependency boundaries, and future change costs to review. Judge a loop improvement by accepted behavior and the correction effort it requires, including failed attempts. Appendix A develops check selection, failure preservation, and the limits of the evidence.

2.3.3 Field note — A predicate that matched the wrong row#

Jepsen's ParticleDB evaluation supplies a concrete example of checking behavior independently (Kingsbury, 2026). The following adapts its small SQL reproduction:

CREATE TABLE records (id int PRIMARY KEY, value int);
INSERT INTO records VALUES (4, 5), (5, 6);
SELECT * FROM records WHERE 4 = 5;

The predicate is false, so the expected result is no rows. ParticleDB versions 1.1.4 through 1.1.17 instead treated this equality as a primary-key lookup and returned the row (5, 6); the report records the defect as fixed by 1.1.18.4. Jepsen generated SQL, compared ParticleDB with PostgreSQL, and reduced disagreements to small examples, while distinguishing genuine defects from permissible semantic differences. This was a single-node evaluation, so the example establishes a version-specific query defect rather than a finding about replication. An assertion copied from the faulty query result would preserve the error; the independently justified empty result exposes it.

2.3.4 Constraint feedback through an actual export#

Consider this authored candidate for exporting an event whose title is Build, measure, learn and location is Main hall:

title,location
Build, measure, learn,Main hall

It looks readable, but a CSV reader sees four fields in the data row instead of two. Quoting the title as "Build, measure, learn" addresses this case; it does not establish correct handling of quotation marks, line breaks, filtering or empty results. Write the expected fields before asking a model to repair the serializer, then check the downloaded bytes independently. An instruction to preserve those fields is a requirement, not evidence that the generated code satisfies it.

For optional practice, download the course workspace and open csv-export/README.md. Its working page supplies filtering and download handling; TASK.md scopes the missing serialization function and the supplied checks retain their own expected values. Give the task to your own permitted model, preserve the first failed check, inspect a real filtered download, and revise the specification or agent context before another attempt. Keep consequential decisions in your existing ADR approach. This replaces an existing practice activity within the agreed study time; it adds no grading criterion or separate submission. If setup or model access is unavailable, inspect the example above and specify the independent checks; record that implementation has not been exercised.

2.4 Assign authority and ownership#

At each stage of the loop, make action authorization explicit: decide who may act, which evidence permits the next step, and who owns the result. For each decision, an agent may propose an option, prepare an action for approval, or execute within explicit limits. Ambiguous intent, weak evidence, irreversible commitments, and material external effects should narrow that authority.

For the CSV export, an agent might propose fields, implement the agreed format, and run checks; the accepting person still decides whether the exported data and access rules meet the requirement. The Agent Fleets chapter extends this allocation across delegated tasks.

The table below separates the records needed to explain and stand behind that change.

Table 2.4. Questions that separate an artifact's origin, endorsement, accountability, and evidence. #
Concept Question it answers Record to preserve Does not prove
Provenance Which exact revision or artifact is this, and which inputs, people, and tools produced or transformed it? Artifact identity, revision, material inputs, actors, and tools That the artifact is correct
Endorsement Who stands behind which claim or decision on the final revision, including any reservations? Named endorser, endorsed claim, scope, revision, and reservations That every property was checked
Accountability Who owns the consequences and must correct, maintain, or retire the result if it becomes wrong or outdated? Accountable owner and correction or retirement obligation That the owner produced the artifact
Evidence Which properties were checked on that revision, under what conditions, and what remains unverified? Check, environment, result, revision, limits, and omissions Universal quality outside those checks

Bind acceptance decisions, checks, and known limits to the revision they concern. Perceived effort can influence quality judgments (Kruger et al., 2004), but time spent does not establish correctness.

2.4.1 Sustainable throughput requires ownership#

The ownership standard should follow the work's consequences and expected lifetime. A disposable experiment may need little maintenance; shared code makes others inherit the cost of understanding, operating, and correcting it—what Cory Doctorow calls accretive work. Publishing an issue or patch also creates work for an external maintainer, so someone must own the claim and respond when it is wrong.

Sustainability angle

Count the cost of repeated generation, validation, and human correction alongside accepted changes. Smaller tasks and maintained project guidance are useful when they reduce rework without weakening the checks.

2.4.2 Optional exercise — Move a prototype into shared use#

What would turn a working demo into a tool someone can operate and own? Give your agent the prototype starting point to investigate one decision at a time, or read the scenario yourself.

2.5 Agent harnesses and workspaces#

The agent harness controls a model's context and tool loop. A development workspace can sit around one or more harnesses, helping a person start sessions, inspect changes, answer questions, and move between machines. Some products also supply the execution runtime or coordinate delegated work. Identify which responsibilities a tool owns before attributing its behavior to the model.

The table below compares examples from product documentation checked on November 3, 2026. These descriptions identify useful capabilities to investigate; they are not comparative measurements of productivity or reliability.

Table 2.5. Examples of interfaces, runtimes, and orchestration around coding agents; documented capabilities as of November 3, 2026. #
Example Responsibility illustrated
Herdr Runs persistent terminals with local or SSH-connected access through herdr-core and its native app; the original Herdr TUI uses a separate server.
T3 Code Presents several coding-agent harnesses through one interface, with per-thread branches, inline diff review, and commit/push/pull-request actions using existing accounts.
OpenChamber Provides a visual workspace around OpenCode, including parallel model runs and diff walkthroughs; it starts or connects to an OpenCode server.
Sesh Brings persistent sessions on paired machines into one interface and surfaces questions and approvals across desktop and mobile clients.
OpenHands Agent Canvas Separates the user interface from Agent Server/SDK execution backends and an Automation Server for scheduled or event-driven work.

Persistence needs a precise failure boundary. Closing a client can leave work running on an awake host; host sleep, process failure, and machine restart are different events. For example, Herdr's native-app documentation says that closing the window leaves terminals running in herdr-core, but stopping that runtime or rebooting stops the programs; restored panes do not automatically resume the agents. The app and TUI have separate sessions, so their recovery claims cannot be used interchangeably.

Likewise, a branch names a development history, while a worktree gives work a separate checkout. Neither alone restricts a process's filesystem, credential, or network access. Check the selected execution backend and permissions, and trace whether cancellation and approval decisions reach the actual worker. An interface that gathers several agents in one place still needs a coordination rule for shared files, dependencies, and acceptance; the Agent Fleets chapter develops those decisions.

Choose a workspace around a concrete difficulty: losing sessions, switching between agents, finding blocked work, or understanding changes. Try one representative task and record the installed versions, where work and session state live, recovery after a client disconnect, and the effort required to inspect and accept the result. Count interruptions, failed attempts, and review effort alongside accepted outcomes. The repository's instructions and checks remain the project harness whichever interface presents them.

2.6 The project harness#

The project harness is the versioned material that lets humans and agents change a repository: instructions, specifications, architecture notes, setup, examples, and validation commands. Project harness is the book's working label for that bundle of repository guidance and executable development controls; harness terminology varies between sources. It supplies project knowledge to the agent harness introduced earlier.

Table 2.6. Three related control layers in agentic development. #
Term Scope What it includes Governing question
Agent harness One model-and-tool execution loop Context assembly, tools, state, permissions, model invocation, and action feedback How can the model observe, decide, and act?
Project harness One repository or maintained codebase Instructions, specifications, architecture notes, environments, commands, tests, rules, and examples How can a contributor change this project without hidden context?
Development system The process that changes an application People, agents, agent harnesses, project harnesses, review, integration, ownership, and organizational policy How does candidate work become accepted and maintainable change?

A useful project harness lets a new contributor clone the project, locate the relevant behavior, run the checks, and make a small change without oral rescue. The common project specification defines the required artifacts. vibe-template provides one example of keeping starter code, instructions, architecture rules, and validation together. The Friction chapter develops fresh-checkout validation and the choice between focused and broader checks.

An analysis of 3,864 public bug reports across Claude Code, Codex CLI, and Gemini CLI attributed 37.3% of root causes to API, integration, or configuration errors (Zhang et al., 2026). That sample cannot describe every agent failure, but it gives a reason to inspect tool contracts, commands, and configuration when improving the workflow.

2.6.1 Agents learn patterns from your codebase#

Accepted code also becomes context for later work. Robinson (2026) describes allowing duplicated authorization checks on the assumption that an agent could maintain them later; the agent instead copied those shortcuts into subsequent changes. Review whether a change leaves a pattern worth repeating, as well as whether its present behavior passes.

2.6.2 Bound probabilistic generation with deterministic controls#

Two agent runs may interpret a task differently while obeying the same state transitions, permissions, and acceptance rules. David Khourshid's Beyond the Prompt talk proposes letting an LLM choose among the events a deterministic state machine currently permits. The demonstration applies that pattern to delivering a code change.

Deterministic boundary lab

Limit the agent to valid transitions

Goal: ship a safe change The agent can choose only events enabled by the statechart.

Agent choices

One goal can produce different valid routes through the model.

Current state active.planning
Available next events

Predict whether RELEASE will be accepted. A rejected proposal leaves the state unchanged.

Statechart rules XState v5 + ELK

Hierarchy shares rules; parallel regions represent simultaneous facts.

Change delivery statechart Planning leads to implementation and parallel verification. Failed tests or requested changes return to implementation. Successful verification enables release, while cancellation can leave the active hierarchy at any point. active compound state initial planning initial implementing verifying parallel state checks compound state running initial passed review compound state waiting initial reviewing approved ready released cancelled RELEASE: active.ready to released RELEASE CANCEL: active to cancelled CANCEL PLAN_APPROVED: active.planning to active.implementing PLAN_APPROVED PATCH_READY: active.implementing to active.verifying PATCH_READY TESTS_FAIL: active.verifying.checks.running to active.implementing TESTS_FAIL REQUEST_CHANGES: active.verifying.review.reviewing to active.implementing REQUEST_CHANGES both regions final: active.verifying to active.ready both regions final TESTS_PASS: active.verifying.checks.running to active.verifying.checks.passed TESTS_PASS REVIEW_START: active.verifying.review.waiting to active.verifying.review.reviewing REVIEW_START APPROVE: active.verifying.review.reviewing to active.verifying.review.approved APPROVE
Active configuration active.planning
Why this matters

The parent state exposes one shared cancellation rule.

Inspect or export the executable model

Copy the XState machine and paste it into Stately Sketch to inspect or simulate the generated diagram.

Observed events
  1. No events sent yet.

TESTS_PASS is a supplied event in this executable statechart. This demo runs no application tests; a real workflow must verify test evidence before supplying that event.

Pause & think

Follow the release gates

In this delivery statechart, release readiness requires both passing checks and an approved review. Checks have passed, but review has not started. Select the missing gate and the destination of REQUEST_CHANGES during review.

Show worked answer

Passing checks alone does not complete the parallel verification state. Review must also approve. REQUEST_CHANGES returns the patch to implementation.

Try a premature release and inspect the unchanged state before following a valid route. One cancellation rule covers the active state, tests and human review can proceed independently, and either failure can return the workflow to implementation. The statechart restricts the available routes; its tests-pass event is supplied input, not an executed test result. The actual checks and reviewer still determine whether the code meets the requirement. Deterministic controls can encode a wrong or incomplete rule. The Architecture chapter develops the related controls around data representation and durable state changes.

The Temper case study extends this pattern to agent-authored state machines and compares their verification boundary with Datadog's system testing and bounded live optimization.

2.6.3 Reuse practices without cloning the whole project harness#

Copying a complete starter repository into an existing project is usually too coarse. Package a reusable capability with its fit criteria, files, dependencies, integration instructions, checks, provenance, and update path so a project can adopt the practice without inheriting every source-template decision.

Modern Web Guidance shows how a maintained external capability can package fast-changing domain knowledge with targeted retrieval, compatibility constraints, an update path, and task-level evaluation. Imported capabilities also create a trust boundary because instructions or bundled code may influence tools operating with the agent's authority. Appendix D's imported-capability review develops these security implications, while the skill-adoption lab provides a bounded review exercise; study its source or download the standalone lab.

2.7 When generation outruns comprehension#

An agent can increase the arrival rate of candidate changes while comprehension, review, and integration remain constrained. The resulting backlog appears as large diffs, delayed review, shallow acceptance, rework, or technical debt. The table below collects evidence about different parts of that mismatch.

Table 2.7. Evidence behind the distinction between candidate production and accepted change. #
Evidence What it supports Important limit
Three field experiments covering 4,867 developers found about 26% more completed tasks with an AI coding assistant (Cui et al., 2026) Candidate production can increase in some settings Individual experiments were noisy, and the result does not apply equally to every person or project
A randomized study of 16 experienced developers completing 246 tasks found 19% longer completion time when early-2025 AI tools were allowed (Becker et al., 2025) Assistance can increase task time in a familiar repository Mature open-source projects and early-2025 tools do not establish a current effect for other settings
A study of 78 developers across seven projects classified about 58% of observed time as program comprehension (Xia et al., 2018) Understanding already consumed substantial development capacity before generative AI Two companies using Java and C# do not establish a universal reading-to-writing ratio
A professional code-review study found that understanding supports knowledge transfer and alternative solutions as well as defect detection (Bacchelli & Bird, 2013) Review is broader than checking whether generated code passes The study predates current coding agents
A live LLM-review study at Mozilla and Ubisoft found that generated comments sometimes informed revisions, but reviewers accepted only a minority (Olewicki et al., 2026) AI-assisted review can contribute evidence while still consuming human judgment One deployment does not establish the effectiveness of every review agent

Completed-task counts and time per task measure different outcomes in different populations. Do not average these productivity estimates into one general AI effect. METR's February 2026 follow-up reported that selection effects and concurrent-agent timing problems prevented a reliable estimate of the later tools' productivity effect (Becker et al., 2026). Keep the study date, task, developer experience, tools, and measurement boundary attached to each result.

Types, tests, small modules, and architectural notes can reduce the work needed to understand a change. Their value is the uncertainty they resolve. Evolving software still needs deliberate work to maintain or simplify its structure (Lehman, 1980).

2.7.1 Test an explanation against behavior#

An agent can help you approach unfamiliar code through concrete examples, data-flow diagrams, and questions. The explain-diff prompts combine surrounding-code context, intuition, a grouped walkthrough, and a comprehension quiz. These are proposed aids to inspection; a model that writes both the explanation and its quiz can repeat the same mistaken assumption in both.

For a consequential claim, predict an observable result, inspect the complete relevant code, and check that prediction against behavior. Separate what the implementation guarantees from conditions the explanation assumes, such as a worker staying alive or a request reaching the same instance. The optional explanation challenge uses a small event recorder to practice finding and correcting an overstatement.

2.7.2 Field note — Kirjolab#

In Kirjolab, agents helped me reach a scope and level of integration I would not have attempted alone. Functional checks made later refactoring safer, but they had not prevented unclear ownership and difficult navigation. The case study records the development history and the structural feedback I carried into subsequent work.

2.7.3 Choose what to participate in#

A workflow can produce acceptable software and leave its owner able to explain it, while removing an activity they wanted to experience. Choose assistance according to the result you need, the skills you need to retain, and the activities you want to take part in.

The table below separates three outcomes when choosing an assistance mode.

Table 2.8. Different outcomes of assistance require different evidence. #
Outcome Question Evidence
Accepted output Does the result meet the intended need? Independent behavioral checks and acceptance review
Retained competence Can the person explain and change it later? Delayed unaided explanation or repair
Valued participation Which parts of the work does the person want to experience? Stated purpose, preferences, and reflection

Randomized studies of programmers learning an unfamiliar library and students practicing mathematics found that AI access could reduce subsequent unaided performance (Shen & Tamkin, 2026; Bastani et al., 2025). A randomized undergraduate topic-learning experiment instead found an immediate benefit from AI access, with a smaller, less certain advantage one week later (Contractor & Reyes, 2026). The tasks and assistance designs differ; Appendix A explains what these task-specific findings support and leave open.

Learning, investigating with colleagues, and enjoying implementation can be purposes of the work. Choose what to delegate in light of those purposes as well as the result's quality and cost. Manual work, agent critique, supervised implementation, and delegation can each fit a different task. Finishing the agreed work can be a reason to stop, even when the agent has capacity for another task.

These choices also affect the team's future capacity to review and maintain software. A workflow that relies on experienced reviewers needs opportunities for people to acquire that judgment. Protected practice and mentoring can make room for predicting behavior, investigating failures, and explaining acceptance decisions. The shared engineering sessions illustrate one approach through individual predictions and rotating responsibilities. Check later independent explanation or repair before claiming a learning benefit, and ask separately whether people retain meaningful choice and manageable workloads.

Appendix A's optional Navigator exercise compares agent guidance with delegated implementation, then checks later unaided explanation and repair.

2.8 Project artifact#

For implementation A, build the required project harness alongside the application. Use the common evidence bundle to show:

  • how another group can find the core event workflow, run it, and validate a change;
  • one consequential stack or storage decision and its owner;
  • one representative AI-assisted task, its configuration and checks, human correction, acceptance decision, and known limits.

These are checkpoints within the existing submission bundle, not additional standalone deliverables.

2.9 Summary#

The development loop turns a requested outcome into a checked, maintainable change. Its project harness carries constraints and learning into later work, while people retain responsibility for acceptance and correction. When generation exceeds review and integration capacity, improve those parts of the loop before increasing output.

2.10 References#

  1. Zhang, R., Dai, W., Pham, H. V., Uddin, G., Yang, J., & Wang, S. (2026). Engineering Pitfalls in AI Coding Tools: An Empirical Study of Bugs in Claude Code, Codex, and Gemini CLI. arXiv Preprint arXiv:2603.20847. https://doi.org/10.48550/arXiv.2603.20847
  2. Cui, K. Z., Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2026). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Management Science. https://doi.org/10.1287/mnsc.2025.00535
  3. Xia, X., Bao, L., Lo, D., Xing, Z., Hassan, A. E., & Li, S. (2018). Measuring Program Comprehension: A Large-Scale Field Study with Professionals. IEEE Transactions on Software Engineering, 44(10), 951–976. https://doi.org/10.1109/TSE.2017.2734091
  4. Bacchelli, A., & Bird, C. (2013). Expectations, Outcomes, and Challenges of Modern Code Review. Proceedings of the 35th International Conference on Software Engineering, 712–721. https://doi.org/10.1109/ICSE.2013.6606617
  5. Olewicki, D., Da Silva, L. M. P., Ben Sghaier, O., Mujahid, S., Amini, A., Mah, B., Castelluccio, M., Habchi, S., Khomh, F., & Adams, B. (2026). Impact of an LLM-Based Review Assistant in Practice: A Mixed Open-/Closed-Source Case Study. IEEE Transactions on Software Engineering, 1–12. https://doi.org/10.1109/TSE.2026.3663093
  6. Talwar, S. (2026, July). LLMs Can’t Program. functional.computer. https://functional.computer/blog/llms-cant-program
  7. Brooks, Jr., Frederick P. (1987). No Silver Bullet—Essence and Accidents of Software Engineering. Computer, 20(4), 10–19. https://doi.org/10.1109/MC.1987.1663532
  8. Lehman, M. M. (1980). Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE, 68(9), 1060–1076. https://doi.org/10.1109/PROC.1980.11805
  9. Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming, 15(5), 253–261. https://doi.org/10.1016/0165-6074(85)90032-8
  10. Robinson, S. (2026, July). Write Code Like a Human Will Maintain It. Unstack. https://unstack.io/write-code-like-a-human-will-maintain-it
  11. Kruger, J., Wirtz, D., Van Boven, L., & Altermatt, T. W. (2004). The Effort Heuristic. Journal of Experimental Social Psychology, 40(1), 91–98. https://doi.org/10.1016/S0022-1031(03)00065-9
  12. Poole, D. L., & Mackworth, A. K. (2023). Artificial Intelligence: Foundations of Computational Agents (3rd ed.). Cambridge University Press. https://doi.org/10.1017/9781009258227
  13. Bromley, M. (2026, September). The Problem With Your AI Tests. Michael Bromley’s blog. https://www.michaelbromley.co.uk/blog/the-problem-with-your-ai-tests/
  14. Osmani, A. (2026, October). Agentic Verification. Elevate. https://addyo.substack.com/p/agentic-verification
  15. Osmani, A. (2026, June). Loop Engineering. AddyOsmani.com. https://addyosmani.com/blog/loop-engineering/
  16. Belcic, I., & Stryker, C. (2026, July). What Is Loop Engineering? IBM Think. https://www.ibm.com/think/topics/loop-engineering
  17. Lulla, J. L., Nersesyan, V., Mohsenimofidi, S., Treude, C., & Baltes, S. (2026, August). Loop Engineering: Building Blocks, Adoption, and Impact. arXiv preprint arXiv:2608.21884. https://doi.org/10.48550/arXiv.2608.21884
  18. Wang, Y., Zhong, W., Huang, Y., Shi, E., Yang, M., Chen, J., Li, H., Ma, Y., Wang, Q., & Zheng, Z. (2025). Agents in Software Engineering: Survey, Landscape, and Vision. Automated Software Engineering, 32(2), 70. https://doi.org/10.1007/s10515-025-00544-2
  19. Shen, J. H., & Tamkin, A. (2026, February). How AI Impacts Skill Formation. arXiv preprint arXiv:2601.20245. https://doi.org/10.48550/arXiv.2601.20245
  20. Bastani, H., Bastani, O., Sungu, A., Ge, H., Kabakcı, Ö., & Mariman, R. (2025). Generative AI without Guardrails Can Harm Learning: Evidence from High School Mathematics. Proceedings of the National Academy of Sciences, 122(26), e2422633122. https://doi.org/10.1073/pnas.2422633122
  21. Becker, J., Rush, N., Barnes, E., & Rein, D. (2025, July). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv preprint arXiv:2507.09089. https://doi.org/10.48550/arXiv.2507.09089
  22. Becker, J., Rush, N., Cunningham, T., Rein, D., & Mahamud, K. (2026, February). We Are Changing Our Developer Productivity Experiment Design. METR. https://metr.org/blog/2026-02-24-uplift-update/
  23. Charoosaei, M., Richter, C., & Papadakis, M. (2026). On the Risks of using LLM-Generated Tests for Regression Testing. https://doi.org/10.48550/arXiv.2610.11835
  24. Egashira, K., Mündler-Sasahara, N., Müller, M. N., & Vechev, M. (2026). TestSuiteBench: Coding Agents Struggle to Generate Strong Test Suites from Specifications. https://arxiv.org/abs/2610.13065
  25. Kingsbury, K. (2026, October). Jepsen: ParticleDB 1.1.4. Jepsen. https://jepsen.io/analyses/particledb-1.1.4
  26. Contractor, Z., & Reyes, G. (2026, October). Experimental Evidence on the Learning Impact of Generative AI. arXiv preprint arXiv:2607.08849. https://doi.org/10.48550/arXiv.2607.08849