Nordhavn

AI made your engineers faster. It did not make them better - and the gap between the two is now the most important thing most teams are not measuring. Nordhavn teaches a working discipline for software development in the age of AI, in the tradition of The Goal and The Phoenix Project: an argument you can act on, delivered as a story you actually finish. It follows one small team through a single hard winter - a leak that should have been impossible, a launch, a customer whose case cannot afford to fail, and a bet-the-company pivot - and works out, in the doing rather than in a lecture, what holds and what breaks when a team hands part of its thinking to a machine. Its central claim is simple and uncomfortable: AI is an amplifier. It does not turn a bad process into a good one - it turns a bad process into a fast one, and a fast bad process ships disaster more confidently than a slow one ever could. Point the same tool at a sound process and it compounds the best work a team can do. The difference between those two outcomes is a discipline. This book is that discipline, shown in practice. Along the way you will see, worked out concretely and never asserted from a slide:

• Why theory-building - the shared understanding of why a system is the way it is (Peter Naur) - not code, is the real product of software work, and why AI makes it matter more, not less.
• Why making one engineer "AI-productive" is a local optimisation that can slow the whole system down - the lesson The Goal taught a factory, and the DORA research now measures in engineering.
• How to keep verification as the constraint you never starve - and how to use AI as the filter that lets human judgement survive the volume, rather than the auto-approver that ships the leak.
• What an enabling specification is - one a domain expert can check and a machine can build from - and why it is the artifact that makes work safe to hand to AI at all.
• How to cast AI as a virtual colleague at the seam between people - the one use of the machine that compounds instead of cannibalising.
• Why going slow to build understanding is the only way to go fast, and why the teams that skip it feel fastest right up to the wall.

It is grounded in the real lineage of the field - Goldratt's Theory of Constraints, Naur's theory-building, Reenskaug and Coplien's DCI, the DORA metrics, the end-to-end principle - and a closing appendix names every idea explicitly, with sources, for readers who want the map after the journey. For engineers, engineering leaders, CPOs and CTOs, and anyone responsible for putting AI into software work who wants more than velocity theatre - a way to tell the difference between moving fast and moving off a cliff.