Let me tell you exactly what “broken setup” means, because I want the context to land correctly.
Windows 10 laptop. Not Windows 11 — I’ve been hesitating on that upgrade for reasons that felt reasonable at the time. VS Code terminal that clips the bottom four lines of the Claude Code UI, which means the prompts asking me to choose between numbered options? Gone. Below the visible window. I was flying partially blind the entire session.
Ctrl+C on Windows 10 in a VS Code terminal doesn’t interrupt a running process. It copies. So when Claude Code appeared to be frozen — sitting on “almost done thinking” for ten minutes — every instinct I had to interrupt it just copied empty terminal text to my clipboard instead.
First time using Claude Code. No prior session. No familiarity with the UI mechanics. No idea that the output was being collapsed behind a ctrl+o to expand prompt I also couldn’t see.
45 minutes later, I had a working app.
What Actually Happened
I’d taken the Claude Code 101 course the week before. One thing it hammered — the Explore → Plan → Code → Commit workflow. Before Claude Code writes a single line, it reads. It understands the structure, the intent, the constraints. Then it proposes. Then it codes.
I also spent time before the session building my CLAUDE.md — a persistent instruction file that tells Claude Code exactly how I work. My background. My preferences. My “don’t ever do this” list. The things that used to require re-explaining to ChatGPT every single session, watching it ignore them anyway.
That file did real work.
The first command I tried — creating a two-line requirements.txt — went into extended thinking for ten minutes. Full planning mode on a config file. First lesson: Claude Code is not always the right tool. I wrote the file by hand in thirty seconds and moved on.
After that, things moved fast.
Claude Code read the CLAUDE.md. Understood the project structure. Generated the core application files. Hit a backtick syntax error — a Markdown fence leaked into the Python source — caught it autonomously and fixed it. Then hit a bigger problem: the Claude 4 extended thinking API had changed. The pattern I’d documented was outdated. Claude Code discovered this at runtime, introspected the installed SDK package to find the current types, diagnosed the fix, updated the code, updated two contract tests, updated the CLAUDE.md example, and ran 22 tests.
All passed.
Then it ran the CLI against the sample PHP file.
The app worked.
I didn’t know it had worked. The actual streamed analysis output was collapsed in the Claude Code UI behind … +40 lines (ctrl+o to expand). Which I couldn’t see. Because it was below the clipped window.
My reaction, verbatim: “I’m not sure what just happened… did it actually read the file and output… something?! Where?!”
“This Feels Like It Sucks”
That was my next reaction — out loud, to nobody — when I couldn’t find the output.
But that frustration became a product decision. I asked: wouldn’t you want this saved to a file so the user could actually scroll through it? That observation became the file output feature — every analysis now saves as a Markdown file next to the input. sample_cobol.cbl produces sample_cobol_analysis.md. Open it in VS Code’s preview pane, share it with the team, attach it to a ticket.
The feature didn’t come from a requirements doc. It came from being annoyed.
That’s how good software decisions usually happen, in my experience.
The CLAUDE.md Moment
I want to say something about CLAUDE.md specifically because it deserves its own mention.
I came into this project with accumulated ChatGPT trauma. A year of watching an AI put emoticons in code block comments. Generate inconsistent error handling. Skip tests entirely on one pass and over-engineer them on the next. Produce code that looked different every time for no apparent reason.
The CLAUDE.md is the answer to all of that.
It’s a persistent instruction file — project level, local level, or global machine level. Mine covers my background, my coding preferences, my “always do this” list, my “never do this” list, and the reasoning behind each rule. Not just “always add error handling” — why I want error handling, what it should look like, what I’ve seen go wrong without it.
Claude Code reads it at the start of every session. Automatically. Without being asked.
The relief of that — having a place to write down exactly how you work and knowing it will actually be followed — is hard to overstate if you’ve spent a year re-explaining yourself to an AI that forgot everything between sessions.
What The Timeline Actually Means
45 minutes. Broken setup. First session ever.
Working CLI. 24 passing tests across five pyramid levels — smoke, unit, contract, integration, live. Streaming output. Prompt caching with visible token savings. Extended thinking with automatic model routing. File output. A README that would make a senior engineer nod.
The last hour after that was additions — more languages, more test cases, more exotic sample code to throw at it. The core app was done in 45 minutes.
I’ve been thinking about what that number means for a team with a proper setup. Developers who’ve run Claude Code before. A CLAUDE.md already dialed in for the project. No fighting the interface, no flying blind.
The math is uncomfortable if you’re managing a sprint and you haven’t looked at this yet.
The bottleneck was never the code. It was the setup tax — the environment, the boilerplate, the scaffolding that eats the first two days of every project before anything real gets built.
That list just got a lot shorter.
I’m not saying your senior engineer is replaceable. I’m saying they could ship three things this sprint instead of one — if they stopped writing the scaffolding by hand.
The code is at github.com/bbornino/claude-legacy-code-explainer, and the full project documentation is at bornino.net/projects.
Next up: CLAUDE.md — the file that finally solved my ChatGPT trauma.