I have 1,714 entries in my Claude Code history file spanning six months. The distribution is absurd:
- Sep-Dec 2025: 12 entries total
- January 2026: 352 entries
- February 2026: 960 entries
- March 2026: 391 (and counting)
I went from “trying this out” to “daily driver for everything” in about six weeks. Here’s what happened at each stage, and what finally made it click.
Stage 1: The skeptic (Sep-Dec 2025)
12 entries in four months. I’d open Claude Code, ask a question, get an answer, close it. It felt like a fancier Stack Overflow. I wasn’t giving it enough context to be useful, and I wasn’t staying in the session long enough for it to learn about my codebase.
The friction was real. I didn’t trust the output. I’d ask Claude to write a function, read the result, decide I could have written it faster myself, and go back to my editor. Classic early-adopter skepticism. “This is neat, but I don’t need it.”
Stage 2: The hook (January 2026)
352 entries. Something shifted.
I started using Claude Code on my Terraform provider for KinD, an open-source project I maintain. I had a feature request sitting open for months. Instead of grinding through it myself, I gave Claude the GitHub issue URL and said “what’s the approach here?” It read the issue, explored the codebase, and proposed a plan.
That was the moment. Not the code it wrote. The plan it proposed. Claude understood the existing architecture, identified the right extension points, and suggested an approach I agreed with. It wasn’t a code completion tool anymore. It was a thinking partner.
Around the same time I started using it for my homelab infrastructure. Talos Linux, Kubernetes, Helm charts, ArgoCD. The kind of work where you’re constantly cross-referencing docs, debugging YAML indentation, and reasoning through resource dependencies. Claude could hold the full context of my cluster config and help me trace why a sync was failing without me pasting the same context over and over. I stopped closing sessions after one question and started having conversations.
352 entries in one month, up from 3 per month. The adoption curve doesn’t ramp; it snaps.
Stage 3: The explosion (February 2026)
960 entries. What happened?
I started using Claude at work full-time. That’s the real accelerant. My day job is platform engineering; Kubernetes, Terraform, CI/CD pipelines, the whole cloud-native stack. Claude became my default tool for all of it. Debugging ArgoCD sync failures, writing Helm charts, reasoning through infrastructure changes. By the time I sat down for personal projects in the evening, I was already warmed up.
On any given day I’d have 2-6 Claude sessions running in parallel. Sometimes in the same repo working on different features. Sometimes spread across completely different codebases. A Helm chart upgrade in one terminal, a floor plan editor bug in another, a Home Assistant automation in a third. Each session holds its own context, so switching between them costs nothing. I’d tab over, pick up where I left off, and keep going.
Here’s what my February looked like across work and personal:
- Work: Kubernetes, Helm charts, ArgoCD, Terraform, CI/CD
- Personal: home automation, Zigbee sensor setup, floor plan editor, personal website, game projects
That’s the part the raw numbers don’t capture. 960 entries isn’t one person coding all day. It’s one person running multiple AI pair-programming sessions in parallel, all day at work and all evening on side projects. The sessions overlap. I’ll kick off a long-running Claude task in one terminal and switch to another session while it works.
This is also when I started building the infrastructure around Claude Code. Custom skills for iterative development. A code reviewer agent. A verifier agent running on the faster Haiku model for quick checks. A go vet hook that fires after every Go file edit. A custom Waybar widget that shows my active Claude sessions. I was optimizing my AI-assisted workflow the same way I’d optimize a CI pipeline.
Stage 4: The new normal (March 2026)
391 entries with 10 days left. The pace hasn’t slowed, but my usage pattern has matured.
I now have 11 custom skills, 3 custom agents, 4 plugins, and two MCP integrations (Notion for knowledge sharing, Firefox DevTools for frontend testing). My settings file has pre-approved permissions for Go tools, Lua testing, and specific websites I reference often. I’ve tuned the system to minimize friction.
The biggest change from January to now is how I start sessions. In January I’d type a question. Now I paste a multi-thousand-character implementation plan and say “Implement the following plan.” The thinking and planning happens first (often collaboratively with Claude in a separate brainstorming session), and execution is a separate phase. That separation improved my output quality more than any other change.
What made it click
Three things, in order of importance:
1. Staying in the session. Single-question usage is a waste of Claude Code’s strengths. The value compounds when Claude has context about your project, your decisions, and your preferences. My longest sessions (100-177 messages) produced the best work.
2. Treating it as pair programming. I stopped asking Claude to write code and started working with it. “We need to fix the sync logic” instead of “write a function that syncs data.” The collaborative framing changes how Claude approaches the problem and how I engage with the output.
3. Building the tooling around it. The custom skills, agents, and hooks removed enough friction to make Claude Code my default tool for everything. Not my backup, not my reference. My starting point. When my first instinct on encountering a problem is to open a Claude session instead of a browser tab, the adoption curve is done.
The numbers don’t lie
My usage by day of week tells the story: Sunday (389 entries), Tuesday (297), Saturday (288), Monday (275). Weekdays are work sessions. Weekends are side projects. The tool is the same for both; the context switches, the workflow doesn’t.
The parallel session pattern is the real multiplier. When you can run 2-6 independent coding sessions at once, each with full project context, you’re not limited by your own typing speed anymore. You’re limited by how fast you can review, test, and redirect. That’s a different bottleneck, and it’s a much better one to have.
If you’re still in the skeptic stage, my advice is simple: pick a real project, stay in the session, and give it enough context to be useful. The 12-to-960 jump took me six weeks.
Comments
You can also comment directly on GitHub Discussions.