Three names keep showing up in modern code reviews, and none of them wrote their best lines about code review. Conway wrote about committees. Brooks wrote about schedules. Parnas wrote about Fortran modules in 1972. Half a century later, the pull requests you merged this morning are still arguing with them.
The six quotes below are the ones that keep landing in review threads when a merge stalls on the same old fight. Each one has an original context from decades ago. Each one points at a 2026 problem that didn't exist when it was written.
1. Conway, 1968: the quote your multi-agent system is secretly obeying
"Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations."
— Melvin Conway, Datamation 14(4):28-31, April 1968
Conway was writing about committees inside aerospace contractors. The paper was a complaint, not a theory. Someone's design-by-committee had produced a compiler whose stage boundaries matched the subcommittee boundaries, and the result was ugly.
Fifty-eight years later, the quote has found a new target: multi-agent architectures. In 2026, teams routinely spin up five, ten, twenty sub-agents to handle a workflow. The silent default is that each team ships its own sub-agent for the piece it already owns. The result is a copy of the org chart with LLM calls in it — hub bottlenecks, lossy handoffs, no shared standards. Anthropic quietly reversed course in late 2026 and started telling teams that one capable agent beats a crowd of narrow ones. That is not a modeling argument. That is Conway speaking from 1968.
Code-review application: When a PR adds a new service, agent, or module, ask whether its boundary matches a problem shape or a team shape. If the only reason it exists is "that is the team that was free," the merge is reinforcing your org chart, not your architecture.
2. Parnas, 1972: the quote that still kills export statements
"The connections between modules are the assumptions which the modules make about each other."
— David L. Parnas, Information Distribution Aspects of Design Methodology, IFIP Congress 1971, Proceedings vol.1, pp.339-344
Parnas was arguing with Fortran programmers. His famous paper from the same stretch — On the Criteria To Be Used in Decomposing Systems into Modules, CACM 15(12), December 1972 — makes the sister point: don't carve a system by processing step. Carve it by what each module can hide.
The sentence above is the one you cite when you reject a PR that leaked an internal data type into a public interface. Every export type Internal... that drifts into a public barrel file is a Parnas violation. In TypeScript 5.x, this is where structural typing bites hardest: an "accidentally public" shape becomes load-bearing before anyone notices, and the API can no longer evolve without a breaking change.
Code-review application: When reviewing a new public surface, list what the caller must assume about the implementation to use it. If the list is longer than three items, the module's boundary is wrong, not its implementation.
3. Brooks, 1975: the quote your "we'll just add another agent" moment deserves
"Adding manpower to a late software project makes it later."
— Fred Brooks, The Mythical Man-Month, Addison-Wesley 1975, p.25
Brooks was writing about OS/360. Half a floor of IBM programmers, one slipping deadline, more programmers added, more communication overhead, more slip. He gave the pattern a name: Brooks's Law.
In 2026, the same shape appears without any humans involved. "The agent is too slow — let's split it into five sub-agents." "The pipeline is too long — let's add a planner on top." Every added agent is a communication edge, a context handoff, a chance for information to decay. Brooks's n²-ish communication cost shows up as token usage: the sub-agent fleet that promised speedup burned 2× the tokens of a single agent and shipped the same answer later. I have approved that PR. More than once.
Code-review application: Any PR that adds a new coordinator, planner, router, or sub-agent needs a specific sentence of justification. "Without this layer, the request fails because X." If the sentence is "it would be cleaner," reject it. You are hiring Brooks's extra programmers.
4. Fowler, 1999: the quote your lint rule can't enforce
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
— Martin Fowler, Refactoring, Addison-Wesley 1999, p.15
Fowler was writing a book about renaming variables for a living. The sentence lands because it compresses the whole premise of refactoring into one line. Compile-passing is the floor, not the ceiling.
The 2026 twist is that the "computer" now writes most of the code, and the "human" is both the next engineer and the next AI agent reading AGENTS.md. When Claude Code or Codex re-enters a codebase six weeks later, it reads the names, the comments, the file layout. Code that was legal but unloved — a function called handleData, a parameter called opts, a 300-line file called utils.ts — now penalizes you twice. The human maintainer and the AI pair-programmer both get lost in it.
Code-review application: Rename and relocate before you ship. In 2026, your reviewer is not just the human on the PR. It is the agent that will inherit this file at 3 a.m. in six weeks.
5. Beck, 1999: the quote that keeps "we'll optimize later" honest
"Make it work, make it right, make it fast."
— Kent Beck, Extreme Programming principles
Beck's three-step ordering has been quoted inside out ever since XP shipped. The point was not that performance comes last. The point was that each step needs to be finished before the next starts. "Work" means a passing test. "Right" means code the next engineer can live inside. "Fast" means a measured bottleneck, not a hunch.
In 2026, the step most teams skip is still "right." AI pair-programmers happily jump from "work" to "fast" — they will generate a benchmark harness, propose a parallelized rewrite, and never once ask whether the function should exist. I have hit merge on exactly that PR, which is how I know. "Make it right" is the step where a human reviewer still has to sit down and ask: does this belong in this module? Does this abstraction pay rent? Does the function name match what it actually does?
Code-review application: When a PR comes in with a passing test and a 10% speedup, don't merge it. The missing step is "right." Ask the author to show the version that is clean, small, and obvious. Then compare.
6. Hickey, 2011: the lesser-known quote that keeps winning
"Simple is actually an objective notion. [...] Easy is relative. [...] easy for whom, or hard for whom? It's a relative term."
— Rich Hickey, Simple Made Easy, Strange Loop 2011
Hickey, the creator of Clojure, delivered this talk at Strange Loop in 2011. The core distinction: simple means one role, one task, one axis. It braids no other concerns. Easy means familiar, near-at-hand, matching what you already know.
The talk has had a second life since 2024. Every "we're adopting X because it is easy" decision in the AI stack has run into Hickey's framing within a year. LangChain was easy, until it braided prompts, tools, state, and routing into one object. "Easy" let you ship the demo. "Simple" would have let you refactor it without a rewrite.
Code-review application: When a PR picks a library "because everyone uses it," ask what the library braids together. If pulling it out requires touching four unrelated concerns, you have imported ease, not simplicity.
Why these six, in this order
These aren't the six most quoted. "Premature optimization is the root of all evil" (Knuth, 1974) is more quoted than any of them. The six above are chosen for a different reason: each one points at a 2026 argument that is still live in your pull-request queue this week.
- Conway fires when a sub-agent split copies the team split.
- Parnas fires when a public interface starts carrying implementation leak.
- Brooks fires when the fix for a slow agent is a bigger agent fleet.
- Fowler fires when the next reader is now an AI.
- Beck fires when "right" gets skipped between "work" and "fast."
- Hickey fires every time a stack picks a library for familiarity.
If a code review stalls, drop the matching quote into the thread. The author either rebuts it or revises the PR. Either outcome is useful.
The six above are a thin slice of a larger shelf. If you want ~100 engineering quotes with the original context next to the modern application — not a generic business quote book, but one that puts lesser-known voices like Hickey next to Fowler — the full collection is here:
Why Do Some Words Stay With You Forever? 100 Engineering Quotes Decoded
