ES

Arquitectura AI-native

Cinco principios para construir sistemas de IA que sobreviven al contacto con producción.

Esta página aún no está totalmente traducida a tu idioma — mostrando la versión en inglés.

Most AI systems are built prompt-first and demo-driven. They impress on a Tuesday afternoon and fall apart on a Monday morning, because the engineering discipline around the model was never there. AI-native architecture is the opposite stance:the model is the genuinely novel part, and everything around it is deliberate. The point isn't that AI writes the code — it's that the engineering is built for a world where it does. Five principles hold that up.

1. The spec is the artifact

Not the prompt, and not the code. The thing the team reasons about, reviews, and changes is a written specification of intended behaviour — boundaries, invariants, acceptance criteria. Prompts and code are implementationsof the spec, never the source of truth. When the spec is the artifact, a behaviour change starts as an intentional, reviewable edit to the document. When it isn't, you tweak prompts until the output looks right and nobody can say why it works — which means nobody can say when it stopped.

2. Evals or it didn't ship

Behaviour worth shipping is behaviour worth pinning down. Every agent that touches real work has a held-out scenario suite — adversarial and edge cases included, not just the happy path — and prompt or model changes are gated on it. Without evals you are flying on vibes: regressions are silent, and you find out from users instead of from a test. The eval suite is the contract that lets you change the system without fear.

3. One source of truth per fact

Duplicated state is duplicated bugs. Every important fact has exactly one authoritative home; anything else is an explicit, derived copy. The moment the same fact lives in two places that can drift, different parts of the system begin to believe different things — and under partial failure or a retry, that gap is exactly where corruption hides. Integrity is not a feature you add later; it is a property you design in or lose.

4. Boring tech where it can be boring

Postgres, FastAPI, Next.js. The novelty budget belongs in the AI layer, where the problem is actually new. Everywhere else, predictable beats clever: the substrate should be the part you never think about, so all of your attention — and all of your risk — goes to the part that is genuinely hard. Reaching for a novel datastore to support a novel model is spending the same budget twice.

5. Async by default

Long writing beats short meetings. Decisions land in documents so the next person — or the next agent — doesn't have to rediscover them. This isn't a remote-work preference; it is the same discipline as the spec. The durable artifact is the written decision, not the conversation that produced it. A system whose reasoning lives only in people's memory is a system that forgets.

Why it matters now

I direct coding agents for the build; the spec, the review, and the architecture stay mine. These principles are what make that possible. When the intent is written down, the evals are the gate, and the substrate is boring, an agent can do the typing without the system drifting out from under you. That is what AI-native actually means.

Want to see where your own system stands against this? Take the AI Architecture Scorecard, or work with me on the real thing.