From principles to production: starting a new series

Sun, 17 May 2026 00:00:00 +0000

A short note on why I am starting a new series, and what I hope to do with it.

Fundamentals still matter in the AI era

Syntax has become cheap. That is the real shift. The leverage is no longer in churning out lines — it is in deciding what should exist, steering the model toward the patterns and architectural boundaries you actually mean to enforce, and being straight about whether what comes back is safe to ship. That is usually what decides whether you end up with something scalable and maintainable.

If you have the room, double down on the fundamentals. It is not wasted time.

The differentiator is not how well you prompt a model. It is the quality of context you bring to the conversation, your ability to challenge and refine the output across iterations, and the judgement to evaluate, debug, and safely integrate the result.

Models generate code and propose designs. In my experience, they rarely surface the architectural decisions that make a system resilient, scalable, or secure. Without guidance and steering, the output is often surface-level, not production-grade.

Should that message be published through a transactional outbox? Does the API Gateway need IP allow-listing and a WAF for this customer integration? Is hexagonal architecture justified here, or overhead? Should we cache these responses on the frontend with something like TanStack Query?

These are still human judgement calls — for now. They lean on experience and on internalised engineering principles, and those are exactly the muscles that do not develop from prompt iteration.

The pattern I keep noticing

In my own work, the moments that matter most are not the moments an AI can decide for me. They are the moments where a fundamental law of software engineering applies, and the right move is to follow the principle, not the suggestion.

The model can sketch the option. The principle tells me whether to take it.

That pattern has become more visible to me as AI tooling has matured, not less. The decisions still rest on the same handful of laws and trade-offs I have been bumping into for the last 20 years across database work, pipeline design, and team-lead roles.

The reinforcement

That observation is what made Milan Milanović’s Laws of Software Engineering land harder than I expected when I read it recently. Most chapters were not new to me — I have walked into these patterns sideways over a long career. But seeing them laid out side by side was a useful reminder that the laws are still doing the heavy lifting, regardless of which tool is generating the first draft.

Take Gall’s Law:

A complex system that works is invariably found to have evolved from a simple system that worked.

That one is not stuck in a textbook. It is in every greenfield project I have seen attempt the “let us design the whole thing up front” approach, and in every one that survived by starting smaller. It is a law I live with on a daily basis — AI tooling or no AI tooling.

The book was the last reinforcement I needed to write more of this down.

The series

Name: From principle to production.

Cadence: one post every two weeks.

Shape: one principle, pattern, or lived lesson per post. The structure will be loose, but the intent is consistent:

What the principle actually says, in plain language.
A real story from my own work whenever I have one — what I got wrong, what I got right, what I would do differently now.
The nuance that the textbook version usually skips. The place where the rule bends, breaks, or needs a second sentence.

When I do not have a clean story of my own, I will say so and lean on the principle itself. I would rather skip an anecdote than invent one.

The series is not a chapter-by-chapter walkthrough of Milan’s book. Sometimes a post will line up with a law from it — YAGNI, Gall, Conway. Sometimes the topic will come from a pattern that does not have a famous name attached, just years of seeing the same trade-off repeat: a migration that went sideways, a schema decision that came back three years later, a team-level habit that quietly multiplied output. What I want to do is translate. The gap between knowing a principle and using it under real constraints — late projects, mixed-experience teams, systems that downstream consumers already depend on — is where most of the interesting decisions live. That gap is what this series is about.

First post

The series opens this May with Gall’s Law. It is one of the principles I keep returning to when a system is under pressure to become more complex than its current maturity can support.
The hard part is resisting the urge to design the final platform on day one, and instead starting with the simplest working system that can survive contact with production, then evolving it deliberately as the constraints become real.