Generate proactive ADR suggestions when new technology options emerge — lab audio overview

Host: Welcome back. You're in GenAI Architecture and Design Patterns — a course about how senior engineers actually structure production AI systems so they don't collapse under their own weight six months in. This chapter is about building what we call an A-D-R engine. A-D-R stands for Architecture Decision Record — a short written document that captures a big technical choice, why you made it, and what the trade-offs were. Today's skill is teaching that system to spot when old decisions might be going stale. Expert: Picture this. You're on a platform team at a mid-sized company — maybe sixty engineers, a dozen AI projects running in production. Eighteen months ago, your team made a call: we'll use a particular hosted language model for all customer-facing chat, and we'll do retrieval — meaning we'll look up relevant documents and feed them to the model — instead of fine-tuning, which means retraining the model on your own data. That decision got written down as a record. Fast forward to today. A new, cheaper model just dropped. A new technique for retrieval came out. A competitor open-sourced something interesting. Nobody on your team is tracking all of this. So decisions quietly rot. You're paying three times what you need to. You're running on a model that's now two generations behind. Nobody notices until a review happens — or worse, until a customer notices. What's missing is a system that watches the technology landscape and taps people on the shoulder when a past decision deserves a second look. That's what you're building today. Host: So this is the third and final exercise in this objective. In the previous one, you built a recommendation engine — given a new decision someone is about to make, it finds similar past decisions by comparing the meaning of the text. Now you're flipping that around. Instead of a person asking "what's relevant," the system itself decides when to speak up. So — what exactly are we building? Expert: You're building a watcher. Imagine a small background system that has two inputs. On one side, it holds all your existing architecture decisions — the model you chose, the hosting strategy you picked, whether you went retrieval or fine-tuning. On the other side, it receives updates from the outside world: a new model released, a pricing change, a new technique published, a security advisory. Your job is to write the logic that takes each incoming update, compares it against every existing decision, and produces a ranked list of suggestions — "hey, this decision from last year might be worth revisiting because of this new thing." The key idea — the thing to really hold onto — is that this is rule-based, not AI-based. You are not asking a language model to guess what's impacted. You are writing explicit rules: if an update is about model pricing, and a decision chose a model for cost reasons, flag it. If an update is about a new retrieval technique, and a decision chose retrieval over fine-tuning, flag it. Think of it like a smoke detector, not a fortune teller. It doesn't predict the future. It watches for specific signals you've decided matter, and it rings a bell. This rule-based approach is deliberate — in production, you want impact analysis to be explainable and auditable, not a black box. Host: That framing really helps. Before someone opens up their editor — what's the part people get stuck on? Expert: The trap is over-flagging. The first version you write will scream about everything. Every new model release will ping every model-related decision. Every pricing update will light up the dashboard. And the moment your teammates start getting twenty suggestions a day, they stop reading them. The system dies of noise. So the tip is this: build in a confidence score from the start. Each rule should not just say "this is relevant" — it should say how relevant, on a scale. A new model from the same provider you already use, in the same size class, at a lower price — that's a strong signal, high confidence. A new model from a different provider in a different category — that's a weak signal, low confidence. Then you only surface the high-confidence suggestions by default. Start strict, loosen later. That single design choice — scoring instead of just flagging — is what separates a toy from something your team would actually keep running. Host: Last stretch. What will a listener walk away able to do, and where does that leave them? Expert: After this exercise, you'll be able to take a stream of technology updates and automatically map them onto an organization's existing architectural commitments, producing prioritized, explainable suggestions about what to revisit. That's a real capability. For your team, this is the foundation of what people call architectural governance at scale — the thing that lets a platform group of five support decisions being made by a hundred engineers without becoming a bottleneck. And because this is the final exercise in the objective, you now have the full picture: a system that tracks whether past decisions actually worked, one that helps people learn from similar decisions, and now one that proactively watches the world and speaks up. Taken together, that's a working decision intelligence layer — something concrete you can bring into your team's next architecture review and say, "here's how we stop letting decisions rot." Go build it. Thanks for listening.