← Back to Foundations

What is Agentic Coding?

I was three phases into building this website when something clicked. I had just finished the design token system — colors, typography, spacing, all synced from Figma into CSS custom properties. Claude Code had written every line. But I hadn’t prompted it the way most people prompt AI. I hadn’t typed “build me a design token system” and hoped for the best.

Instead, I had a spec file that defined exactly what the token system needed to do. I had an architecture document that explained how tokens flow from Figma variables into tokens.css. I had a plan broken into tasks, each with a verification step. And when Claude finished writing the code, I didn’t eyeball it — I ran the checks, confirmed the output matched the spec, and moved to the next task.

That’s agentic coding. And it’s fundamentally different from what most people are doing with AI right now.

The definition

Agentic coding is the practice of building software by directing an AI agent with structured intent, verification loops, and persistent context. You define what needs to be built. The agent writes the code. You verify the result against a spec.

The core insight is this: you are not writing code. You are directing an agent that writes code. That distinction changes everything about how you work — what you prepare before a session, how you structure your instructions, how you check the output, and how you carry context across sessions.

This isn’t a loose metaphor. It’s a literal description of the workflow. You write a specification. You create a plan. You hand the plan to an AI agent. The agent executes. You verify. You repeat.

The core loop: plan, execute, verify

Every piece of this website was built through the same cycle.

Plan. Before writing any code, I open a planning session. This session is dedicated to research, discovery, and breaking work into phases. The output is a plan document with specific tasks, acceptance criteria, and verification steps. No code gets written during planning — that would pollute the context window with implementation details before the structure is in place.

Here’s what a simplified plan looks like for a phase:

## Phase 5 — Blog System

### Task 1: mdsvex configuration
- Configure mdsvex preprocessor in svelte.config.js
- Support frontmatter parsing (title, date, slug, categories)
- Verify: blog post renders at /blog/[slug] with correct metadata

### Task 2: Post listing page
- Create /blog route with paginated post listing
- Sort by date descending
- Verify: all published posts appear, draft posts excluded

### Task 3: RSS feed
- Generate RSS XML at /rss.xml
- Include title, description, link, pubDate for each post
- Verify: feed validates at W3C Feed Validator

Each task has a verify step. That’s not optional decoration — it’s the mechanism that prevents the most common failure mode in AI coding: code that looks right but doesn’t work.

Execute. I start a fresh session with clean context. I load the plan, the spec, and the architecture doc. Claude Code reads the plan and starts executing tasks in order. Because the plan is specific, the agent doesn’t have to guess what I want. It knows the acceptance criteria. It knows where files go. It knows what “done” looks like.

Verify. After execution, I check each task against its criteria. Does the blog post render? Does the RSS feed validate? Are draft posts excluded from the listing? If something fails, I don’t start over. I note the failure, and in the next session, I address it with targeted context.

This loop is the entire methodology. Everything else — the tools, the configuration, the memory systems — exists to make this loop more reliable.

What makes it work

Three principles separate agentic coding from prompting and praying.

Structured intent: specs, not vibes. The quality of AI output is directly proportional to the quality of your input. When your input is a casual prompt — “build me a blog” — you get casual output. When your input is a spec that defines the data model, the routes, the edge cases, and the success criteria, you get production-grade output.

I keep a /project folder in every repository. It contains:

project/
├── SPEC.md          # What we're building and why
├── ARCHITECTURE.md  # How the system works
├── STATE.md         # Where we are right now
├── ROADMAP.md       # What's next
└── phases/          # Plans and summaries per phase

This isn’t bureaucracy. It’s the context that makes AI effective. Every new session starts by reading STATE.md to know where we are, ARCHITECTURE.md to understand the system, and the relevant plan to know what to do next. Without this, every session starts from scratch and the agent wastes tokens rediscovering your project.

Verification at every step: automated checks, not “looks right.” The biggest trap in AI coding is accepting output that appears correct. Code that renders without errors. A component that looks right in the browser. A function that returns the expected value for the one case you tested.

Agentic coding requires you to define what “correct” means before the code is written, then check against that definition after. This can be automated tests, manual verification against acceptance criteria, or build checks. The point is that verification is explicit, not vibes-based.

When I built the OG image system for this site, the plan didn’t say “generate OG images.” It said: “OG images render at /blog/[slug]/og.png, use project fonts (Libre Caslon Condensed + IBM Plex Mono), include the post title and site URL, output as 1200x630 PNG.” After Claude wrote the implementation, I hit the endpoint, checked the dimensions, checked the fonts, checked the layout. Three of those checks failed on the first pass. Without explicit criteria, I might have shipped it broken.

Context management: fresh sessions, memory systems, state files. AI models degrade as the context window fills up. After roughly 50-60% capacity, output quality drops noticeably — the model starts contradicting earlier decisions, forgetting constraints, generating code that conflicts with existing patterns. I call this context rot.

The fix is structural. Planning and execution happen in separate sessions. Each session starts fresh with only the context it needs. State files carry information between sessions so no context is lost, but no single session is overloaded.

This is also why skills and memory systems matter. A skill is a reusable instruction set that loads into context when needed — like a publishing checklist or a deployment workflow. Instead of re-explaining your process every session, you load the skill and the agent follows it. If you want to see how that works in practice, the system setup guide covers it in detail.

How it differs from “just using AI to code”

Most people using AI to code are doing some version of this: open a chat, describe what they want, paste the output into their project, fix the errors, repeat. That works for isolated functions. It falls apart for anything with multiple files, shared state, or architectural decisions that compound over time.

The difference isn’t the AI model. It’s the methodology around it.

When you ask ChatGPT to write a function, you get a function. It might be good. It might not. You evaluate it with your own judgment and move on. When you direct Claude Code through a multi-phase build with specs, plans, and verification — you get a system. Components that reference the same design tokens. Routes that follow the same patterns. Architecture that stays consistent across 10 phases because the architecture document is loaded into every session.

Vibe coding produces isolated outputs. Agentic coding produces coherent systems. For a deeper breakdown of the differences, I wrote a detailed comparison.

Who this is for

I came to agentic coding from Webflow. I spent years building marketing sites, learned design systems inside out, understood how content strategy drives page structure. What I didn’t have was the ability to code those ideas into production software.

Agentic coding bridged that gap. Not by teaching me to write JavaScript — by giving me a way to direct an agent that writes JavaScript, while I focus on what I actually know: design, content, product thinking.

This approach works best for:

  • Designers transitioning to code. You already understand systems, components, and user flows. Agentic coding lets you apply that thinking to software.
  • Solo builders and freelancers. You can’t hire a team but you need team-level output. Directing AI agents gives you leverage.
  • Domain experts building tools. If you understand your field deeply — marketing, education, operations — you can direct AI to build software that serves that field.

Who it’s not for: anyone looking for AI to replace their thinking. Agentic coding requires you to know what you want, define how success is measured, and verify the result. The AI handles implementation. The judgment stays with you. If you hand over the judgment too, you’re back to vibe coding.

What you need to get started

Three things.

An AI coding agent. I use Claude Code, Anthropic’s CLI tool. It runs in the terminal, has access to your filesystem, and can read, write, and execute code. Other agents exist — Cursor, Copilot, Windsurf — but Claude Code’s terminal-based workflow fits the plan-execute-verify loop cleanly because you control exactly what context it sees.

A project. You need something to build. Not a tutorial exercise — a real project with real requirements. The methodology only makes sense when you’re dealing with complexity: multiple pages, shared components, data flows, deployment. Start with something you care about shipping.

A methodology. Structure your project with a spec, architecture doc, state file, and roadmap. Break work into phases. Plan before you execute. Verify after. You don’t need my exact setup — the principles are what matter. Define intent clearly. Keep context clean. Check your work.

You don’t need to be a developer. You don’t need a computer science degree. You need domain expertise — the understanding of what you’re building and why. The better your understanding, the better your instructions to the agent, and the better the output.

The execution is the simplest part. The hard part is knowing what to build and being precise about what “done” looks like. If you can do that, you can build with agentic coding.