Architecting for AI: what changes, and what still holds

Posted on Oct 23 • Originally published at abhisheksrivastava.dev

"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.

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."

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

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.

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.