Back

The architect who still writes code should mostly be reading it

·21 min read

In the July/August 2003 issue of IEEE Software, Martin Fowler sketched the kind of architect he admired with a single working day: in the morning the architect programs with a developer, trying to harvest some common locking code, and in the afternoon sits in a requirements session helping the requirements people understand the technical consequences of their ideas, such as development costs. The same column contains a rule of thumb that sounds like the opposite advice. An architect's value, Fowler wrote, is inversely proportional to the number of decisions he or she makes, because raising the team's ability pays back far more than being the sole decision maker and an architectural bottleneck.

Read quickly, these are two camps: the architect who keeps coding and the architect who gets out of the way. I think they describe one job seen from two sides, and that the job has changed in a specific way since code became cheap to generate. My thesis is that the architect's main contact with code should now be reading it, in particular reading the diffs that other people and other machines produce, and that writing should be limited to code that is thrown away or code that is small and off the critical path. An architect who reads no diffs works from a stale picture of the system, and one who writes the team's feature code becomes a single point of failure.

This is a claim about emphasis, and it can be wrong. The evidence on AI-assisted code is mixed and often comes from vendors, and the strongest objection, that an architect inside the diffs erodes the team's ownership, needs a proper answer, which it gets below. First, the problem the old advice was solving.

Fowler's two warnings describe one job

Fowler's column leans on a definition from Ralph Johnson, who had argued on the Extreme Programming mailing list that architecture is the shared understanding the expert developers have of the system, and that a component is significant because those developers say so. On that definition, architecture is a social fact that lives in people's heads and in the code at once. If the two drift apart, I suspect the architect is the person most likely to hold the stale version, because the architect is the person least often forced to run the code.

The column names two types. Architectus Reloadus makes the important decisions alone, on the theory that a single mind keeps the design coherent and perhaps because the team may not be skilled enough. Architectus Oryzus stays aware of what is happening in the project, tackles important problems before they become serious, and treats mentoring as the most important activity. Fowler reports that colleagues at a ThoughtWorks retreat agreed on the nature of this job but could not find a name for it, and that one of them, Mike Two, proposed guide, as in mountaineering: an experienced team member who teaches the others to fend for themselves and is still there for the really tricky stretches.

That is the first warning, and it concerns ground truth. A diagram on a wiki records what someone intended at some point. Only the code shows what the system does today: which module really calls which, where the retry loop lives, whether the "read-only" service has started to write. In my judgment, an architect who stops writing code usually stops reading it as well, and the shared understanding Johnson described shrinks to a private belief held by one person.

The second warning is about throughput. If every design choice has to pass through one head, the team's speed is bounded by that head's calendar. Writing feature code makes the problem worse, since an architect is pulled into meetings and cannot give a task the sustained attention it needs, so the code arrives late or in a hurry; that part is my observation about how the role is usually staffed, not something Fowler claims. His inverse rule is a statement about where the gain is: raising the level of the team gives more than being the sole decider.

Together the warnings ask for contact with the code and distance from the critical path. Feature code supplies the first and breaks the second; reading supplies the first and leaves the second alone.

Write code only to answer a question the team cannot yet answer

There is code an architect should still write. It falls into a few recognizable kinds, and what they share is that the team does not depend on it landing on a given date.

The first is the throwaway experiment. In a 2003 interview with Bill Venners for Artima, Andy Hunt and Dave Thomas separated prototypes from tracer bullets. A prototype exists to answer a narrow question about an interface, an algorithm or performance, and it is meant to be discarded. Thomas's example is hypothetical: the requirements call for 10,000 database transactions an hour while the highest throughput known for that database is 5,000, and the way to find out is to hack together a rough script. Hunt adds that such a script may not touch the application code at all. Thomas says prototypes are designed to be thrown away, and compares one to a town on a western film set: all facade, nothing behind it. Venners asks in the interview whether management might try to turn a prototype into a tracer bullet, which is the temptation to watch for. An architect who writes a spike should mark it disposable in the file name and delete it on a date written in the commit message.

The second is the tracer bullet. In the same interview, the authors describe a thin end-to-end skeleton, from the user interface through business logic to the database, that users can see and that grows one use case at a time, with early feedback making course corrections cheap. Unlike the prototype, this skeleton is what the system is built on. It is the first version of the real system, narrow but complete, and it gives the team an architectural skeleton to hang code on. This is the code an architect is best placed to write, because the purpose of the exercise is to test the structure: whether the layers can talk to each other, whether the deployment pipeline works, whether the logging gives enough to diagnose a failure. Once the skeleton exists, the architect hands it over and moves away, and the code should now belong to the team.

The third is the reference implementation, a worked example of one pattern, such as how a handler validates input and calls the domain layer, small enough to be copied. The fourth is the decision record. Michael Nygard proposed in 2011 that each architecturally significant decision be written up in a short file of one or two pages kept in the repository, with a context, a decision, a status and the consequences, on the grounds that large documents are never kept up to date. At Google, Malte Ubl wrote in 2020, a design doc is the place to write down the trade-offs, and he notes that the overhead of writing and reviewing one may not fit prototyping and rapid iteration. Each of these artifacts costs little next to a decision nobody wrote down.

None of them puts the architect on the schedule's critical path. The spike is thrown away, the tracer is handed over after the first weeks, the reference implementation is a few hundred lines, and the record is a page. My test for any architect's writing is whether the team's next delivery date moves if the architect is out sick for a week.

Review catches small things, which is why structure slips past it

If reading is the main activity, an obvious reply is that code review already exists. It does, and the best evidence on what it does comes from before AI assistants.

Alberto Bacchelli and Christian Bird studied code review at Microsoft, observing 17 developers, interviewing them, classifying 570 comments from review threads, and surveying 165 managers and 873 programmers. Finding defects was the top stated motivation, first for 44% of the surveyed programmers. The comments told a different story. Of the 570, 165 (29%) were about code improvement, such as better practices, removing unused code or readability, and only 78 (14%) were about defects, the fourth most frequent of nine categories. Of those 78 defect comments, 65 concerned logic errors such as a wrong expression in an if clause, 6 concerned high-level issues, and 5 concerned security. The authors also report that reviewers valued knowledge transfer and team awareness, and that understanding the change is the key part of reviewing. One senior developer remarked that he had seen reviews where someone commented on formatting and missed a security issue or a data-model issue.

The study covers one company, with surveys run in the first half of 2012, so it is no law. The authors themselves note that defect comments mostly address small, superficial concerns while programmers and managers expected remarks on design. I infer from the six high-level defect comments that structural problems, such as a dependency pointing the wrong way or a second implementation of something the codebase already has, are among the least likely to draw one. A reviewer sees a diff, and the architecture is mostly what lies outside the diff. Someone has to carry the picture of what is not shown, and a diff-based review does not assign that job to anybody.

Review also assumes the author understands the change. A human who writes a 150-line change usually knows why each line is there and can explain it. When an assistant produces the change and the developer accepts it after a skim, that assumption fails, and the reviewer may be the first person to read the code with attention.

What the evidence on AI-generated code supports, and what it does not

The evidence here is thin and uneven, and the most quoted numbers come from sources with something to sell.

One controlled study is by Neil Perry, Megha Srivastava, Deepak Kumar and Dan Boneh, presented at the ACM CCS conference in 2023. Participants completed security-related programming tasks with or without an assistant built on OpenAI's codex-davinci-002. After exclusions there were 47 participants, 33 with the assistant and 14 without, mostly university students. On the SQL task, 36% of the assistant group wrote injectable code against 7% of the controls. On the signing task, 3% of the assistant group produced a secure solution against 21%. A logistic regression pooling all five questions, in the paper's Table 3, gives p of 0.056 for the assistant group, just above the usual threshold, and the authors list the small, student-heavy sample among their limits. Participants with the assistant were also more likely to believe their code was secure. With an older model and a lab setting, the result is a reason to check, not a measurement of today's tools.

The DORA programme's 2024 report, drawn from a large annual survey of technology professionals, estimated that AI adoption was accompanied by a 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability. Google Cloud's announcement words these as accompanying adoption, not as proven effects, and RedMonk's write-up quotes the report as tying both figures to a 25% increase in adoption. The 2025 report, with nearly 5,000 respondents, says that, unlike the year before, adoption shows a positive relationship with delivery throughput, while the relationship with delivery stability remains negative. Its summary describes AI as an amplifier of whatever a team already has. The throughput sign reversed between the two years, while the stability sign did not.

METR's 2025 study of experienced developers had 16 of them complete 246 real issues in repositories they knew well, randomly allowing or forbidding AI. With AI allowed, they took 19% longer, while believing afterward that it had made them about 20% faster. METR now marks that result as out of date. In February 2026 it reported a follow-up with 57 developers and more than 800 tasks, and said the data gave an unreliable signal of the current effect, mainly because many developers declined to take part if it meant working without AI. METR thought developers were probably more sped up by then, but called its data only very weak evidence for the size of the change. The relevance to architects is indirect and the inference is mine: people who use these tools are poor judges of their own results, in speed in one study and in security in the other, and a review that depends on the author's confidence inherits the same weakness.

Vendor reports add more. GitClear analysed 211 million changed lines from 2020 to 2024 and reports that the share of cloned lines rose from 8.3% to 12.3% between 2021 and 2024 while the share of moved lines, its proxy for refactoring, fell from 25% to under 10%. It sells code analytics, and I did not see a design in the report that isolates assistants as the cause of the trend. CodeRabbit compared 320 AI-co-authored pull requests with 150 human-only ones and counted 10.83 issues per pull request against 6.45. It labelled authorship from signals in the pull request and assumed the rest were human, and it sells an AI review product.

Veracode reports risky security flaws in 45% of tests across more than 100 models in four languages, and also sells security tooling. Sonar's January 2026 survey of over 1,100 developers found 96% did not fully trust AI-generated code to be correct while 48% said they always check it before committing. Stack Overflow's 2025 survey found that 46% of respondents to its trust question distrusted the accuracy of AI tools, and 66% of respondents to its frustrations question named output that is almost right but not quite.

Taken together, these results agree on a trust gap and a verification lag, and disagree on whether the code is actually worse. Direct evidence on architecture is scarce. One December 2025 arXiv pilot by Tyler Slater gave three models (GPT-5.1, Claude 4.5 Sonnet and Llama 3 8B) a single microservice task under a hexagonal-architecture constraint and reported, in the abstract, a 0% violation rate for GPT-5.1 and 80% for Llama 3. One task is an anecdote. A June 2026 observational study by Oliver Larsen and Mahyar Moghaddam compared 74 Java repositories that had adopted agentic tools with 77 matched controls, using 1,811 monthly snapshots analysed with an architecture-recovery tool. Total architectural smell counts barely moved (+1.1%, p of 0.82) while lines of code grew 12.8%, and the density of smells fell 6.7%, which the authors call a denominator effect and not an improvement. That is the closest thing I found to a repository-level measurement. It says growth did not come with more detected smells in that sample, and it cannot say whether individual agent changes respect a team's own rules, because smell detectors do not know those rules. The 2026 MSR study of agent pull requests by Ehsani and colleagues, which covers about 33,000 pull requests from five coding agents in the AIDev-pop dataset, measures whether the pull requests get merged and why they are rejected, not whether they respect an architecture. So the claim that AI erodes structure is plausible and thinly tested, with one pilot pointing toward erosion for a small model and one observational study showing no rise in smell counts. The claim that reading is the bottleneck has more behind it, because the Sonar survey and the Microsoft review study both show a gap between the checking people say matters and the checking they do.

Nobody can read every line, so the architect's reading has to follow risk

A made-up calculation shows why reading has to be selective. Suppose a team of 8 engineers merges 2 pull requests a day each, averaging 120 changed lines, which is 1,920 lines a day. Assistants might raise that to 3 pull requests of 200 lines each, which is 4,800 lines a day. Careful reading, the kind that checks structure and not syntax, is assumed to proceed at 200 lines an hour. These figures are invented for illustration. Reading everything would take 9.6 hours a day in the first case and 24 in the second. The architect cannot read it all, and in the second case nobody can.

So the reading has to be targeted, and risk is the sensible filter. In the second case, if a tenth of the lines touch boundaries, the architect's share is 480 lines, or 2.4 hours a day. That is large but possible, and in practice the architect would split it with senior engineers. The boundaries worth the attention are few, and this is the list I would start with.

  1. New dependencies between modules or services, and the direction of each one.
  2. Changes to public interfaces, event schemas and database migrations.
  3. Anything that touches authentication, authorization or the handling of personal data.
  4. New abstractions, helpers or utilities, checked against what the codebase already has.
  5. Error handling and retry behavior at the edges of the system.
  6. Configuration, feature flags and infrastructure definitions that change how the system behaves in production.

Much of the rest can be automated, and it should be. A rule such as "the domain package must not import the infrastructure package" is a test, not a topic for discussion, and a decision record that ships with the rule in executable form outlasts one that states it in prose. The architect's reading then concentrates on what no rule yet covers, and each time a human finds a violation that no check caught, the follow-up is to write the check. Here writing code comes back into the architect's job, as small tools that encode decisions, and an assistant is useful for this part: it can draft a first version of a dependency check, which a person then verifies against known violations.

A second reading task matters as much: reading generated code for what is missing. An assistant can produce a plausible handler that works and still duplicates a pagination helper the codebase already has, if nobody pointed it there. The question to put to a diff is whether it matches the structure the team intended, which requires knowing both the intended structure and the real one. Both come from reading.

An architect in the diffs may take ownership from the team

The strongest objection says all of this is a reason to keep architects out of the code. Teams own what they decide and build. An architect who reads every boundary change becomes a reviewer of last resort, developers start to write for the architect's approval, and the team's judgment weakens, which is the pattern Fowler's inverse rule warns against. There is a practical side as well. Senior engineers who find the architect in their pull requests may reasonably conclude they are not trusted, and some of the best will leave.

The objection holds for one design of the practice and fails for another. It holds if reading means approving. If a change cannot merge until the architect has looked at it, the architect is on the critical path again and the bottleneck has simply moved from design meetings to the pull request queue. The Bacchelli and Bird findings point in the same direction, since the paper reports knowledge transfer and team awareness among the outcomes of review, next to the catching of defects. A reading practice that preserves those benefits looks different: it runs after merge or in parallel, it comments in the open, and it asks questions before issuing verdicts. When the architect finds a boundary change that conflicts with a decision record, the first move is a question to the author, and the second is a conversation about whether the record is out of date, because sometimes the author has found something the architect missed. In that case the record changes. Ownership stays with the team since the team can overrule the record, and the architect's job is to make that overruling visible and deliberate.

The objection's premise, that staying out of the code protects ownership, is where I think it fails. A team can own a system it does not fully understand, but then ownership means responsibility without information, and an incident is usually where that shows. Suppose the team made a decision three months ago and a generated change has since undone it quietly. Only someone who read that change can notice; otherwise the team learns of it from production.

A fair worry remains about scale. Past a certain size one person cannot hold the picture, and the architect function has to be spread across several people, with reading rotated among senior engineers. For ownership that is a good result, because the practice has been absorbed into the team.

A month of logged reading would show whether this is worth it

The claim can be tested cheaply, and the test belongs to whoever holds the architect role. For four weeks, read every change that touches the six categories above, within a day of merging. For each one, record in a plain file whether the change matched the intended structure, whether it contradicted a decision record, and whether the finding turned into a question, a new check or a change to the record. At the end, count. If the log shows no mismatches, either the team is disciplined enough that reading adds little, or the sampling is wrong, and the next step is to widen the categories before dropping the practice. If it shows several, the mismatches per hundred reviewed changes are the first local evidence of what the reading is worth to this team, something none of the studies above can supply. I cannot say in advance which result is more likely.

Sources

  1. Fowler, M. (2003). Who Needs an Architect? IEEE Software, July/August 2003 (Design column). https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
  2. Hunt, A., Thomas, D. (2003). Tracer Bullets and Prototypes. Interview by Bill Venners, Artima Developer, 21 April 2003. https://www.artima.com/articles/tracer-bullets-and-prototypes
  3. Nygard, M. (2011). Documenting Architecture Decisions. Cognitect blog, 15 November 2011. https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions
  4. Ubl, M. (2020). Design Docs at Google. Industrial Empathy, 6 July 2020. https://www.industrialempathy.com/posts/design-docs-at-google/
  5. Bacchelli, A., Bird, C. (2013). Expectations, Outcomes, and Challenges of Modern Code Review. Proceedings of the 35th International Conference on Software Engineering (ICSE 2013), pp. 712-721. https://2013.icse-conferences.org/content/expectations-outcomes-and-challenges-modern-code-review.html
  6. Perry, N., Srivastava, M., Kumar, D., Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS '23), Copenhagen; DOI 10.1145/3576915.3623157; arXiv:2211.03622. https://arxiv.org/abs/2211.03622
  7. Google Cloud (22 October 2024). Announcing the 2024 DORA report. https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report ; Stephens, R. (26 November 2024), RedMonk write-up quoting the report for the 25% step (secondhand), https://redmonk.com/rstephens/2024/11/26/dora2024/
  8. Google Cloud (23 September 2025). Announcing the 2025 DORA report (the wording on throughput, stability and amplification was read here, not in the full PDF). https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report ; report PDF: https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf
  9. METR (10 July 2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ ; METR (24 February 2026). We are Changing our Developer Productivity Experiment Design. https://metr.org/blog/2026-02-24-uplift-update/
  10. GitClear (2025). AI Copilot Code Quality research, 211 million changed lines, 2020 to 2024 (vendor analysis). https://www.gitclear.com/ai_assistant_code_quality_2025_research
  11. CodeRabbit (2025). State of AI vs Human Code Generation report, 470 pull requests (vendor analysis). https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
  12. Veracode (2025). GenAI Code Security Report (vendor analysis). https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
  13. Sonar (8 January 2026). State of Code developer survey, press release on the verification gap (vendor survey). https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/
  14. Stack Overflow (2025). Developer Survey 2025, AI section. https://survey.stackoverflow.co/2025/ai
  15. Slater, T. (2025). Quantitative Analysis of Technical Debt and Pattern Violation in Large Language Model Architectures. arXiv:2512.04273 (single-task pilot with three models, abstract page read only). https://arxiv.org/abs/2512.04273
  16. Ehsani, R., Pathak, S., Rawal, S., Al Mujahid, A., Imran, M. M., Chatterjee, P. (2026). Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub. MSR '26, using the AIDev-pop dataset; arXiv:2601.15195 (abstract and HTML summary only). https://arxiv.org/abs/2601.15195
  17. Larsen, O. A., Moghaddam, M. T. (2026). Mining Architectural Quality Under Agentic AI Adoption: A Causal Study of Java Repositories. SEAA 2026; arXiv:2606.13298 (abstract page read only). https://arxiv.org/abs/2606.13298
  18. Illustrative review arithmetic: 8 engineers, 2 or 3 pull requests a day of 120 or 200 changed lines, reading at 200 lines an hour, 10% of lines at boundaries. All figures invented for the example.