Most engineers have repeated some version of this definition in a design review: architecture is the part of a system that's hard to change. Martin Fowler put the idea in print in a 2003 IEEE Software column, Who Needs an Architect? His Software Architecture Guide still leads with Ralph Johnson's version, which describes architecture as "the shared understanding that the expert developers have of the system design." Fowler sums up Johnson's conclusion this way: "Architecture is about the important stuff. Whatever that is."
In a 2025 engineering post, Airbnb described an LLM pipeline it pointed at about 3,500 React test files written against Enzyme. The job was to move them to React Testing Library. The first automated pass converted 75% of them in four hours. The whole migration finished in six weeks, against an internal estimate of roughly a year and a half of engineering work. Fewer than 100 files needed a human to fix them by hand.
Fowler's column saw a result like that coming. He described a ThoughtWorks colleague, Pramod Sadalage, whose tooling made schema changes and data migration routine, and he concluded the schema had stopped being architectural on that project. His point was that the list of hard-to-change things can shrink, and that an architect's most important job is to shrink it by making decisions reversible. Agents are now shrinking that list at scale. If an agent can migrate about 2,600 test files in four hours, "hard to change" no longer describes code structure. What's left on the list tells you where to spend your design time, and one question sorts it: could the team revert the change tomorrow without asking anyone?
Architecture is whatever a revert can't undo. Most of it needs someone else's agreement to change.
Code structure got cheap to change
The evidence that agents can move large codebases is no longer anecdotal. Google published a paper in January 2025 on how it uses LLMs for internal code migrations. In one case, Google Ads converted 32-bit IDs to 64-bit IDs across a huge codebase. Engineers estimated the total migration time dropped by about 50%, and 80% of the code changes in the landed commits were fully AI-authored. In another, a JUnit3 to JUnit4 migration touched 5,359 files and more than 149,000 lines in three months. About 87% of the AI-generated code was committed without changes.
Amazon reported the same pattern at a different scale. In August 2024, Andy Jassy said Amazon Q Developer had upgraded tens of thousands of production applications from Java 8 or 11 to Java 17. He put the savings at more than 4,500 developer-years of work compared with doing the upgrades by hand.
Those migrations are all the same kind of change. Framework swaps, language version upgrades, type changes, and test framework moves change how the code works without changing what it promises anyone outside it. The tests say whether the change worked, nobody downstream has to change anything, and a revert undoes a mistake. They're also the friendliest cases. Three of the four are test or version migrations, where an executable test suite already acts as the answer key. Most enterprise systems don't have that answer key yet, so they shouldn't expect these numbers on day one.
The Google paper also says where the speed ran out. In the JUnit migration, the bottleneck was "the speed at which engineers could review the changes," so the team limited how many changes it generated each week. The authors are blunt about it: "Code reviews and change rollouts still require a human operator." The agents took over most of the typing, and the people who had to approve the work and carry the risk became the limit.
I ran into the same limit at a much smaller scale in 64 PRs Before Lunch. On Oct. 31, a lead agent and 11 worker agents merged 64 pull requests across the web, Apple, and Android versions of GSD Task Manager. The merges ran from 9:30 to 11:38 a.m. By lunch, none of those changes had reached a user, because deciding what evidence was enough to ship them was still my job.
Data, contracts, identity, and the org chart stayed expensive
The parts of a system that resist agents share one trait: a revert doesn't put them back. Live state has already changed, a side effect has already fired, or someone outside the team has already built on the old behavior.
Data is the clearest case. An agent can rewrite a model class in minutes, but the rows in production still carry the old shape. This is the item Fowler crossed off in 2003, and on a single project with good migration tooling he was right. Scale, side effects, and live money put it back on the list. Stripe's post on online migrations describes how it moved hundreds of millions of Subscriptions objects to a new model. The pattern has four steps: dual-write to old and new stores, move reads, move writes, then delete the old data and code. The authors point out that at one second per object, migrating 100 million objects sequentially would take more than three years. They also never changed more than a few hundred lines of code at once. The code change was the small part of that project, and keeping money correct while the data moved was the large part.
API contracts fail the revert test for a different reason. Hyrum Wright made an observation that Titus Winters later named Hyrum's Law: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." An agent can rename a field in your service in seconds. Every consumer's roadmap and deploy schedule still has the old name in it. Even if the agent opens a pull request in every consumer repo, each owning team still has to review it, ship it, and accept the risk.
Identity and trust boundaries move slower than contracts. Which service holds which credential, which data crosses which network boundary, and who may call what are all security decisions. Changing one means threat modeling, security review, audit evidence, and in regulated industries, an examiner's questions. The boundary exists so that no single actor, human or agent, can move it alone.
The org chart shapes the other three. Melvin Conway wrote in 1968 that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." Agents speed up the work inside a team's boundary. They don't change who talks to whom, which teams own which services, or how a decision travels between them. If anything, agents make Conway's law matter more. When writing code inside a team gets cheap, negotiating across team boundaries becomes the largest cost in delivery.
I watched these costs set the calendar on the data center migration program I led this year. The scope covered more than 4,000 servers and 1,869 databases. Over Labor Day weekend, our teams cut over 932 applications to a new primary facility, and the business ran from it on Tuesday morning. Blackout windows, audit evidence, and identity foundations paced the cloud phases that came next, and they pushed the first migrations into mid-2027. Security, risk, and finance each held a steering committee seat, because each shared accountability for the outcome. A faster coding agent wouldn't have moved a single one of those dates.
A revert is the test for what counts as architecture
"Hard to change" always mixed three costs: the effort to write and test the code, the coordination to get people to agree, and the risk of changing live state. For most of software history, effort was expensive enough to make routine design choices look permanent. Jeff Bezos gave that distinction its best-known names in his 2015 letter to Amazon shareholders. Type 1 decisions are one-way doors, hard to reverse and worth slow deliberation. Type 2 decisions are two-way doors, and he wanted those made quickly. Agents cut the effort, and most code structure turned out to be a two-way door. Architecture is the set of one-way doors that remain, where a revert can't restore live data, unsend a side effect, or take back a promise another team has built on. Fowler's word for the same property was irreversibility, and it gives a working test.
Could your team revert this change tomorrow without asking anyone for permission or repairing state behind it?
If the answer is yes, and the change keeps every promise the code makes outside the team, it's design. Agents can churn it as often as the team likes, as long as the tests prove the promises held. If reverting means unwinding changed live data, repairing external side effects, renegotiating consumer roadmaps, or satisfying an audit examiner, it's architecture.
The test has a soft edge, and Hyrum's Law is the reason. Consumers depend on behavior nobody wrote down, like response ordering, timing, HTTP header casing, and the exact text of an error message. No test checks a promise nobody recorded, so a refactor can pass every test and still break someone downstream. Consumer-driven contract tests and canary releases narrow that gap without closing it. Internal churn is safe only where a team can see how its consumers use the service. Operations set a second limit. Churn is only cheap if the on-call engineer can still find a fault in code that changed three times that week.
The test also explains Google's limit. Reviewing changes that keep their promises is throughput work, so the team could pace it by limiting weekly volume. Changing a promise is a negotiation, and you can't pace a negotiation with a pull-request queue. It fits Johnson's framing too. He described architecture as a shared understanding, and a shared understanding is exactly the thing one party can't refactor alone.
The fair challenge is that agents will handle coordination too. They already draft migration plans, open pull requests in downstream repos, and generate contract tests. I expect that to improve. But an agent that drafts the change on both sides of a boundary hasn't agreed to it for anyone. The owning team carries the pager and the risk, so the owning team decides. What would change my mind is consumer teams routinely auto-merging agent-opened breaking changes on automated evidence alone. That would mean contract suites and canary telemetry standing in for a human review. Some teams will get there for low-risk internal services. I don't expect it for schemas that settle customer funds or boundaries that protect customer data.
Platform teams should spend design time on the seams
If agents can churn everything inside a boundary, a platform leader's design attention belongs on the boundaries themselves. That changes what an architecture review is for. Reviewing code structure in a design meeting made sense when restructuring code took a quarter. It makes less sense when an agent can try three structures before the meeting starts. Bezos's letter warned that large organizations tend to run the heavyweight Type 1 process on Type 2 decisions, and that slowness is the result. A review that debates code structure now makes that mistake.
I'd open every review with two questions. What in this proposal can't a clean git revert undo? Whose agreement does it need to be safe? Whatever those two questions don't cover can go back to the team and its agents.
The seams deserve the time instead. Data models and schemas need an owner, a published versioning policy, and a migration pattern teams can follow without inventing one, like the dual-write pattern Stripe describes. API contracts need to be explicit, versioned, and tested from the consumer's side, because Hyrum's Law guarantees the implicit ones exist anyway. Identity and authorization belong in the platform, where agents and humans inherit them, rather than in application code an agent can edit. Team boundaries should line up with the contracts, because Conway says they will end up matching whether you plan it or not.
The GSD sprint was a small version of the same idea. The plan put a shared corpus of expected results ahead of the agent work, so three codebases had one contract to build against. That corpus held 352 cases by the end of the sprint.
Once those guardrails exist, let the agents churn, with one condition. The license depends on an answer key that can prove the promises held, and most enterprise systems still have to build one. Where it exists, a team that owns a well-defined service with clear contracts can let agents refactor its internals every week. It can swap frameworks and upgrade runtimes without asking anyone. The platform makes the inside of each boundary cheap and reversible, so the expensive conversations happen only where the agreements are. This builds on the argument in The Agent Is Not the Platform: the durable part of the engineering system is what lets the agent be replaceable.
Put your architects where the agreements are
What agents left behind is the architecture Johnson was describing all along, which is the shared understanding and the agreements that hold it in place. Airbnb's migration ran at pipeline speed because no consumer had to change anything and a revert could undo any mistake. The cloud program I led had 1,869 databases and a calendar set by blackout windows and sign-offs. The migrations that decide the next few years of your platform look like the second one, so that's where your architects should be sitting.
Sources
- Martin Fowler, Who Needs an Architect? (IEEE Software, July/August 2003)
- Martin Fowler, Software Architecture Guide
- Charles Covey-Brandt, Airbnb, Accelerating Large-Scale Test Migration with LLMs
- InfoQ, How Airbnb Used LLMs to Accelerate Test Migration
- Google, How is Google using AI for internal code migrations?
- AWS DevOps Blog, Amazon Q Developer just reached a $260 million dollar milestone
- Jacqueline Xu, Stripe, Online migrations at scale
- Hyrum Wright, Hyrum's Law
- Adrian Colyer, ACM Queue, review of Melvin Conway's "How Do Committees Invent?" (Datamation, 1968)
- Jeff Bezos, 2015 letter to Amazon shareholders
