Lesson 12 – Agentic Coding using Claude Code

The Evolution of Agentic Workflows

Claude Code offers a powerful command-line interface for agentic coding, but its built-in agents often fall short when you need specialized, repeatable workflows that follow strict project standards. The introduction of custom subagents changes this paradigm by allowing developers to define purpose-built agents that operate with precise instructions and tool access. This approach moves beyond generic assistance toward a modular, composable architecture where each task in a pipeline has a dedicated agent responsible for a specific outcome. The progression from a single intelligent assistant to a team of coordinated specialists mirrors how large-scale software projects are actually built, with different team members owning distinct responsibilities like testing, security review, and code quality.

Understanding why this matters requires looking at real-world constraints. Built-in agents behave according to general patterns learned during training, but they lack awareness of your team's coding standards, security requirements, or testing frameworks. A generic code review agent might comment on style and logic, but it won't enforce your organization's policy against hardcoded credentials or verify that every endpoint has been tested. Custom subagents solve this by embedding domain-specific rules directly into their system prompts, turning them into reliable guardians that enforce consistency across every pull request.

Defining Custom Subagents with Markdown and YAML

The architecture of a custom subagent rests on a simple yet flexible foundation: a markdown file containing a metadata block and freeform instructions. The frontmatter, written in YAML, declares the agent's name, a description used for automatic triggering, and an explicit list of allowed tools. This explicit tool gating is crucial for security and predictability—a test runner subagent, for example, might only need shell and file read/write access, while an audit agent might be restricted to read-only operations. After the frontmatter, the body of the file becomes the system prompt, where you define the agent's persona, its step-by-step methodology, and the exact standards it must enforce.

The distinction between project and personal subagents adds an organizational dimension to this system. Project subagents live inside a `.claude/commands` directory at the root of a repository, making them part of version control and shared across the team. This ensures that every developer contributing to the project benefits from the same specialized workflows. Personal subagents, meanwhile, reside in a global configuration directory and travel with you across all projects—useful for tasks like personal note formatting or your own preferred commit message style. The video emphasizes that this dual structure prevents project-specific instructions from leaking into unrelated work while still allowing individual customization.

Triggering Mechanisms and Slash Commands

Custom subagents come to life through two distinct triggering methods. The first is automatic invocation, where Claude Code analyzes the intent of your request and decides which subagent is best suited to handle it. This works well for broad task categories, like asking Claude to "review this feature for security vulnerabilities" when a security-focused subagent exists. The second method is manual triggering via slash commands, which gives you explicit control over which agent runs at each stage of a workflow. Typing `/test-writer` or `/security-review` invokes the corresponding subagent outright, bypassing any ambiguity about which instructions apply.

The practical workflow demonstrated in the video uses slash commands to chain multiple subagents together in a defined sequence. Starting from a feature specification, the developer first calls a test writer subagent to generate comprehensive test cases for a new profile page component. Once the tests are written, a test runner subagent executes the suite, captures output, and summarizes failures in a structured format. The output of this agent then flows into a code quality review agent and finally a security audit agent, each adding its layer of scrutiny. This pipeline transforms a manual, multi-step process into a repeatable, single-session interaction that maintains context across all stages.

Building a Scalable Testing Pipeline

The centerpiece of the practical example involves constructing agents for test writing and test execution. The test writer subagent is instructed to analyze the feature specification, understand expected behaviors, and produce test files that follow the project's particular testing framework conventions. It doesn't just generate arbitrary assertions; it must understand edge cases, frontend rendering logic, and how to mock external dependencies. The prompt for this agent includes rules about file naming, import patterns, and the expected structure of test blocks, effectively encoding the team's testing playbook into a reusable digital asset.

The test runner subagent takes a different shape. Its instructions center on executing commands, parsing output, and reporting results in a human-readable format that highlights failures and potential root causes. Rather than simply dumping raw terminal output, it's instructed to categorize issues and suggest next debugging steps. This division of labor between a writer and a runner illustrates a fundamental design principle for agentic pipelines: each agent should own a narrow, well-defined responsibility. When responsibilities are cleanly separated, you can independently improve the test writer's prompt to catch more edge cases without altering how tests are run and reported.

Adding Security and Quality Reviews

Beyond simple test execution, the workflow introduces specialized review agents that target distinct aspects of code health. A security audit subagent is programmed to scan for common vulnerability patterns like SQL injection vectors, insecure deserialization, improper session handling, and exposed secrets. Its system prompt likely includes a checklist of the OWASP top ten vulnerabilities and explicit instructions to check for project-specific anti-patterns, such as direct database access from controller code or missing input sanitization layers.

A code quality subagent runs in parallel, focused on readability, maintainability, and adherence to style guides. It checks for function length limits, cyclomatic complexity, proper error handling, and documentation completeness. By separating security from quality, each agent can have a narrower, more focused prompt that reduces hallucination and improves reliability. The two agents can run simultaneously, and their outputs can be combined into a single comprehensive review document that the developer uses to harden the feature before merging. This parallelization demonstrates how custom subagents enable faster feedback cycles without sacrificing thoroughness.

Structuring Subagent Documentation for Reuse

A recurring theme in building effective subagents is the value of clear, structured documentation within the prompt itself. The video demonstrates how to write agent instructions that are both precise and pedagogical, explaining not only what to do but why certain checks matter. This "teaching" approach makes subagents more robust when encountering novel code patterns, as they can reason from first principles rather than just pattern-matching against a checklist. Including examples of good and bad code in the prompt gives the agent concrete references that reduce ambiguity about what constitutes a violation.

Another practical insight is the use of output formatting rules within subagent prompts. A security audit agent might be instructed to produce a JSON report with specific fields like severity, file path, line number, and recommendation. This structured output makes it possible to programmatically process the agent's findings in downstream steps, integrating AI-generated content into CI/CD pipelines or dashboard systems. The custom subagent system essentially creates a contract between the human intent and machine-readable output, bridging the gap between conversational AI and automated software engineering.

Toward Fully Autonomous Development Pipelines

The workflow demonstrated in this video represents a stepping stone toward fully autonomous development environments where AI agents collaborate under human supervision. By decomposing a large task like "build this feature and ensure it's production-ready" into discrete subagent-managed steps, the cognitive load on the developer decreases dramatically. Instead of context-switching between writing tests, running them, debugging failures, and performing manual code review, the developer orchestrates a team of agents and focuses on high-level decisions and edge cases that require human judgment.

The modularity of this system also makes it inherently scalable. As new project requirements emerge, you can add new subagents to the pipeline without reworking existing ones. A performance benchmarking agent might be added after the security review step, or an accessibility audit agent could run in parallel with code quality checks. Each agent is a self-contained file that can be version-controlled, discussed in pull requests, and iteratively refined based on real usage data. Over time, the team accumulates a library of battle-tested digital specialists that encode the project's collective engineering wisdom.