𝗚𝗶𝘃𝗲 𝗬𝗼𝘂𝗿 𝗖𝗼𝗱𝗲𝗯𝗮𝘀𝗲 𝗮 𝗖𝗼𝗻𝘀𝘁𝗶𝘁𝘂𝘁𝗶𝗼𝗻

Architecture in people's heads does not survive coding agents.

For years, codebase rules lived as tribal knowledge. Senior engineers knew which layers could talk to each other. They knew which dependencies were forbidden. New engineers learned by breaking things and getting corrected in reviews.

This works for humans because humans build context over time. Agents do not build context. They only know what they can see.

If a rule is not written down, an agent thinks the rule does not exist. I have seen agents wire inner layers to outer layers. They introduce dependencies we specifically avoided. The code works, but the architecture drifts.

You must turn your architecture from folklore into law.

A constitution is not documentation. Documentation explains how a system works today. A constitution defines what a system is allowed to become.

Your constitution should focus on things that survive a major refactor. It should include:

  • The laws and invariants
  • System boundaries
  • Foundational assumptions

The best constitutions are short, restrictive, and slow to change.

Do not tie architecture to directory structures. Directories change. Tie architecture to responsibilities. A domain model is still a domain model regardless of its folder.

Every law needs a reason. A rule without a rationale gets deleted by someone who does not understand it. The rule teaches behavior. The reason teaches judgment.

Most importantly, you must enforce your laws.

Instructions are guidance. Enforcement is reality. An agent or a human will eventually ignore a written instruction.

If a rule is critical, do not rely on prose. Put it in your CI. Put it in a linter. Put it in a validator.

Every important rule needs two forms:

  • The human version: This explains the intent.
  • The machine version: This guarantees compliance.

This is not about adding process. It is about adding leverage. When architecture is enforceable, you do not need to inspect every decision. The machine does it for you.

You can delegate more work when you can trust the boundaries.

How to start:

Pay attention to your reviews. Every time you say "we do not do that because," you have found a law.

Start with a few rules:

  • Dependency direction
  • Secret handling
  • Critical contracts
  • Boundary ownership

Écrivez la règle. Écrivez la raison. Ajoutez ensuite le contrôle de code qui la rend impossible à enfreindre.

Une loi sans application n'est qu'une suggestion.

Source : https://dev.to/miteshethos/give-your-codebase-a-constitution-3k4h

Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi