MODULE 16 / 18 · PART 5 · LEAD THE AGENT & THE INTERFACE
High-Impact Architectural Questions
The questions that prevent systemic regressions after the immediate fix.
THE SHORT ANSWER
What this module changes.
Solving today's 404 is step one. These questions test whether the fix belongs in the architecture, who depends on the behavior, and how you would know if you are wrong.
As a Senior Architect, solving the immediate 404 is only step one. Here are the critical architectural questions that prevent systemic regressions:
Decisions made in a WhatsApp group or a hallway are easy to lose and expensive to relitigate. The questions here turn them into written, owned, reversible choices that survive staff changes.
THE MODULE PROMPT LIBRARY
20 prompts for architectural questions.
Copy any prompt, replace the [bracketed] slots with your own project context, and attach the files the agent needs. Use “Copy all prompts” when you want the full module in one place.
20 copy-ready prompts. Bracket text is a slot for your own context — replace it before you send the prompt.
Is this a one-off fix or a symptom of a missing abstraction? What would the fix look like if we expected this class of request to recur?
Why it worksFixes the pattern instead of the instance, which is the difference between a patch and an architecture.
Who else depends on the behavior we are about to change, and how would we find out if we are wrong?
Why it worksBlast radius is the first question in any change review, and the hardest to answer after the fact.
What is the invariant here, and where is it enforced — in code, in the database, in a convention, or in someone's memory?
Why it worksAn invariant that lives in memory is an invariant that will be violated by the next hire.
If this component is unavailable for ten minutes, what does the user see, and what does the system do?
Why it worksAvailability is a product decision; the answer should be designed, not discovered during an incident.
What is the failure mode we have not tested: slow, partial, duplicated, or out-of-order responses?
Why it worksProduction fails in partial ways; tests usually only cover the clean failure.
Where does this data come from, who owns it, and what is the source of truth when two systems disagree?
Why it worksData ownership ambiguity is the root of most reconciliation bugs and most cross-team escalations.
What happens at ten times the current load, and which resource saturates first?
Why it worksScaling problems are predictable; the first saturated resource is the design constraint.
Is this decision reversible, and what would it cost to reverse it in six months?
Why it worksReversibility, not correctness, is what determines how much deliberation a decision deserves.
What is the migration path for existing data and existing clients, and can it run while the system is live?
Why it worksA design without a migration path is a design that ships as a maintenance window.
Which of these requirements are actually constraints, and which are habits we have not questioned?
Why it worksSeparating real constraints from inherited assumptions is where the cheapest wins hide.
What is the observability story: how will we know this is working, and how will we know it is failing before a user tells us?
Why it worksIf you cannot see it, you cannot operate it, and you will not know when it degrades.
What is the security boundary here, and what is the trust level on each side of it?
Why it worksEvery interface is a trust boundary; unstated trust assumptions become vulnerabilities.
What is the rollback plan, and how long does it take to execute under pressure?
Why it worksA rollback you have never rehearsed is a hope, not a plan.
Which parts of this design are load-bearing assumptions, and what is the cheapest experiment that would falsify them?
Why it worksTests the assumptions while they are still cheap instead of after the rewrite.
What is the cost of this abstraction in cognitive load, and does it pay for itself in the next three changes?
Why it worksAbstractions are investments; unmeasured ones become liabilities.
Who is on call for this, and what will they need at 3 a.m. to diagnose it without the author?
Why it worksDesigns are judged by the worst night of their operational life.
What is the smallest version we could ship that would teach us whether the rest is worth building?
Why it worksConverts an expensive bet into a cheap experiment.
What did we decide here, what did we reject, and where is that written down?
Why it worksUndocumented decisions get relitigated every quarter by people who were not in the room.
If we are wrong about this, how will we find out, and how much will it cost to correct?
Why it worksTurns an architectural bet into a monitored, bounded risk.
What would we have to believe for this design to be the right one — and do we actually believe it?
Why it worksSurfaces the assumptions the design silently depends on, which is where reviews should focus.
PRACTICE · 20–30 MINUTES
Try it on a project you actually own.
Answer five questions for your current project in a one-page decision note. Put it in docs/decisions/ and link it from the README.
- Pick one prompt from this module that matches a real task.
- Replace every bracketed slot with context from the feature you are working on now.
- Attach only the files the agent needs. Keep secrets, credentials and personal data out of the chat.
- Ask for the artifact — a spec, diff, test, runbook or decision note — and the evidence that it works.
- Record what changed and what remains unverified in the repository.
Want the same prompts across every module? Search the full prompt library or return to the course overview.