There's a piece of programming advice that has been around for years: keep your modules "deep." A deep module does a lot of work but only asks you to learn a little to use it. A light switch is a good example. You flip it, the room lights up, and you never think about the wiring in the wall. Simple to use, complicated underneath.

For most of my career, that advice was easy to admire and easy to skip. Building things that way was considerate, but ignoring it didn't cost you anything you could point to.

That changed on June 1, 2026, the day GitHub Copilot started charging by the token. Almost overnight, how deep your modules are stopped being a matter of taste and started showing up as a number on a bill. Here is why.

What an AI agent is really paying for

Picture a restaurant. The menu is short and clear. The kitchen behind it is huge and complicated. You order from the menu. You never have to walk into the kitchen, read the recipes, or understand how the sauce is made.

That menu is what programmers call an interface: the small, public list of what something can do. The kitchen is the implementation, all the messy work that makes it happen. A well-built module is a short menu in front of a big kitchen.

Now bring in an AI coding agent. Every time it uses one of your modules, it has to read the menu and hold it in mind while it works. That reading is not free. The agent is charged for every word it takes in, and its attention is limited, the same way yours is when you are trying to juggle too many things at once.

So a short, clean menu is cheap to read and easy to work with. A long, sprawling menu is expensive and distracting. The menu is the part you pay for, again and again, every time the agent sits down to order.

A bigger menu doesn't just cost more. It makes the work worse.

You might think you can just pay the higher bill and move on. You can't, because the same extra reading that runs up the cost also makes the agent worse at its job.

Researchers have measured this. One well-known study found that when the information a model needs is buried in the middle of a long block of text, its accuracy can drop by more than 30 percent, even when the answer is sitting right there. A 2025 report tested 18 of the top AI models and found that every one of them got worse as it was handed more to read, even on easy tasks. Not just the weak models. The whole field.

The reason is simple. The more you put in front of a model, the more things compete for its attention, and the easier it is for the part that matters to get lost in the noise. Extra text doesn't have to be wrong to hurt you. It just has to be there, crowding out what the agent needs most.

So a bloated interface costs you twice. Once on the invoice, and again on the quality of everything the agent does around it.

Why deep modules win when you're paying by the token

Three things follow, and they all point the same way.

Deep modules are cheaper to use. The agent reads the short menu, not the whole kitchen, so far fewer words ever reach the bill.

Deep modules are more reliable. Less to read means less to get distracted by, which keeps the agent in the zone where it does its best work.

Deep modules pay off over time. When the menu stays small and steady, you can rebuild the kitchen behind it as often as you like without re-teaching the agent anything. You set the menu once and keep ordering from it for years.

A shallow module is the opposite on every count. It hands the agent a long menu, makes it more likely to get lost, and re-bills you for all that reading on every single job.

A good module can still cost you if you ship it the wrong way

Here is the part most teams miss. Designing a module well is only half the job. What you pay for is whatever the agent can reach and read, not what you meant to keep private.

Say you have a nicely designed module, but it lives in the same big shared codebase as everything else, with its full source code sitting right there in the project. From the agent's point of view, the kitchen door is wide open. The easiest move is to walk in and read the recipes. You built a short menu, and the agent reads past it to everything behind it anyway.

Now publish that same module instead. Package it up, give it a version number, and have other projects install it the way they install any outside library. The project now contains the finished product and the menu, not the recipes. The source code simply isn't there to wander into. The agent reads the menu, because the menu is all there is.

That is the single biggest, cheapest fix available: stop letting projects reach straight into shared source code, and start shipping shared code as published, versioned packages. One honest caveat, since it leads into the next article. Publishing hides the recipes, but if your menu itself is overgrown, it can still be a lot to read. Trimming the menu down to only what people use is a job of its own. Getting the kitchen out of the room is just the first and biggest win.

The cost used to be paid once. Now it's paid every time.

A confusing module used to be a one-time tax. A new teammate would hit it, scratch their head, figure it out, and move on. Painful once, then over.

When an AI agent does the work, that tax never stops. It gets paid on every run, by every agent, in money and in worse output, for as long as the module exists. The roughly 20 percent of your code that is needlessly hard to use is quietly driving most of your AI bill and most of your AI mistakes at the same time. Those aren't two problems. They're one problem showing up on two bills.

Where this goes next

You can't fix this by bolting a clever tool on top. If the foundation leaks all its complexity into every interaction, no amount of cleverness on top will save you. The foundation and the tooling have to be built for each other.

Publishing your shared code as clean, versioned packages is the first and biggest step, and it's the one I'd start with this week. The next article is about the rest: how to keep modules genuinely simple to use under real-world pressure, and how that foundation pairs with the right tooling to build a setup where low cost isn't something you chase, but simply how the thing works.

Deep modules were always the right call. The meter just made it the obvious one.

Sources & further reading

• John Ousterhout, A Philosophy of Software Design. The original case for deep vs. shallow modules.
• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (2023). The accuracy drop when key information is buried mid-text.
• Hong, Troynikov & Huber, "Context Rot: How Increasing Input Tokens Impacts LLM Performance," Chroma Technical Report (2025). The 18-model test.
• Anthropic, "Effective Context Engineering for AI Agents" (2025). On a model's limited attention budget.
• GitHub, "GitHub Copilot is moving to usage-based billing." Token-based billing live June 1, 2026.