AI writes code, architecture and tests keep it sane

Don’t you think that, with AI, we are learning once again that code alone -regardless of its quality - provides very limited safety and control over application quality?

You can use the best techniques and design patterns, and even force your AI assistants to follow them. However, if you focus only on production code, you are drifting toward a system that is difficult to maintain and evolve - and you will feel that pain faster than ever.

Why does this happen? Because it is extremely difficult to maintain high software quality when the only source of guidance is the code itself.

That is why many engineers will need not only to learn how to use AI agents, but also to revisit - or learn from scratch - why well-defined boundaries matter and what makes tests truly valuable.

The boundaries that keep you in the right context

Well-designed boundaries in your software do more than support evolution. They keep relevant knowledge contained, establish clear APIs for communication, and isolate everything that does not belong. As a result, they reduce the risk of hallucinations and make AI responses faster and more cost-effective.

Why is that?

• Smaller context – Whether a task sits within a single boundary or spans several, clear modularization allows you to specify what is relevant. As a result, the agent processes only a subset of the system instead of everything.
• Better information – Well-defined boundaries ensure that the knowledge inside them is consistent, unambiguous, and cohesive. This significantly reduces noise from irrelevant details and minimizes the risk of hallucinations.
• Easier validation – When the API within a boundary is explicit, it becomes much easier to verify whether new code belongs there and whether it fulfills the requirements.

The tests that keep you safe

Boundaries improve context and understanding - both for the agent and for you. High-quality tests, on the other hand, validate whether the system behaves as expected.

Regardless of the testing approach (TDD, test-first, or test-after), if you focus on verifying behavior rather than implementation details, you create a safety net. This reduces the risk that the agent generates code that only appears correct.

Additionally, when existing functionality is covered in this way, you gain confidence that previously implemented behavior remains intact - even as AI assists with changes.

Presence doesn’t mean quality

Having boundaries and tests does not automatically mean you are in a good situation. When they are missing, the problem is obvious - but their mere presence does not guarantee value.

You may have boundaries that reflect neither the problem space nor the solution space - they may be nothing more than named directories. In such cases, you might be in an even worse position than if you had no boundaries at all. Many will assume those names carry meaning when they do not, while the vocabulary inside remains poorly cohesive and tightly coupled with other parts of the system.

On the other hand, you may achieve high test coverage while your tests focus purely on implementation details and rely heavily on mocks. In that case, every code change - even when behavior remains the same - forces changes in tests. This is the moment when passing tests stop providing real confidence. They exist only for the sake of coverage, not for safety or quality.

Both scenarios - poor boundaries and weak tests - lead to situations where you pay the full cost of these practices but receive none of the expected value.

If you find yourself in such a situation, remember: the problem is not modularization or testing itself, but how these practices are implemented in your project.

Summary

Architectural boundaries guide implementation, while tests give you control over what has been built.

You not only know that code resides in the right place and uses the correct language, but you also know that new functionality satisfies new requirements - and does not break anything that previously worked.

AI can accelerate code creation, but only architecture and tests give you control over what you are actually building.