William Christopher Anderson This is what I came to after three years in private. I am still a little stunned. I want to tell you what I found. I sat four rooms the world already names: Hodge, Poincaré, Navier-Stokes, and Birch and Swinnerton-Dyer. I did not sit them as prizes. I sat them as shapes. The chapters and … Read more
The fastest way to be displaced by AI is to stay at the level AI operates at most comfortably. Monday we established that AI cannot do architecture: the training data problem is structural, not temporary, and the gap between generating plausible-looking code and designing systems that survive contact with the real world is not closing. … Read more
Mondays post established why AI cannot do architecture – and why that gap is structural, not temporary. The training data problem means LLMs pattern-match against a corpus of mostly bad architecture. That will not change as models scale. What changes is the opportunity: if AI handles expression and design is the only bottleneck remaining, the … Read more
LLMs are extraordinary at writing code. They are genuinely bad at architecture. Most people treat this as a temporary limitation – a capability gap that will close as models improve. It won’t. And understanding why tells you everything about what software engineering actually is. Why LLMs Are Good at Code The answer is in the … Read more
I have worked with agile teams, waterfall teams, hybrid teams, and teams that had simply embraced anarchy. Different processes, different ceremonies, different levels of documentation and discipline. Engineers, project managers, product owners, SMEs, architects – all present, all engaged, all doing their jobs. The methodology varied. The problem did not. Every one of them was … Read more
Project plans are built from the wrong material. The team collects user stories, estimates each one, stacks them into sprints, and calls it a schedule. User stories are units of value — they describe what the customer gets. They do not describe units of work. The actual work — the components, the integrations, the infrastructure, … Read more
Boundary-Driven Testing begins with a single observation: testing difficulty is not a testing problem. When a unit test requires a running database, the test is not broken. When a change to a business rule breaks seventeen tests that have nothing to do with that rule, the test suite is not fragile. When a component cannot … Read more
Experience-Based Decomposition begins with the same premise as VBD: components should be organized around how they change. Most frontend patterns organize by size or technical role. Atomic Design gives you atoms, molecules, organisms, templates, and pages — a clear taxonomy built on composition. It solves a real problem: it stops component libraries from becoming an … Read more
Volatility-Based Decomposition begins with a simple premise: systems should be organized around how they change. Most architectural patterns organize code by technical role. Controllers live in one place, services in another, repositories somewhere else. This produces a clear taxonomy, but it does not explain how change propagates through the system. When business rules evolve, workflows … Read more
Software teams rarely suffer from a lack of frameworks. They suffer from frameworks that do not speak to each other. A team might apply Domain-Driven Design to their backend, atomic design to their component library, coverage targets to their test strategy, and agile ceremonies to their project management. Each framework is locally sensible. Together, they … Read more