Background
I have been using Claude Code as my primary development environment for 18 months. This is not supplementary AI tooling — it is the core workflow, with traditional IDEs as secondary tools for specific tasks (visual debugging, database inspection).
This post is a practical account of how I work, not an argument for why you should work this way. The workflow suits a specific profile: contract developers working on well-scoped problems with a clear technical vision. It may not suit everyone.
The workflow
Session structure
Every Claude Code session begins with a context-setting message that describes the project, the current state, and the specific task for the session. This is not optional — a cold start without context produces generic code that needs significant revision. A warm start with precise context produces code you can ship.
My context messages follow a consistent format:
- Project: what it is, tech stack, key architectural decisions
- Current state: where things stand, what was done in the last session
- This session: the specific task, the constraints, what success looks like
The context investment at the start of a session pays back in reduced correction cycles throughout the session.
The design-first discipline
Claude Code makes implementation fast. This is dangerous if it tempts you to skip design. The fastest path to bad code is to implement before you have thought clearly about what you want.
My rule: no code until I can describe the interface precisely. Function signatures, data schemas, the contract between components — these are designed and reviewed before implementation begins. Claude Code helps with this design phase through critique and questions, not code generation.
Test-first as a quality gate
I write tests before generating implementations. This is not just good practice — it is a quality control mechanism for AI-generated code. A generated implementation that passes a comprehensive test suite is a different level of confidence than one that you have reviewed but not tested.
The test-generation workflow: describe the function's behavior precisely, generate tests that cover the happy path and the key failure modes, then generate the implementation. When the implementation does not pass the tests, the failure is a signal to fix the implementation, not the tests.
"Tests written after implementation tend to test what the code does. Tests written before implementation test what the code should do. The difference matters."
Code review cadence
Every generated code block is reviewed before it enters the codebase. This sounds obvious; in practice, the review discipline weakens under deadline pressure. Maintaining it consistently is the difference between a codebase you trust and one you are afraid to change.
My review checklist for generated code:
- Does it do what I asked?
- Does it handle the failure modes I care about?
- Is it consistent with the conventions in the rest of the codebase?
- Are there implicit assumptions I did not specify that might be wrong?
The last item catches the most bugs.
What Claude Code is bad at
Novel algorithmic problems
When the solution requires a genuinely novel approach — not an application of an existing pattern, but invention of a new one — Claude Code is less useful. It is a powerful pattern-matcher. Problems that require pattern-creation require more human involvement.
Integrations with poorly documented APIs
Claude Code's knowledge has a training cutoff. Integrating with an API that was released or substantially changed after that cutoff requires more manual work, more external documentation, and more critical evaluation of generated code.
Domain-specific optimization
Generated code is typically correct but not optimized for specific hardware or workload characteristics. Database query optimization, high-performance networking code, and embedded systems code all require domain expertise that cannot be entirely delegated.
Long-running stateful sessions
A Claude Code session has a context window. For projects that require holding extensive context across many sessions, the overhead of context-setting becomes significant. This is manageable but requires discipline.
The productivity model
My honest assessment of the productivity change: the work I do in a week using Claude Code would take me three weeks using a traditional workflow. The 3x figure is not universal — it depends heavily on the nature of the work. Implementation-heavy work compresses more than design-heavy work. Greenfield projects compress more than maintenance of legacy systems.
The more important change is scope. I now take on projects I would not have taken on before — not because I was not capable of doing the work, but because the time cost was prohibitive for a solo engagement. The scope of feasible solo work has expanded.
The skill that matters most
Precise description. The ability to describe what you want — including the constraints, the edge cases, the things to avoid — precisely enough that the first generation is close to correct.
This skill transfers from writing. The same discipline that produces clear technical writing produces effective Claude Code prompts. If you cannot explain what you want in clear prose, you cannot get Claude Code to build it correctly.
Developers who improve fastest at the Claude Code workflow are the ones who invest in their ability to describe problems clearly. This is not a new skill — it is the same skill that makes you good at writing design docs, code review comments, and incident reports. Claude Code rewards it more directly.