How Software Architects Use Claude for Real Design Work
Architects use Claude for the parts of the job that are reading and writing at volume: gathering constraints from an existing codebase, drafting and stress testing architecture decision records, comparing options against stated tradeoffs, and checking whether a proposed design matches what the code actually does. It does not replace judgment about what the organization can operate.
What architecture work actually consists of
Strip away the diagrams and the job is mostly this: find the constraints, enumerate the options, weigh them against constraints the organization cares about, write the decision down, and defend it later.
Only one of those steps is creative. The rest are reading and writing at volume, across systems no single person has fully in their head. That is precisely the shape of work where an agent with repository access is useful, and it is why architects were early adopters of coding agents even when they were not the ones writing the code.
The constraint discovery step is where the time goes. Before you can propose anything, you have to know how the current authentication flow works, which services depend on the queue you want to replace, what the deployment topology is, and which of last year's decisions are still load bearing. Every hour of that is reading, and most of it is reading things that were already documented somewhere nobody can find.
Four uses that hold up
Constraint extraction from an existing system. Point the agent at the repository and ask what a subsystem depends on, where a piece of state is written, or what would break if a service disappeared. It reads faster than you and it does not skim. Verify the surprising answers, since a confident wrong answer costs more here than in most contexts.
Drafting and stress testing ADRs. Give it the context and the options and ask for the decision record, then ask it to argue against the decision. The second half is more valuable than the first. Models are good at producing the counterargument you already half know and were avoiding.
Design review against the actual code. This is the highest value use and the one most teams skip. Hand it the proposal and the repository and ask which assumptions in the proposal do not hold. Proposals routinely assume behavior that was refactored away two quarters ago, and that mismatch is expensive to discover during implementation.
Tradeoff analysis with explicit criteria. Not "which is better" but "score these three options against latency, operational burden, migration cost, and team familiarity, and show where they disagree." Stated criteria produce useful output. Open ended comparison produces a listicle.
Diagrams are the least interesting use
Generating a diagram from a description is easy and mostly cosmetic. Generating a diagram from the code is useful, because it shows the system as it exists rather than as it was designed. The gap between those two pictures is usually the most informative artifact of the whole exercise.
Where it fails, predictably
An agent has read a great deal about distributed systems and nothing about your organization. It does not know that the team maintaining the billing service is two people, that the last migration took nine months, or that the platform group has a hard rule about managed services. It will produce a technically defensible design that your organization cannot operate, and it will produce it confidently.
It is also weak on cost and capacity questions that depend on real traffic. If you ask whether an approach will hold at your volume, you are asking it to guess, and the guess will be well formatted. Feed it your actual numbers or do not ask.
The practical rule: treat it as an extremely well read colleague who joined yesterday. Excellent on mechanism and precedent, useless on politics and operations, and worth checking whenever the answer is convenient.
Make the decisions retrievable or you will make them twice
The lasting problem in architecture is not producing decisions, it is finding them later. Six months on, someone proposes the option you rejected, and the reasoning exists only in a closed pull request, a meeting nobody recorded, and the memory of one person who has since changed teams.
An agent makes this worse before it makes it better, because it lowers the cost of producing documents. Volume without retrieval is noise.
The fix is to index the decision record along with the code and docs it refers to. RDK handles this: files from local vaults, docs, and code become encrypted private chunks, and any agent searches those chunks before querying a model. When someone asks why the queue was chosen over the log, the answer is retrieved from the ADR you already wrote rather than reconstructed by a model that never saw it.
The cost side follows. Stacked retrieval means private vault search answers 40 to 65 percent of questions outright, the public network adds 15 to 20 percent, and the model handles the remaining 5 to 10 percent, which cuts token spend 80 to 90 percent compared with regenerating context every session.
What to write into an ADR so it survives
Context, the options considered, the decision, and specifically why each rejected option was rejected. The last part is what future readers need and what almost every template under documents. A rejected option without a stated reason will be proposed again, because it still looks reasonable.
Frequently asked questions
- Can an AI agent do architecture work?
- It can do the reading and writing parts: extracting constraints from a codebase, drafting decision records, arguing both sides of a tradeoff, and checking a proposal against what the code actually does. It cannot judge what your organization can operate, because it has no visibility into team size, on call load, or institutional history.
- What is the most valuable way to use an agent in system design?
- Design review against the real repository. Hand it the proposal and the code and ask which assumptions no longer hold. Proposals routinely depend on behavior that was refactored away, and finding that mismatch before implementation rather than during it is where the time is actually saved.
- How do I stop an agent from producing confident but wrong design advice?
- Give it your constraints explicitly and make it score options against them, rather than asking which approach is better. Supply real numbers for anything capacity related. Then verify the answers that are convenient, since those are the ones you are least likely to check on your own.
- Why do teams keep relitigating architecture decisions?
- Because the reasoning is not retrievable. The decision lands in a closed pull request or an unrecorded meeting, and the person who holds the context leaves. Write the rejected options and their reasons into a decision record, then index it so an agent can surface it when the question comes back.