Chapter 4: Agent Mode (The Way That Works)

Dijkstra said the programmer should let correctness proof and program grow hand in hand. In agent mode, they do. The specification and the implementation emerge together, each informing the other.

I Stopped Fighting

This chapter describes my workflow. Your path will differ. What works for my brain, my projects, my thinking style may not work for yours. Cursor, Windsurf, GitHub Copilot, or dozens of other approaches might serve you better. One data point in a rapidly evolving landscape.

I tried autocomplete. Copilot, inline suggestions, the whole predictive typing dance. Everyone said it was revolutionary.

It drove me insane.

I do not think in fragments. I do not think in lines. I think in systems. In architectures. In complete solutions to complete problems. The constant interruption of suggestions mid-thought felt like someone whispering answers during an exam. Helpful in theory. Distracting in practice.

So I stopped fighting and found what works for me. Agent mode. Not code completion. Not inline suggestions. Full delegation to Sonnet with the freedom to explore, implement, and solve problems end-to-end.

The Agent Mode Mindset

Instead of “complete this line,” you say “solve this problem.” Instead of accepting or rejecting suggestions every few seconds, you specify the outcome and let intelligence manifest it. Instead of dancing with autocomplete, you are delegating architecture.

When I need to build a data pipeline for my blog, I do not start typing def transform and wait for Copilot to finish my thought. I open Claude Code and describe the system I want to exist.

“Build a Python content processing pipeline that reads markdown from editing/revisions/, extracts metadata, processes images for responsive sizes, and populates Neo4j with content relationships. Handle errors gracefully. Make it fast.”

And Sonnet builds it.

Not line by line. Not suggestion by suggestion. End to end. Architecture, implementation, error handling, the works.

This isn’t because I’m lazy. It’s because I can think at the architecture level while the implementation happens in parallel.

The Tools

My workflow involves two complementary tools. VS Code for review and refinement. Claude Code from the command line for building. Others find similar success with Cursor’s agent mode, Windsurf, or other IDE integrations. The principle of separation between review and generation matters more than the specific tools.

VS Code is where I read code. Where I understand systems. Where I refine implementations. Not where I write them. I open a Python script that was AI-generated. Read through the logic. Understand the architecture. Spot edge cases that need handling. Identify optimizations. Then I describe what needs to change, and the agent makes it happen. VS Code is my lens into the codebase. My thinking space.

The command line interface is where the work happens. I describe what I want. The AI builds it. I review in VS Code. Refine the specification. The agent updates it. The CLI keeps me focused on outcomes, not keystrokes. On systems, not syntax.

# Typical workflow example
claude-code "optimize the image processing pipeline to handle WebP conversion in parallel"

# Review in VS Code
# Refine

claude-code "add caching so unchanged images skip processing entirely"

# Iterate until it's right

This separation matches how my brain works. I do not want to write code. I want to architect systems. The tools should match the thinking. Find the combination that matches yours.

Unattended Mode

The most powerful discovery: running AI agents in unattended mode inside containers.

When I have a well-defined problem but want to explore multiple solutions, I spin up a container and let the AI experiment overnight. “Here is the content processing pipeline. Find the bottlenecks. Try three different optimization approaches. Document the results.”

I wake up to a report comparing sequential vs. parallel processing vs. incremental updates, complete with benchmarks, trade-off analysis, and working implementations of each.

This is fundamentally different work. I am not implementing solutions. I am specifying experiments and reviewing results. The container keeps experiments isolated. Unattended mode means I am not waiting. The agent explores thoughtfully, not by brute force.

This workflow will not appeal to everyone. Some developers prefer tighter loops and more direct control. Know yourself.

Architecture-First

Some developers think in lines of code. They see the solution as they type it. Autocomplete makes perfect sense for them.

I think in systems. In data flows. In architectures. By the time I am ready to implement, I already know what needs to exist. The typing is just transcription. And transcription is exactly what AI should handle.

“Build AWS CDK infrastructure for static site hosting with CloudFront distribution, S3 origin, and automated deployment from GitHub actions.”

Sonnet understands this. Not because it is smarter than autocomplete, but because the instruction is complete. Architectural intent, not partial syntax. The implementation that emerges handles details I would have gotten wrong or forgotten. CloudFront cache invalidation, S3 versioning for rollback, proper IAM policies, error handling in deployment scripts. Not because I prompted for each detail. Because agent mode thinks in complete solutions.

Model Choice: What Works for My Use Case

I’ve tried different models in agent mode. GPT variants, Claude models, others as they emerge.

For my workflow (systems architecture and end-to-end implementations), Claude Sonnet consistently produces the most coherent systems.

Not necessarily the cleverest code. Not always the most optimized algorithms. But the most thought-through architectures for my use cases.

When building a content processing pipeline, Sonnet does not just transform markdown to HTML. It considers what happens when a file is malformed. How to handle images that do not exist. What if two posts reference each other cyclically. How to make this fast without making it fragile.

This systems thinking is why I stick with Sonnet for my agent mode work. It builds like an architect, not like a code generator.

Your mileage may vary. GPT-4 might excel at different tasks. Newer models will undoubtedly shift this landscape. The key is finding the model that thinks most compatibly with how you think.

Sonnet 4.5: My Current Default

At the time of this writing, Sonnet 4.5 is the model I use for almost everything in agent mode.

It handles complex architectural decisions. It maintains context across long implementations. It asks clarifying questions when my specifications are ambiguous.

Not because it’s objectively “the best” on some benchmark. Because it thinks compatibly with how I think. In systems. In implications. In trade-offs.

When I specify Neo4j integration for content relationships, it doesn’t just write Cypher queries. It designs a schema that makes sense, handles relationship updates gracefully, includes transaction boundaries for consistency.

This is architecture, not code completion.

(By the time you read this, newer models will exist. The principles matter more than the specific version numbers.)

The Review Cycle

The combination of a review environment and an agent tool creates a workflow that matches how I actually think. Specify what needs to exist. Let AI build the complete implementation. Review in your IDE with full context. Refine the specification based on what you see. Iterate until it is right.

This cycle respects how understanding actually develops. You cannot fully specify a solution before you see it. You need to iterate. But iteration at the architecture level, not the line level.

The IDE gives you the full codebase view. Multiple files open. Full context. Understanding how pieces fit together. The agent tool gives you the implementation power. Together, they let you work at the level of “what should exist” instead of “how to type it.”

Different Models for Different Thinking

Sonnet handles implementation in agent mode. But for research and conceptual exploration, I sometimes use GPT or other models.

When I am trying to understand graph database modeling approaches, I do not jump to implementation. I explore the conceptual space first. “Compare event sourcing vs. snapshot models for content versioning in Neo4j. What are the trade-offs?” Some models excel at broad conceptual analysis, pattern recognition across domains, helping you think through approaches before committing. Then I take the insights back to my implementation agent.

Different models serve different cognitive needs. One for divergent thinking. Another for convergent building. Your combination will be different from mine.

The Container Experiment Pattern

Running AI agents in unattended mode inside containers has become one of my favorite techniques for tackling ambiguous problems.

The Setup (Example with Claude Code)

# Example: Spin up container with agent tool
docker run -it --rm -v $(pwd):/workspace anthropic/claude-code

# Inside container, run in unattended mode
claude-code --unattended --task "optimize-content-pipeline.md"

(Other agent tools have similar capabilities. The pattern matters more than the specific implementation.)

The Experiment Task File

# Task: Content Pipeline Optimization

## Context
Current pipeline processes all markdown files sequentially.
Build times have grown from 2 minutes to 15 minutes.
Processing includes: markdown parsing, image optimization, Neo4j updates.

## Experiment Goals
1. Identify actual bottlenecks (don't assume)
2. Implement 3 different optimization approaches
3. Benchmark each with real content
4. Document trade-offs

## Success Criteria
- Build time under 5 minutes for full rebuilds
- Incremental builds under 30 seconds
- No regression in output quality
- Maintainable code (we'll be living with this)

## Constraints
- Must work with existing AWS CDK infrastructure
- Can't break Neo4j relationship integrity
- Need to handle both full and incremental builds

What I Wake Up To

A complete report. Bottleneck analysis showing it was image processing, not Neo4j. Three working implementations: parallel processing, caching, and a hybrid approach. Benchmark results with actual numbers. Trade-off analysis for each. A recommendation with reasoning.

Actual exploration happening while I sleep. Your results may vary. This requires trust in your agent, good containerization, and clear specifications.

Why This Works (For Me)

Autocomplete optimizes for line-by-line productivity. Agent mode optimizes for system-level thinking.

I do not care about typing speed. I care about architectural clarity. About building systems that work. About solving problems completely rather than incrementally.

When an AI agent builds a complete AWS CDK stack, it is not faster because it types faster. It is faster because it considers the entire system at once. CloudFront configuration that matches S3 bucket settings. IAM policies that grant exactly the right permissions. Deployment scripts that handle failures gracefully. Error handling that cascades properly. These are systemic properties that emerge from specifying complete outcomes.

If you prefer the tighter feedback loop of autocomplete, that is equally valid. Different tools for different minds.

The Learning Curve

Agent mode has a different learning curve than autocomplete. Autocomplete: learn to accept and reject suggestions quickly, builds on existing typing skills. Agent mode: learn to specify outcomes clearly, requires architectural thinking.

For developers who think in systems, agent mode is immediately intuitive. You already think this way. The tool finally matches the thinking. For developers who think in lines, autocomplete makes more sense. Neither is better.

I tried autocomplete for months. It never felt natural. Agent mode felt right immediately. Because it matched how I already think about problems.

Building Trust

Agent mode requires trust in ways autocomplete does not. With autocomplete, you see every suggestion. You are always in control. With agent mode, you are delegating complete implementations.

Start with small, well-defined tasks. “Add error handling to this function.” “Optimize this database query.” “Generate test cases for this module.” Review the output carefully. Understand how Sonnet thinks. Gradually increase delegation. “Refactor this module for better performance.” “Build a caching layer for this API.” “Create AWS CDK infrastructure for static hosting.” Eventually you are delegating entire systems. Content processing pipelines. Graph database schemas. End-to-end deployment automation.

Trust does not come from blind faith. It comes from validated experience.

Practical Patterns

The Specification File

Create a markdown file describing what should exist:

# Content Processing Pipeline

## Purpose
Transform blog posts from markdown to deployed static site with graph database integration.

## Components
1. Markdown processor: Parse frontmatter, extract metadata, render HTML
2. Image optimizer: Convert to WebP, generate responsive sizes, update references
3. Graph builder: Map content relationships in Neo4j
4. Deployment orchestrator: Coordinate AWS CDK deployment

## Quality Gates
- All images under 200KB
- Build time under 5 minutes
- No broken internal links
- Neo4j relationships match content reality

Feed this to Claude Code in agent mode. Let Sonnet build it.

Specify the initial system. Review the implementation. Identify gaps or improvements. Refine the specification. Iterate until satisfied. This is not waterfall. It is iterative architecture. But iteration happens at the system level, not the line level.

The Unattended Experiment

When you have time but not clarity: write the experiment specification, launch in a container with unattended mode, do other work or sleep, review results, choose direction based on evidence. Let Sonnet explore the solution space while you explore the problem space.

What I Have Built This Way

In the past six months using agent mode with Sonnet: a complete Astro blog content management system with markdown processing, Neo4j integration for content relationships, automated image optimization, and AWS CDK infrastructure. Build time, three minutes for 200+ posts. A data processing pipeline with ETL from multiple APIs to graph database, error handling with retry logic, performance optimizations, and monitoring. Deployment automation with GitHub Actions, infrastructure as code, rollback capabilities, and health checks.

None of this was typed line by line. All of it was specified architecturally and implemented by Sonnet in agent mode.

The Mental Shift

The hardest part of agent mode is not the tools. It is the mental model. You have to stop thinking like an implementer and start thinking like an architect. Not “how do I write this code” but “what system should exist.” Not “what is the syntax” but “what are the constraints and requirements.” Not “let me type this” but “let me specify this outcome.”

This feels unnatural at first. We are trained to equate programming with typing. Agent mode asks you to let go of the typing and focus on the thinking.

For some developers, this feels like loss of control. For others, it feels like finally working at the right level of abstraction.

Why Not Both

People ask why I do not use both. Autocomplete for some tasks, agent mode for others.

Because the mental models conflict. Autocomplete keeps you in line-by-line thinking. You are always half-waiting for the next suggestion, half-evaluating whether to accept or reject. Agent mode requires complete architectural thinking. You cannot specify a system while thinking in lines. Switching between them creates cognitive whiplash.

I chose agent mode because my brain works in systems. Your choice might be different. But trying to use both simultaneously fragments your thinking.

Already Here

Agent mode is not some future technology. Multiple tools can build complete systems from architectural specifications right now. Claude Code, Cursor, aider, Windsurf.

The limitation is not the technology. It is whether this style of work matches how you think. Can you specify what should exist without specifying how to build it? Can you review a complete implementation and identify what needs refinement? Can you trust delegation enough to let AI work while you think?

If yes, agent mode might transform how you work. If no, autocomplete might serve you better. Neither is superior.

Beyond Development

What started as a development workflow evolved into something deeper. Agent mode is not just how I build software. It has become how I think, how I work, how I reflect.

I converted my personal journal into a VS Code repository integrated with agent mode. Every thought, every reflection, every insight captured in markdown with agent collaboration available. Not to write for me. To help me think more clearly, organize more systematically, explore ideas more thoroughly. Then came work. Migrated from OneNote to VS Code repos. Meeting notes, project documentation, strategic planning, all living in an environment where I can invoke agent mode to synthesize patterns, identify gaps, refine thinking.

The entirety of my existence and reflection now often happens in this realm. Every morning intention. Every evening review. The agent helps me see patterns I would miss. Connections I would not make. Questions I should be asking but was not.

This only works because it is balanced.

Exercise keeps me grounded in the physical. Meditation anchors me in presence. Family reminds me what matters beyond systems and optimization. Animals teach me about connection that transcends language. Real-world experiences keep a toe on this planet, showing me where things still are, what remains true outside the digital realm.

You temper metal on a hot iron. The heat transforms the material, but you need the anvil too. The resistance. The real world pushing back against the malleable digital.

Agent mode amplifies my thinking. It does not replace my living. The danger is letting these tools become the only realm you inhabit. The only way you think. The only mirror through which you see yourself and the world.

I live in agent mode for work and reflection. I live in life for everything that makes work and reflection worth doing. We are on a rock hurtling through space, and the agent does not think for me. It thinks with me.

Next: Chapter 5: The Socratic Partner (Conversational Mode)

← Previous: Chapter 3: Git for the Agentic Age | Back to AgentSpek

This chapter is part of AgentSpek: A Beginner’s Companion to the AI Frontier. All content is protected by copyright. Unauthorized reproduction or distribution is prohibited.

Sources and Further Reading

This chapter builds on Edsger W. Dijkstra’s “The Humble Programmer” (ACM Turing Award Lecture, 1972), particularly his insight that “the programmer should let correctness proof and program grow hand in hand.” In agent mode, the correctness proof and implementation can grow together through specification-driven development.

The discussion of different cognitive styles in programming draws from research in cognitive psychology, particularly work on systematic versus intuitive thinking, though applied here to the choice between autocomplete and agent-based development.

For those interested in architectural thinking, Christopher Alexander’s “Notes on the Synthesis of Form” (1964) provides foundational concepts about separating design intent from implementation details.

Douglas Engelbart’s “Augmenting Human Intellect” (1962) envisioned computers amplifying human thinking rather than replacing it. Agent mode realizes this vision by handling implementation while humans focus on architectural thinking.

For practical implementation, current documentation for Claude Code and Anthropic’s agent capabilities provides technical details, though the field evolves rapidly as agent capabilities improve.