Twelve Years of Commits to the Same Repo, Then One Day I Added an AI Teammate

The IIS-URLAuthorization script came first, and it never got a comment explaining why. iisreset, disable a module, move on, ship the ticket. That was 2026-05-22, and it was one of two setup commits, the other being a rules file for how the agent should behave, landing in the shared AI-rules directory. Twelve years earlier, the same repo’s early history is me doing the same kind of thing with no name for it: trial-and-error against a deploy hook until it stuck, no doc, no rule, just a commit message and the next day’s fix if it broke.

The repo is 34,161 commits deep. What’s different isn’t the code, it’s what sits next to it now.

The rule that predates the bug

Two days after the teammate setup commits, a ticket adds a rules file, describing how work phases should proceed, to the shared AI-rules directory and wires it into the project’s agent instructions and the /item skill. That’s a doc checked into source control, read by an agent before it touches a ticket. A day after that, another ticket does something similar for hotfixes: cherry-pick or recreate-resolution, never back-merge master, plus a URL pattern added to a rules file that governs URL conventions. Neither of those exists because a human forgot the rule once. They exist because an agent needs the rule stated somewhere it can read it fresh every session, since it has no memory of the conversation where we worked it out the first time.

That’s the actual mechanical difference from twelve years of human commit history. A human who breaks the “don’t back-merge master” convention learns it by breaking it once, feels bad, remembers. An agent that breaks it will break it again next session unless the rule is a file. So the rules started getting written down, not as documentation for onlookers, but as input to a process that runs without continuous human attention.

Where I tried the wrong fix first

The actual test of this came with the ticket for /sync, a script step, where I wanted it to fail loudly if a merge conflict came up during onboarding rather than silently skip a step. I wrote it, committed it, and moved on to the next task.

It got reverted the same day, the revert commit’s message just noting it was undoing /sync’s silent-fail behavior on merge conflict. The loud failure I’d written didn’t distinguish between a conflict that needed a human and a conflict the sync step could resolve itself by retrying against develop. It just stopped everything and threw an error string at whoever was running onboarding, agent or not, on cases that should have self-healed. I’d built the safety behavior without checking what fraction of conflicts it would actually catch versus just block. Cost was a full onboarding run failing on something that didn’t need to fail, and a revert commit sitting in the log as the record of it.

The fix that stuck was smaller: the rules file landed in the shared AI-rules directory the same day as the IIS script, and it’s a rules file, not a script. The distinction mattered. A script encodes one behavior and fails when the world doesn’t match its assumptions. A rules file states intent and lets whatever’s reading it, agent or person, apply judgment. /sync needed the second thing, not the first.

The review commit that isn’t a merge

A bug ticket dated 2026-05-20 covers a notification-preferences bug in the opt-in flow, and the commit message says “teammate review feedback on opt-in flow.” Not a code review from a person reading a diff. A review pass run as part of the ticket, folded into the same commit that fixes the bug, because the review step is now a stage in the pipeline rather than a separate person’s separate calendar slot.

None of this shows up as new architecture. The database schema, the branch model, hotfix-into-master-into-develop, all of it is the same shape it was a decade ago, and you can see it in the same stretch of history: a hotfix ticket gets a fix into one patch release, then the next, then reverted once when the merge order was wrong, then redone. What changed is that alongside the ticket commits there’s now a parallel stream of commits whose only purpose is making the next agent session start with the same context the last one ended with. Twelve years of commits taught me what the deploy hook needed. The rules files exist because the agent doesn’t get twelve years, it gets whatever’s checked into the shared AI-rules directory at the start of the session.

dxdev LESSON · paste into your AI coding agent
LESSON: Before A Script Fails Loud, Check How Many Cases Are Actually Self-Healing
SOURCE: dxdev.com/blog/2026-09-12_twelve-years-then-an-agent-showed-up
WHAT HAPPENED: The author wrote /sync to stop and throw an error whenever onboarding hit a merge conflict, replacing a silent-skip behavior, and committed it without checking what fraction of conflicts actually needed a human versus could resolve themselves by retrying against develop. It was reverted the same day, with the revert commit message noting it undid the silent-fail-to-loud-fail change. The cost was a full onboarding run failing on conflicts that didn't need to fail. The fix that stuck was different in kind, not just detail: instead of a script encoding one fixed behavior, the team landed a rules file in the shared AI-rules directory the same day as an unrelated IIS-URLAuthorization script, stating intent so that whatever reads it, agent or person, can apply judgment rather than hitting a hardcoded assertion.
THE RULE: Before hardcoding a failure condition into a script, check what fraction of the cases it will trigger on are actually unrecoverable versus self-healing; if the right response depends on judgment rather than one fixed behavior, that logic belongs in a rules document the agent or person can read and apply, not in a script that can only pass or fail.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Does this script's failure path treat every trigger case identically, even though some of them would resolve themselves if retried or left alone?
      2. Before shipping a change that makes something fail loudly, did you check what fraction of past occurrences would have been false positives under the new behavior?
      3. Is this a case where behavior varies by judgment call (belongs in a rules file an agent re-reads each session) or a case with one correct deterministic response (belongs in a script)?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.