Pair-Designing an Architecture With AI: Where It Helps, Where It Lies

TL;DR — Use an AI in architecture design for coverage (enumerate options, including ones you'd skip), steelmanning (argue for the approach you already rejected), and failure-mode interrogation (walk the state machine when the network dies mid-write). Do not trust it for consensus claims ("most teams do X" — no such measurement exists), performance numbers it didn't compute, or anything requiring a cost model of your team. Its worst failure is agreeing with your framing: ask for options before you state a preference, then make it argue the other side.

The three things it's genuinely good at

Enumerating the option space

Architecture mistakes are rarely "we picked the wrong one of two". They're "we never considered the third one". A model's strength is exactly here — it has read a very large number of designs, and recall over a broad space is what it does well.

"I need offline-capable editing for a notes feature. Give me six approaches, including ones you'd normally consider outdated or overkill. For each: what it optimises for, what it costs, and what kind of team it suits."

You'll get last-write-wins, CRDTs, operational transforms, an outbox queue, event sourcing, and server-authoritative-with-optimistic-UI. Maybe four are wrong for you immediately. The value is that you rejected them knowingly, and one of the four will contain a mechanism worth stealing.

Coverage is the deliverable here. Judgement is not.

Steelmanning the option you already dismissed

The most useful prompt I run in a design session:

"We're planning to build this with a full sync engine. Make the strongest possible case for the boring version: a single 'pull on open, push on save' round trip, no conflict resolution, last write wins. What would have to be true for that to be sufficient?"

That last sentence is the load-bearing one. "What would have to be true" converts an argument into a checkable list — "edits are single-device 95% of the time", "a lost edit is recoverable from local history", "sessions are short". Now you can go and check those against your analytics instead of debating them.

Roughly half the time the boring option survives contact with the list, and that's a quarter of engineering time you didn't spend.

Interrogating failure modes

This is where it's tireless in a way humans are not, at 4pm on a Thursday:

"Walk through this design when: the process is killed mid-sync; the device clock is 40 minutes fast; the user edits on two devices while offline; the server returns 409 on the third of five batched writes. For each, what's the resulting state?"

It will find real holes. It found one in a design of mine where a partial batch failure left the outbox in a state that would replay two of five writes — obvious in hindsight, invisible in the diagram.

The four lies

1. Invented consensus

"Most Android teams use a repository per feature module." "The standard approach in 2026 is…"

No such measurement exists. There is no survey of Android architectures, and if there were, the model hasn't read it. What you're getting is an average of writing about architecture, which is heavily skewed toward blog posts, which are heavily skewed toward whatever was fashionable in the training window. It's delivered in the register of a fact.

The tell is any sentence containing "most teams", "the industry standard", or "best practice" without a named source. Ask "according to what?" — you'll get a graceful retreat, which is itself the answer.

2. Numbers it did not compute

"This should reduce cold start by around 30%." "CRDTs typically add 15–20% to payload size."

These are shaped like measurements and are not measurements. The plausible range is the problem: a wildly wrong number gets challenged, a plausible one gets copied into the design doc and then into the sprint justification.

Rule: delete every quantity in the output that the model didn't compute in front of you. If a number matters to the decision, it's a spike, not a prompt.

3. No cost model

It cannot know that your team is four people, that two have never shipped Kotlin Multiplatform, that one is on parental leave in March, and that the deadline is real because it's tied to a partner launch. So it designs for an idealised team with no history and no calendar.

You have to supply the constraints explicitly, and it's worth being blunt:

"Constraints: 4 Android engineers, none with KMP experience. Existing app is 400k lines, Dagger, no module boundaries below feature level. Ship date is 14 weeks out and immovable. Now re-rank those six options."

The re-ranking is usually different and usually correct. The model isn't bad at weighing constraints — it's bad at inventing the ones you didn't give it.

4. It agrees with your framing

This is the expensive one, because it's invisible.

Ask "should we adopt MVI?" and you get an essay on why MVI is a good fit. Ask "is MVI overkill here?" and you get an essay on why it's overkill. Same problem, same model, opposite answers — because the question smuggled in the conclusion and the model completed the pattern.

So the sequencing matters more than the prompt wording:

1. Describe the problem and constraints only. No candidate solutions, no hints at preference.
2. Ask for options and trade-offs.
3. Then say what you were leaning toward — and ask it to argue the opposite.
4. Ask what it would need to know to change its answer.

Step 4 is a decent honesty probe. A well-posed design question has an answer to "what evidence would flip this"; if there isn't one, you're being told what you wanted to hear.

What this looks like in an hour

A design session that actually works, from my own notes:

• 10 min — write the problem and constraints down properly. This is work you'd have to do anyway, and it's where most of the value gets created, because vague inputs produce fluent nonsense.
• 15 min — option enumeration and trade-offs. Read critically; strike the consensus claims and the invented numbers as you go.
• 15 min — steelman the two front-runners against each other, using "what would have to be true".
• 15 min — failure-mode walkthrough on the leading option.
• 5 min — draft the ADR: context, options, decision, consequences. Now it's easy, because every section already exists in the transcript.

The decision at the end is yours, and it should be defensible without mentioning the tool at all. If your justification is "we asked and it suggested this", you skipped the part where the thinking happened.

The rule

Treat it as a very well-read colleague who has never seen your codebase, never met your team, and will never say "we don't have the time for this." That's a genuinely valuable colleague — for breadth, for pressure-testing, for the questions you're too close to ask. It is not an architect, because architecture is mostly the constraints, and the constraints are the one thing it can't see.