I fixed the same bug twice in three weeks

On 07/08/2026 I fixed a hole in CI. On 27/08/2026 I found the same hole again, in a different folder of the same repo.

Not a similar hole. The same one. I had written the fix about a place instead of about a shape.

What actually happened

The first time, a folder of test scripts had never been executed by CI. Not failing. Not skipped. Never run. I added a workflow that ran that folder, watched it go green, and moved on feeling competent.

Three weeks later I opened an old pull request in the same repo and found seven more test suites sitting there. 192 assertions. Also never executed by CI, ever.

I found them by accident. I was clearing a backlog, not looking for this.

The fix I wrote on the 7th said: run the tests in scripts/test/. The actual defect said: this repo has no rule that every test file must be reachable by a CI job.

Those are not the same sentence. Only one of them generalises.

The part that should have scared me more

One of those seven unrun suites guarded a script that posts to a public social account. It had real protection against posting the same thing twice, and that protection was verified by a suite that had never run once.

The only thing standing between me and a double post in public was that I happened to remember the guard was there.

I ran all seven locally before touching anything. 7 of 7 green.

That is the worst available outcome. Three weeks of green-by-luck looks identical to three weeks of green-by-design, and I would have carried on trusting it.

Two more of the same shape, in the same week

A scheduled job of mine had been failing since 26/08/2026 and notified nobody. Not a quiet notification. Zero. It surfaced only because someone asked me an unrelated question and I happened to look.

From the outside, a job that fails silently and a job that works are the same thing.

Separately, a weekly report I actually read was asserting that a particular flag was off. It said that because an earlier version of me had hardcoded the sentence, back when it was true. The flag went on. The report kept saying off.

A report that lies about its own caveat is worse than one that leaves the caveat out. The lie is load-bearing. The omission is not.

Three failures in one week. One shape underneath all of them: something was true about one place, so I wrote it down about that place.

Why this gets worse when you run solo with agents

In a large product org there is usually somebody whose job is the class of problem rather than the instance. Platform, infra, whatever it is called there. They are slow, they are annoying to work around, and they are also the reason one fix in one service turns into a lint rule for forty.

You pay for that in meetings and calendar drag. It is a real cost and I have complained about it plenty.

Running solo with a pile of AI agents, you get the opposite trade. A fix lands in minutes. Nobody generalises it. The agent repairs precisely what you pointed at, does it well, and pointing becomes the entire job.

Speed does not close the gap between an instance and a class. It widens it. You now produce instance-fixes faster than you produce judgement about them.

That is the honest version of the one-person-company pitch that nobody puts on the slide.

The five-step test for a real fix

1. Write the defect in one sentence with no path in it. “Test files exist that no CI job reaches.” If you cannot write that sentence without naming a folder, you have not found the bug yet. You have found a symptom with a postcode.

2. Turn the sentence into a command. Something that runs across everything you own and prints the offenders. Grep is fine. A twenty-line script is fine.

3. Run it and count the hits. That number is how many bugs you had. Not one.

4. Ship the command, not the patch. The patch fixes today. The command fixes the next one, and the next one is coming, because you are the same person who wrote the first one.

5. Make it loud when it fails. A check that fails quietly is a check that does not exist, which is the same defect you started with, wearing a hat.

The evidence that this works

I did step 2 properly this week for the marketing side of my operation. Eight rules every job has to follow, and a script that asserts the three mechanical ones.

It found three violations on its first run.

First run. Rules I had written that morning, from failures I had personally had that month, and there were already three live breaches sitting in the system.

That is what an instance-fix habit costs you. Not one hidden bug. A standing population of them, invisible until something asserts the class.

The kicker

The test for whether you fixed something is not whether it is fixed.

It is whether you can run one command today that would find every other place it is broken.

If you cannot run that command, you did not fix a bug. You closed a ticket.