Tips to Structure Codebases for AI Agents in 2026

Code in 2026 has become a commodity.

Anthropic claims that 80% of its new code comes from agentic AI, and then announced Claude Fable 5. OpenAI recently evaluated an internal beta product with zero lines of manually-written code. In a world where creating new code is inexpensive, the challenge shifts towards maintainability.

A consistent project structure helps both the agent and the development team to validate and navigate change.

So the question remains: how to increase codebases in a way that they can be reused and expanded?

If we look at critical points on large codebases management, there are some static aspects (project structure) and dynamic ones (how it should evolve).

1. Follow good design patterns: SOLID, DRY and integration patterns.
2. Maintain a solid testing foundation: TDD.
3. Define your specific repository structure: business logic, test, infrastructure. They should all have their own location.
4. Integrate existing tooling: reuse testing frameworks and CI/CD tools.

Agent behaviour is part of the project dimensions. Do you want to buy or build? Your agent should be aware of this.

Since we will be interacting with agents, there are also some behavioural aspects related to our codebase. Some examples:

1. Reuse vs build: instruct your agent to reuse as much as possible from GitHub instead of creating new code. See an example in the next section.
2. Do not change tests unless clearly justified.
3. Aim for simplicity: things like aiming for immutable data structures and avoiding certain features (in my case, TypeScript generics).

A TypeScript-based example

It’s 2026, and we find ourselves collaborating with AI agents. The best way to gather good patterns is to define them as part of a CODING.md file.

The following are some examples of how to be prescriptive in modern TypeScript projects.

1. Set coding rules

Always use TypeScript instead of JavaScript and follow object-oriented principles. I initially wrote a bullet-point list, but Claude quickly expanded it with additional descriptions. Notice the reference to primitive data types, immutability and DRY principles:

2. Reuse instead of adding code

Agents are prone to creating code by default. We can mitigate that by aiming for reusability.

I explicitly instruct the agent to check npm first, along with the associated GitHub repository, and set a trust threshold of 100 stars.

3. Well-defined project structure

This is a more traditional aspect. The codebase should follow a clear structure, such as domain, infrastructure, shared, and test layers.

4. Leverage good practices: design patterns

I include a section describing the well-established software design patterns. This makes reviewing agent-generated changes more predictable and efficient in the future.

5. Provide personal preferences explicitly

I maintain an Avoid section in the CODING.md file to avoid certain features. While this is a personal choice, it helps enforce consistency.

In my case, I don’t want to deal with class inheritance or generics in TypeScript (!).

Conclusion

With minimal effort invested in defining codebase rules, we can significantly reduce time spent on code reviews, ad hoc “vibe coding,” and rollbacks.

You can review the example file used in this article here: CODING.md