Architecture with AI as a sparring partner – without losing ownership

A sparring partner you can ask anytime

You’re working through an architecture choice and need someone to discuss it with. AI can suggest approaches, explain patterns, and help you find weaknesses in a proposal. It’s available at 11 p.m., when the idea finally falls into place and the rest of the team has logged off.

That’s useful. But the answer can sound convincing long before it fits your system. As a tech lead, you need to help the team examine what sits behind the proposal: its assumptions, constraints, and trade-offs.

What do you do with the answer?

“How should we build this?” is a perfectly reasonable place to start. The problem comes when the first answer also becomes the decision.

Try taking it further: “Here are our constraints. What alternatives exist? What are the arguments against your proposal? What do we need to investigate before choosing?” That gives the team more to work with. You still need to assess whether the answers hold up.

An experiment at Anthropic offers a reason to pay attention to understanding along the way. In a randomized study, Shen and Tamkin had 52 engineers learn an unfamiliar Python library with and without an AI assistant. The AI group averaged 50 percent on a comprehension quiz immediately after the task, against 67 percent in the group without AI. The study measured learning of the library, not the quality of architecture decisions or competence over time.

Within the AI group, the researchers observed that engineers who used the assistant for explanations and follow-up questions often showed better understanding than those who handed the work over to it. Those approaches were not randomly assigned. This is an observation, not proof that a particular way of asking produces better learning.

A well-written proposal doesn’t tell you how thoroughly the team has examined it either. That needs to come out in the discussion.

Test the proposal against the system you have

In Handling disagreement in technology choices (in Norwegian) I wrote about design review: a short, focused meeting where the relevant people present arguments based on experience and facts. Proposals developed with AI belong in the same process.

Whoever presents the proposal should be able to explain why it fits. The team assesses complexity, operations, skills, and consistency with the rest of the system. When information is missing from the conversation with the model, a familiar pattern can look far more suitable than it is.

I watched that play out on a migration. An existing codebase had to move to another language and platform, for strategy and security reasons. The model’s first architecture had the new system shadow the old one: running alongside it, taking the same input, writing nothing, logging only what it would have done.

This is a variant of dark launching, as described by Fowler. The pattern itself doesn’t require the systems to run on the same server. But the proposed implementation in this migration wasn’t buildable. The old system runs on an outdated server whose deploy agent is dead and cannot be restarted, so nothing can be deployed there: not the new app alongside the old, and not the logging the comparison would have needed on the old side.

Moving it to a new server first would have cost one outage, for the database move and the queue drain – and a second one later, to turn the shadowing off. Several more iterations went the same way.

What finally produced a buildable architecture was the developers, new and long-serving, putting enough of the existing system into words that the constraints became visible.

The pattern was familiar. What the model lacked was the information about one dead process on one old server. It wasn’t written down anywhere, but it was decisive for the architecture. We needed the experience of the people who knew the system.

Questions that help the team move forward

As a tech lead, you don’t need to turn design review into an exam. You’re helping the team establish whether the proposal holds up. Three questions make a useful starting point:

• Why does this fit our situation? “The AI recommended event sourcing” says little about the need. Ask how the choice addresses the problem.
• Which alternatives did we consider? Bring out what was rejected and why. If the team has only looked at one proposal, you can investigate an alternative together.
• What don’t we know yet? Perhaps no one can explain what happens when traffic grows tenfold. Then you need an investigation, someone responsible for it, and an agreed date for an answer.

“We don’t know yet” can be a responsible answer. What matters is how the team follows it up, and whether the uncertainty needs to be resolved before making the decision.

Let the team own the decision

In The Quiet Responsibility I wrote about letting the team challenge and improve proposals before they become standards. The same applies here. The people who will build and operate the solution need a chance to shape the choice.

A finished document can’t do that work alone. Make time for questions. Listen to the person who knows the old deployment setup, and to the new developer who doesn’t understand why an alternative was rejected. Both may see something the proposal is missing.

A practical pattern

You can organize the work like this:

1. Explore with AI. Work individually or in pairs. Describe known constraints, ask for alternatives, and examine the model’s reasoning.
2. Hold a design review. Assess the proposals with the team and the people who know the operational side. Record assumptions and open questions.
3. Resolve what determines the choice. Assign investigations or small experiments. Make the decision once the team has enough information, and record the uncertainty that remains.
4. Write a TDR. Document the choice, alternatives, and the team’s reasoning in a Technical Decision Record. Agree what might warrant revisiting the decision.

For your next design review, ask whoever presents the proposal to bring one rejected approach and one assumption that still needs checking. That gives you something concrete to examine together, before the architecture becomes code.