Notes on building systems that have to keep working.
Working notes, not polished essays. I show how things were built, and why.
Play is how you learn what no one has figured out yet
There are two ways to learn: from a teacher with the answer, or by playing until you work it out. Topics like AI need the second, yet we default to choosing the first.
What I learnt about Code-First Design, from using Claude Design
I've been using Claude Design to understand where code-first design fits into modern software development.
One bug, eight fixes, and the cost of cognitive debt
AI can accelerate implementation and repairs, but it does not replace the deliberate thinking needed to catch requirements that were never stress-tested.
How you talk to AI is itself a design decision
Spec-driven and iterative prompting are both design choices. The question is where quality judgment belongs: upfront in a contract, or later through feedback.
AI is a universal translator, but it still amplifies your intent
AI compresses the distance between intent and working software. That makes small tools worth building, but it also makes unclear intent show up faster and louder.
Before adopting AI, agree on what you mean by AI
Adopting AI is too broad to be useful as a directive. Teams need sharper language before they can make sensible decisions about tools, risks, workflows, and ownership.
The thinking you can't get back (and the hidden cost of AI)
Every level of AI assistance removes work from humans. The hidden question is which parts of that work were also building judgment, memory, and understanding.
Five levels of AI in software teams (and why the hardest part isn't the AI)
A practical ladder for how software teams change as AI takes on more of the work, from removing boilerplate to surfacing what humans should pay attention to next.