DEV Community: James O'Reilly

Context bankruptcy: The case for strategic forgetting for AI Agents

James O'Reilly — Fri, 10 Jul 2026 14:12:20 +0000

Most of us have seen a coding agent fail to complete a task we know it can do. We just don't understand the inconsistency in quality and lazily chalk it up to the "non-deterministic" nature of AI. What you might not realize is that the agent isn't failing because of intelligence, it's failing because its context is cluttered with noise.

To fix this, we need to shift from context maximizing to deterministic pruning. Here is what you will get out of this deep dive to help you build those boundaries:

Why feeding an agent your entire repository causes agent reasoning failures.
How to navigate brownfield codebases by isolating subsystems for agents.
How to dynamically mask dead code before launching an agent turn.
The essentials for a reliable pruning harness.
Why unconstrained context bloats PRs and burns out reviewers.

In computer architecture, thrashing occurs when an executing process demands more memory than the caches can hold. The processor stops executing useful instructions and spends all its resources swapping pages of memory in and out of RAM.

Coding agents have a similar bottleneck inside their prompt windows. With brownfield development, it might be tempting to dump the whole legacy codebase into context and prompt "refactor this to Next.js" (Read my article How to automate modernization with Antigravity and multi-agent orchestration to learn why this is a bad idea and what to do instead). However, if you do dump the whole codebase into context the agent is more likely to confuse dead code and old library usage as current intent.

You've reached context bankruptcy when the context actively degrades reasoning accuracy.

The visibility trap and why more context breaks reasoning

Some developers treat complete repository ingestion as a headline feature of the large context windows of frontier models. They assume comprehensive visibility equals deep understanding. It doesn't.

In clean greenfield projects, broad context ingestion works but in a multi-million-line legacy codebase, broad context ingestion adversely impacts an agent's ability to reason.

Most of us don't work on greenfield apps and many work inside messy poorly documented legacy codebases they inherited. They typically contain gems like folders named "v1-alpha", temporary helper scripts that are no longer usable or reflect current code, and orphaned feature flags. When an agent sweeps this data into context via naive RAG sweeps or massive context windows, it treats outdated patterns as current engineering truth.

The rule driving this failure is Hyrum's Law applied to AI context windows: with sufficient ingestion breadth, every observable historical implementation detail will eventually be depended upon by an autonomous model.

Give an agent access to 1,000 files and it will reason over your hackiest workarounds. It anchors on deprecated helper scripts and replicates tech debt into new modules.

Selective ignorance and how to enforce the boundary

When I review a legacy monolith I'm not familiar with, I don't read every file.

I practice selective ignorance and deliberately ignore most of the repository when building a mental model around the module I want to modify. I do this by treating the surrounding subsystems as if they were black boxes bounded by strict contracts.

The agent execution environments should model this behavior.

Addy Osmani recently documented context rot (the measurable performance dip models experienced as prompt windows fill) and agentic engine optimization (AEO) (formatting codebase documentation). Our industry remains obsessed with ingestion pipelines and larger token limits. Nobody is building harness infrastructure designed to force strategic forgetting.

To protect agent reasoning we must shift our engineering effort from context maximization to deterministic pruning.

If the agent sees the whole repository, you aren't scaling engineering velocity. You're scaling cognitive debt.

Pruning harnesses versus context bankruptcy

I treat context budget allocation as an architectural constraint because strategic forgetting requires replacing broad ingestion with deterministic pruning.

The contrast between unbound ingestion and strategic forgetting is significant.

Architectural Dimension	Unbound Ingestion (Context Bankruptcy)	Strategic Forgetting (Pruning Harness)
Ingestion Strategy	Global vector RAG sweeps or broad context dumping across `*/`	Dynamic AST pruning scoped strictly to active dependency graphs
Legacy Conflict Resolution	Ingests competing API wrappers; model hallucinates hybrid syntax	Hides deprecated subsystems; enforces single active contract
Prompt Capacity	85%+ context budget consumed by historical boilerplate and dead code	<15% context budget consumed; working memory preserved for execution
Reasoning Stability	High susceptibility to context rot; attention allocation dilutes over noise	High attention concentration; deterministic diff generation
Verification Overhead	High cognitive load; engineers scrutinize massive diffs for side effects	Minimal cognitive load; diffs match expected five-line boundary

Architectural context pruning is not an optimization step. It is a baseline reliability prerequisite. If an autonomous agent can read deprecated internal modules, it will eventually depend on them.

Models are probabilistic which makes them unreliable at deterministic access controls. Simply refining a prompt to instruct the model to ignore sections of a large codebase will fail under complex reasoning loads. This is because models will attend to tokens inside their prompt windows regardless if those tokens are no longer relevant to the project.

To guarantee selective ignorance, implement a muted repo pattern which dynamically manipulates repository visibility before launching an agent turn. Here's how it works…

1. Map active dependency graphs

Run a static Abstract Syntax Tree (AST) parse starting from the target entry file. Generate a strict allowlist containing only immediate upstream imports and downstream consumers.

2. Dynamically create ignore masks

Write an ephemeral .antigravityignore, .geminiignore, .claudesignore or .cursorignore file before the agent turns. Mask out archive/, deprecated helpers, and unrelated domain packages.

3. Use interfaces as substitutes for implementation

Replace complex external database wrappers and legacy integrations with clean interfaces or OpenAPI stubs. Force the model to code against these interfaces.

4. Launch scoped agent turns

Execute the agent prompt inside the pruned sandbox. This enables the model to work with focused attention free of historical distraction.

Essential implementation components

Building a deterministic pruning harness relies on three core components.

1. Runtime CLI file gating

Modern agentic IDEs maintain persistent workspace indexes so I avoid editing .antigravityignore, .geminiignore, .claudesignore or .cursorignore dynamically per agent turn because overwriting ignore manifests trigger file-watcher invalidation events. When that happens the machine rebuilds codebase indexes in a race condition against the model's first token.

To avoid editing the ignored files each agent turn, one option is passing file allowlist flags directly into your terminal command when launching the agent (agy --add-dir src/auth/dir). Or, if building a custom harness, pass allowed file arrays into your tool execution APIs in memory.

# .claudesignore .cursorignore .geminiignore .antigravityignore
# Force strategic forgetting in brownfield repositories

**/node_modules/
**/dist/
**/build/

# Gated Legacy Systems - Block the agent from historical noise
/legacy/v1-alpha/
/deprecated-soap-wrappers/
**/*.deprecated.ts

# Large static assets that trigger context thrashing
**/*.json
**/*.csv
package-lock.json
pnpm-lock.yaml

# Block the agent from analyzing un-verifiable dark matter code
/e2e/stale-tests-2022/

2. Hybrid semantic dependency mapping

Do not rely on naive vector embeddings to select codebase context. Vector similarity retrieves semantically similar code which can pick up unwanted legacy code.

Pure static AST tree-shaking would likely fail in brownfield monoliths because legacy systems lie at compile time. I'm thinking about systems that run on Java reflection, dependency injection containers, and runtime module loaders. For example, a shallow AST transversal would miss dynamically injected resources leading to dependency pruning causing runtime exceptions.

Instead, combine shallow AST parsing with recent observability outputs or runtime error logs to discover dynamic runtime dependencies before gating context windows. If runtime telemetry proves verify.ts calls legacy-sql-pool.js via DI reflection, include legacy-sql-pool.js in the allowlist. If static analysis and runtime traces both show zero execution paths to deprecated-auth.ts, keep it out of the allowlist.

3. Differential verification gating

Brownfield architecture is typically handled by isolating complexity behind interfaces. For example, modifying a billing service doesn't require you to read connection pool source code.

We can apply this thinking to agent prompt windows. By replacing deep internal library code with lightweight interface definitions, the model receives the correct contract specifications without ingesting implementation noise.

I do want to point out however, that in legacy systems interfaces may lie. It's the runtime side effects that are the real source of truth. If you do decide to stub code to save tokens during generation, be sure to enforce a differential verification gate. That way, success can be measured by passing tests against the legacy runtime, not the contract stubs.

How Antigravity implements pruning

Since I work at Google on Antigravity, I wanted to share my knowledge of how Antigravity implements isolation natively:

Subagent context isolation: Antigravity separates exploration from execution. The main agent has the ability to dynamically generate subagents which will have their own isolated context buffers and instructions from the main agent. The main agent may decide to delegate token-heavy or codebase-wide operations to subagents and keep the primary execution memory clean.
Planning mode checkpoints: Enforce explicit planning artifacts (/plan) so reviewers verify implementation design decisions and verification strategy before code generation.

Vigilance fatigue

Unconstrained context ingestion doesn't just degrade model reasoning, it also has a toll on people. I know when I review lengthy and broad, machine-generated diffs it triggers vigilance fatigue.

Reviewing code submitted by one of my colleagues is different from reviewing AI-generated code because I have less trust that basic architectural boundaries have been honored. I end up scrutinizing every line of code to verify the edit represents intentional business logic and not accidental side effects caused by historical noise.

As reviews grow in size and number, my attention struggles. It becomes increasingly difficult to avoid rubber-stamping bloated pull requests. Strategic forgetting helps protect reviewers by limiting the agent's reach.

Tuesday morning checklist

Most engineering organizations measure AI maturity by counting deployed subagents or tracking token consumption volume. In my opinion, both are vanity indicators.

True agentic scaling requires shifting focus from ingestion maxing to isolation discipline. Audit your agent workflows against three deterministic pruning heuristics:

Enforce small diff boundaries: If a localized bug fix generates PRs touching more than two files, halt execution. Your agent isn't being thorough, it's probably distracted by unrelated legacy code..
Treat ignore manifests as dynamic build artifacts: Don't maintain .antigravityignore files manually. Compile ignore manifests dynamically before agent turns combining AST import traversal with runtime trace telemetry (observability/error logs) so dynamic dependency injection paths stay unmasked.
Sandbox dependencies behind contract stubs: If an agent can read implementation source code for external SDKs or shared database wrappers, hide it. Use interface definitions or OpenAPI contract stubs instead.

Your agent headcount matters less than your isolation boundaries.

Additional resources

Here are a few other agentic brownfield development resources:

Article: How to automate modernization with Antigravity and multi-agent orchestration
Codelab: Automating legacy modernization at scale using agentic pipelines and Antigravity

Help others find this post.

Share this post with your friends on socials.
Follow me on LinkedIn or X for more content like this.

Thanks for reading!

10 Indispensable Prompts Our Team Refuses to Build Without

James O'Reilly — Tue, 16 Jun 2026 17:10:21 +0000

Look at any builder's prompt history and you'll see a collection of highly specific, chaotic, one-off prompts. We use AI to debug a single error message, refactor a messy email, or generate a quick boilerplate.

If you sit down with people who consistently ship high-quality work, you'll find something interesting. They aren't just improvising. They have a set of go-to prompts they have tweaked and improved over time and used on nearly every project.

I asked some of my peers and leaders a simple question: "What prompt do you use most often, and why?"

What they shared wasn't just a list of arbitrary commands. Here's the unfiltered look at the prompts our team refuses to ship without, and more importantly why they use them.

Listed in alphabetical order.

Build a spec

Maja Bilić
Senior Outbound Product Manager • Engineering
Follow on LinkedIn

The prompt:

Act as a cynical Principal Architect and Technical PM. I want to
build a [product] that allows [user] to do [action]. Do not write
code. Analyze this concept and list the top 5 technical, UX and 
architectural considerations. Then ask me key questions for each of 
the 5 considerations so we can work together on building the spec. 
Once you have all the answers, create a PRD doc and implementation 
plan. Don't over engineer or over simplify the design or 
implementation plan.

Why? I have written bad PRDs and I have read many bad PRDs. This prompt ensures I use the persona of a cynical Architect / PM who helps distill the idea, critique the approach and concept, and collaborate on defining the most important pieces. This way I make sure I work through the plan with an agent's help while also developing the product design idea further. I also love the guardrail of not over engineering or over simplifying things - AI tends to do that sometimes, especially when writing product design docs.

Widget tests

Andrew Brogdon
Staff Developer Relations Engineer • Engineering
Follow on X, LinkedIn

The prompt:

I'd like to partner with you on increasing the robustness of this 
project by creating widget tests. If you haven't already, please 
read the Flutter team's skill for creating widget tests 
(https://github.com/flutter/skills/tree/main/skills/flutter-add-
widget-test).

Then, let's do these things:
*  Examine my application's codebase to identify areas of the UI/UX  
   that are not being tested properly.
*  Determine if the existing code is written in a testable way (are 
   dependencies injected? Are domains loosely or tightly coupled?  
   Etc.).
*  Determine which domains require more rigor than others.
*  Create an overall testing plan for the application.
*  Determine which areas of functionality are already aligned with 
   that plan, and which are missing tests.
*  Create a plan to implement those tests.* Execute that plan.Do 
   not proceed from one step to another unless you are completely 
   confident about your reasoning. 

You are encouraged to as many questions as needed.

Why? My favorite use of agentic coding tools is to actually do all the things I used to feel guilty about not doing in my projects. Proper testing is definitely on that list. The official skills from the Dart/Flutter team do a great job of instructing agents on what good widget tests look like, so combining it with this prompt (which essentially just fits those steps into my own coding workflow) helps me reduce the toil required to maintain reliable, guilt-free codebases.

Find all the tests / Clean-up commit

Aja Hammerly
Director of Builder Relations • Engineering
Follow on X, LinkedIn

The prompt:

Run all the tests and identify any missing tests and write them. 
Pay special attention to edge cases and race conditions.

Find any unused code, embarrassing comments, comment to code 
inconsistencies, unresolved TODOs, or other things in this commit 
that shouldn't be in there.

Why?

I find that when I'm working on code I'll often get extremely focused on the "happy path", the main path I want a user to take through the code. While I'm focused on that I'll put in TODO or FIX comments on edge cases I don't want to think about yet. I'll also forget to update comments and leave debugging comments in sometimes. And while I try to follow test driven development, I don't always get tests in on all the edge cases. I run these two prompts, usually in a new conversation without the development context as a first round of code review before submitting to an AI or human reviewer for the next step. This ensures that what I've built is in good shape for others to review and use.

Check for correct and compliant permissions

Rich Hyndman
Head of Antigravity Developer Relations • Engineering
Follow on X, LinkedIn

The prompt:

Run a comprehensive check on this Android project to ensure all 
permissions are correct and compliant. Perform the following steps:

1.  Locate and analyze all 'AndroidManifest.xml' files (including 
    main, debug, and flavor-specific manifests), extract a master 
    list of declared '<uses-permission>' tags. 
2.  Cross-reference these declared permissions against the codebase 
    to verify where they are actually used. Identify any bloatware 
    or unused permissions that can be safely removed.
3.  Check the Kotlin/Java source files to ensure that all runtime 
    permissions implement the dynamic runtime permission request 
    flow 'checkSelfPermission','onRequestPermissionsResult' or the 
    Activity Result API.
4.  Verify that any hardware features associated with the 
    permissions (like android.hardware.camera) are correctly 
    declared. Output your findings as a Markdown report. Provide 
    file paths and suggested code diffs for any fixes. Do not make 
    any file edits until I approve the plan.

Why? Antigravity, with Gemini 3.5 Flash and the Android plugin is an excellent Android development partner! Checking for the correct permissions can keep your app running smoothly and help avoid delays when uploading to the Play Store.

Conduct code review

Shir Meir Lador
Head of AI, Developer Relations • Engineering
Follow on X, LinkedIn

The prompt:

Act as a strict, highly analytical Principal Engineer conducting a 
pre-production code review. You have incredibly high standards and 
zero tolerance for fragile, "happy-path" code. Your goal is to 
guide me to write bulletproof, production-ready systems.

Grade my uncommitted changes on an A-to-F scale for production 
readiness. 

Do not award an "A" unless my code is exceptionally robust. 

Specifically, analyze the changes for:

1.  Efficiency: Redundant API calls, wasteful database queries, or 
    un-cached resource leaks.
2.  Resilience: Silent failure points, lack of explicit error 
    boundaries, and missing rate-limit fallbacks.
3.  Architecture: Tight coupling and lack of clear separation of 
    concerns.

For every issue, explain pragmatically where the code is vulnerable 
to real-world production failures. Then, provide the exact git 
diffs needed to upgrade my code and earn that "A."

Why?

If you ask an LLM to review your code, it almost always defaults to being polite. It tells you your naming is clean, suggests a few docstrings, and hands you a green checkmark. But polite reviews don't prevent production outages. I like this prompt because it completely cuts through that AI fluff. By forcing the model to grade your work on a harsh scale and demanding a working git diff to fix it, you turn it into a real partner. It stops guessing and starts actually reading your network calls and database queries to find where the code is going to break. It’s like having an uncompromising senior dev sitting over your shoulder, pointing out exactly where you got lazy, and then handing you the exact code to fix it.

Explain trade-offs to aid decision-making

James O'Reilly
Staff Developer Relations Engineer • Engineering
Follow on X, LinkedIn

The prompt:

Explain the pros and cons of executing your suggested 
Implementation Plan. Be specific about the trade-offs we're making 
related to performance, cost, security and maintainability so I can 
make an informed decision on how to proceed.

Why? I force AI to stress-test its own logic. By asking it about the trade-offs being made, I find the AI will rethink its strategy, stay hyper-focused on our specific implementation and avoid giving vague, hand-wavy responses. I also find this approach prevents AI from acting like the final authority and keeps me in control of the decision making.

Improve AI-generated code through research

Emma Twersky
Head of Flutter & Dart Developer Relations • Engineering
Follow on X, LinkedIn

The prompt:

Research online, focusing on X threads, StackOverflow, GitHub 
issues and tech blogs for common security pitfalls, architectural 
misalignments, and subtle logic errors found in AI-generated 
<INSERT TECH YOU'RE USING HERE> code. Based on these findings, 
generate a manual review checklist specifically for auditing high-
risk areas like platform channel validation, deep link routing, and 
sensitive data logging in crash reports.

Why? While AI can write code 10x faster, it often produces slop—code that is rational but conceptually buggy because it makes incorrect assumptions about unspecified details. Research shows that up to 40% of AI-generated code contains vulnerabilities, and developers often trust it more than their own, which creates a dangerous mismatch. I use this prompt to generate a targeted checklist that protects against 'rubber-stamping' verbose AI changes and ensures my human judgment focuses on the high-risk 'seams' where models typically fail. Use AI to generate the tasks, but still keep a human in the loop where it matters most.

Find problems through iteration

Fred Sauer
Head of Frameworks & Languages Developer Relations • Engineering
Follow on X, LinkedIn

The prompt:

Simplified, my "last" (series of) prompt(s) looks something like:

-  Code review the uncommitted changes.

I prefer being less specific has oversteering can lead to blind spots.
I prefer a new chat session for a fresh set of "eyes".
I iterate until the results returned are boring and I'm satisfied.

If I come into this last phase with an opinion, (e.g. the change feels too complex), or I feel I don't have a good insight into how "good" the change is, then I might challenge the model with this prompt:

-  Code review the uncommitted changes. Identify any unhandled 
   corner cases. Assess performance. Summarize findings.

Then, having received 5 findings:

- Fix 1, 3 and 5.

Why? I don't have ONE last prompt I send. It's more that my change goes through stages. The earliest stage is often about discovery (find the needle or thread to pull on). Then I move on to existence proof, i.e. I just want it to prove the thing I want to do can be done. Then I evaluate: is the PoC reasonable? Too complex? Makes changes entirely in the wrong place(s)? I then iterate and try to make the solution elegant, both how it's implemented, and where what is changed. Once I have something I'm happy with, like I feel happy if I had written what I now have, I move on to that last phase you discuss with is code review. This is about finding problems or identifying opportunities to make the change even better. I'm often surprised with what insights the model comes up with.

Review every pull request

Remigiusz Samborski
Lead Developer Relations Engineer • Engineering
Follow on X, LinkedIn

The prompt:

I use the following prompt embedded in GitHub Actions for most of my engineering projects:

## Role

You are a world-class autonomous code review agent. You operate 
within a secure GitHub Actions environment. Your analysis is 
precise, your feedback is constructive, and your adherence to 
instructions is absolute. You do not deviate from your programming. 
You are tasked with reviewing a GitHub Pull Request.


## Primary Directive

Your sole purpose is to perform a comprehensive code review and 
post all feedback and suggestions directly to the Pull Request on 
GitHub using the provided tools. All output must be directed 
through these tools. Any analysis not submitted as a review comment 
or summary is lost and constitutes a task failure.

[...]

Full prompt: link

Why? Using an automated Gemini CLI review in PRs helps catch issues and improvement opportunities during the review process. Additionally as more code is generated by AI Agents and development speed increases, reviews are becoming the bottleneck. By ensuring every PR gets reviewed automatically, human reviewers can focus on the higher-level architectural and conceptual review of the proposed change.

Apply directed acyclic graph analysis for tests

Karl Weinmeister
Director, Developer Relations • Engineering
Follow on X, LinkedIn

The prompt:

Analyze the application workflow as a directed acyclic graph. 
Identify impactful tests for components, seams across components, 
and across the system. Present your findings in a markdown table as 
a prioritized gap analysis.

Why?

Most application workflows aren't linear. When you ask an LLM to suggest tests, you typically get a generic checklist that could apply to any project.

However, when you force it to think about your system as a DAG with nodes and edges, it starts reasoning structurally about where things can break.

I’ve also asked to consider the “seams” - a term from Michael Feathers' Working Effectively with Legacy Code. It points the model toward boundaries between components that are often under-tested.

Finally, I’ve asked the model to summarize the results as a prioritized table of opportunities. This gives your agent a clear roadmap for making your app more resilient.

Conclusion

The thread connecting all of these prompts is about de-risking human assumptions. Whether it's hunting for obscure edge cases, translating developer speak for end-users, or stress testing an architecture before code is written. Our team uses AI as an adversarial thinker designed to ask the hard questions we might overlook when we're deep in the weeds.

By building these "must-run" prompts into our daily workflows, we don't just ship faster, we ship with a level of confidence that used to require entire committees to achieve.

Now it's your turn

A great prompt is meant to be shared. We've shown ours, now show us yours!

What is the one prompt you run on every project without fail?
What is the worst disaster an AI prompt has ever saved you from?

Drop your go-to prompt in the comments below and let's build a valuable resource together.