Mina Patel
Staff software engineer
A promising AI product can outgrow its first architecture quickly, but novelty is not the only source of risk. The harder problem is choosing which parts should remain replaceable and which parts deserve the discipline of a long-lived platform.
We now begin with four questions: what must be deterministic, what can be probabilistic, what data may leave the system, and which workflow needs a human decision. Those answers usually narrow the stack more effectively than a feature comparison.
The result is a deliberately boring core: clear interfaces, observable jobs, provider-agnostic prompts, and a small evaluation set that runs before every meaningful release. The interesting work belongs at the product edge.
“Choose foundations for the decisions you expect to revisit, not the demos you want to show once.”
Discussion (31 Replies)
Sara Ahmed
Design Technologist
The idea of making the review ritual small enough to repeat is the part I am taking away. Security guidance is only useful when it survives a busy development sprint.
Leo Martins
Cloud Architect
Would love to see the threat-model template you used. We have been trying to keep it close to the pull request without making the PR unreadable.
Ayesha Khan
Product Engineer
The key is to record the architectural decision and the residual risk clearly, rather than producing a 30-page static specification.