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. 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.
| 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 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. 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.
| 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.
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. Study its source or download the standalone lab.
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.2.1 Constraint feedback loop#
The demonstration starts with an underspecified request to add CSV export to an event list. Generate a candidate, validate it, revise the project memory from failed checks, and begin the next round. Compare a run with the default constraints with one that selects every constraint before generation.
Constraint learning loop
Turn evidence into project memory
- 01Constrainstate what must remain true
- 02Generateproduce a bounded candidate
- 03Validatecompare evidence with intent
- 04Revisemake the learning explicit
Candidate + evidence
No candidate generated
- —Browser testCan clicking Export create a download?
- —Changed-files checkDid the patch stay inside export.ts and export.test.ts?
- —CSV assertionAre commas and quotation marks escaped?
Generation is not evidence. Generate a candidate, then run the checks.
The candidate is deterministic teaching data, not model output. Use validation failures to revise the project's rules and context before the next generation attempt.
2.3 Human-agent relationship is a control design#
Here, Human Agent Relationship (HAR) means the allocation of intent, authority, execution, evidence, intervention, and accountability across the development workflow. 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.
| 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 |
Record material assistance and human corrections in the AI-use log, and bind the checks and known limits to the submitted revision. Perceived effort can influence quality judgments (Kruger et al., 2004), but time spent and disclosed AI use do not establish correctness.
2.3.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 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. It supplies project knowledge to the agent harness introduced earlier.
| 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.4.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.4.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
Give the agent a map
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.
Automatically checked practice. Saved answers are private to your account.
Checking saved answers…
Your answers to earlier versions
Show worked answer
Passing checks alone does not complete the parallel verification state. Review must also approve. REQUEST_CHANGES returns the patch to implementation.
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; the 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.
2.4.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. The Agent Fleets chapter develops the security implications, while the skill-adoption lab provides a bounded review exercise; study its source or download the standalone lab.
2.5 How did development control change before and after agents?#
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.
| 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. The A–B–C phases vary the agent setup while preserving the required application behavior.
2.6 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.
| 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 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 |
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.6.1 Field note — Kirjolab#
When GPT-5.6 became available, I decided to revisit one of my long-standing ideas. I wanted to combine some of the better features of Zotero, Parsifal, and Overleaf in one service. Kirjolab grew from that experiment: a web application for storing, reviewing, and working with research papers, references, evidence, and writing in one place. Within a few days of exploratory prompting, I had a working prototype. That was a real success: agents helped me reach a degree of scope and integration I would not have attempted alone.
The speed also exposed a limit.
Functional gates continued to protect behavior, but they did not initially constrain structural ownership.
By 25 July, src/client/app.ts had reached 12,495 lines and combined an element registry, event binding, rendering, and feature orchestration.
The source structure eventually required extensive refactoring.
Existing tests made that repair safer, but they had not prevented the architecture from becoming difficult to navigate.
I carried those lessons back to my project template so that structural feedback would arrive earlier. I also found that mutation testing with Stryker and cognitive-complexity analysis with Fallow complement one another: one challenges whether tests detect behavioral changes, while the other identifies code that is becoming difficult to reason about. Agents tend to follow the patterns already present in a codebase, so the project should establish and reinforce the direction it wants future changes to take.
2.6.2 Optional exercise — Write with an agent as navigator#
- Choose two small, comparable tasks involving an unfamiliar part of the stack, such as parsing an API response or enforcing a lifecycle transition. State the required behavior and give each task the same time budget.
- For one task, write the code yourself while the agent offers hints, explanations, and critique. Predict the next step before requesting a hint, and record where guidance changed your reasoning.
- For the other task, let the agent implement the change and use the remaining time to review and correct it. Apply the same kinds of acceptance checks to both results.
- In a later session, without the agent or transcript, explain each implementation's invariant and repair a small, previously unseen fault. Record correctness, explanation quality, time, and assistance needed during the original work.
Compare accepted output with later unaided performance; code volume and keystrokes measure neither understanding nor retained judgment. Task differences and practice order can explain a result from one pair, so use this as a learning diagnostic rather than a causal study.
2.7 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.8 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.9 References#
- 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
- 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
- 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
- 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
- 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
- Talwar, S. (2026, July). LLMs Can’t Program. functional.computer. https://functional.computer/blog/llms-cant-program
- 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
- 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
- Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming, 15(5), 253–261. https://doi.org/10.1016/0165-6074(85)90032-8
- Robinson, S. (2026, July). Write Code Like a Human Will Maintain It. Unstack. https://unstack.io/write-code-like-a-human-will-maintain-it
- 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
- Poole, D. L., & Mackworth, A. K. (2023). Artificial Intelligence: Foundations of Computational Agents (3rd ed.). Cambridge University Press. https://doi.org/10.1017/9781009258227
- 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/
- 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