Building Systems With AI: From Prompt to Production
Building systems with AI means treating the model as a fast implementer, not an architect. You write the specification, define the boundaries it may touch, and gate every change behind tests. Generation is the cheap step; specification and verification are the work.
Why prompting alone stops working
A single prompt can produce a convincing prototype. It cannot produce a system, because a system is defined by its boundaries — what talks to what, what happens when a dependency fails, who is allowed to do which thing. Models optimise locally and have no stake in the answer six months from now.
This is the gap the 2026 statistics describe. Adoption is near universal, but only around 29% of developers trust the output, and roughly 77% keep it away from production. The people who closed that gap did not find a better model. They added structure around it.
Specification-driven development in practice
The pattern that works has three parts, and skipping any one of them is where teams get hurt.
- A written spec per change: what should be true afterwards, which files may change, what must not change. Ambiguity in the spec becomes an invented decision in the code.
- Tests that gate the pipeline: if a generated change cannot be verified automatically, it does not merge. This is the single highest-leverage control available.
- Human architectural review for anything structural: new dependencies, new data flows, new trust boundaries. Everything else can move fast.
A build sequence that survives contact with users
| Stage | What you do | What the model does |
|---|---|---|
| 1. Frame | Write the one-sentence outcome and the non-goals | Nothing yet |
| 2. Source | Find an open-source component that solves the hard part | Summarise candidates |
| 3. Spec | Define interfaces, data shapes and failure behaviour | Draft, you correct |
| 4. Scaffold | Approve the file layout | Generate structure |
| 5. Implement | Review small diffs | Write code against the spec |
| 6. Verify | Own the test suite | Write tests you then read |
| 7. Harden | Audit auth, input handling, secrets | Assist, never decide |
The security layer you cannot delegate
A Stanford randomised trial found that developers using AI assistance produced less secure code while reporting more confidence in it. Confidence and correctness moved in opposite directions, which means your own sense of safety is not a usable signal.
The practical response is a fixed checklist applied to every generated change touching a trust boundary: authentication and session handling, authorisation on every endpoint rather than just the UI, input validation at the server, secrets never in generated config, and dependency provenance checked before install.
Where open-source components fit
The fastest systems to build are the ones where the difficult, well-defined part is already solved by someone else and your work is the integration, the domain logic and the interface. That is not a compromise; it is how most durable software gets made.
The practical problem is finding the right component. Star counts measure popularity, not suitability. Every entry in the RepoLoot catalog is analysed for what it does, the problem it solves, what you can build on it and the implementation difficulty — so the decision takes minutes instead of days.
Frequently asked questions
- What is specification-driven development?
- A workflow where an AI agent receives a detailed written requirement — what must be true afterwards, which files it may touch, what must not change — instead of an open-ended prompt, with automated tests gating the result before it merges.
- How do you keep AI-generated code secure?
- Apply a fixed checklist to every change that touches a trust boundary: authentication and session handling, server-side authorisation on every endpoint, server-side input validation, no secrets in generated config, and dependency provenance checked before install. Do not rely on your confidence — a Stanford trial found confidence rises as security falls.
- Can AI design system architecture?
- It can draft and critique, but it should not decide. Models optimise locally and have no stake in how the system looks in six months. Keep human review for new dependencies, new data flows and new trust boundaries.