Introduction to AI Agent-Driven Development

This course teaches you to operate AI agents that autonomously execute complex development tasks—from specification to deployment.

Who This Course Is For

You’re a legal technologist, developer at a legal services firm, or engineer building legal software. You write code—whether that’s contract automation, case management systems, or compliance tools. You’ve used ChatGPT or Copilot, but you sense there’s a deeper way to integrate AI into your development workflow.

This course is for developers who want to move beyond copy-pasting AI suggestions into systematically operating AI agents for autonomous code execution.

Prerequisites: Comfortable reading and writing code (TypeScript/JavaScript examples, but concepts apply to any language). No AI/ML background required.

What You’ll Learn

This course covers three areas:

Understanding the Tools (Lessons 1-2) — What AI agents actually are, how they work under the hood, and why understanding the machinery matters for effective operation.
Methodology (Lessons 3-6) — The four-phase workflow for agent-driven development: Research, Plan, Execute, Validate. How to ground agents in your codebase and set up project context.
Practical Techniques (Lessons 7-11) — Hands-on patterns for planning, testing, debugging, code review, and writing agent-friendly code.

By the end, you’ll operate AI agents the way you operate Legal Intelligence or Rechtspraak.nl—as precision tools that amplify your capabilities rather than replace your judgment.

The Paradigm Shift

Software engineering is undergoing a fundamental transformation - one that mirrors changes the legal profession has already lived through.

Legal research transformation:

Before digital: Lawyers hunted through physical NJ annotations, Staatsblad archives, and relied on memory and colleagues to find relevant jurisprudence
After Legal Intelligence/Rechtspraak.nl: Lawyers design search strategies, operate the tools, verify relevance of results
Result: Massive gains in bandwidth - same lawyer can cover far more ground with higher confidence

Software engineering transformation:

Traditional: Engineers write code line-by-line, focusing on syntax and implementation details
Agent-driven: Engineers orchestrate AI agents that autonomously execute tasks, focusing on architecture and verification
Result: Same gains - bandwidth, repeatability, precision through specification

A gain in bandwidth and creativity, rather than loss of control.

You already know how to operate sophisticated tools to amplify your capabilities. This course teaches you to do the same with code.

First Principles: Understanding the Machinery

Before we discuss what AI agents can do, let’s establish what they actually are - because the terminology makes them sound far more magical than they deserve.

LLM = Brains (Token Prediction Engine)

A Large Language Model is a statistical pattern matcher built on transformer architecture. It:

Predicts the next most probable token (word/sub-word) in a sequence
Processes ~200K tokens of context (working memory)
Samples from probability distributions learned from training data
Has zero consciousness, intent, or feelings

What’s a Token? A token is the atomic unit of an LLM - the “pixel” of text processing. Averages ~3-4 characters, but varies widely: common short words are single tokens ("the", "is"), while longer or rare words split into subwords.

Why it matters:

Cost: LLM providers bill per token (input + output)

Context limits: The ~200K token window is your working memory budget

Performance: Token-efficient prompts = faster responses and lower costs

Rule of thumb: 1 token ≈ 0.75 words in English (Dutch runs slightly higher due to compound words like “aansprakelijkheidsrecht”). A typical source file runs 3K-15K tokens.

Think of it like an incredibly sophisticated autocomplete - one that’s read most of the internet and can generate convincing continuations of any text pattern it’s seen before.

Technical reality vs. marketing speak:

We Say (Metaphor)	What’s Actually Happening
”The agent thinks”	LLM generates token predictions through multi-head attention layers
”The agent understands”	Pattern matching against training data produces contextually probable output
”The agent learns”	Statistical weights update during training (NOT during your conversation)
“The agent reasons”	Breaking down problems into sequential token predictions that build on each other

Agent Software = Body (Execution Layer)

The LLM alone can only generate text. Plain old, deterministic, agent software wraps the LLM to enable action:

File operations: Read, Write, Edit
Command execution: Bash, git, run tests and linters
Code search: Grep, Glob
API calls: Fetch documentation, query legal databases

The LLM is the brains. The agent framework is the body.

When an agent “implements a feature,” here’s what’s actually happening:

LLM predicts “I should read the existing contract parser” → Agent executes Read(src/contract-analyzer.ts)
LLM predicts code changes → Agent executes Edit(file, old, new)
LLM predicts “run tests” → Agent executes Bash("npm test")
LLM analyzes test output → Predicts fixes → Loop continues

No magic. No consciousness. Just probability distributions driving tool execution.

Why This Matters for You as an Operator

Understanding the machinery prevents three critical errors:

Error 1: Assuming the agent “knows” things

Reality: It only sees current context (~200K tokens)
Your fix: Provide explicit context (covered in Lesson 3)

Error 2: Expecting the agent to “care” about outcomes

Reality: It executes your literal instruction to completion
Your fix: Be precise and include constraints (covered in Lesson 3)

Error 3: Treating it like a teammate instead of a tool

Reality: It’s a precision instrument that speaks English
Your fix: Maintain tool mindset (covered in Lesson 3)

Analogy: Operating an AI agent is like operating Legal Intelligence

You don’t get frustrated when Legal Intelligence returns irrelevant results from a vague search query. You refine your search terms, add filters, specify date ranges. The tool executes your instructions precisely - garbage in, garbage out.

Same with AI agents. They’re tools that execute language-based instructions with impressive fluency but zero comprehension. A poorly specified task produces poor output, regardless of how “smart” the underlying model is.

The Power (and Limitation) of “Fancy Autocomplete”

This might sound reductive, but it’s liberating:

Power: These token prediction engines are incredibly good at generating code patterns they’ve seen
Limitation: They have no model of correctness, only probability
Implication: Your job is to create verification systems (tests, types, lints) that catch probabilistic errors

You’re not managing a junior developer. You’re operating a sophisticated code generation tool that needs architectural guardrails.

Think of it like document review: you wouldn’t accept contract clauses generated by autocomplete without verification. Same principle applies here - the output needs systematic checking, not blind trust.

Summary

You’re learning to operate precision tools, not manage teammates. Understanding what AI agents actually are - LLMs (token prediction engines) wrapped in agent software (execution layer) - is fundamental to using them effectively.

The three operator errors covered above stem from anthropomorphizing these tools. Avoid assuming they “know” things, “care” about outcomes, or function like teammates. They’re sophisticated instruments that execute language-based instructions.

The next lesson covers agent architecture, execution workflows, and how your role as an engineer evolves into an operator.