Agent-driven development: what the workflow actually looks like

Most descriptions of "AI-assisted development" stop at "use Copilot for autocomplete." That's not what agent-driven development is. This post breaks down what a real agent-driven workflow looks like, including the components that make it work: MCP servers, skills, subagents, and hooks.

The mindset shift

In a traditional workflow, you write code. In an agent-driven workflow, you define intent and verify output. The agent writes the code.

This sounds like a shortcut. It isn't. The cognitive load shifts from syntax and boilerplate to architecture, judgment, and code review. You spend less time writing loops and more time deciding whether the data model is right, whether a generated abstraction leaks, whether the TypeScript types are strict enough.

The developer's job becomes: set up the context, define the constraints, review the output, and catch what the agent gets wrong.

The four components

MCP servers

MCP (Model Context Protocol) is what gives agents access to external systems. Without it, an agent works from training data and whatever you paste into the prompt. With it, the agent can read your actual database schema, query your existing codebase, or pull from a design file.

The difference matters. An agent guessing at your schema generates plausible-looking code that misses your actual column names and relationships. An agent with a live database connection generates code that maps directly to your real data.

Common MCP servers in a dev workflow:

The quality of the agent's output is bounded by the quality of its context.

Skills

A skill is a reusable workflow, an encoded sequence of steps that runs on demand. Instead of re-explaining the same task every session, you define it once and invoke it with a single command.

/code-review     → analyze diff, flag bugs and simplification opportunities
/security-check  → scan generated code against a security checklist
/verify          → spin up the app and confirm the feature works end-to-end

Skills are how institutional knowledge stops living in someone's head and becomes a repeatable process. Every time the agent finishes generating a component, /security-check runs the same review, every time.

Subagents

A subagent is a separate agent instance spawned to handle a specific slice of a larger task. The main agent orchestrates; subagents execute in parallel.

The typical use case is a task too large or too multi-directional for a single context window. Instead of one agent holding everything, you split the work:

You can define the breakdown explicitly, or ask the main agent to figure out the split itself. Either works. What matters is that each subagent prompt is self-contained. Subagents have no memory of the parent conversation, so everything they need must be in their prompt.

Hooks

Hooks are event-driven triggers that run automatically at specific points in the workflow. They're how you add guardrails without relying on memory.

PreToolUse (file edit)  → lint check before any file is modified
PostToolUse (file edit) → TypeScript type check after every change
Stop                    → run test suite when agent finishes a task

Without hooks, quality checks depend on you remembering to run them. With hooks, they're automatic. The agent finishes editing a file and the type checker runs immediately, before you see the output.

Hooks also handle decisions the agent shouldn't make autonomously. A hook that requires confirmation before deleting files means nothing gets removed without explicit approval.

A complete workflow example

Here's what building a new feature looks like with all four components in play:

The sequence above compresses to a simple rule: MCP gives the agent eyes, subagents give it parallelism, hooks give it guardrails, and skills give it memory. The developer provides judgment.

What the developer actually does

The common anxiety about agent-driven development is that it reduces the developer to a prompt engineer. In practice, the opposite problem is more common: developers under-correct the agent because reviewing generated code feels passive compared to writing it.

The agent is fast and confident. It will generate a working solution with a subtle architectural problem and not flag it. The developer's job is to catch that problem, which requires understanding the system at least as well as you would if you'd written it yourself.

Agent-driven development is faster, but it's not easier. The skill that matters most is knowing what bad code looks like when you didn't write it.