𝗚𝗶𝘃𝗲 𝗬𝗼𝘂𝗿 𝗖𝗼𝗱𝗲𝗯𝗮𝘀𝗲 𝗮 𝗖𝗼𝗻𝘀𝘁𝗶𝘁𝘂𝘁𝗶𝗼𝗻
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
규칙을 작성하세요. 이유를 작성하세요. 그런 다음, 규칙을 어기는 것이 불가능하도록 만드는 코드 체크를 추가하세요.
집행력이 없는 법은 그저 권고 사항일 뿐입니다.
출처: https://dev.to/miteshethos/give-your-codebase-a-constitution-3k4h
선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi