Blog
Notes on architecture leadership and AI in software development— how intent becomes capability, governance, and change the organization can absorb.
-
From strategy to systems
The gap between board intent and what delivery ships is rarely a tooling problem. It is an architecture problem: missing ownership, unclear trade-offs, and change the estate cannot absorb.
-
AI as a force multiplier, not a substitute for design
Copilots accelerate typing. They do not replace ownership of intent, interfaces, or the failure modes the business will feel.
-
Architecture review when half the code was generated
Review must shift from line taste to boundaries, invariants, and evidence that the system still matches the agreed target shape.
-
Governing AI features in banking and insurance
Regulated estates need AI treated as a capability with owners, controls, and evidence—not as a demo that escaped into production.
-
A prompt is not a requirement
Prompts steer models. Requirements bind people, systems, and risk. Mixing them up produces demos that cannot be operated.
-
The technical debt shape of AI-assisted sprints
Velocity charts look healthy while the estate accumulates near-duplicate modules, shallow tests, and undocumented decisions.
-
When not to put a model in the critical path
Probabilistic components belong where failure is contained. Money movement, hard compliance gates, and irreversible actions need deterministic cores.
-
Observability for AI-augmented systems
Logs of prompts are not enough. You need traces across tools, quality signals, cost, and the business outcome that followed.
-
Human-in-the-loop is an architecture decision
“Someone will check” is not a control unless you design roles, queues, SLAs, and what the system does while waiting.
-
Data products before AI programmes
Most AI programmes stall on unclear data ownership, quality, and contracts—not on model choice.
-
Security boundaries for copilots and agents
Agents that can call tools are new attack surface: prompt injection, data exfiltration, and over-privileged actions dressed as helpfulness.
-
Build vs buy for AI capabilities
The question is not “which model.” It is which capabilities are differentiating, which are commodity, and what lock-in you can reverse.
-
Refactoring with AI without losing system intent
AI can reshuffle code fluently. Preserving why the system is shaped this way still requires humans and tests that encode intent.
-
Platform teams and AI toolchains
If every squad wires its own models, keys, and prompts, you get shadow AI. Platform should offer a paved road with guardrails.
-
Testing software when behaviour is probabilistic
Asserting exact strings fails. You need fixtures, judges, thresholds, and regression sets tied to business harm.
-
From AI proof-of-concept to production
PoCs prove possibility. Production demands ownership, SLOs, cost control, and a path the organization can operate every day.