The old rules were written for human limits
Most architecture rules you follow were written with a human team in mind. DRY exists because typing the same logic twice costs effort and fixing it in three places is easy to get wrong. Layered architecture exists partly so a new hire can find things. "Keep functions short" exists because people can hold only a few things in their heads at once.
In L1 you placed decisions on a spectrum from prescribed to delegated. Before you can place anything well, you need to know what has actually changed when an LLM writes most of the code. Four things change, and each one breaks a different old assumption.
Shift 1: Writing code is cheap, checking it is not
A coding agent can produce a 400-line feature in minutes. Your team still has to read it, run it and trust it. The cost has not gone away. It has moved.
# Rough shape of where the hours go on one feature (illustrative, not measured)
# human-written agent-written
# design 2h 2h <- unchanged
# typing the code 6h 0.3h <- collapses
# reviewing / reading 1h 3h <- grows: more code, and you didn't write it
# debugging / fixing 2h 2h+ <- confident mistakes are slow to find
The numbers are made up to show the shape. Measured evidence is mixed and dated. METR's randomised trial (February to June 2025) found that experienced open-source developers took 19% longer with AI tools, even though they believed the tools had made them faster. METR's early-2026 follow-up pointed towards a speedup. METR itself called that new data unreliable, partly because many developers would no longer agree to work without AI. Treat any single productivity number with suspicion. The direction practitioners agree on is narrower: verification has become the bottleneck, not typing.
Gotcha: if your architecture makes code easy to write but hard to check, an agent makes that worse. It speeds up the cheap part and floods the expensive part.
Shift 2: The agent sees a window, not the codebase
A senior engineer carries a mental map of the system built up over years. An agent has only its context window: whatever files, instructions and tool output are loaded right now. Windows are large, but filling one does not mean the model uses all of it well.
- Lost in the Middle (Liu et al., 2023) found that models retrieve information best when it sits at the start or end of the input, and noticeably worse when it sits in the middle.
- Chroma's Context Rot report (July 2025) tested 18 models and found that performance became less reliable as input length grew, even on simple tasks.
In practice it looks like this:
> agent: add a discount field to Order
# The agent reads orders/model.py and orders/api.py. It never opens
# billing/invoice.py, which computes totals from Order by hand.
# Result: the discount is saved but never applied to invoices.
# Tests in orders/ pass. The bug lives in a file the agent never saw.
The agent did not get worse at coding. It saw only part of the code, and the dependency it missed was hidden outside that part.
Shift 3: Every session starts from zero
A human who agreed last Tuesday to "never call the payments DB directly" still remembers it on Wednesday. An agent does not. Unless the decision is written somewhere it will read, such as an instruction file, a type, a test or a lint rule, the next session can quietly undo it.
<!-- AGENTS.md: an open, plain-Markdown format many agents read at startup -->
## Architecture decisions
- All payment access goes through `payments/client.py`. Never import `payments/db`.
- Money is `Decimal`, never `float`.
Files like AGENTS.md or CLAUDE.md help. But they are instructions, not enforcement, and later levels look at their limits. For now, remember this: any decision that lives only in someone's head or a chat log is lost when the session ends.
Shift 4: Mistakes arrive with confidence
A junior who is unsure usually tells you so. An agent writes a call to a library function that does not exist in the same calm, tidy style as correct code. Nothing in its tone tells you which is which. So you cannot review agent code the way you skim a trusted colleague's pull request. Something has to check it mechanically: a compiler, a test, a type checker or a person reading carefully.
Walkthrough: audit your team's rules
Take your current architecture guidelines and sort each rule by why it exists. Here is a worked example:
# rule : exists because of... -> with agents
- DRY, extract shared helpers : human typing + fix-in-many-places cost
-> weaker reason; regeneration is cheap, but
duplicated bugs still need finding
- Keep files short : human working memory
-> STILL matters, now for the context window
- Write ADRs for big decisions : onboarding new humans
-> MORE important; agents forget every session
- Explicit module boundaries : team coordination
-> MORE important; limits what an edit can break
- Clever, compact idioms are fine : experts read them quickly
-> worse; harder to verify, easier to get wrong
- Code review on every PR : catch human slips
-> still needed, but the volume is now the problem
Three outcomes are common. Some rules lose their original reason: they guarded against effort that is now cheap. Some rules keep the same form for a new reason: short files used to help human memory and now help the context window. Some rules become more important: anything that writes decisions down or makes work checkable.
Trade-off: do not throw out a rule just because its original reason is gone. Check whether a new reason has replaced it. DRY's typing argument is weaker now, but one bug copied into five places is still five bugs.
Key takeaways
- Cheap code generation moves cost from writing to reviewing and verifying. Design for checkability.
- The context window is finite, and models use long inputs unevenly. Code the agent cannot see is code it can break.
- Agents have no memory between sessions. Decisions must live in artefacts the agent reads or that enforce themselves.
- Agent mistakes are confident, so tone tells you nothing. Use mechanical checks.
- Audit each rule: is it there for a human limit, and has a new reason replaced the old one?
- Productivity evidence is thin and changing (METR 2025 vs. early 2026). Do not anchor on one number.