Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For AI-assisted software work, Derek Wang’s practical recommendation is to put durable project rules in files the coding model is told to read before generating code—not to rely on chat prompts alone. He proposes connecting those rules to architecture decisions, delivery contracts, and checks that actually run. Files can make constraints easier to carry between sessions, but they do not guarantee that a model will follow them.
Why put project rules in files?
A chat instruction can guide the current exchange, but it may not be available in a later generation. A project file offers a persistent place to explain the purpose of the software, its module boundaries, and its naming conventions. The team must still ensure the model reads the file and that the rules remain accurate.
Wang captures his argument in the line, “A prompt is a memory, not an architecture.” It is an engineering thesis about where durable constraints belong, not proof that file-based instructions work better in every project.
How the constraint pyramid is meant to work
Wang’s framework has five connected layers. The idea is to carry project intent down to implementation, while feeding lessons from implementation back into the rules and checks.
| Layer | What it records | Example form |
|---|---|---|
| Strategy | The project’s purpose and governing principles | README or constitution |
| Architecture | Accepted decisions about system structure and boundaries | Accepted architecture decision records (ADRs) |
| Contracts | What a task or operational procedure must specify | Specification and runbook |
| Gates | Checks that can reject work that breaks enforceable rules | Pre-submit checks |
| Implementation | The model’s code, constrained by the layers above | Generated output |
The layers are useful only when they connect. A rule in a README that has no corresponding check is guidance, not enforcement. An architecture record that is never related back to the implementation can become an archive of decisions rather than a way to govern current work.
Which rules should be enforced, documented, or suggested?
Wang also groups constraints by strength. This is his framework, not a universal industry standard; its value is making clear how a team expects each rule to be followed.
| Level | Meaning | Where it belongs |
|---|---|---|
| L1: hard constraints | Rules the project intends to enforce automatically | Code and gates |
| L2: architecture constraints | Decisions that shape system structure and boundaries | Accepted ADRs and file layout |
| L3: execution suggestions | Recommended ways to carry out work, without automatic enforcement | Runbook steps, skills, or checklists |
Labeling a rule helps prevent a suggestion from being mistaken for a hard requirement—or a hard requirement from being left as prose. If a rule must never be broken, represent it in a check where practical rather than depending only on the model to interpret the wording.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesHow to introduce the approach in a project
- Create a short file the model will read before each generation. Start with the project’s purpose, module boundaries, and naming rules. Put it somewhere the team can reliably include in the coding workflow.
- Mark each rule’s strength. Identify hard constraints, architecture decisions, and suggestions so contributors and the model can distinguish their status.
- Connect rules to implementation. Where a requirement can be checked automatically, add it to a pre-submit gate. Keep architecture records tied to the code and layout they describe.
- Review recurring deviations. Wang suggests treating repeated violations as diagnostic signals: a suggestion may need to become a gate, a contract may be missing a step, or an architectural boundary may need reconsideration.
- Update the files as the project changes. Remove or revise instructions that no longer match the implementation, and adjust checks when the intended rule changes.
What the reported 636-line example does—and does not—show
In his September 16, 2026 DEV Community essay, Wang says a README in one project grew to 636 lines as it accumulated boundaries, path conventions, naming, and layering rules. He reports that after the model read the file before each generation, weekly style drift “nearly vanished.” This is an author-reported project anecdote. The essay provides no study design, sample size, independent measurement, or comparison group, so the figure and outcome do not establish a general effect.
Rank #3
Where the approach can fail
- Rules are not loaded: A file cannot guide a generation if the workflow does not make the model read it.
- Documentation drifts: Instructions can stop matching the code as architecture and conventions change.
- Gates do not run: A check that is skipped or absent cannot enforce its rule; as Wang puts it, a gate that never executes is only a wish.
- Architecture records lose their connection to code: ADRs need to be mapped back to the implementation or they risk becoming a diary.
- Advice is mistaken for enforcement: Prose can guide behavior, but it cannot substitute for an automated check when a rule must be reliably enforced.
The practical test is not whether a project has a large instruction file. It is whether the right rules are available at generation time, whether enforceable constraints are checked, and whether the records stay aligned with the code.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
