Lesson 9 – Agentic Coding using Claude Code

The power of repeatable automation

In modern software development, consistency across repeated tasks often determines long-term project health. Manually executing the same sequences of prompts leads to drift in quality, forgotten steps, and cognitive overhead that slows down even experienced engineers. The lesson tackles this problem head-on by introducing custom slash commands in Claude Code, a mechanism that captures entire multi-step workflows into single, invocable units. Rather than treating AI assistance as a one-shot interaction, the approach transforms it into an institutional memory layer, where best practices for seeding data, generating specifications, and implementing features become encoded once and reused indefinitely. This shifts the developer’s role from prompt composer to workflow architect.

The demonstration uses the Spendly application repository as a concrete sandbox, showing how theoretical concepts translate into real files and terminal sessions. By the end of the session, participants will have witnessed the complete lifecycle: identifying a repetitive bottleneck, capturing it as a markdown-based command file, testing it iteratively, and then chaining commands together to build increasingly sophisticated automation pipelines. The focus remains firmly on practical execution, with every concept immediately validated through live coding.

Understanding custom slash commands

A custom slash command in Claude Code functions as a templated interaction, defined in a markdown file that the agent interprets when invoked. This markdown file holds the exact instructions, context, and constraints that would normally be typed manually into the chat interface. The key insight is that these commands become part of the project’s codebase, living alongside the application they help build. This colocation means they benefit from version control, code review, and the same collaborative refinement as the rest of the code. When a new developer joins the team, they inherit not just the code but the standard operating procedures encoded in the slash commands.

The lesson distinguishes between project-scoped and user-scoped commands, a critical architectural decision that affects collaboration dynamics. Project-scoped commands sit in the repository and are shared across the team, ensuring uniform workflows for tasks like database seeding, code review, and test execution. User-scoped commands live in a developer’s local configuration and handle personal preferences or machine-specific shortcuts. Understanding when to elevate a personal script to a team-wide command avoids pollution of the shared space while still capturing genuinely reusable process knowledge.

When workflows cry out for automation

Not every interaction with an AI agent deserves its own slash command. The lesson outlines clear signals that indicate a task is ripe for command packing. Repeatability is the primary driver, tasks that are executed frequently with minimal variation are the strongest candidates. Consistency requirements come second, when multiple team members must perform the same operation and deviations cause downstream errors, a shared command acts as a guardrail. Complexity represents the third category, where multi-step sequences that are hard to remember or easy to misorder benefit enormously from encapsulation. Real-world examples explored include commit message generation, security review checklists, test suite execution pipelines, and the generation of structured specification documents.

The anti-pattern of constantly re-typing the same elaborate prompts is not just inefficient; it’s also fragile. Each manual invocation is an opportunity to miss a parameter, forget an edge case, or apply an outdated mental model. By investing a few minutes in crafting a well-tested command file, teams buy back hours of debugging and alignment conversations later. The lesson demonstrates this equation vividly with the seed commands that populate development databases with realistic user and expense data.

Building the seed commands step-by-step

A significant portion of the session builds two foundational commands: one for seeding user records and another for seeding expense records. Starting from a blank markdown file, the instructor walks through structuring the command with clear objectives, specifying the table schemas explicitly so the agent generates valid data, and defining success criteria that the command must meet before it can be considered complete. This deliberate, explicit approach contrasts with more casual prompting techniques, emphasizing that automation commands should function reliably without human oversight.

Testing becomes an integral part of the creation process, not an afterthought. After writing the initial command, the instructor runs it, observes the agent’s behavior, inspects the generated data, and refines the markdown file based on what didn’t work as expected. This iterative loop models how real-world command development should proceed. The seed commands ultimately produce consistent, random-but-plausible data that gives developers a realistic environment for testing new features without manual database population, saving minutes each day and preventing the drift that happens when different team members create their own ad-hoc test data.

Automating the spec generation pipeline

The most ambitious workflow demonstrated converts the creation of feature specification documents into a repeatable command. The instructor crafts a slash command named create-spec that takes a feature name as input and orchestrates Claude Code through the process of analyzing the existing codebase, understanding the architecture, and generating a structured specification document. This command doesn’t just dump a generic template; it reasons about the specific application context, examining models, routes, and existing patterns before producing a context-aware spec.

The registration feature serves as the real-time test case. The command generates a spec that includes user stories, technical requirements, API endpoint designs, and acceptance criteria, all aligned with the Spendly application’s conventions. The instructor then reviews the generated document, demonstrating how to quality-check an AI-generated spec as a senior engineer would review a junior’s work. This review step is crucial: it reinforces that automation amplifies judgment rather than replacing it, and that custom commands should produce artifacts that are reviewed and refined, not blindly accepted.

From spec to implementation via plan mode

The workflow doesn’t stop at documentation generation. The lesson connects the spec into Claude Code’s plan mode, a feature designed to convert high-level descriptions into structured implementation plans that the agent can then execute. The transition illustrates a complete development loop: capture requirements as a command-generated spec, review and approve the spec, feed it into plan mode for technical decomposition, review the generated plan for architectural soundness, and then instruct the agent to implement the plan while you observe and intervene as needed.

This pipeline mirrors mature software engineering practices like Request for Comments processes or design-doc cultures, but compresses their cycle time dramatically. Where traditional workflows might require days of meetings and document shuffling before any code is written, this approach produces working code from a feature idea within a single session. The key enabler is the trust established by the consistent structure of the custom commands, because the spec is always generated with the same quality standards, plan mode receives input it can reliably decompose into actionable steps.

The cultural shift towards agentic coding

Beyond the mechanical techniques, the lesson advocates for a mindset shift that redefines the developer’s role when working with AI tools. Agentic coding means moving from prompting to engineering, from asking the AI for help to building systems where the AI operates within constraints you've designed. The custom slash command becomes the unit of encapsulation for this engineering discipline, analogous to how functions encapsulate logic in traditional programming.

This approach demands new skills. Developers must learn to write clear, comprehensive command files that account for edge cases and failure modes. They need to design command hierarchies where high-level commands compose lower-level ones, building a library of capabilities that grows with the project. The lesson points toward a future where a team’s competence is measured partly by the quality of its AI command library, a living asset that encodes hard-won process knowledge and accelerates every subsequent hire. The Spendly repository serves as a minimum viable example of what such a library looks like in practice.

What this means for full-stack productivity

The techniques demonstrated have the most immediate impact on full-stack web development workflows, where the cycle of ideate-specify-implement-test repeats across many features. By collapsing the specification and technical plan phases into commands, developers reclaim hours previously spent structuring documents and aligning on approaches. The seed commands solve the perennial problem of maintaining realistic development databases, reducing the friction of starting new work or resetting environments.

The broader lesson is that AI-assisted development matures only when paired with thoughtful automation architecture. Scattered use of AI for isolated tasks provides incremental benefits, but systematic command packaging multiplies those benefits across teams and time. As the session concludes, the natural next step is to explore other areas where repeatability yields compound returns, from deployment scripts to incident response runbooks, applying the same slash command pattern to ever more critical and complex engineering workflows.