When should an architect reason from first principles and when should they pattern-match to known solutions? What goes wrong with each?

What each is good for

Pattern matching is fast, low-risk and correct most of the time. Most problems are not novel; the organisation's problem has been solved thousands of times, and recognising which known problem it is, is the most efficient move available. It also produces designs that other engineers understand immediately, which has substantial ongoing value.

First-principles reasoning is slow and is the only thing that works when the pattern does not fit — and it is what identifies that the pattern does not fit, which is the harder judgement.

Where pattern matching fails

• Superficial similarity. The problem looks like a known one and differs in a property that matters. The most expensive errors in architecture have this shape: adopting a pattern whose preconditions are absent.
• Importing preconditions silently. Every pattern assumes things — a scale, a team structure, a failure model, a cost profile. Cell-based architecture assumes automation mature enough to operate many cells; event sourcing assumes a domain where history is the truth; a service mesh assumes enough services to amortise it. The pattern is described without the preconditions and adopted without them.
• Cargo culting from a different scale. A solution from an organisation three orders of magnitude larger frequently addresses a problem you will never have, at a cost you cannot amortise.
• Patterns that persist past their conditions, applied out of habit long after the situation changed.

Where first-principles reasoning fails

• It is slow, and applied everywhere it prevents the team from shipping.
• It rediscovers known failures at your own expense. The accumulated experience embedded in a pattern is real knowledge, and a from-scratch derivation typically misses the edge cases that the pattern exists to handle.
• It produces unfamiliar designs that every future engineer must learn, which is a permanent tax.
• It is frequently a preference wearing an argument. "Our requirements are unique" is usually familiarity with current process rather than genuine distinctiveness — and the honest test is whether the uniqueness is valuable to customers or merely historical.

The productive combination

Pattern-match first, then check the preconditions from first principles.

1. Recognise the pattern — this is a caching problem, a consensus problem, a fan-out problem.
2. State the pattern's preconditions explicitly, which the pattern's description usually omits.
3. Check each one against your situation. This is the first-principles work, and it is bounded and fast.
4. If they hold, use the pattern. If one fails materially, that is where original thinking is required — and only there.

This confines expensive reasoning to the part that actually needs it, which is the practical skill.

The habit worth building

For any pattern you use, be able to state why it works. Not the name and the diagram, but the mechanism and the conditions. An engineer who can state a pattern's preconditions will recognise their absence; one who knows only the shape will apply it wherever the shape appears — and that difference is most of what distinguishes experienced architectural judgement from confident recall.