Working with AI Teammates

Overview

Teams now include contributors that are not people. That is a description of current practice rather than a prediction, and it changes the architect’s daily work in ways that are mostly unglamorous.

The useful framing is not whether this is good. It is: which parts of your own work can be delegated, and what does reviewing the result actually require?

What delegates well

Module 7 established the general shape and Section 2 applied it to legacy work. For architectural work specifically, four categories delegate well:

Enumeration. Every failure mode of this design, every call site of this dependency, every case the requirements do not cover. Exhaustiveness is where human attention is weakest and where verification is easy — the items either exist or they do not.

First drafts of structured artifacts. A comparison table against stated criteria, a decision record’s scaffolding, a diagram from a described structure. The structure is standard; your contribution is the content and the judgement.

Explanation of unfamiliar material. A subsystem, a protocol, a technology’s trade-offs. Cheap, and you were going to verify it against reality anyway.

Adversarial review of your own design. The most valuable and the most underused. Asking for the strongest case against a design you have built is work your own investment makes you bad at, and Module 7’s red-teaming was exactly this.

What does not

Anything requiring unwritten context, which the first topic of this module established is where the real constraints live.

Anything carrying accountability. Not a capability limit but a structural one: the decision has to attach to someone answerable.

Choosing the question. The reliable failure is a well-executed answer to the wrong question, and nothing in the output indicates it.

Reviewing what comes back

graph TD
  A["<b>1 · Were the constraints<br/>in the input?</b>"] --> B["<b>2 · Does the<br/>arithmetic hold?</b>"]
  B --> C["<b>3 · What is missing?</b><br/><i>omissions leave<br/>no trace</i>"]
  C --> D["<b>4 · Reasons, or text<br/>that sounds like reasons?</b>"]

  classDef one fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef two fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef three fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A one
  class B,D two
  class C three

Module 9’s four checks, which are the review protocol for a generated design. The third remains the hardest, because a complete-looking document gives no sign of what it left out.

Two things change about review when the contributor is not a person.

The confidence signal disappears. A colleague’s design is weakest where they were uncertain, and the uncertainty is visible — in hedged language, in a section that trails off, in the way they present it. Generated work is uniformly confident, so the usual heuristic for where to look hardest is absent and must be replaced by a checklist.

Volume breaks the economics. Module 9’s arithmetic: cheap production does not raise quality so much as raise quantity, and review capacity becomes the constraint. The practical consequence is that reviewing generated work thoroughly only scales if you also decide what not to generate.

The honest difficulty with delegation

Delegating work you could do yourself is how you learn whether it was done well. Delegating work you could not do yourself is a different act — you are accepting output you cannot evaluate, and no amount of plausibility substitutes.

This sets a real boundary on how far delegation extends: you can safely delegate what you could verify, not what you could produce. Those are different sets, and the second is larger — you can verify arithmetic you would not have thought to perform, which is why the previous section’s findings were catchable. But the gap is not unlimited, and an architect delegating design in a domain they cannot evaluate has delegated the accountability too, which is the one thing that does not transfer.

Four delegations, and the one that was refused

How the work across this guide actually divided.

Delegated and verified — the enumeration. Every failure mode of the agent loop in Module 5, every call site of the credit path in Section 2, the full list of cases the requirements left uncovered in Module 2. Mechanical, exhaustive, and checkable against the code and the documents.

Delegated and verified — the adversarial pass. Module 7’s red-team of the Modules 4–6 design. Asking for the strongest case against your own work is where investment makes you least reliable, and five of the defects it surfaced were real. The verification was ordinary: each claimed defect was checked against the design and the constraints, and the ones that held were kept.

Delegated with a procedure attached — the characterization tests. Section 2’s trap: a model asked to write tests for the credit logic asserted intended behaviour, and the failures against the real system were exactly where the undocumented contractual-adjustment path lived. The delegation stayed, with the rule that observed values come from running the code and never from the model. That is delegation working because the verification step was designed before the work started.

Refused — the reconstruction of the 2023 decision. Module 9’s recovery topic could have asked for a plausible rationale for why the smart-routing feature was switched off. A model would have produced one, fluently, and it would have been fabrication: the reasoning exists only in the heads of people who were there, and the honest status is “no rationale found”. This is the delegation boundary in its clearest form — the output would have been unverifiable and would have discredited the entire record set.

And what could not have been delegated at all. That there is no spare engineering capacity. That Ivan Petrov’s veto is real and informal. That the absence of a postmortem is itself the finding. Every one of those is unwritten, and each governed more of the design than any technical choice did.

Feeds the workbook

Your competency gap analysis should distinguish what you can verify from what you can produce. The gap between those two sets is the honest measure of how far your delegation can safely extend.

Check your understanding

1. Which part of your work would you delegate first? What is your verification step, and did you design it before or after?
2. Name something you have accepted that you could not have evaluated. What made you accept it?
3. Where is your “no rationale found” — something you were tempted to have filled in plausibly?

---

→ Delegating your own work is the small version. The large version is shaping everyone else’s. — Configuring the environment