Field Notes
from Production
Random thoughts, occasional insights, and lessons from breaking things where the stakes were real. 47 pieces; probably a few should have been tweets.
How I built this site with Claude Code.
I built the first version of this site over about three weeks of work with Claude Code. The build story covers the architecture, review workflow, and decisions I still owned.
Claude Code and the context window on bigger projects
My website is close to a thousand files. I keep Claude Code useful by giving each session one task, naming the files involved, and keeping the project instructions current.
Claude Code permissions: what to allow and what to block
Claude Code can change real files and run commands. Check the permission mode, protect secrets, review the diff, test the result, and keep a restore path.
Fixing bugs with Claude Code (without losing your mind)
Something broke. Describe what you expected, show what happened, let Claude investigate, then test the proposed fix.
What is vibe coding, and when should you use it?
Vibe coding is useful for disposable experiments where failure is cheap. Software you intend to keep needs review, tests, version control, and an owner.
Keeping your Claude Code project organized
Give each file an obvious home, document the stable rules, and test what your deployment actually includes.
Teaching Claude Code your standards with rule files
Use CLAUDE.md for project-wide facts and rule files for detailed standards, including rules that load only for matching paths.
Creating reusable Claude Code skills
If you keep pasting the same prompt, save it as a small Claude Code skill. You can run it with a short command and add templates or scripts later.
The CLAUDE.md file: what to put in it, and what to leave out.
Each Claude Code session starts with fresh context. CLAUDE.md loads the project facts and instructions you want available, while auto memory stores patterns Claude learns.
Choosing which customer journeys to digitalize first
Do not delay a clean common journey while reproducing every legacy exception. Start with measured demand, keep a human handoff, and add the next case only when it earns its place.
Which decisions should your digital team own?
A digital team needs authority to decide, say no, and change course when evidence changes. Agree on risk limits and escalation points before delegating those decisions.
Moving from IT delivery to product ownership
Follow one product decision from customer problem to release. Check who chooses the work, who can reject a request, and who owns the result.