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
One developer’s 48-day account found that expanding always-on agent instructions from 90KB to 147KB did not reduce the violations they tracked. The author then moved eight repeatedly violated rules into code gates and recorded no further recurrences for those rules. That is a useful workflow case study, not proof that long instruction files fail or that code checks will work for every team.
What happened over the 48 days
In an English translation of a 2026 Zenn article, developer untactit describes tracking one machine and one operator for 48 days. The author reports that always-on instruction files grew from 90KB to 147KB while the count of flagged violations did not decline. The author’s measure counted clauses a human noticed and flagged as broken; it was not a measured rate of all agent violations. As the author puts it, “Even after increasing instruction files from 90KB to 147KB, violations did not decrease.” Read the English-translated account.
The author tracked 24 rules. Eight were moved into code gates; the other 16 remained document-only. The author reports zero counted recurrences for the eight gated rules and recurrences among the 16 left in documentation. The groups were not randomly assigned or shown to be comparable, so this is an observed difference in one workflow—not evidence that code gates alone caused it.
Free tools Windows power users keep installed
One-click scans. No signup required.
The author’s three-stage rule lifecycle
- First violation: record it. Treat the incident as evidence of a possible instruction gap, not an automatic reason to add a permanent rule.
- Second violation: document the clause, but keep the active reminder focused. The author surfaced only the three most recent frequent violations at the start of each turn rather than continually expanding the prominent instructions.
- Third violation: consider a code gate. When a documented rule was broken again, the author stopped relying on documentation alone, built a check, and tested it against deliberately broken input.
This sequence is the author’s proposed response to repeated violations. It is not a validated threshold: a team may choose a different point based on the cost of mistakes, the effort to build a check, and how often the behavior matters.
#1 Best Overall
When a rule can become a useful code gate
A gate is most plausible when the desired behavior leaves an artifact a check can inspect: a diff, file, command result, test outcome, or other repository state. For example, a rule against changing unrelated files might be checked against a defined set of allowed paths. By contrast, advice that depends on intent, judgment, or context may not have a reliable mechanical test; it may belong in documentation or review guidance.
Before implementing a gate, assess the rule on five dimensions:
- Observability: Does the behavior produce an artifact the check can examine?
- Detection: Does the check catch deliberately introduced violations, including relevant edge cases?
- Error costs: What happens if it rejects acceptable work (a false positive) or permits a violation (a false negative)?
- Maintenance: Will the check remain accurate as repository conventions and tooling change?
- Evidence: Is the rule a repeated problem in your own workflow, or are you extrapolating from another team’s experience?
Test both sides: feed the gate deliberately broken input to see whether it detects the violation, and feed it acceptable changes to find false positives. The author says gate accuracy had not been measured in the reported experience and recounts a 66% false-positive rate on one sample of a regression judge. That single sample is not a general estimate, but it illustrates why a check should be validated before being trusted.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallWhat other studies do—and do not—establish
A controlled study of persistent rule files
A 2026 study by Zhang, Wang, Cui, Qiu, Li, Zhu, and He examined persistent rule files using Claude Code with Claude Opus 4.6 on SWE-bench Verified. Its corpus contained 679 instruction files and 25,532 rules, and its evaluation involved more than 5,000 agent runs. In that benchmark and setup, the authors report that rule-file conditions improved performance; their ablation found negative constraints individually beneficial while positive directives could hurt. They also report no degradation up to 50 rules under the tested conditions. These findings do not replicate untactit’s code-gate workflow, and the study cautions that it is limited to one vendor, model, and benchmark. See the study and its scope.
A study of instruction-file structure
A separate 2026 study by Damon McMillan analyzed 1,650 Claude Code CLI sessions and 16,050 function-level observations. After correcting for multiple testing, it found no detectable contrasts for the tested structural variables, including file size and instruction position. It reported an association between session progression and declining odds of compliance in the tested conditions, but described that relationship as non-monotonic. The study did not test code gates or untactit’s workflow, so it cannot explain the 48-day result. Read the study’s methods and findings.
Together, these studies caution against treating file length as a simple cause of noncompliance. They also do not show that adding rules always helps, that negative rules should always dominate, or that code gates are generally superior. The results depend on what was tested, with which model, benchmark, and workflow.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to apply the case study without overgeneralizing
- Keep documentation for context, intent, and guidance that cannot be checked reliably.
- For a repeated, consequential, observable violation, consider a small gate rather than adding another instruction alone.
- Validate the gate with both deliberately broken and acceptable examples; track missed violations and false alarms.
- Review the check as the codebase changes, since a once-accurate rule can become stale.
- Track your own cases consistently. A count of flagged incidents is useful for workflow decisions, but it is not a complete violation rate when unnoticed incidents go uncounted.
Untactit explicitly notes that the experience was n=1, that unflagged violations were missed, and that “The actual violation rate should be higher than this.” The report is therefore best read as a practical hypothesis: repeated failures may call for an enforceable check when the behavior is observable, but the check itself must earn trust through testing.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Quick Recap
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.
