Agentic Development Part 1: Overview

The Spec-Driven Development series already covered how to write good specs, turn them into API contracts, translate them into plans and tasks, and verify them with tests. A spec is useless on its own, though, if nothing executes it — and that’s where agents come in. But “agent” is often used loosely for anything that involves AI in coding, when there’s a real functional difference between an assistant that answers questions and an agent that actually acts autonomously in the codebase. This article opens a new series, Agentic Development, by defining what actually makes a system “agentic”, how the specs from the previous series become the prerequisite that makes this autonomy safe to use, and the spectrum of control you need to understand before delegating work to an agent.

From Chat Assistant to Agent

Before discussing agents, it helps to look at the spectrum agents sit on. AI coding tools didn’t emerge as a single category — they evolved through several stages that differ functionally, not just in marketing.

Autocomplete — the earliest form, suggesting the next line or block of code based on what you’re typing. No understanding of intent, no independent execution. The developer still writes and runs every line manually.

Chat assistant — the developer asks, the AI answers or produces code snippets as a single-turn response. The developer still takes that code, places it in the right file, runs it, and evaluates the result. The AI has no direct access to act outside the conversation.

Agent — given a goal (not a single-step instruction), the agent plans the necessary steps, uses tools (reading/writing files, running commands, calling APIs) to execute those steps, evaluates the results, and repeats this cycle until the goal is reached or human intervention is needed.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
    A[Autocomplete] -->|adds conversational context| B[Chat Assistant]
    B -->|adds tool use + execution loop| C[Agent]
    
    A -.-> A_loop("no independent\nexecution") -.-> A
    B -.-> B_loop("single turn,\ndeveloper executes") -.-> B
    C -.-> C_loop("plans, acts,\nevaluates, repeats") -.-> C

The most fundamental difference between a chat assistant and an agent isn’t how smart the model is, but who holds the execution loop. With a chat assistant, that loop sits with the developer — the developer decides when to run code, when to evaluate results, and when to ask again. With an agent, the loop is held by the system itself — the agent decides the next step based on the previous step’s results, without waiting for new instructions from a human at every step.

These three categories aren’t an absolute “better” hierarchy. Autocomplete still fits line-by-line work that needs full control; chat assistants fit exploration and brainstorming; agents fit tasks whose scope is already clear and can be verified automatically. Choosing the right category for the context matters more than always reaching for the most autonomous one.

Defining an Agent in the Coding Context

With the agent’s position on the spectrum above clear, here’s a more precise definition: a coding agent is a system given a goal in natural language or a structured spec, which then independently plans, executes using tools, and evaluates its own work in a loop, with human involvement less frequent than one confirmation per step.

Three characteristics always appear together on systems worthy of the “agentic” label:

Tool use — the ability to act in the real world (or at least outside the conversation), not just produce text. Reading and writing files, running terminal commands, calling external APIs, searching the codebase. Without tool use, a system can only “talk about” a solution, not actually apply it.

Planning and reasoning — the ability to break a large goal into concrete steps, and to adjust the plan when previous steps’ results don’t match expectations. This is what distinguishes an agent from a plain automated script: a script follows a step sequence fixed at the start, while an agent adjusts its sequence based on what it discovers along the way.

Execution-evaluation loop — the recurring cycle of acting, checking results, and deciding the next step, without waiting for new instructions at each iteration. This loop is what lets an agent handle multi-step tasks on its own, instead of stopping and asking after every small step.

flowchart TD
    A[Receive Goal/Task] --> B[Plan: Plan the Steps]
    B --> C[Act: Execute via Tools]
    C --> D[Observe: Evaluate Results]
    D --> E{Goal Reached?}
    E -- No --> F{Plan Needs Adjusting?}
    F -- Yes --> B
    F -- No --> C
    E -- Yes --> G[Done]
    E -- Failed/Stuck --> H[Escalate to Human]

This loop will be a recurring reference in the rest of this series — Part 2 examines the components that build this loop in more detail (planner, tool execution, memory), and Parts 7-10 discuss how to keep it from going off the rails.

Why Specs Are a Key Prerequisite Here

There’s a direct relationship between how autonomous an agent is and how expensive ambiguity becomes. With a chat assistant, the developer evaluates every response before using it — ambiguity in the prompt at worst produces one slightly-off answer, which is immediately visible and fixable in the next turn. With an agent working in a long loop without tight supervision, the same ambiguity can propagate — a wrong decision in step three becomes the foundation for decisions four, five, and beyond, before a human ever sees the result.

This is why the entire previous Spec-Driven Development series wasn’t written first by accident. A clear spec — intent, constraints, acceptance criteria, and non-goals as covered in Part 2 of that series — acts as the fence that makes agent autonomy safe to use. Without this fence, giving an agent more autonomy is the same as giving errors more room to multiply unchecked.

flowchart LR
    A[Low Agent Autonomy] -->|spec ambiguity relatively safe| B[Small Error Impact]
    C[High Agent Autonomy] -->|without a clear spec| D[Ambiguity Propagates at Every Loop Step]
    C -->|with a clear spec as fence| E[High Autonomy Stays Controlled]

This relationship also explains why the series are ordered as they are: spec-driven development as the foundation, then agentic development. Trying to give an agent large autonomy without a solid spec as a fence is a recipe for the problems discussed in the next section.

The Agent Autonomy Spectrum

Agent autonomy isn’t a binary condition — either fully autonomous or not autonomous at all. In practice, autonomy sits on a spectrum, and the right position depends on the task context, the level of trust in the agent, and how strong the available automated verification mechanisms are.

Higher levels aren’t automatically “better” — this is an explicit trade-off between speed and control. Levels 1-2 give maximum control but sacrifice speed because every step waits for human approval. Levels 4-5 give high speed but demand a far more mature verification infrastructure — strong test coverage, clear task definitions, and automated guardrails — before they’re safe for routine use.

Most production teams today operate most effectively at levels 3-4, with level 5 applied selectively to tasks with a narrow scope that are already well-verified. Raising the autonomy level requires real investment in test coverage and task definition clarity — not just better prompts.

Risks That Grow with Greater Autonomy

The higher the autonomy level, the larger several categories of risk become — risks you should understand before delegating work to an agent.

Compounding errors — small mistakes early in the loop become the foundation for later steps. At low autonomy levels, these errors are caught quickly because a human evaluates each step. At high autonomy levels, errors can accumulate across many steps before finally showing up in the final result — and at that point, tracing back to the root cause is far harder than if it had been caught at the first step.

Unexpected decisions outside the intended scope — an agent given a broad goal and large autonomy can take an approach that technically achieves the goal, but in a way that wasn’t anticipated or desired. This connects directly to the importance of non-goals covered in Part 2 of the previous series — without explicit boundaries, an agent with large autonomy has a very wide space to improvise in.

Rollback difficulty — the more steps an agent executes without checkpoints, the harder it becomes to separate which changes are valid and which need to be undone when a problem is found. Interdependent changes make partial rollbacks tricky, sometimes more complicated than rewriting from scratch.

Verification lagging behind execution speed — an agent can produce changes far faster than a human can review them in depth. If execution speed isn’t matched by adequate automated verification, high autonomy actually creates a piling-up review backlog rather than genuinely accelerating the delivery of verified features.

flowchart TD
    A[Agent Autonomy Increases] --> B[Execution Speed Increases]
    B --> C{Adequate Automated Verification?}
    C -- Yes --> D[Real Delivery Speed Increases]
    C -- No --> E[Review Backlog Piles Up]
    E --> F[Compounding Errors Not Caught Early]

These risks aren’t a reason to avoid high autonomy altogether, but a reason to build proportionate verification mechanisms before raising the autonomy level. Parts 7 through 10 of this series will specifically cover how to design tasks, context, and guardrails that keep greater autonomy safe to use — not merely faster but riskier.

When Agentic Development Is the Right Fit

Just as spec-driven development isn’t worth it for every job, high agent autonomy isn’t always the right choice either. Some signals indicate a context suits greater autonomy:

• Tasks with a clear, well-defined scope — when the acceptance criteria from the spec (see Part 2 of the previous series) are specific enough to verify automatically, the agent has a clear target without needing to guess
• Codebases with strong test coverage — a comprehensive test suite acts as an automated guardrail (covered in more depth in Part 5 of the previous series), making regressions detectable without waiting for manual review
• Repetitive, proven work patterns — routine migrations, refactorings with consistent patterns, or feature implementations similar to previous ones done successfully
• Isolated execution environments — changes can be tested in a sandbox or separate branch before touching production, reducing the consequences of errors that slip past review

Conversely, some contexts suit low autonomy or no agent at all:

• Early-stage architecture exploration — when the requirements themselves aren’t fully clear, giving an agent large autonomy actually accelerates premature architectural decisions before enough exploration has happened
• High-risk decisions without adequate supervision — changes to payment systems, core security, or sensitive data where error consequences are severe should keep tight human review regardless of how mature the verification infrastructure is
• Codebases with minimal test coverage — without adequate automated guardrails, raising agent autonomy here is like removing the safety net before it’s truly needed

The most common temptation is raising the autonomy level because speed is enticing, without first ensuring the verification infrastructure is proportionate. The correct order is the reverse: build guardrails and task clarity first, then raise autonomy gradually while observing the results.

Series Preview

Part 1 gives the big picture of what an agent is, how it relates to the specs covered in the previous series, and the autonomy spectrum you need to understand before delegating work. The next six articles in the Agentic Development series will dissect each of these aspects more deeply:

• Part 2 — Anatomy of a coding agent: the planner, tool use, memory, and verification loop components in more detail
• Part 3 — Designing tasks for agents: granularity, definitions of “done”, and scope that keeps agents from going off track
• Part 4 — Context engineering: providing the right codebase context so agent results stay consistent with the project
• Part 5 — Verification and guardrails: automated mechanisms to keep agents from “hallucinating” breaking changes
• Part 6 — Multi-agent workflows: orchestration patterns for many agents on complex tasks, and when they help vs. when they’re overkill
• Part 7 — Combined spec-driven and agentic development best practices: a synthesis of both series, checklists, and common anti-patterns

Every article will keep referring back to concepts from the Spec-Driven Development series — the two are designed as one unit, not two standalone topics.

Summary

• An agent differs from a chat assistant in who holds the execution loop — with an agent, the system itself decides the next step based on previous results, instead of waiting for new instructions at every step
• Three core characteristics of a coding agent: tool use (acting outside the conversation), planning/reasoning (breaking goals into steps and adjusting the plan), and the execution-evaluation loop (the recurring act-check-decide cycle)
• The larger the agent’s autonomy, the more expensive ambiguity becomes — which is why a clear spec from the previous series acts as the fence that makes large autonomy safe to use
• Agent autonomy sits on a five-level spectrum, from line-by-line suggestions to full execution without direct supervision — higher levels aren’t automatically better, but an explicit trade-off between speed and control
• Risks that grow as autonomy rises: compounding errors, decisions outside the intended scope, rollback difficulty, and verification lagging behind execution speed
• Agentic development fits tasks with clear scope, codebases with strong test coverage, and repetitive work patterns — less suited to early architectural exploration or high-risk decisions without adequate supervision
• The correct order: build guardrails and task clarity first, then raise the autonomy level gradually — not the other way around