A Requirement Rather Than a Reality
Oct 29, 2026
Software engineering was named in 1968 as an aspiration, not a description: a discipline the field decided it needed because too much was falling through the cracks. Vibe coding is interesting not because it uses AI, but because it can separate producing code from the human responsibility to understand it, a responsibility that review, testing, traceability and change control all depend on. How much discipline a system needs depends on how long it lives and what it touches. Fintech products sit at the far end of both, and there the discipline is written into the standards. Vibe coding still has a place, at the start, as a way of seeing requirements, but the prototype is not a signed baseline: what is worth freezing is the load-bearing decisions, not every screen. Spec-driven development can hold those decisions, but only if the spec keeps being maintained; a tool is not the discipline itself.
Read
The Hollow Sprint
Oct 9, 2026
Agile was an answer to uncertainty at a time when building software was expensive: plan little, build small, learn from what the customer sees. AI has made build capacity and decision capacity diverge. A team that keeps its old rhythm ends up running hollow sprints: on schedule, every ceremony intact, with more and more unconfirmed decisions inside them. Cheaper building could justify more upfront planning or even more iteration, and both are right, for different kinds of decision. AI moves the last responsible moment in two directions at once. The unit of methodology is no longer the project. It is the decision.
Read
The Evaluation Constraint
Aug 2, 2026
Two engineering organizations with the same headcount, the same budget and the same stack will diverge enormously over five years, and the divergence is not talent or effort. It is which allocation of capacity they found. Superior allocations exist, they are rare, and finding one is a search problem — which means the arm of that search AI just made cheap is not the arm that was ever binding.
Read
The CTO Decision Stack in Startup and Enterprise
Jul 12, 2026
The third post in the CTO Decision Stack series. The seven layers don't change between a ten-person startup and a ten-thousand-person enterprise. What changes is what each layer is optimizing for, given different constraints — capital, reputational exposure, existing assets, and time horizon. A startup shipping a throwaway product to win a deal and an enterprise refusing to is not one of them being undisciplined. Both can be right. The recurring failure isn't a bad decision at either end. It's importing a tradeoff that was correct somewhere else.
Read