Conversation Over Completion: What Claude Changes About Development Workflows

Steve Klabnik spent years as a core contributor to Rust, co-authored The Rust Programming Language with Carol Nichols, and has been thinking carefully about how tools shape developer practice for over a decade. His recent guide on getting started with Claude for software development is not a beginner tutorial or a product endorsement. It is a practitioner’s note about a workflow shift he has found worth sharing.

That is worth paying attention to, because Klabnik is not someone who writes breathlessly about new tools. When someone from the Rust community, where correctness and explicit reasoning matter above convenience, says they have changed how they work with AI assistants, it suggests something has shifted in what these tools can do.

The Completion Paradigm and Its Limits

Most AI coding tools are completion engines. GitHub Copilot watches what you are typing and suggests what comes next. Cursor wraps this in a VS Code fork with retrieval-augmented generation over your codebase. Aider goes further by maintaining git awareness, letting you work across multiple files with an LLM backend of your choice. All of these are genuinely useful, and all of them are fundamentally oriented around the idea that the developer steers while the AI fills in gaps.

This works well for routine code but falls apart on hard problems. When you are debugging an obscure interaction between your async runtime and a third-party library, or redesigning an API surface that needs to stay consistent across twenty callsites, you do not need autocomplete. You need something that can hold the full problem in context and reason about it with you.

What 200,000 Tokens Enables

Claude’s current models operate with a 200,000-token context window. For reference, 200,000 tokens is roughly 150,000 words, or around 15,000 to 25,000 lines of code depending on the language and density. A typical non-trivial service might have 5,000 to 30,000 lines across its core modules.

This means you can give Claude the relevant source files, your test output, the error trace, recent git history, and a description of what you are trying to do, and it can reason across all of that simultaneously. No retrieval step, no chunking, no hoping the right file made it into the context window.

Compare that to how RAG-based tools work. When Cursor indexes your codebase, it builds vector embeddings and retrieves the most similar chunks to your current query. This works well when you are looking for something you already know roughly what to search for. It breaks down when the relevant context is spread across files in ways that are not semantically similar, or when you need the model to understand the relationships between subsystems rather than just find related text.

Copilot’s workspace context feature has improved on this considerably, but it is still fundamentally a retrieval-first design. With Claude, for codebases of moderate size, you can often sidestep that problem by including what is needed directly.

Conversation Over Sessions

There is a second difference that is structural rather than merely quantitative. The way you get the most out of Claude is by maintaining a running dialogue about a problem, building up shared context over several turns rather than firing off single-shot prompts.

This changes how you approach a debugging session. Instead of “here is my error, fix it,” you might start with “here is the architecture, here is what I am trying to do, here is the error I am seeing.” Then follow up with clarifications, push back on suggestions that do not fit your constraints, ask Claude to explain its reasoning. The quality of output improves substantially because the model has more to work with.

Claude Code, the CLI tool Anthropic released in early 2025, formalizes some of this. It supports a CLAUDE.md file at the project root where you write persistent instructions: your preferred coding style, things to avoid, the testing framework in use, context about why certain architectural decisions were made. These instructions are loaded automatically at the start of every session. It is a simple mechanism, but it solves real friction, the need to re-explain your project’s context every time you start a new conversation.

A CLAUDE.md file for a small project might look like this:

# Project Context

This is a Discord bot written in TypeScript using discord.js v14.
Use ESM modules, not CommonJS. Tests use vitest.

## Architecture
- src/commands/ - slash command handlers
- src/events/  - Discord event handlers
- src/lib/     - shared utilities

## Constraints
- Do not use process.exit(); use graceful shutdown via ShutdownManager
- All database queries go through src/lib/db.ts, not direct Prisma calls in command handlers

Twenty seconds to write, and it removes a recurring source of prompt-level noise from every subsequent session.

Why a Systems Programmer’s Perspective Matters

The Rust community has a particular relationship with correctness. Rust developers are accustomed to tools that tell them when something is wrong, to type systems that prevent entire classes of bugs, to a culture of explicitness about assumptions. An AI coding tool that generates plausible-looking but subtly wrong code is arguably worse than no tool at all, because it substitutes false confidence for the rigor Rust programmers have been trained to apply.

Klabnik writing a guide on Claude suggests its behavior on correctness-sensitive code has gotten good enough to integrate into a workflow where correctness is taken seriously. That is a higher bar than whether it autocompletes boilerplate faster.

This lines up with something observable about how Claude handles uncertainty. When it does not know something or is making an assumption, it tends to say so and qualify the suggestion. For a developer who needs to understand their code rather than just make tests pass, that epistemic behavior matters. It does not eliminate errors, but it changes the character of the errors: you are more likely to be warned when Claude is uncertain than surprised when something quietly fails.

Where This Approach Has Limits

Large context is not infinite context. For very large codebases, even 200,000 tokens will not hold everything, and you still need to think carefully about what to include. Claude also cannot run your code, execute tests, or observe runtime behavior unless you provide that output explicitly. Aider’s integration with your editor and test runner is genuinely useful for tight feedback loops that Claude Code does not fully replicate yet.

Claude also makes mistakes on complex algorithmic problems, producing code that looks correct and compiles cleanly but contains subtle logic errors. The large context window helps catch some of these because Claude can check its own work against more of the surrounding code, but it does not eliminate the problem. The developer still needs to understand and verify the output, which means the tool works best for developers who have the context to evaluate what it produces.

The Practical Upshot

A more productive frame than “which AI tool autocompletes best” is “which tool helps me think through hard problems.” Claude’s combination of large context, strong reasoning, and conversation-oriented design makes it well-suited for the second task. The guide Klabnik published reflects that, and the audience he writes for, developers who care about doing things right rather than just doing things fast, is exactly the audience where this distinction matters most.

Working with Claude on Discord bot development and systems-level code, what I have found is that it works best when you treat it as a collaborator: describe the problem in full, share the constraints, push back on suggestions that do not fit. The context window matters because of what it makes possible, which is an extended technical conversation where you can work through a hard problem from multiple angles without losing the thread.