AI and the Big Ball of Mud

A Big Ball of Mud is difficult to understand. User flows spread across components, services, and global state. Side effects emerge in places that are barely predictable from the visible structure. Inheritance connects areas that have little to do with each other from a domain perspective. A seemingly local change can touch dependencies across several domains.

For humans, this kind of analysis eventually becomes expensive. Not necessarily because any single location is exceptionally complicated. The problem is the number of potentially relevant relationships that have to be followed at the same time.

And then a coding agent arrives.

It searches the repository, follows references, opens services, base classes, and tests, reconstructs call chains, looks for writes to a state object, and reads the next file when the previous one points to yet another dependency.

At some point, the human asks, “Why exactly am I in this file now?” The agent simply opens the next one.

That is not a trivial improvement. Especially in tightly coupled systems, today’s coding agents can take over analytical work that is extraordinarily exhausting for humans. Repository-level benchmarks and current research therefore no longer focus only on generating individual functions. They increasingly examine navigation, search, multi-file reasoning, tool use, and the selection of relevant context.

As of August 2026. This article describes the current state of coding agents, their context mechanisms, and their economic conditions. Nobody can seriously predict what such systems will be capable of in five or ten years. Perhaps one day the instruction really will be: “Throw it away and rebuild it.” As of August 2026, that is not a dependable architecture strategy.

The interesting question is therefore not whether AI can help with a Big Ball of Mud. It already can.

The more interesting question is: What exactly does it improve?

No problem. We have AI now.

Coding agents have several properties that fit the work in large codebases remarkably well. They can search across a repository, inspect many files, follow symbols and references, run tests, interpret logs, and try another path after an unsuccessful approach.

Most importantly, they do not have to keep the results of an analysis in human working memory in the same way. An agent can reload context, repeat searches, condense intermediate findings, or reconstruct a path it has already investigated.

That does not mean it has “understood” the entire system. That claim would be too strong. But an agent can mechanically explore a great deal of explicit code context and navigate a large search space much faster.

Repository exploration can account for a substantial share of current agent runs, and this is now observable empirically. The 2026 FastContext paper analyzed 300 coding-agent trajectories on SWE-bench Multilingual. Reading and searching together accounted for 56.2 percent of tool-use turns and 46.5 percent of the main agent’s tokens. By separating and condensing this exploration, the authors reduced the main model’s token consumption substantially in their experiments, by roughly 60 percent in the best case depending on the benchmark. At the time of writing, the work is a preprint; its concrete figures are neither universal nor equivalent to a mature body of evidence. It does, however, illustrate clearly that locating relevant code is itself a measurable part of a coding agent’s work.

Similar results appear in other recent research. ContextSniper substantially reduces token use in its repository-level repair pilot experiments, although submitted-resolution rates decrease slightly. SWE-ContextBench, in turn, shows that correctly selected and condensed prior experience can reduce token cost and runtime, while unfiltered or incorrectly selected context provides little benefit or can even be harmful. Both studies are still young and are preprints as of August 2026.

The underlying problem is therefore anything but hypothetical:

Before an agent can change code, it first has to determine which code is relevant at all.

A Big Ball of Mud makes exactly that question difficult.

Analytical capability is not architecture

Suppose an agent reconstructs the following sequence for a ticket:

A calls B.

B changes C.

C triggers a side effect in D.

A shared base class also overrides behavior and causes E to run.

The agent finds this chain. It may even be able to explain why the chain matters for the ticket. Perhaps it then adds a test and implements the change in the right place.

That is valuable.

But afterwards, this still exists:

A → B → C → D → E

The domain boundaries have not become clearer. Responsibilities have not been recut. Dependencies have not suddenly become directional. Global state is still global. A base class that couples several domain areas still couples them after the successful analysis.

AI can compensate for missing architecture through analysis. Analysis is not a substitute for architecture.

Being able to reconstruct a dependency path is not the same as ensuring that the dependency path is meaningfully constrained.

This leads back to a mechanism that has already played an important role in this series. A Big Ball of Mud can remain functional for a surprisingly long time because organizations compensate for its structural deficits. Specialists know the dangerous areas. Reviews catch risks. Regression tests protect critical paths. Release processes become more cautious. Individual people know which apparently harmless change is better left alone.

Coding agents can become a new and exceptionally powerful form of that compensation.

The system does not necessarily become simpler. We merely become better at working in it anyway.

When the history is not in the repository

A second problem is easy to overlook, especially in old systems: not everything relevant to a change is present in the current code.

Why does this special case exist? Was it added after a production incident in 2019? Was there a technical constraint that no longer exists? Is the strange extra request a workaround for a backend that has long since been retired? Does the if encode a real domain rule or merely a historical exception? Was this dependency chosen deliberately or created during a release under time pressure?

An agent can analyze the code that exists. It can also inspect Git history, issues, ADRs, documentation, logs, or old pull requests if those artifacts are available to it. This is another area in which agents can be highly useful: they can search large volumes of such material and connect related evidence.

But the decisive limitation is: The information has to exist somewhere.

If a decision was never documented, the ticket no longer exists, the developer who made it has left the company, and only the resulting code remains, an agent can form hypotheses. It can detect patterns and generate plausible explanations.

It cannot reliably reconstruct lost history from nothing.

A large context window cannot recover lost history if that history is no longer stored anywhere.

This is not a problem unique to AI. A new human developer faces the same boundary. Agents merely expand the amount of existing material that can be evaluated economically.

And this is exactly why architecture becomes interesting in agentic coding: not only as the structure of code, but as the structure of the knowledge required to change it.

Architecture as context compression

Good architecture is often described using concepts such as maintainability, separation of concerns, information hiding, or clear responsibilities. Coding agents add another useful perspective:

Architecture constrains the relevant search space.

Assume a change concerns the planning domain.

In a well-structured system, planning has a recognizable slice. Its public interfaces are defined. Dependencies on other areas cross a small number of controlled boundaries. Inside the slice, layers and responsibilities are similarly understandable.

For a local change, an agent may need to inspect the Planning slice, a few adjacent models, its public interfaces, and the relevant tests. It does not need to understand every implementation detail of billing, user management, reporting, or another independent area.

The important property of a boundary is therefore not only what it includes. It is what it excludes.

Architecture is also an exclusion mechanism.

It does not only say:

Planning is here.

It also says:

If these boundaries hold, you do not need to understand large parts of the rest of the system for this change.

That is information hiding in a form that is directly relevant to resource consumption by agents. Modularization creates areas whose internal details can reliably remain irrelevant to other areas. The principle is far older than LLMs. Agentic coding merely adds another resource perspective to it.

This can be viewed as a form of context compression.

Not because architecture physically compresses the source code. An excellently modularized system can still contain millions of lines. It compresses the portion of the system that has to be considered for a concrete decision.

Or more simply:

Good architecture saves context because it can make things reliably irrelevant.

This should not be misunderstood as a mathematical law. A modular codebase does not guarantee low token consumption. A difficult ticket can require substantial analysis even in an excellent system. Conversely, a change in a chaotic system can happen to remain entirely local.

As a matter of basic computer-science logic, however, the relationship is plausible: The better a problem space is decomposed and its dependencies constrained, the smaller the relevant search space for a local task can be.

Current research on context selection fits this idea remarkably well, although it does not directly prove the architecture thesis. CodexGraph uses explicit code graphs for structure-aware retrieval and navigation. CodeMEM uses AST-based representations to preserve repository and session context selectively. SWE-ContextBench shows that correctly selected compact experience can be more efficient than unfiltered history.

Research is therefore already examining intensively how agents can find, structure, and condense relevant context.

Software architecture answers the same question at another level:

What should be capable of being relevant to this task at all?

Good architecture does not reduce the amount of code. It reduces how much code a change needs to know about.

A Big Ball of Mud lacks exactly this boundary

Consider the same change in a Big Ball of Mud.

It begins in file A. A uses service B. B writes to global state C. Another component reacts to C. C inherits behavior from a base class. The base class knows about navigation, configuration, and functions from several domain areas. A second slice modifies the same state through another path. A custom infrastructure mechanism reacts to part of these changes as well.

This is not impossible for an agent to search. That is precisely one of its strengths. It can inspect A, open B, search for writes to C, follow the inheritance chain, and then determine what else modifies C.

But every newly discovered relationship can introduce further potentially relevant relationships.

The agent can search this space.

But it has to search it.

In a modular system, analysis ideally reaches a dependable boundary at some point. A public API, a directional dependency, or a slice boundary allows the conclusion that implementation details beyond that point are irrelevant to this change.

In a Big Ball of Mud, the agent often has to search for that boundary first. And a dependable one may not exist at all.

This does not imply that exploration effort grows mathematically exponentially. There is no basis for that claim. It can, however, grow sharply when every newly discovered dependency introduces further candidates into the relevant search space.

Current repository-level research also shows that larger context windows do not simply make this problem disappear. RepoReasoner, published at FSE 2026, explicitly evaluates cross-file reasoning and call chains. Even when oracle context is provided, difficult cross-file tasks remain challenging; longer context does not consistently improve results because additional material can also add additional noise.

The problem is therefore not simply:

Does the entire repository fit into the context window?

It is:

Which part of it actually helps the agent make this decision?

Agentic coding is expensive even with good architecture

At this point, it would be tempting to infer poor architecture directly from high token consumption.

That would be wrong.

Agentic coding can consume substantial resources even in excellently structured systems. An agent reads code, creates a plan, implements, compiles, runs tests, analyzes failures, corrects them, reruns tests, evaluates its patch, and responds to review results. Multi-step agents can additionally launch subagents, explore alternative solutions, or spend a considerable share of their budget on verification.

The 2026 Tokenomics study analyzes token distribution in a multi-agent software-development workflow. Across the 30 tasks in that study, iterative code-review stages consumed the largest average share. This is a small and specific experiment, not a general cost formula for agentic coding. It does show why “many tokens” may initially mean nothing more than that the agent did a lot of work.

The architecture comparison therefore begins at a more precise point:

How much additional effort exists solely because the agent first has to discover which part of the system is relevant to the task?

Good architecture does not minimize token consumption. It can reduce the share spent solely on rediscovering the system before a local change can be made.

The relevant distinction is therefore not cheap versus expensive, but rather productive context versus exploration cost.

And the AI can still add one more if

Then the next ticket arrives.

A particular state should behave differently under three additional conditions. The existing system already contains many similar special cases.

A coding agent can search for those conditions. It finds the places where the same state is read and modified. It recognizes existing conventions. It adds the special case at the point where it appears to fit existing behavior with the lowest risk. Then it extends the tests.

The tests are green. The ticket is done.

And perhaps special case number 38 has just been added to the system.

An agent can find good local solutions very quickly. Historically, that has already been part of the problem.

The previous article in this series, on how a Big Ball of Mud emerges, examined precisely this mechanism. Nobody sits down in the morning and decides to build an incomprehensible architecture. Many individual decisions can be entirely rational locally. Under time pressure, the existing structure is extended. The solution works. Another special case is added. Consolidation never happens later.

A coding agent does not change that mechanism by default.

That does not mean it has done poor work. Quite the opposite. It may have fulfilled exactly the task it was given:

Implement this ticket with the lowest possible risk in the existing system.

If another if is the safest local change, a good agent can find exactly that if very efficiently.

The problem is the level of optimization. A locally optimized patch is not automatically an architectural improvement.

A successful change is not yet a structural improvement.

AI as a new compensation layer

This leads to an interesting hypothesis for Big-Ball-of-Mud systems.

Such systems have often remained changeable for a long time because other mechanisms compensated for their deficits: experienced specialists knew the dangerous areas, extensive regression tests protected changes, reviews compensated for poor local comprehensibility, release rituals reduced risk, personal knowledge replaced documentation, and workarounds bridged structural shortcomings.

Agentic analysis can now become another compensation layer.

It does not restore the missing boundaries. But it can initially reduce the effort required to make a concrete change despite those missing boundaries.

That creates an economically interesting possibility:

AI could move the economic tipping point of a Big Ball of Mud further into the future.

A system whose changes would already have become disproportionately expensive for humans alone may remain productively changeable for longer with agentic assistance.

At present, this is a hypothesis, not an established law. Direct comparisons between real codebases with substantially different architectural structures remain insufficiently studied.

The mechanism itself is plausible, however: if analyzing the system is expensive and a new tool makes that analysis cheaper, the cost of an individual change initially falls. The underlying system does not have to become better for that to happen.

The Big Ball of Mud does not become healthy. It merely remains workable for longer.

AI can compensate for the consequences of missing structure without changing the structure itself.

A month’s allowance in one day

I experienced this shift myself in one particularly boundaryless system.

Within a single working day, I had used an agent allowance that, under my Windsurf plan at the time, was roughly intended to last a month.

I had not asked the agent to rewrite the system. I had essentially asked it to understand the system well enough to work in it.

It searched, read files, and followed dependencies. New findings led to more files. Assumptions had to be checked and sometimes discarded. The agent was able to perform this work and was extremely useful while doing so.

But the analysis was not free.

This experience is not empirical evidence for a general cost function. It does not show that every Big Ball of Mud consumes a similar number of tokens, nor that a modular comparison system would have been cheaper by any particular factor.

As an observation, however, it is still interesting. Part of the complexity cost that would previously have appeared almost entirely as human analysis time suddenly materialized in another resource: agent allowance.

For me, that was the point at which “architecture as context compression” changed from a theoretical idea into a very concrete economic question.

What research already shows — and what it does not

Research on coding agents is moving so quickly that this section will probably age sooner than many other parts of this series. As of August 2026, however, several levels can still be separated reasonably clearly.

Repository exploration has measurable costs

The need to locate relevant files and code regions is already a standard concern in repository-level research. FastContext measures a substantial share of read and search activity in tool calls and token consumption. ContextSniper reduces token volume by selecting repository and tool output. CodexGraph uses explicit structural representations of repositories to support navigation and retrieval.

The concrete figures are not universally transferable. Different models, agent harnesses, benchmarks, and tasks produce different trajectories.

The underlying observation remains relevant:

Exploration is not a free prelude to programming. It is part of the agent’s work.

Context selection matters more than maximum context volume

The RepoExec study, published in Findings of NAACL 2025, shows that repository-level code generation depends strongly on appropriate dependency context. Other recent work therefore explicitly studies how relevant information can be selected, structured, or preserved across multiple interactions.

SWE-ContextBench reports that correctly selected and summarized prior experience can reduce runtime and token cost, while unfiltered context provides smaller or negative benefits. LoCoBench-Agent observes a trade-off between thorough exploration and efficiency: more exploration can improve comprehension, but it costs additional interactions and resources. Both works are preprints at the time of writing.

A large context window does not remove the problem either. RepoReasoner still finds substantial limitations on complex cross-file tasks and reports that longer context does not consistently improve results when the extra material adds noise.

Structured representations can help

Several recent approaches try to expose repository structure more explicitly to agents.

CodexGraph models code relationships as a graph and supports structure-aware queries. CodeMEM uses AST-based memory structures for repository and session context. Another study from June 2026 examined supplementary visual repository graphs; in its evaluated scenarios, input token consumption fell by up to 26 percent when such graphs were added alongside textual tools while issue-resolution accuracy was maintained or improved. That study is a preprint.

This is not evidence that “clean architecture saves X percent of tokens.”

It does show that structuring and constraining repository context matters empirically.

The direct architecture comparison is still missing

The central thesis of this article therefore needs a clear boundary.

In the research reviewed for this article, I did not find a controlled study that compares functionally equivalent software systems with substantially different internal architecture — for example, a consistently modular system and a heavily boundaryless Big Ball of Mud — under identical coding-agent tasks and then compares token consumption, tool calls, or exploration effort.

That matters.

Current research supports the claims that repository exploration consumes resources, irrelevant context can be harmful, and better selection or structured representations can produce measurable efficiency gains.

It does not yet support an empirically established formula such as:

A Big Ball of Mud costs a coding agent five times as many tokens.

And certainly not:

Big Balls of Mud consume exponentially more tokens.

As of August 2026, that evidence is not available.

The thesis of this article therefore remains on three distinct levels:

1. Computer-science logic: Constrained dependencies can constrain the potentially relevant search space for a local task.
2. Adjacent empirical evidence: Repository exploration, context selection, and long agent trajectories have measurable token, runtime, and tool costs.
3. Open research question: How strongly different software architectures affect agent resource consumption when the tasks are otherwise comparable.

Those levels should not be confused with one another — especially because the hypothesis sounds so plausible.

The bill increasingly arrives in tokens, context, and compute

The costs of poor architecture are not new. They have simply been visible in other units.

Developers need longer for analysis and changes. Lead times increase. Errors and regressions become more likely. Onboarding takes longer. Specialists become bottlenecks. Reviews become more demanding. Releases require additional safeguards.

Agentic coding adds further resources to that cost model: input tokens, output tokens, cached context, retrieval, tool calls, agent runs, compute, runtime, and still human reviews and correction loops afterwards.

Not every provider bills each of these resources separately. Some are bundled, some become cheaper through caching, and others remain hidden behind quotas or subscriptions. The underlying technical resources are still consumed.

AI does not make a Big Ball of Mud free to understand. We are simply no longer paying exclusively with human attention.

This creates an interesting, still hypothetical observation metric for technical debt.

It is difficult to measure how much “system understanding” a specific change requires. Coding agents, however, generate increasingly detailed usage data: tokens, cache use, tool calls, agent runtime, context sizes, and exploration trajectories.

A previously difficult-to-see part of technical debt might therefore become at least partly measurable in the future:

How much machine context does this system require before a local change can be made with sufficient confidence?

That would not be a universal architecture metric. A difficult feature remains difficult even in a well-structured system. Models and agent harnesses differ considerably. And a token is not a standardized unit of cognitive complexity.

As an additional observation, however, the value could become interesting.

AI does not necessarily eliminate complexity costs. It can shift part of them into machine processing.

The flat-rate effect

For a long time, this relationship was surprisingly easy to overlook.

A developer pays a monthly fee for an AI tool. They use it across several tickets. At the end of the month, the same subscription fee appears.

From the developer’s perspective, the cost function initially looks very simple:

AI costs X euros per month.

That says little about how much machine work was required for a particular change.

Subscription models abstract actual resource consumption through included usage, credits, session or weekly limits, fair-use rules, and different model classes. Once those boundaries are exceeded, additional usage may be limited or billed on a consumption basis.

Developments among major providers in 2026 show clearly that the boundary between flat subscription pricing and actual consumption is currently being recalibrated.

GitHub moved regular Copilot plans to GitHub AI Credits on June 1, 2026. Consumption is calculated from input, output, and cached tokens using the corresponding model prices. GitHub explicitly justified the change by pointing to the substantially higher compute and inference demands of long agentic sessions and stating that the previous premium-request model no longer represented those differences sustainably. Some annual subscriptions temporarily remained on the old request-based model.

That legacy model is a useful example of why individual numbers require careful interpretation. For GPT-5.5, GitHub lists a premium-request multiplier of 57 in August 2026 for remaining annual legacy plans.

That does not mean that “GPT-5.5 tokens became 57 times more expensive.”

The factor belongs to a specific accounting unit in a legacy request-based model. Token price, request multiplier, included credits, and actual inference cost are different quantities.

The same basic pattern — included usage combined with more consumption-oriented extensions — now appears elsewhere as well.

OpenAI changed Codex pricing in April 2026 to a credit rate card directly tied to input, cached-input, and output tokens. Codex remains included in several ChatGPT plans; after included limits are reached, additional credits can be used where supported. Actual credit consumption therefore depends directly on the token mix of a task.

Anthropic likewise combines paid Claude plans with usage limits. Claude and Claude Code share available usage limits on individual plans; after those limits are reached, users can enable usage credits where supported or move to consumption-based API usage. Anthropic also notes that usage depends on factors including the length and complexity of interactions, the model, and the features being used.

None of this proves that current subscriptions are necessarily loss-making for providers. We do not have the internal cost and usage data required to make that claim.

It means only this:

The price of a subscription and the machine work required for a task are not the same quantity.

When architecture costs disappear inside the subscription

Imagine two teams.

Team A works in a modular system with clear domain boundaries and directional dependencies. Team B works in a heavily boundaryless system. Both use the same coding-agent product.

If both teams see only the same monthly subscription fee on their cost center, their AI costs initially look identical.

That does not imply identical resource consumption.

Team A might spend a large share of its agent budget on implementation, tests, and review. Team B might spend a larger share first determining which files, services, states, and side effects are relevant at all.

We do not yet know empirically whether that difference is small or very large in real systems.

The economics change, however, when usage becomes more transparent and more strongly consumption-based. Additional repository searches, larger amounts of context, further agent runs, or longer compute time can then become directly cost-relevant depending on the product and billing model.

That may make visible something that was previously hidden in developer time, frustration, and implicit specialist knowledge.

The cost of poor architecture does not disappear. A flat-rate AI plan can merely obscure the unit in which that cost is currently being paid.

Perhaps this will change how we discuss technical debt in a few years. Not only:

How long does a developer need for this change?

But also:

How much context and machine exploration does our development system require merely to constrain this change?

The Big Ball of Mud has always been expensive. Agentic coding may cause part of that bill to be presented not only in hours, but also in tokens and compute.

“But the agent can handle it”

This may be where the most dangerous misconception appears.

Suppose changes in a problematic legacy system previously took several days. With a good coding agent, similar tickets suddenly work again within hours.

That is a real productivity gain.

From a management perspective, however, a tempting interpretation follows:

Then the architecture problem must no longer be that important.

The visible symptoms have become smaller. The developer no longer has to spend two days navigating the repository. The agent takes over a substantial part of the navigation, finds the global state, discovers the base class, reconstructs the side effect, creates a test, and implements the next special case.

Delivery speeds up again.

But no slices have been restored, no layers introduced, ownership clarified, global dependencies reduced, historical workarounds removed, or target architecture created.

The fact that an agent can find a path through the system does not mean the system has regained a sustainable structure.

The organizational effect could even point in the opposite direction. The more successfully AI compensates for the symptoms of a Big Ball of Mud, the lower the short-term economic pressure may become to address its structural causes.

That, too, remains a hypothesis. But it follows the same pattern that stabilized the Big Ball of Mud before AI: as long as compensation mechanisms are cheap enough, continuing to operate the existing system can remain a rational decision.

Coding agents may therefore change not only productivity, but also the point at which poor architecture becomes economically intolerable.

Can AI also help us get out?

Yes — probably substantially.

The same capabilities that make an agent such an effective compensation layer are highly relevant to architecture work. An agent can analyze dependency structures, inspect change coupling in history, reconstruct user flows, identify gravitational centers in the code, generate tests, safeguard refactorings, and repeatedly check which dependencies still violate a newly introduced boundary during an incremental migration.

Architecture recovery is another obvious use case. When a system has lost its visible architecture, machine analysis can help expose the structures that are actually effective. Current research on code graphs, repository representations, and context-aware navigation shows that precisely these kinds of structural information can be useful to agents.

The difference is therefore less about the tool than about the assignment.

“Implement this ticket in the existing system.”

uses the agent primarily as a compensation mechanism.

“Help me understand the structure of this system and restore dependable boundaries.”

uses the same capabilities for architecture work.

Both can be sensible. They are simply two very different goals.

How to analyze a Big Ball of Mud, which boundaries can realistically be restored, and when remediation makes more economic sense than replacement belongs in the later action-oriented articles in this series.

What AI actually changes about a Big Ball of Mud

AI creates a remarkable ambiguity around the Big Ball of Mud.

It can keep systems changeable even when analysis has already become extremely expensive for humans alone. It can inspect more code in less time, follow references, collect edge conditions, and reconstruct dependencies. It can extend tests and perform local changes at a speed that would have been difficult to imagine in some legacy systems only a few years ago.

That is a lot. It would be wrong to downplay those capabilities.

At the same time, the structural problems do not disappear. The agent still has to compensate for missing boundaries. It must search, select, and process context. It consumes tool calls, tokens, compute, and runtime. And as long as the next ticket works again, that successful compensation may itself reduce the immediate pressure to address the underlying architecture problem.

AI can therefore make a Big Ball of Mud easier to work in without making it any less of a Big Ball of Mud.

Whether future coding agents will be able to analyze large legacy systems largely autonomously, reconstruct their hidden domain models, and perform safe structural transformations remains open. As of August 2026, we are not at that point.

What we can already observe today is more subtle:

AI may not mean the end of the Big Ball of Mud. At first, it may simply extend its lifespan.

Today, the agent can find a surprising number of paths through the mud. That does not make the ground dry.

Sources and current research

The following publications and provider information form the main basis for the time-sensitive claims in this article:

• Parnas, D. L. (1972): On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM 15(12), 1053–1058. DOI: 10.1145/361598.361623.
• Le Hai, N.; Nguyen, D. M.; Bui, N. D. Q. (2025): On the Impacts of Contexts on Repository-Level Code Generation. Findings of NAACL 2025, 1496–1524. DOI: 10.18653/v1/2025.findings-naacl.82.
• Liu, X. et al. (2025): CodexGraph: Bridging Large Language Models and Code Repositories via Code Graph Databases. NAACL 2025, 142–160. DOI: 10.18653/v1/2025.naacl-long.7.
• Wang, P.; Zhang, L.; Liu, F.; Tao, C.; Zhu, Y. (2026): CodeMEM: AST-Guided Adaptive Memory for Repository-Level Iterative Code Generation. Findings of ACL 2026, 16903–16917. DOI: 10.18653/v1/2026.findings-acl.834.
• Wang, Y. et al. (2026): RepoReasoner: Evaluating Repository-Level Code Reasoning Ability of Long-Context Language Models. FSE 2026.
• Qiu, J. et al. (2025): LoCoBench-Agent: An Interactive Benchmark for LLM Agents in Long-Context Software Engineering. arXiv:2511.13998 (preprint).
• Zhu, J.; Hu, M.; Wu, J. (2026): SWE Context Bench: A Benchmark for Context Learning in Coding. arXiv:2602.08316 (preprint).
• Zhang, S. et al. (2026): FastContext: Training Efficient Repository Explorer for Coding Agents. arXiv:2606.14066 (preprint).
• Luk, C. et al. (2026): ContextSniper: AntTrail’s Token-Efficient Code Memory for Repository-Level Program Repair. arXiv:2607.01916 (preprint).
• Ma, D. et al. (2026): LLM Agents Can See Code Repositories. arXiv:2606.14061 (preprint).
• Salim, M.; Latendresse, J.; Khatoonabadi, S.; Shihab, E. (2026): Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering. arXiv:2601.14470 (preprint).
• GitHub (2026): GitHub Copilot is moving to usage-based billing and Model multipliers for annual plans on request-based billing (legacy).
• OpenAI (as of August 2026): Codex rate card and documentation on credits for additional Codex usage.
• Anthropic (as of August 2026): documentation on Claude Code usage and limits and usage credits for paid Claude plans.