In 5 weeks, a single-line instruction in a configuration file evolved into a multi-layered automated verification system.

This system was not designed from the start. Problems erupted every week, and the structure changed each time. In hindsight it looks like a clean evolution, but on the ground it was a relentless series of frustrations and trial-and-error.

This article is a record of the 5-week timeline. What went wrong each week, and what structural changes were introduced.

Week 1: The Age of Rules

It started simply. Natural language rules written in a single configuration file.

"Check the current state before modifying code." "Run tests before deploying." "Do not delete files without approval."

The first few days worked surprisingly well. The AI read the rules and followed them. "Maybe this is all you need?"

The problem was that this "it works" feeling was an illusion. The AI did not "understand" the rules — it followed them only because they were in the context for that session.

Week 2: Frustration

Rules started breaking. The same pattern every time.

The AI violates a rule. I point it out. The AI apologizes. "I will be more careful going forward." Then it repeats the exact same mistake on the next task.

More rules were added. 5 became 10, 10 became 18. The more rules there were, the harder it became for the AI to follow all of them simultaneously. Fixing one side broke the other.

The most frustrating part was that the same types of mistakes kept repeating in the same contexts. Modifying files without approval, overwriting code without checking current state, expanding scope to touch things that were never requested.

That is when the realization hit. Natural language rules alone cannot control AI behavior. The problem was not the number of rules, but the fundamental limitations of rules as a format.

Week 3: Structural Shift

The turning point began with one question. "Instead of educating the AI, what if we built a structure it cannot escape?"

Two things were introduced.

First, verification agents. The AI that writes code and the AI that verifies it were separated. When the same AI creates and reviews, it cannot catch its own mistakes. So a verification agent using a separate AI model was introduced. After code changes are complete, the verification agent is automatically triggered to check security, performance, scope deviation, and more.

Second, auto-triggers. Triggers that automatically load context at session start were created. Instead of the AI "remembering" rules, rules are structurally injected at session start. No reliance on memory means nothing can be forgotten.

After this shift, violation incidents decreased noticeably. They did not disappear entirely, but the pattern of "same type of mistake repeating" was decisively broken.

Week 4: Approval Model

Once Week 3's structure stabilized, a new problem emerged. If everything is automated, there is no way to stop incidents when they occur.

What verification agents catch is "code quality," not "should this be done right now?" Even if the AI writes technically perfect code, only a human can judge whether the work itself is needed at this moment.

So the approval model was introduced.

The traffic light system was also introduced during this period. A system that automatically checks "does this decision impose restrictions on the user?" for every product decision. Green means proceed, yellow means discuss, red means immediate redesign.

The principle "if the user is inconvenienced, it is not a product" was established during this period. A decision to never compromise user experience for implementation difficulty or scope expansion.

Week 5: System Complete

In the final week, everything came together.

18 rules compressed to 5 core principles. Week 2 taught us that too many rules are the problem. We reduced 18 to 5, but made each principle structurally enforceable.

Verification agents expanded to multi-layer. From a single code review agent to a 4-stage verification chain: plan review, code review, spec check, and deploy guard. Each agent uses a separate AI model.

Workflow skills introduced. Recurring work patterns were turned into reusable skills. Feature development, deployment, meetings, content creation — each received a standardized procedure.

In Week 1, there were 0 structural enforcements. By Week 5, a multi-layered automated verification system was operational. This change was not planned — it was the natural result of responding to problems that erupted each week.

Key Insights

The most important insight from 5 weeks of evolution is this.

Telling AI "do it this way" has limited effectiveness. AI apologizes well, writes great self-reflections, and makes the same mistake next time. This is not an AI defect — it is the limitation of natural language instructions.

Structural enforcement means creating a state where violating rules is systemically impossible, rather than the AI "trying to follow" the rules.

For example:

• Instead of "check current state" rule → a structure where the next step cannot proceed without current state verification results
• Instead of "verify the code" rule → a structure where a separate AI automatically verifies after code changes
• Instead of "run tests before deploying" rule → a structure where deployment is blocked unless automated tests pass

This principle applies to humans too, not just AI. The best rules are rules you do not need to try to follow. Because the structure enforces them.

This framework is still evolving. New problems will emerge in Week 6, Week 7, and the structure will change again each time. What matters is that the direction of change is always "stronger structure," not "more rules."