You Are The Driver (The AI Is Just Typing)

I’ve been skeptical about AI coding tools for years. As someone who spent five years at Glitch watching people learn to code—really learn, from scratch, making mistakes and understanding why—the idea of tools that “write code for you” felt like it missed the point.

But I’ve been using AI agents daily for a few months now, and I’ve changed how I think about it. Not about the importance of understanding, if anything, I believe in it more than ever. What I’ve changed my mind about is what these tools actually are.

Mikayla Maki at Zed (my fav IDE!) wrote a fantastic post about working with agents that crystallized something I’d been feeling but couldn’t articulate. The framing that clicked for me: LLMs automate typing, not thinking.

That’s it. That’s the whole thing!

What I Mean By “Typing”

Here’s how I think about it now: imagine you have a collaborator who types incredibly fast and knows every API and syntax by heart, but has the attention span of a goldfish and the judgment of someone who just started their first week on the job.

You wouldn’t hand them a vague spec and disappear for a week. You’d sit with them, explain what you’re trying to accomplish, watch them work, and course-correct when they start wandering off in weird directions. When they finish a section, you’d review it carefully before moving on.

That’s what working with AI agents is. You’re not being replaced. You’re being given a very fast, very literal-minded pair of hands.

Keith’s LLM Rules

I’ve landed on a workflow that’s been smoothed out over months of trial and error. It comes down to three things.

Plan First, Always

The temptation is to just start prompting. “Add a feature that does X.” “Fix this bug.” “Refactor this module.” And sometimes that works! For small, well-defined tasks where you already know exactly what the implementation should look like. For most tasks, it will work 80% and you won’t realize the 20% that didn’t work.

But for anything substantial, I’ve learned to start with planning. I’ll write a PLAN.md file (or ask the agent to help me write one by interviewing me) that includes: what we’re trying to accomplish, what constraints we’re working within, which files are relevant, and what success looks like. This isn’t just documentation—it becomes context I can reference throughout the work.11 This is very much my “write a 20-page document before touching any code” energy that made me a bad fit for growth teams. Turns out it makes me a great fit for working with agents, who absolutely need that level of explicit context.

The planning phase is where I do the thinking. The agent helps me research, asks clarifying questions, points out things I might have missed. But the decisions are mine. By the time we start writing code, I should be able to predict roughly what the implementation will look like.

Break Things Into Small Pieces

Here’s where I diverge slightly from the “move fast” crowd: I keep tasks small enough that I can review everything the agent produces in one sitting. Not because I’m paranoid (okay, a little paranoid), but because agents have this tendency to quietly wander off course in ways that compound.

You’ll be three files deep into a refactor and suddenly realize the agent decided to “helpfully” restructure something unrelated, or left TODO comments where actual code should be, or solved a problem in a way that’s technically correct but completely wrong for your codebase.

Small tasks mean small blast radius. When something goes sideways—and it will—you haven’t lost a day’s work.

Review Like It’s Someone Else’s Code

This is the part people skip, and it’s the part that matters most.

Every line of agent-generated code needs your sign-off before it ships. I treat it like a PR from an external contributor who doesn’t know my engineering practices or values. Because that’s essentially what it is. The agent doesn’t know that we care about accessibility, or that we have strong opinions about error handling, or that a particular abstraction exists for reasons that aren’t obvious from the code alone.

Your name is on the code. Make sure you can stand behind it.

This Is Still A Craft

Here’s what I want to push back on: the narrative that AI is going to make programming obsolete, or that you can just vibe-code your way to a working application without understanding what you’re building.

During the government shutdown, I built crawlers to pull benefit information from state websites using AI tools. It was genuinely faster than doing it manually—what would have taken weeks took hours. But I couldn’t have done it without understanding web scraping, data cleaning, the structure of government websites, and how our users would actually use the information.

The AI handled the typing. I handled the craft.

That’s the opportunity here. Not “programming is dead” but “I can focus more on the parts that matter.” Writing thorough tests, building clean abstractions, thinking through edge cases—all the things that used to get squeezed out when you were racing to ship. The boring mechanical work gets faster, which means you can invest more in the parts that require judgment.

But only if you stay engaged. Only if you do the planning. Only if you review what comes out.

When To Be Skeptical

I’m still skeptical about a lot of AI claims. The “build an entire app with no coding knowledge” demos are impressive until you need to debug something, or handle an edge case, or integrate with a real system. At some point, someone has to understand what’s happening.

My rule: only use agents for tasks you already know how to do. If you couldn’t write it yourself (slowly, looking things up), you can’t effectively supervise an agent writing it for you. You won’t know when it’s going off the rails. You won’t catch the subtle bugs. You won’t be able to maintain it later.

This isn’t gatekeeping—it’s just practical. Learn the thing first, then use tools to do it faster.

What I Actually Use

I get asked about my setup a lot, so here’s what’s working for me right now.

Claude Code is my daily driver. It’s a command-line tool that lets me work with Claude directly from my terminal, and the agentic workflow means I can delegate larger chunks of work while staying in the loop. I’ve built a lot of project-specific skills—custom instructions that tell Claude how this particular codebase works, what patterns we use, what to avoid. It’s the planning-first approach, encoded into the tool itself.

For batteries-included structure, I use Superpowers by Jesse Vincent. It’s a skills framework that automates the workflow I described above: it forces the agent to ask clarifying questions before writing code, builds implementation plans you can actually review, and maintains a todo list that can be pulled back into context when things get complicated. The subagent-driven development process means Claude can work autonomously for longer stretches without wandering off course.22 The fact that it enforces true red/green TDD—write failing test, watch it fail, write minimal code, watch it pass—is also extremely my jam. Tests aren’t optional when an enthusiastic agent is writing your code.

Use new models when they come out. This sounds obvious but I see people sticking with older versions out of inertia or cost concerns. The models are improving fast, Opus 4.5 is wildly better at planning and maintaining context than previous versions. Yes, I still review everything. But the baseline quality keeps going up, which means I spend less time fixing obvious mistakes and more time on the interesting problems.

Read Simon Willison. Simon has been documenting his AI experiments in real-time for years now, with the kind of rigor and skepticism that’s rare in this space. He’s not trying to sell you anything; he’s just figuring out what works and sharing it. When I’m trying to understand a new capability or figure out if something is hype or real, his blog is usually my first stop.

The Craft Hasn’t Changed

Twenty years ago I was FTPing PHP files onto a shared hosting server and just seeing what happened. The tools were simpler but the fundamental work was the same: understand what you’re building, write it carefully, fix it when it breaks.

AI agents are just the latest in a long line of tools that promised to change everything. And like every tool before them, what they actually changed is the balance of where we spend our time. Less typing, more thinking. Less boilerplate, more design. Less mechanical work, more craft.

That’s a good trade. But you have to hold up your end of it.