Worked Design — AI in a Legacy MVC Application

Second rehearsal scenario, and the one most working .NET architects will actually face: a 15-year-old ASP.NET MVC line-of-business application — thousands of users, a SQL Server schema nobody fully remembers, and an executive asking "where does AI fit?" The common failing answer is proposing a rewrite. The scoring answer is adding AI without destabilizing the monolith.

Triage the opportunities

Run step one of the method across the whole application, not one feature. Three candidates almost always surface, and they map directly onto the capstone blueprint:

• Doc-QA over internal knowledge — wikis, SOPs, past tickets. A RAG assistant with citations; the highest-value, best-understood pattern (the capstone's credential assistant, aimed inward).
• An ops assistant — "why did last night's import job fail?" answered from job tables and logs via read-only retrieval, exactly the capstone's ops-assistant solution.
• An AI-ready repository (Module 18) — CLAUDE-style agent docs, conventions, golden tests, so AI coding tools stop hallucinating against the legacy codebase. Zero runtime risk, immediate developer-velocity payoff.

Notice what triage excludes: nothing here touches the order-processing path. High-risk core workflows earn AI last, if ever. Trade-off aloud: you are leaving the flashiest demo on the table in exchange for shipping safely.

Integrate without destabilizing

The architectural rule that carries this design: the monolith stays authoritative. AI lives in a sidecar service — a modern .NET API alongside the MVC app (a container next to the IIS box, or an Azure App Service) — and the monolith calls it over HTTP like any other dependency.

• No direct DB writes from AI code. The sidecar reads via views or replicas; anything it wants changed goes through the monolith's existing service layer, where validation and audit already live. An LLM-adjacent process with write access to a 15-year-old schema is how outages happen.
• Deterministic seams. The MVC app sends a request and gets JSON with a confidence grade; if the sidecar is down or unsure, the page renders without the AI panel — fail-closed degradation, not an error page.
• Auth reuse. The sidecar honors the app's existing roles; retrieval filters by what the user may see, so the assistant never becomes a permissions bypass.

Trade-off: a sidecar adds a network hop and a second deployable. Against "AI bug takes down the LOB app," that cost is trivial — say so.

Phase the rollout, cheapest risk first

Sequence by risk, not by impact: (1) AI-ready repo — days of work, no runtime footprint; (2) internal doc-QA for one pilot team, with a golden set and refusal monitoring from day one; (3) ops assistant, read-only, once retrieval quality is proven on phase 2's telemetry. Each phase ships value, builds the evaluation habit, and earns trust for the next. When the interviewer asks "why not start with the customer-facing feature?", the answer is the method: requirements said the monolith must not wobble, so the cheapest-risk phase goes first — because of that requirement, not because of caution for its own sake.