Steve Klabnik, best known as co-author of The Rust Programming Language and a former member of the Rust core team, recently published a guide to getting started with Claude for software development. His credibility in the systems programming world is real, and when someone with that background writes up their tooling workflow, it’s worth reading. But the guide is also a starting point, not a destination. The more interesting question is why this category of tool represents something structurally different from what came before.
The Autocomplete Era Is Closing
For a few years, AI coding assistance meant inline suggestions: you type, the model guesses the next token. GitHub Copilot popularized this, and the experience is genuinely useful in narrow ways. It’s good at boilerplate. It reduces the friction of writing a function signature you already know. It saves keystrokes.
But it’s fundamentally a text completion tool sitting inside an editor. The model sees a small window of context, typically a few thousand tokens, and predicts forward. It doesn’t understand your project’s architecture. It doesn’t know that you switched from REST to gRPC three months ago. It doesn’t remember that you have a convention around error types or that a particular module is scheduled for deprecation. Every session starts cold.
Claude Code operates differently. It’s a terminal tool that works with your entire repository. The context window in Claude 3.5 Sonnet and the newer Claude 3.7 Sonnet is 200,000 tokens. For reference, 200k tokens is roughly 150,000 words, or a medium-sized novel. That covers most real codebases in their entirety. Rather than guessing the next line, Claude can read your whole project, understand its structure, and then make surgical edits across multiple files simultaneously.
This isn’t a quantitative improvement on autocomplete. It’s a different kind of tool.
CLAUDE.md: Documentation as Configuration
One of the most underappreciated pieces of the Claude Code workflow is the CLAUDE.md file. You place it in your project root, and Claude reads it at the start of every session. It’s essentially a context document written for the model rather than for humans.
A minimal CLAUDE.md might look like this:
# Project: my-discord-bot
This is a Discord bot written in TypeScript using discord.js v14.
The bot uses slash commands registered via the REST API at startup.
## Conventions
- All command handlers live in src/commands/
- Use zod for all input validation
- Errors are wrapped with the AppError class in src/errors.ts
- Do not use any. We run with strict TypeScript.
## Do not touch
- src/legacy/ — this code is being migrated and should not be modified
## Testing
- Run tests with: npm test
- Integration tests require a .env.test file (see .env.example)That’s it. But that file does a lot of work. It tells Claude your stack, your conventions, where things live, and what’s off-limits. Without something like this, you’ll spend a lot of prompts correcting the model’s assumptions. With it, Claude can operate with much more autonomy from the start.
Klabnik’s guide emphasizes this setup step, and he’s right to. The CLAUDE.md file is the single highest-leverage thing you can write before asking Claude to touch your code. Think of it as the onboarding documentation you’d write for a new engineer who will never ask clarifying questions unless you explicitly tell them to.
You can also nest CLAUDE.md files. A file at src/api/CLAUDE.md can provide context specific to the API layer without cluttering the root document. For large projects with multiple distinct subsystems, this composability matters.
The Agentic Loop
What makes Claude Code distinctly agentic rather than just “LLM with more context” is the tool use loop. Claude can read files, write files, run shell commands, and read their output, all within a single session. You can describe a task at a high level, and it will figure out what files to read, what changes to make, and then verify its work by running your tests.
A session might go:
- You: “Add rate limiting to the
/api/searchendpoint. Use the existing Redis client.” - Claude reads the route file, the Redis client module, and any existing middleware.
- Claude writes the rate limiting middleware.
- Claude modifies the route to use it.
- Claude runs
npm testand reads the output. - If tests fail, Claude reads the failure output and iterates.
None of this requires you to paste code into a chat window or explain where the Redis client lives. Claude discovers that itself. The workflow is closer to delegating a task to a junior engineer than it is to using a text editor.
This is also where the failure modes differ from autocomplete. When autocomplete gets something wrong, it’s usually obvious: the suggestion doesn’t compile or is clearly wrong. When an agentic tool gets something wrong, it might produce a plausible-looking change across five files that introduces a subtle bug. The review step becomes more important, not less. Claude Code outputs diffs before applying them, and reading those diffs carefully is a new skill the workflow demands.
SWE-bench and What Benchmarks Actually Tell You
Claude’s performance on SWE-bench Verified, the standard benchmark for evaluating AI systems on real GitHub issues, has been a meaningful signal. Claude 3.7 Sonnet with extended thinking scored around 70% on SWE-bench Verified in early 2025, which placed it among the top-performing models on that benchmark at the time. For comparison, GPT-4o sat closer to 38-48% on comparable evaluations, and earlier Claude models were in the 40-50% range.
SWE-bench is a reasonable proxy for agentic coding tasks: it tests whether a model can read a real codebase, understand a bug report, and produce a patch that makes tests pass. It’s not a perfect benchmark, and benchmark optimization is a real concern. But the performance gap between top models and the rest of the field reflects something real about context handling and reasoning quality.
For practical use, this means Claude handles the kind of “find the bug, fix the bug” task reasonably well on moderately complex codebases. It struggles more with tasks that require deep architectural knowledge the CLAUDE.md can’t fully capture, or with highly ambiguous requirements.
Extended Thinking
Claude 3.7 Sonnet introduced extended thinking, which allows the model to reason internally before producing output. For coding tasks, this shows up most clearly on problems that involve non-obvious design decisions: “How should I structure this to make it testable?” or “What’s the right way to handle backpressure here?”
You trigger it by asking Claude to think through a problem before responding. The model produces a visible reasoning trace that you can read, which is useful for debugging why it made a particular choice. Extended thinking increases latency and token cost, so it’s not the right tool for every task, but for architectural decisions or tricky debugging, it changes the quality of output noticeably.
Klabnik mentions thinking mode in his guide. I’d add that it’s particularly useful on initial design questions where you’re still figuring out the structure of something, and less necessary once you’re in implementation mode and the shape of the solution is clear.
What Doesn’t Change
None of this replaces the need to understand what you’re building. The developers getting the most out of agentic tools are the ones who can read the generated code critically, catch conceptual errors, and provide precise feedback. If you don’t understand why a piece of code is wrong, you can’t correct Claude effectively.
The workflow also doesn’t eliminate design work. Claude is good at implementation within a defined structure. Defining that structure is still your job. A poorly specified task produces plausible-looking output that solves the wrong problem. The prompt engineering skill that matters most isn’t cleverness with syntax; it’s the ability to describe what you actually want precisely enough that an intelligent system can execute it without guessing.
For my own work building Discord bots and tooling in Rust and Go, the workflow has settled into a pattern: I handle the design and architecture, write the CLAUDE.md to capture the decisions I’ve made, and delegate implementation of well-specified components. For anything touching concurrency, external APIs, or security-sensitive logic, I read the output more carefully than I do for utility functions or CLI scaffolding.
Getting Started Without Getting Lost
Klabnik’s guide is a good practical entry point. The key things to take from it: install Claude Code, run /init to generate an initial CLAUDE.md, refine it to match your actual conventions, and then give it a modest task to see how it behaves on your specific codebase.
The harder thing to internalize is that the workflow shift is real. You’re not just adding a smarter autocomplete. You’re adding a tool that can act on your codebase at scale, which means both more leverage and more responsibility to review what it produces. The developers who will find it frustrating are the ones who expect it to work like a search engine that returns code. The developers who will find it genuinely useful are the ones who treat it like a capable but literal-minded collaborator who needs clear direction and careful oversight.
That balance between delegation and review is still being worked out across the industry. But we’re past the point where the answer is “AI coding tools are gimmicks.” The question now is how to use them well.