The cost of being noticed

We live in a small golden age for finding security bugs. Models are good enough now that a scanner can read a transitive dependency three layers deep and tell you, with reasonable confidence, that a function nobody has called in four years could in theory be coaxed into doing something bad.

This is, genuinely, great. It’s the kind of thing I would have wanted as a junior engineer staring at a package-lock.json and praying.

It is also, somehow, exhausting.

The inbox problem

I have repos I haven’t touched in years. A weekend hackathon. A class project. A tool I built to solve one problem on one Tuesday in 2021 and then forgot. None of these are running anywhere. None of them have users. Some of them don’t even build anymore, on purpose — the Node version is gone, the API they wrapped is dead, the world has moved.

GitHub does not care.

Every few days my inbox lights up with another Dependabot alert. Critical severity in a transitive dep of a thing you haven’t opened since the previous decade. And every time, I have to make the same little decision: do I go bump the lockfile, or do I admit defeat and archive the repo?

Thankfully, dependabot makes a PR for you, so the cost of bumping the lockfile is just a click and a merge. But it’s still annoying to be notified on what is effectively a ghost project. I did a culling of my projects. Archived a lot of them. Bumped and archived others. But some are still sort of alive, sort of active, and they still get the alerts. It’s like having a mailbox that only delivers bills and junk mail, but you can’t unsubscribe.

The asymmetry

The thing that wears on you is the asymmetry. The cost of generating the alert is approaching zero — a model reads the graph, flags the CVE, opens the PR. The cost of resolving it is the same as it ever was: a human, a checkout, a build, a vibe check, a merge.

So the rate of alerts goes up and the rate of resolutions doesn’t. The queue grows. The queue is always going to grow.

This isn’t anyone’s fault, exactly. The scanner is doing its job. The maintainer of the dependency is doing their job. GitHub is doing what users (correctly) asked it to do. It’s just that the economics of attention have quietly inverted, and nobody printed new instructions.

The archive button

There’s a specific kind of relief in archiving a repo. It says: this thing existed, it had its moment, and I am not pretending I’m going to maintain it. It’s honest. It’s also a small grief. You’re admitting that the version of you who wrote the thing isn’t coming back to it.

I’ve started doing it more freely. If I look at an alert and my first thought is “ugh, not this one again,” that’s the signal. The repo doesn’t owe me anything. I don’t owe it anything either. Click. Done. Quiet.

The ones that survive are the ones I’d actually defend in a meeting. Everything else gets to rest.

The bit I’m still figuring out

What I haven’t worked out is the middle case — the small project that does still run, that one or two people use, that I half-care about. Those are the ones the scanner is most useful for, and also the ones where the maintenance tax compounds the fastest. Each alert is a small ask: are you still here? Are you still the person who handles this?

Sometimes the answer is yes. More often, lately, the honest answer is not really, but I’m not ready to say so out loud.

I think the future shape of this is something like: AI finds the bugs, AI proposes the fix, AI runs the tests, and a human signs off in ten seconds — or doesn’t, and the project quietly enters a cared-for-but-frozen state instead of a guilt-ridden one. We’re not there yet. We’re at the awkward middle, where the discovery is automated and the resolution still wants my whole afternoon.

Until then: the archive button is right there, and I am learning to use it without ceremony.