Programming or coding is writing a set of instructions that tells a computer what to do. A programming language supplies the grammar for those instructions, and a runtime carries them out, exactly as written. A running program also keeps information: the values it has read, computed, or saved so far. That stored information is called its state. A program, therefore, transforms an input, based on its instructions and its initial state, into an output or a state change. An output might be an answer on screen; a state change might be a record saved to a database.
Agentic coding starts from a described behavior, not a typed program. The director of agents inputs what the program must do; a coding agent writes the source code, runs it, and reports the result. The agent may also develop tests, including test inputs, to verify the targeted output is achieved. The agent, thus, works in a loop: write, run, compare the result with the desired behavior, and fix the differences. Failures generally occur while the agent is working through the above loop. The agent assesses the error and then corrects the code without help. The end result is a program with a defined behavior determined by its source code: the files of instructions that form the basis for further development and improvement.
Generating a correct program begins with describing the desired behavior precisely. A coding agent cannot infer requirements that were never specified, so an unclear prompt can produce an incorrect program. “Return a new list containing only records with valid email addresses” defines an input, an output, and a constraint. An agent can implement that instruction, and the director can verify whether the result satisfies it.
System vocabulary serves the same purpose at a larger scale. Explicitly naming qualities such as speed, reliability, security, and cost makes the relevant tradeoffs visible before the agent makes those choices implicitly. Andrew Ng, the Stanford professor and DeepLearning.AI founder, has made a related point about AI-assisted programming: as agents become better at generating code, memorizing syntax becomes less important, while understanding what the generated system is doing and evaluating its tradeoffs becomes more important.[3]
Directing agents well requires understanding how software is produced, not reading every line of code. With that understanding, the director can step in where agent behavior drifts: too many test cases, useless tests, or too few; a codebase grown enormous that needs abstractions, dead-code removal, and cleanup. These higher-order problems matter because technical debt hurts agent behavior directly: duplicated logic and dead code mislead the next agent that reads the codebase. The engineering scope below names the five systems this judgment steers.[1]
Reviewing the agent's work still requires tracing: following one realistic input through the program, step by step, to its output. If the actual output matches the desired output, the program works for that input. Edge inputs, unusual variations of the input, confirm that the program is robust; the shows a launch where they were missed. Beyond the code, systems fail at other layers: resources run out, dependencies break, and processes skip steps. The failure taxonomy below lists those layers, and tests, QA, and monitoring are the guards that catch them. Review depth should follow risk, not authorship. The verification levels below match the strength of the check to the consequence of being wrong.[2]
Execution modelHow source code becomes behavior
Read any program as a path. Data enters, the program stores and transforms it, control flow chooses what happens, and an observable result leaves.
- 01
Input
Data enters the program, such as a RecordOne structured item of data: a set of named fields stored together, like one row in a table (a user's name and email, say)., a button click, a file, or an API responseThe data a service sends back over the network after a program asks it for something. An API (application programming interface) is the set of requests a service agrees to answer..
- 02
State
A record of values the program currently knows, which may be temporary in RAM or written into storage (a drive).
- 03
Control
Conditions (if x, then y else z) select a path, and loops (while x, do y) repeat work across items or until a stopping rule is reached.
- 04
Work
Functions group operations behind a name. Modules organize related functions and values for reuse.
- 05
Result
The program returns output, changes external state, or reports a failure that another part of the system must handle.
A coding agent proposes the source code, but the runtime produces the behavior. The director verifies the path, not the agent's description of it.
Working vocabularyThe working vocabulary of software production
Directing agents does not require reading every line of code. It requires the vocabulary to discuss how software is built, tested, and kept healthy.
- Runtime
- The program that executes source code exactly as written and reports an error when it cannot continue.
- Node.js, the Python interpreter
- Linter
- A tool that reads source code without running it and flags suspicious patterns, style problems, and unused code.
- npm run lint
- Test coverage
- The share of the code that automated tests actually exercise. High coverage of trivial code can still leave critical paths untested.
- 87% of lines covered
- Technical debt
- Accumulated shortcuts that make future changes slower and riskier for both agents and people.
- six copies of one validation rule
- Abstraction
- One named home for logic that is used in many places, so a change lands once instead of everywhere.
- a single shared validate_email function
- Dead code
- Code that nothing calls anymore. It bloats the codebase and misleads agents that read it.
- an unused legacy endpoint
Failure taxonomyHow systems fail
The absence of a crash does not mean the system succeeded, because code is not the only layer where failures can occur. Identifying the layer in which a failure occurs helps the director determine what safeguard to ask the agent to add. System layers are outlined below with examples.
01Programming failure
The code itself is wrong: a syntax error stops translation, a runtime failure stops execution, or a logic bug completes with the wrong result.
Example: A loop that silently skips an invalid record.
Look for: Failed builds and runtime exceptions are often straightforward for agents to fix from the error message. Logic bugs are harder because they become visible only when the program's actual output is compared with the intended output based on a variety of inputs.
Resource failure
The system running the program fails when it reaches a resource limit: memory, disk space, CPU capacity, or a service rate limit.
Example: A traffic spike exhausts server memory and requests stall.
Look for: Verify that resource limits are not affecting runtime performance: slowdowns, timeouts, and out-of-memory errors appear in monitoring while the same code passes every test.
Dependency failure
Something the program relies on changes or goes down: an external API, a library update, a database, a network.
Example: An email provider changes its API and confirmations stop sending.
Look for: Errors that name a service the code did not change, often starting when nothing was deployed.
Process failure
The steps around the code break down: missing edge-input tests, no review, a bad configuration, or deployed with no rollback plan.
Example: A fix ships untested and takes signups down for an hour.
Look for: Incidents that a checklist, a test, or a staged rollout would have prevented. QA exists to catch this layer.
Review depthMatch verification to the consequence
AI-generated code is not guaranteed to be correct and still requires review. The depth of that review should reflect the cost, scope, and reversibility of a potential failure.
- 01PreviewCopy, styling, or a contained visual change.ProveInspect the rendered result at the relevant screen sizes.
- 02Focused testA local function or behavior with limited impact.ProveTrace representative inputs and run focused automated tests.
- 03Isolate and recoverShared files, database writes, integrations, or persistent state.ProvePreview scope in a disposable environment and prove rollback or recovery.
- 04Explicit approvalAuthentication, permissions, money, deletion, or other high-impact operations.ProveRequire stronger tests, human review at the action boundary, monitoring, and a rollback plan.
Engineering scopeFive systems the director must steer
The roadmap excludes syntax evaluation because agents write and correct code, but the agent still needs guidance to choose the tradeoffs that best fit users, data, risk, and operating environment.
- 01
Full stack
Trace a user action through rendering, caching, APIs, authentication, sessions, background work, persistence, testing, security, and accessibility.
AskWhere does a request enter, where does state live, and how does a failure return to the user?
- 02
Data
Choose storage from access patterns, then protect transactions, concurrency, freshness, privacy, governance, and the full data lifecycle.
AskWhat must be stored, for how long, and which consistency or privacy rule cannot be violated?
- 03
Architecture
Define boundaries and state deliberately, validate technology choices, and evolve the architecture as a prototype grows into a production system.
AskWhich tradeoff is more important: latency, availability, simplicity, or cost, and how might that change after the prototype?
- 04
Security and reliability
Design the test strategy, graceful degradation, failure containment, dependency checks, and security controls before a failure reaches users.
AskWhat can fail or be attacked, how far can the damage spread, and what independent evidence will catch it?
- 05
Production operations
Emphasize deployment, release strategy, CI and CD, observability, alerts, incidents, real load, scaling, dependency maintenance, and technical debt.
AskHow will the system be released, observed, recovered, and evolved under real load?
Agents can generate implementation options. They cannot supply application context they were never given, or flag a tradeoff the director does not know exists.
Do not confuse theseProgramming fundamentals versus software engineering as a whole
Programming fundamentals are the core building blocks of a program: values, conditions, loops, functions, modules, and errors that, when knitted together correctly, generate a program. Software engineering is the wider discipline of turning those programming fundamentals into systems that survive contact with real users: testing, version control, interfaces, deployment, monitoring, and on-call. Fundamentals allow a single function to be verified. Engineering is what keeps a thousand functions working together. With fundamentals alone, the director can review the code an agent generated. However, the code may still be unworthy of the repository: it may break a contract, lack security, fail to scale, or not actually be useful to users.
Worked exampleOne feature, four ways to fail
An agent builds a signup form that saves new users to a database. Every check the agent ran passed, and the feature ships. Over the first week the launch still fails four times, each time at a different layer of the system.
- 01A logic bug: signups with unusual email formats are rejected. The agent's tests never included an edge input, so the code passed every check it ran.
- 02A resource failure: a marketing spike fills the server's memory and signups stall. The code is correct; the system around it hit a limit.
- 03A dependency failure: the email provider changes its API and confirmation messages stop sending. Nothing in the codebase changed when the failure began.
- 04A process failure: the fix is deployed without a rollback plan, and a bad configuration takes signups down for an hour.
- 05Each layer has its own guard: edge-input tests, load monitoring, dependency checks, and a release process with rollback. Directing the agent means asking for these guards, not only for the code.
Agentic code may contain logic bugs, and the system around it can fail from resources, dependencies, and process. Thorough testing and QA at every layer is what prevents those failures.