Main idea

How do we write an API in this team? How do we handle errors? How do we write an async job? How do we test a call to an external service? As long as these answers stay implicit, they get reconstructed every time — and a coding assistant, which has no reason to prefer the local convention to any other, proposes a different one for each feature.

The result isn't a quality defect feature by feature: each solution can be correct in isolation. The result is a team maintaining several architectures inside a single product, with no decision having acknowledged that plurality.

What is missing is a catalogue of sanctioned patterns, decided by the team and written down. Decided, because an inventory of what the code already contains merely ratifies the dispersion; written, because an unstated convention transmits neither to a newcomer nor to a tool.

Why it matters

This shifts the target of the effort toward homogeneity: case-by-case review can't keep up with a generation throughput, whereas an upstream reference can.

It also reveals a cost the acceleration hides. Slowness imposed a de facto homogeneity — reinventing every time was too expensive, so you copied the module next door. That brake falls away when producing costs nothing, and nothing replaces it until the convention has become a decision.

Nuances and limits

An overstuffed catalogue becomes a handicap: it freezes choices the context should be able to reopen, and it ends up ignored because nobody keeps it current. Its value lies in the short list of recurring questions, not in exhaustiveness.

And homogeneity isn't an end in itself. On an exploratory scope, letting several ways of doing things coexist for a while is a legitimate way to compare them — provided the choice is then settled and written down.

Open questions

• Who arbitrates a new pattern's entry into the catalogue, and by what signal does a team recognize that an existing entry has stopped being suitable?