Plus le projet grossit, plus l’IA se trompe: le bounded context comme investissement

Summary

Teams that bring Kiro, Claude Code or GitHub Copilot to a green-field project often enjoy the same honeymoon, then watch the wow factor fade sprint after sprint. I argue that the model is not to blame: the context it has to hold grows with the project, and published research shows that, with the same model, accuracy drops as the context gets longer. Without boundaries, that context is paid for on every request: in tokens, review time, regressions and repeated explanations. The article sets out Context Budget, the method I have introduced on several projects. The budget is the number of tokens the AI consumes on each request: it is exceeded as soon as the AI has to absorb more context, data or business rules than the task needs. The method rests on five practices: one living specification per bounded context; an assessment of the project’s trajectory on a fixed schedule, with the architect, the product owner or the business analyst, and the team; boundaries prepared from day one with interfaces, adapters and the C4 model; one context per domain; and a refactoring owned by the team: the boundaries are drawn with the architect in Event Storming workshops, then the team builds them into the code, with support from the architect or the tech lead. A fictional example walks through the split: billing leaves Orders and becomes its own bounded context. With the complete method, I have seen the time to develop an API, end-to-end tests included, drop from 3.5 days to 3 hours.

Key ideas

• It is not the model that weakens, it is the context that grows. Studies on long contexts agree: with the same model, accuracy drops as the context gets longer, and a larger window lets in more context without guaranteeing that it is used any better.
• On a project that grew without boundaries, every request rereads the world. The cost never shows up on a budget line: it is spread across every request from every developer, every day, and it grows with the project.
• In Domain-Driven Design, a bounded context is a part of a large system with its own unified model; it is also a context the AI can hold in full. Hence the name Context Budget: the budget is exceeded as soon as a task makes the AI absorb more context, data or business rules than the task needs. Every bounded context must fit within that budget, and the AI sees neighbouring contexts only through their contracts.
• To pay for the split only once, you have to prepare for it. With interfaces, adapters and the C4 model from day one, a component can become a container, then a system, without rewriting the code that calls it: the split is a move, not a rewrite.
• The project’s trajectory is assessed on a fixed schedule, not when symptoms appear. Between two assessments, a few warning signs justify bringing the next one forward.

Why I wrote this