Tech

Claude Code will check almost anything you point it at. It will test the code, review its own work, hunt for edge cases it hasn’t covered, and argue with you about whether an approach is sound. What it won’t do is ask whether the premise is the right one, because it’s not really part of the work, it’s the foundation.

A premise here is whatever was already true when the session started and never got said out loud. It doesn’t get examined because nothing draws attention to it, and everything built on top of it can be correct, tested and reviewed while the premise underneath is quietly false. So you have to make sure it’s understood.

Claude Code finishes something and tells you what it did, and that report is the most trustworthy-sounding part of the whole exchange, because it arrives in the past tense from something that was there. The report is produced the same way as everything else, which makes it a plausible account of what probably happened, assembled afterwards.

Every session starts with nothing, which is easy to underestimate because it doesn’t feel that way. Claude Code can read the whole project, so it can read and find out what any of the code does, and that looks a great deal like knowing what’s going on. But it has no idea why any of it is like that.

Ask Claude Code for almost anything and a plan comes back, ordered and confident and usually reasonable, which is most of the value, but also the part that took me longest to handle. A plan that arrives looking finished invites you to review it, but the work that mattered happened before any of it was written.

When I review a plan, I end up editing it, fixing what’s in front of me and tightening what’s there, while the shape of the thing stays whatever got decided in the first few seconds. Nothing in the output tells you which parts were decisions and which were defaults, which were assumptions or inferences, because it reads equally well either way.

Claude Code gives you three places to put things that shape how it works, and it took me a few months to figure out how to optimize them. Rules are prose it reads, skills are procedures it follows when a task calls for them (or can be invoked manually), and hooks are rules (and code) that run at various steps (before/after tool calls, session start, etc). Each is appropriate for different things and getting that wrong is how you end up with a rule the model doesn’t follow or a hook that fires on work you actually wanted to do.

Up to last year I did use AI daily, but mostly for autocomplete, functions, maybe even small UI components, where I already knew what I wanted and roughly how it should look. I tried building actual projects and complex features a few times too, but I never really felt it could handle it well enough, the friction was high enough that my attempts died quickly. And every such attempt made me conclude the hype had run ahead of the thing, and stopped bothering until the next time.

Back in the opener I wrote "No CMS" and moved on in four words, without saying what happens instead. Then I spent three posts hardening an admin — auth, input validation, a write contract with an audit log — and called the series done. Consider this the postscript, because the honest answer to that "No CMS" is a small toolbox whose only job is keeping me out of the admin I spent all that effort building.

Seven posts in, the rebuild has been live long enough that the things I called "more than this site needs" have had a chance to either earn their keep or expose themselves as decoration. This is the closer: a short retrospective on the verdict, the patterns I'd reach for again, and the handful of decisions I'd revisit if I started over.

Every post on the site is markdown in a database column. Three different consumers turn that column into something readable, and each one wants the output in a different shape: blog pages want React with syntax highlighting; the Atom feed's <content> element wants self-contained HTML with no external CSS; the feed's <summary> and the OG/SEO meta description want plain text. One pipeline can't serve all three without compromising at least one of them, so I built three.

Server components are the best thing Next.js has done in years. Most of my code never ships to the browser, the few interactive widgets are visibly marked with "use client", and the data layer is one fetch away from any page that needs it. That part of the App Router pitch is real.