Architecting for AI: what changes, and what still holds

"Am I here just to press Enter?" A colleague asked me that, half joking, after a long day of accepting an assistant's suggestions. Architecting for AI is my attempt at an answer.

Vendors say AI will cut delivery effort by half. The people doing the work are quietly asking whether they still have a job. Both are reacting to the same thing: a component that is clever, fast, cheap, probabilistic and unaccountable has arrived inside systems designed before it existed.

The book makes one argument in three parts.

Part I: what AI really changes

Three things are changing at once.

• The market. For thirty years most of the software industry has sold effort. When a model compresses the effort behind a feature from a week to an afternoon, the question becomes: if you are not selling effort, what are you selling?
• The method. Agile, story points and pull-request review were designed for a world where writing code was the slow part. It no longer is. The slow part is now understanding, deciding and checking.
• The architecture. A model is not another API. It is probabilistic, its price changes with the length of what you send it, its version changes underneath you, and it will confidently answer questions it has no business answering. Put that in a request path and assumptions that used to hold stop holding.

Part II: what still holds when architecting for AI

This is the part the vendors leave out. Capability maps, domain models, data discipline and decisions written down matter more with AI, not less, because AI amplifies whatever you give it, including the mess.

TOGAF and domain-driven design still tell you where a model belongs and where it does not. And most AI answers that go wrong do so because of the data around the model: as one chapter puts it, "the model read what it was given. The system gave it the wrong page."

Part III: an AI framework that fits

The practical part is how to extend the enterprise architecture practice you already have so it can carry AI:

1. Extend the ADM for AI. Ask one AI question per phase, place AI on the capability map, and record AI decisions in an ADR that says what would change the decision.
2. Treat evaluation as the new testing. Build the golden set before the prompt, score every change, and put the gate in the pipeline.
3. Keep agents inside guardrails. Write the workflow before the agent, give every tool a contract, and put a checkpoint before anything that writes.
4. Design for trust. Register every AI feature, let its risk tier set the depth of review, and decide in advance where the model does not decide.

Each chapter takes one popular belief about AI in software and puts it through the same test: the myth, the part that is genuinely good, and the correct practice to start on Monday. Every chapter ends with a checklist.

Who it is for

Solution architects, enterprise architects and tech leads who are being asked to "add AI" to something, and the engineering managers and leaders who fund those programmes. If you are a developer worried about the Enter key, it is for you too.

Press Enter, by all means. Then read what comes out.

Read Architecting for AI online, or get the Kindle or paperback edition.

---

Originally published at abhisheksrivastava.dev. The book is Architecting for AI: Everything Changes, Except the Fundamentals.