How we build software

"Coding is just one part of engineering. There's also debugging, operating services, scaling up infrastructure, deciding what to optimize, setting up hardware and capacity, talking to users, product planning, etc. Coding is the easy part, everything else is not yet solved."

— Boris Cherny, creator of Claude Code at Anthropic, 9 June 2026

Quite so. Software engineering is the disciplined discovery, analysis, design, construction, operation and evolution of software systems so that they solve the right problems reliably within real-world constraints. The coding is the part AI has made fast and cheap. Everything around it — the judgement about what to build, what to leave out, and what simply has to be right — is the work that decides whether the result is any good. That work is what City Software Engineering is named for.

Efficiency was always the mark of good engineering. For a long time it was easy to skip: hardware was cheap next to the cost of writing code, so carrying extra complexity and over-provisioned infrastructure was simply affordable. AI has reversed that. When code is quick to produce, the lasting cost of a system is what it takes to run and to change — and AI, trained on the bloated codebases that came before it, tends to reproduce exactly the bloat that drives those costs up. Building well is no longer a luxury for teams with large budgets. It is the difference between software that pays its way and software that doesn't.

Simpler

Forty years before that tweet, Fred Brooks drew the distinction that still matters most: the complexity that is essential to the problem, and the complexity that is merely accidental — introduced by how we chose to build, not by what we set out to solve. Most of the trouble we see is accidental: services split apart for no reason anyone can defend, technology added because it was fashionable, layers no one can quite account for. We hold no allegiance to a language, framework or tool, which means we can judge a system on what it needs rather than on what we happen to like. We take complexity out wherever it isn't earning its place, because every piece left in is something to run, secure and change for as long as the system lives.

Safer

A bridge can't be designed without knowing its span and the traffic it must carry. Software is no different — but its equivalent, the non-functional requirements (load, throughput, latency, reliability, security), is the part most often left unsaid. We make it explicit, then engineer the parts that carry real load and real risk to meet it. The booking that mustn't sell the last seat twice; the record that must never be lost; the path that has to stay up: these have well-understood patterns, and we use them rather than reinvent them. The rest of the system can stay deliberately ordinary. This is the discipline behind mission-critical systems in healthcare, finance and government, where being wrong is not an option — and behind platforms built to manage third-party cyber risk, where security isn't a feature bolted on but the product itself.

Cost-efficient

Put the effort where the essential complexity lives, and most of a system can be plain, modest in its demands and cheap to host. Get it wrong — over-build the ordinary, under-serve the critical — and the cost climbs on both sides: infrastructure to prop up parts that were never designed for the load, and engineering time lost to complexity that need never have existed. We design so the running cost stays in proportion to the value, and stays that way as usage grows. Software that is cheap to run is almost always software that is also simpler and safer. The three pull in the same direction.

These aren't new ideas for us — they're the pattern behind everything Matt Tanner has spent his career building, running and rescuing: find the few parts that carry the weight, build those properly, and refuse to over-engineer the rest.