Rule 2: Never Accept an AI's Proposal Blindly

The system architect's problem — an AI is trained to recommend the best solution, but it does not know what you know

The system architect's problem — an AI is trained to recommend the best solution, but it does not know what you know

My first rule was about the moment of decision: back up, understand, make the AI critique itself, ask what could go wrong. Four checks before you say yes.

This one is about something harder. It is about whether you are in a fit state to say yes at all.

The asymmetry

An AI proposes solutions based on patterns. It has read an enormous amount of code and it knows what a good fix generally looks like. That knowledge is real and it is useful.

But it does not know:

• Which of your modules three other subsystems quietly depend on
• Which code path is on the hot loop and which runs once at startup
• Which "obviously dead" branch actually fires on one customer's data
• What you tried two years ago and why you abandoned it
• Which assumptions the rest of your architecture is silently built on

You know those things. Not because you are smarter — because you have the history. Fourteen years of it, in my case. The AI has the code in front of it; you have the code and every decision that produced it.

So when the AI says "the right fix is to restructure X," it is saying: given the patterns I know, this is what a good fix looks like. It is not saying: given your system, this is safe. It cannot say the second thing. It does not have the information.

The architect's job is to supply the missing half. That is the whole job.

Why it is so easy to say yes

Here is what makes this hard in practice, and it has nothing to do with the AI's quality.

The proposal is confident. AI output is fluent and well-structured. A plan with numbered steps and clear justifications reads like a plan someone verified. Fluency is not verification, but your brain processes it as if it were.

The proposal is complete. It has already thought through the steps. Rejecting it means doing that thinking yourself, right now, when you were hoping the AI would do it for you. Saying yes is the path of least resistance in the most literal sense.

You are probably tired. This is the real one. If you supervise several projects — and if you run multiple AI agents you supervise several projects by definition — then at any given moment you are context-switching between systems you only half have loaded in your head. A proposal arrives from lane three while your attention is in lane one. You skim it. It looks reasonable. You say yes.

That yes was not a decision. It was a reflex dressed as a decision.

Speed is the actual danger

I have worked with human engineers for two decades. They get things wrong too — regularly. But there is a structural difference that matters enormously.

A human engineer who takes a wrong architectural direction takes days to get anywhere. In those days there is a standup, a question, a pull request, a conversation over coffee. There are natural interruption points where someone says "wait, why are we doing it this way?" The slowness is the safety mechanism. It buys you time to notice.

An AI agent that takes a wrong architectural direction has refactored eleven files before you finish reading the proposal you approved. By the time you feel the wrongness, the change has propagated. Now the cost is not "undo one commit." It is "understand what happened across eleven files, decide what to keep, and unpick the rest" — and the AI's own summary of what it did is no longer fully trustworthy, because if it had understood the system correctly it would not have gone the wrong way in the first place.

The speed that makes AI agents productive is the same speed that makes a wrong yes expensive. You do not get to keep one without the other. What you get to control is the yes.

The rule I actually follow

If I am tired, sick, or overloaded, I do not decide that case. I pause it.

Not "I decide more carefully." Pause. The decision waits until I am in a state where I can hold the whole system in my head.

This sounds like an obvious productivity platitude until you notice what it costs. Pausing feels like losing time. The agent is idle. The task sits. There is a visible cost to waiting and an invisible cost to deciding badly, and human beings are terrible at weighing those against each other — especially when tired, which is exactly when the choice arises.

So I made it a rule instead of a judgment call. Rules survive fatigue. Judgment does not.

The one exception: things I know I can undo. If a proposal is small, contained, and I can see that the worst case costs two or three hours of AI work to reverse, I approve it and move on. That is not carelessness — it is a calibrated bet with a known ceiling. The two-to-three-hour test is the whole exception, and if I cannot state the ceiling clearly, the exception does not apply.

Everything else waits.

What to do instead of waiting

Here is the part that makes the pause practical rather than merely virtuous.

I do not have one AI agent. I have twenty. And they are working on different things — a website page, a plugin fix, a test harness, a documentation pass, a data import. At any moment, several of them are waiting on a decision from me.

Those decisions are not equally hard. Some need the full architecture in my head. Some are "yes, that colour is fine."

So when a hard decision arrives and I am not in shape for it, I do not sit and stare at it. I go work a different lane. I answer the three easy questions from three other agents, I review a page of copy, I approve a test. Real progress happens. The hard decision keeps sitting there — and, crucially, my subconscious keeps chewing on it while I do the easy work.

This is the difference between "pausing" and "blocking." Nothing is blocked. One specific decision is deferred while I stay productive elsewhere. The agent whose proposal I deferred is not idle either — I give it something smaller and reversible to do in the meantime.

The case that taught me this

We had a concurrency problem with variants and strings — the runtime's dynamic value types being accessed from multiple threads at once. Real problem, real crashes, needed fixing.

The AI analysed it and proposed a fix. The analysis was competent. The proposal was coherent. And it was big — a substantial modification to how those types were handled throughout the runtime.

I could have approved it. It would have looked like progress that same day.

The thing that stopped me was not that I spotted a flaw in the reasoning. It was a much vaguer feeling: I do not know what this breaks. A change of that size in the dynamic-value layer touches everything, because everything in the language flows through variants. The unknown was not "will this fix the bug." The unknown was "what new bugs will we meet, and will we recognise them as coming from this change six weeks from now?"

That is the signature of a decision you should not make while tired. Not "I see a problem." Just: the blast radius is large and I cannot currently model it.

So I postponed it. One to two days. I kept working other lanes and let it sit.

The solution I arrived at was tiny. Twenty or thirty places in the code, two or three lines each. It does not interfere with the main logic anywhere — it sits beside it. The engine is, structurally, unchanged. And it holds under millions of operations.

Not a smaller version of the AI's plan. A different shape of solution entirely — one that only became visible once I had the whole system loaded and unhurried, and could ask "what is the least this could be?" instead of "is this plan acceptable?"

The AI could not have found it, because finding it required knowing which twenty or thirty places actually matter, and that knowledge is not in the code. It is in the history.

What the pause actually does

I want to be precise about this, because "sleep on it" sounds like folk wisdom and this is more specific.

The pause is not for gathering information. I did not go and read documentation for two days.

The pause changes the question. Under time pressure, facing a completed proposal, the question your mind answers is: "Is this plan acceptable?" That is an evaluation task — you check the plan against itself, and a coherent plan passes.

With time and a rested head, the question becomes: "What is the smallest thing that could possibly work here?" That is a design task, and it searches a different space — a space that contains the twenty-lines-in-thirty-places answer, which no amount of evaluating the big plan would ever surface.

You cannot get from the first question to the second by being more careful. They are different questions. Only slack gets you there.

To be clear: sometimes the big change is right

I am not arguing that the small fix always wins.

We also replaced a global semaphore in the runtime with hazard pointers and per-thread allocator caches — a five-stage migration over about a week and a half, each stage validated for twenty-four hours before the next. That was genuinely the right answer, and no two-line patch would have done it. The problem was structural, so the fix had to be structural.

The difference was not the size of the fix. The difference was that I committed to it after the pause, having modelled the blast radius, with a staged rollout and a rollback point at every step — rather than during it, on the strength of a proposal that read well.

Rule 2 is not "prefer small changes." It is: decide when you are able to decide, and not before. Sometimes the outcome of a proper decision is a very large change. That is fine. What is not fine is a large change you agreed to because you were tired and the plan sounded good.

The rule, stated plainly

An AI proposes the solution its training suggests. You hold the context that determines whether that solution is safe. If you are not currently able to supply that context — because you are tired, ill, or spread across too many systems — then you are not able to make the decision, and approving it anyway is not a decision. Pause that case, work a different lane, and come back when the whole system fits in your head.

The only exception is a change whose worst case you can state in hours.

That is it. It costs a day or two occasionally. It has saved me weeks repeatedly.

I run twenty AI coding agents on a platform I built from scratch — own compiler, own database, own protocol. The agents are enormously productive. The constraint that makes them productive is not their capability. It is the discipline around the yes.

Previous: Your AI Just Proposed a Grand Plan. Here's What to Do Before You Say Yes.

More: elastcode.com/downloads/articles.html