THOUGHTS ON
ARCHITECTURE,
AI, AND SYSTEMS

Architectural principles matter more now because they are the guardrails for these non-deterministic systems that can otherwise code themselves into unmaintainable disasters.

Loose coupling, high cohesion, and legibility go beyond human preferences and relate to deeper properties: changeability, testability, and correctness under evolution. Those constraints don't disappear just because the author is an AI. If anything, they become more important, because now you've introduced a non-deterministic contributor that can regenerate large parts of the system at any time.

What does change is where the burden shifts.

If AI is doing most of the writing, then code readability matters less at the line-by-line level, but system legibility still matters a lot. Someone (human or AI) still needs to reason about boundaries, responsibilities, and failure modes. If your system is tightly coupled, the blast radius of any regeneration becomes enormous.

I think the new quality metrics start to look something like:

1. 1.

   SPEC FIDELITY

   How precisely the implementation matches an unambiguous specification. This becomes the primary source of truth.

2. 2.

   TEST SURFACE AREA AND DEPTH

   Not just coverage, but whether tests meaningfully constrain behavior. Weak tests will get exploited instantly by generative systems.

3. 3.

   REGENERATION STABILITY

   If the code is regenerated multiple times from the same spec, equivalent behavior should still emerge. Loose coupling improves that stability.

4. 4.

   OBSERVABILITY AND DIAGNOSABILITY

   When something breaks, the system should make it fast to determine why. This matters when the author cannot clearly explain intent.

5. 5.

   CONTRACT CLARITY

   Interfaces should be explicit enough that a human or AI can extend the system without unintended side effects.

The metric I suspect we will begin to apply will be how the system behaves under iteration. This may actually make software engineering more rigorous, not less. The hand-wavy parts, 'this feels clean', get replaced with things you can actually test and enforce. Do not stop encoding design, because the model 'usually gets it right'.

Someone recently asked me: 'With tools like GitHub Copilot and Cursor becoming more common, how can junior engineers balance speed with developing their own coding abilities?'

Struggling with syntax was always a poor gatekeeper in our field. I'm glad that barrier is being lowered. Instead, Software Engineering is about understanding tradeoffs, designing modular systems, writing code that's easy to debug and maintain, and optimizing for the right kind of performance.

These deeper skills are harder to build, but also more important. And now, thanks to AI code tools, new engineers can accelerate that learning by building many small projects, refactoring them, and experiencing how a codebase evolves.

This was something we used to only gain over years, now perceptual expertise can be built in months.

Perceptual expertise is the ability to recognize patterns, design flaws, or architectural missteps almost at a glance. It's how senior engineers 'just know' when something feels off.

One of my favorite pieces on this is Joel Spolsky's 'Making Wrong Code Look Wrong' — the idea that good code conventions make bugs visually obvious, so you catch them before they ship.

I encourage senior engineers to guide new grads toward building, revising, and reflecting — not just prompting.