Recently, Anthropic’s VP of Engineering Fiona Fung said in a talk something to this effect: processes rarely disappear on their own. We tend to layer on more processes. She was describing how the Claude Code team, after adopting AI-assisted development, had to rewrite nearly all their engineering practices from scratch.
The context was specific. Her Claude Code team went through a fundamental shift: AI had driven code generation costs near zero, and coding was no longer the bottleneck. But when she and the team looked back, they realized most of their engineering processes still rested on the old assumption that “engineering bandwidth is expensive.” Six-month roadmaps, line-by-line code reviews, “who wrote this code,” the separation between managers and code – all of these practices shared the premise that engineering bandwidth was scarce.
She called this phenomenon processes “quietly ceasing to work.” Each process made sense when it was created. But when the environment changes, they don’t automatically stop. They keep running, consuming the team’s cognitive resources. And more insidiously, almost no one actively asks: is this process still doing what it was meant to do?
The problem is that when the bottleneck shifts by an order of magnitude, the systems built around the old bottleneck don’t disappear on their own. They keep running. They keep consuming time. They keep creating the illusion that “we’re doing the right thing.” They just stopped producing value.
Fiona Fung gave an example in her talk. When she joined the Claude Code team, they had standups. As the team grew, the standup turned into a spreadsheet where everyone filled in their weekly progress. Later, she thought, “Wait, why not turn this into a Claude script?” So the standup became an automated skill. Then she looked at the spreadsheet and asked, “Does this even still matter?” and deleted it.
That took months. And every step was reasonable. Standups made sense when the team was small. The spreadsheet made sense when the team was medium-sized. The problem was never any single decision at any single point in time. The problem was that no one was responsible for retiring a process once it had served its purpose.
A 2021 study published in Nature found that humans systematically overlook “subtraction” when solving problems. Participants were asked to improve a Lego structure, the paragraph order of an essay, or a recipe. The vast majority defaulted to adding elements, even when removing one would achieve the same or better results. More critically, this bias persisted even with monetary incentives. It wasn’t that people were unwilling to remove things. They simply didn’t think of “removing” as an option.
Economist Mancur Olson introduced a related concept in 1982 called “institutional sclerosis.” His core finding: the defeated nations of World War II actually grew faster after the war, because the war had destroyed their accumulated bureaucracies and interest groups. The victors kept their institutional layers intact, and those institutions continued serving their own interests, but overall economic growth was slower as a result.
A software engineering team’s institutional layer won’t be destroyed as dramatically as a nation’s. But the cost structure shift brought by AI plays a similar role – it acts as a “reset event.” It creates a window where the old institutional logic no longer holds, but the institutions themselves are still running. The window doesn’t stay open forever. Fiona described a 50-person review meeting where she noticed everyone only looked up when their turn came, spending the rest of the time staring at their laptops. She asked, “Why are we having this meeting?” The room went silent. And the meeting was cancelled. Her conclusion: institutions don’t die on their own. “We need explicit permission to kill old processes.”
If code is no longer the bottleneck, then every process built on the assumption that “code is expensive and engineering bandwidth is scarce” needs a fresh look. Several categories stand out.
The first is planning. Six-month roadmaps, heavyweight design documents, writing a spec before every change – these practices share the same premise: coding is expensive, and once you commit to coding, you must be sure the direction is right. When code generation costs approach zero, the prototype itself becomes the cheapest way to validate an idea. Fiona’s team now works by “have an idea, go build a prototype.” Technical debates have shifted from whiteboard discussions to “generate three PRs with different implementations and see which has the least downstream impact.” She calls this approach JIT planning. It’s not about skipping planning – it’s about postponing it until the information resolution is high enough.
The second is code review. Traditional line-by-line review served two functions: catching errors and knowledge transfer. AI has weakened both. AI can catch pattern-based errors faster than humans: null dereferences, deadlocks, resource leaks. And in an environment where code can be regenerated by AI at any time, what matters for knowledge transfer is not the details of the code but the details of intent. Ayman Shoukry, a former engineering executive at Microsoft and Amazon, proposed an alternative: a two-layer review. Humans review intent – technical approach, business logic, design decisions. AI reviews implementation – style, security, edge cases. This isn’t about making code review AI-powered. It’s about decomposing the work of code review itself.
Inside Anthropic, Boris Cherny confirmed a similar practice in a PCMag interview: every PR goes through Claude Code’s review as a first pass. “The level of detail at which it finds bugs – I was shocked. I didn’t expect it to be this good.” But human signoff is still required. Fiona added that what humans keep is the part of “trust but verify” that can’t be reduced to rules: security boundaries, legal review, product judgment.
The third is code ownership. “Who wrote this code” is a reasonable question in traditional engineering. When something breaks, you need to find the person most familiar with the code. But when almost every PR involves AI-written code, the question itself becomes fuzzy. Fiona’s team no longer asks “who wrote it” directly. Instead, they ask: what question are you really trying to answer? Are you looking for the person responsible for a regression? An expert to answer a customer question? Someone who understands the context behind a piece of logic? Different questions lead to different solutions, and in most cases, Claude can automate the solution.
The fourth is the definition of the manager role itself. Fiona pushed a practice at Anthropic that she considers the most controversial: every manager must first join the team as an IC, write code, build trust, and then take on management responsibilities. Her recruiting team initially thought this would make hiring impossible. But her logic was hard to argue with: in the AI era, managers can write code again. In the past, it was hard for managers to stay hands-on because internal toolchains changed too fast. Writing one PR a year was already the limit. Now with Claude, the cost of context switching has dropped dramatically. “I don’t remember git commands anymore,” she said. “I just have Claude handle it every time.”
If subtraction is harder to think of than addition, then being aware that you should unlearn is not enough. You need mechanisms to counter the default bias toward accumulation.
Fiona’s approach is three team principles. First, every team member, including cross-functional partners, must use Claude Code. This ensures everyone has firsthand experience to judge which processes are no longer necessary. Second, “Claudify whatever can be Claudified.” Ask “can this be automated” before deciding whether a human should do it. Third, “explicitly authorize the killing of old processes.” The third is the easiest to overlook. Processes rarely disappear on their own, she said. We tend to layer on more. Without explicit authorization, engineers see a redundant process and think, “Someone else set this up. I don’t have the authority to touch it.” Authorization turns “killing processes” from overstepping into part of the job.
Concretely, there are a few useful heuristics.
The first comes from Fiona herself: find the workflow on your team that is the noisiest, the most costly, the one you personally least want to do, and ask: “Is it still doing what it was set up to do?” This is not a technical question. It’s an organizational one. The 50-person review meeting was cancelled not because someone found a better alternative, but because someone asked the question.
The second comes from organizational change research: set a subtraction rule. The radical management research group Corporate Rebels visited a company that had a hard rule: every time someone wants to introduce a new policy, they must first abolish at least one existing policy. This isn’t about optimizing a specific process. It’s about creating a meta-mechanism that fights institutional entropy. The Nature study also confirmed that even a lightweight reminder – “please consider subtraction” – significantly changed the kinds of proposals people made.
The third heuristic is temporal. Fiona said she and the team revisit their team principles every few months: “Does this principle still have the effect it had before? Is it still doing what we wanted when we created it?” The important part is not the frequency. “A few months” is not a hard number. What matters is that the review itself has become an institutionalized action, not a one-time cleanup. Model capabilities keep improving. Constraints keep shifting. What was optimization yesterday could be waste today.
One last point, and it’s counterintuitive. Unlearning is not about returning to a “no process” state. It’s an ongoing activity that demands judgment. Process itself is not the enemy. Process that has never been examined is. It’s like code refactoring. You don’t refactor because the code is dirty. You refactor because the system’s context has changed. Vadim Kravcenko wrote: “We refactor code every sprint. The organizational layer deserves the same treatment.”
Back to the opening remark. Fiona Fung said it repeatedly in her talk: “What made you successful in the past may not continue to make you successful.” This is not a feel-good platitude. It is an engineering judgment. AI has changed the most fundamental cost assumptions of software development. The processes, norms, role definitions, and organizational structures that made sense under the old assumptions will not update themselves just because the assumptions changed. They need to be actively identified, evaluated, and abolished. “Actively” is not a rhetorical flourish. It’s because the default direction is always accumulation, not cleanup.
MIT professor Zeynep Ton observed: “In large organizations, people know they will be noticed for what they add, not for what they remove.” For engineering managers who are leading teams and pushing AI tool adoption, this means unlearning is not just a skill. It’s a management responsibility. You have to say it out loud: deleting old processes is okay. It is encouraged. It is part of the job. Because no one else will do it for you.