Architecture Design — How to Use AI as a Design Advisor— Using advice well, weighing trade-offs, and the responsibility people carry

01What a Design Decision Is — Deciding "What Is Hard to Change Later" First

The phrase "architecture design" sounds grand, but the substance is simple. Decide the things that are hard to change later, first. That is the whole of it. Martin Fowler describes architecture as "the things that the experts in that field think are important, and the things that are hard to change." Variable names and button colors can be fixed any time. But the type of database, the boundaries that divide a system, and dependencies on external services carry a heavy cost to reverse once they are decided and running.

So design decisions carry a weight that ordinary code changes do not. Sorting the decisions by type makes them easier to handle.

• Reversible decisions — easy to undo even if you get them wrong. How to split functions, part of the library selection. Decide these fast and fix them as you go.
• Semi-reversible decisions — reversible, but it hurts. The shape of an API, how data is held. Worth pausing once before you commit.
• Near-irreversible decisions — effectively no going back. The underlying database, the boundaries between systems, the core of external dependencies. Take your time here.

If you decide everything at the same speed without feeling this difference in weight, it catches up with you. Burning time agonizing over reversible decisions, then committing to irreversible ones on momentum — that is the single most common failure in design.

02How to Use AI's Advice — Not to Let It Decide, but to Widen Your View

As a design partner, generative AI has several strengths. At the same time, there are clearly areas you must not hand over to it. The discipline is to use the two separately.

AI's advice has quirks of its own. First, fluency and correctness are different things. An assertion delivered in polished prose looks right, but it is not rare for the grounding to be thin. Second, AI is pulled along by the question. Ask "should we go microservices," and you tend to get an answer that leans toward recommending microservices. To ask neutrally, place the options on equal footing: "for these requirements, which is more appropriate, a single structure or a split structure — argue both sides." And the biggest caveat of all is that AI does not know all of your constraints. Budget, team size, the fit with existing systems, internal approval processes, regulatory requirements — these shape a design heavily, but unless you state them explicitly, they will not be reflected in AI's answer. It will cheerfully produce a textbook-correct proposal that does not work at your company.

03Record It in an ADR — Putting into Words Why You Decided That Way

Design decisions are questioned more six months later than at the moment they are made. Nobody can recall "why we chose this structure," so it becomes too frightening to touch and is left alone — a familiar scene. A light mechanism to prevent this is the ADR (= Architecture Decision Record). It is a method proposed by Michael Nygard in 2011 for recording a single decision in one very short document.

An ADR is not a heavy design specification. The rule of thumb is a length you can write in a few minutes per decision. In the standard form you write only the following items.

• Title and status — "Accepted," "Deprecated," "Superseded," and so on. You can update just the status later.
• Context — under what circumstances, and what you needed to decide. Constraints go here too.
• Decision — what you chose. State it in a single sentence.
• Consequences — what got better from that choice, and what you took on as a result. Write the downsides honestly too.

Consulting AI pairs well with the ADR, because the options and trade-offs that come up during the discussion become raw material for "Context" and "Consequences" as they are. That said, do not paste in the text AI produced as is. Rewrite it in your own words, against your own constraints. The act of rewriting is itself the step that makes the decision your own.

04Judging Trade-offs — "Good Design" Changes with the Situation

There is no single right answer in design. There is only the way you strike a balance for each situation. For the same requirements, the right structure differs between a team of three and a team of thirty. When you ask AI for advice, unless you hold this balance yourself, you get swept into generalities.

It helps to nail down the typical opposing axes as a contrast.

Ask AI, and it often recommends a grand, highly extensible structure. Textbook-correct. But giving up today's simplicity for a future that may or may not arrive rarely pays off. Ask yourself "when, and with what probability, will that flexibility actually be needed?" and if the probability is low, choose the simple option — a judgment only someone who knows the context can make.

ISO/IEC 25010, the international standard that organizes software quality characteristics, lists several qualities side by side: maintainability, performance efficiency, reliability, security, and more. The important point is that these cannot all be maximized at once. Which to prioritize, which to compromise. That prioritization is the very substance of a design decision, and the part you cannot fully hand off to AI.

05Verification — How to Check Instead of Swallowing Advice Whole

Don't adopt AI's design advice as is; check it from several angles. A design that runs is not necessarily a correct design. The following are the minimum checks before you decide.

• Ask it back for the grounds — "give me three specific reasons why that option is good." If the reasons are thin, the advice is low-confidence.
• Have it produce the counter-proposal — ask the same AI, "if you were arguing against this option, how would you criticize it?" If it can only produce the same answer consistently, its view may be narrow.
• Try it in a minimal build — verify important decisions with a small prototype (= a trial build) before formal adoption. Correctness on paper and how it feels in motion are different.
• Add constraints and ask again — state budget, headcount, and existing systems explicitly and re-ask; the first answer sometimes collapses. Advice that collapses was only worth that much.

In particular, consulting multiple AIs or multiple sources reveals the bias in the advice. Even an option one model strongly recommends may be evaluated differently once you bring in another perspective. Because verifying a design is harder to automate than testing code, people need to hold a "procedure for doubting" as a discipline of their own.

06Human Responsibility — AI Advises; People Decide and Bear It

This is the core of the installment. However fluently AI advises, the responsibility for choosing that design lies with the person who chose it. "Because the AI said so" does not hold up later. When a failure occurs, when an audit asks, it is people who are called on to explain.

To keep this locus of responsibility from blurring, draw a few lines.

• The final call is made explicitly by a person — keep a step where a person approves AI's output, even if only in form. Don't let it flow through automatically.
• Leave a person's name on the record of the decision — write who decided in the ADR. Don't create decisions with no one responsible.
• Don't adopt a design you cannot explain — if you cannot state the reasons in your own words, hold off even if AI recommends it. You cannot defend what you do not understand.

In the pharmaceutical and medical context, this principle weighs even heavier. Handling patient data, system reliability, change management — every one of these assumes that "a person judges, and can explain that judgment." Using AI in design is not itself a problem, but you cannot shift the subject of responsibility onto AI. The tool is an advisor, not a decision-maker. Not losing sight of that line amid the convenience is the heart of the discipline.

07Operation — Design Does Not End in One Pass

A design is not complete the moment you release it. As you keep it running, the gaps between assumption and reality come into view. Holding the view that architecture is something you grow changes how you deal with AI, too.

In the operational phase, AI is useful in scenes like these.

• Finding the gaps — explain the trends in logs and failures, and search together for "where the design is straining."
• Mapping the blast radius of a change — have it enumerate "if we change this, where does it ripple," and reduce oversights.
• Taking stock of past ADRs — as circumstances change, have AI list decisions that no longer fit as candidates for review.

Here too the principle is the same. AI is good at drawing the guideline that helps you notice, but whether to change is decided by people. Don't condemn a past decision by today's standards — reread the "Context" of the ADR, understand that it was reasonable at the time, and then judge whether to update it. An attitude of respecting the history of a design builds systems you can maintain for a long time.

08Connections to Other Chapters

The architecture design in this installment is continuous with the other installments in the series. Read together, they reveal the flow from design to implementation to collaboration.

• The power to put requirements into words — before design comes articulating what to build. Ask AI to design with vague requirements, and you get only a vague answer.
• Verification and quality assurance — the correctness of a design decision is confirmed through testing and operation. Design and verification go back and forth.
• Next time's pair-programming discipline — after the design is decided, how to collaborate with AI in the implementation phase. Because the weight of the decisions differs, so does the way you work together.

Architecture design is, even within AI use, the area where human judgment is questioned most. Implementation has more that AI can take over, but what to build, what to give up, and why you decided that way stays in human hands. Not letting go of that initiative is the work left to the designer in the age of AI.

Now that we can consult AI on design, convenience has surely grown. As a partner that widens the options, lays out the trade-offs, and questions the assumptions, AI is excellent. But that excellence is excellence as an advisor, not as a decision-maker. Don't get swept along by a fluent assertion; choose against your own constraints, leave the reasons in an ADR, and let a person bear the responsibility — this whole discipline does not change no matter how clever the models become.

If anything, the smarter AI gets, the more plausible its advice becomes, and the stronger the temptation to swallow it whole. That is exactly why you should draw the line — people decide, and people bear it — first, as a discipline. Using AI in design consultation is not about handing over the decision, but about using it to raise the quality of the decision. Next time we move to the implementation phase after the design is set — the "pair-programming discipline" of people and AI writing code side by side.