Today I burned through half of my weekly token budget digging into a project that was already release-ready. I found bugs no one would have found. I fixed configs that were already working. By the evening, the project was better. Whether it had become more necessary is another question.
What changed mechanically is that the cost of entry into a task dropped almost to zero. Entry used to be a filter. Before starting anything, you would ask yourself: is this really worth investing two months into? Most of the time, the answer was no, and you went off to do something else. The difficulty of getting started did prioritization for you — most ideas got filtered out simply because you physically could not do everything.
Now the filter is gone. You formulate an idea, and the neural net is already building it. The step of asking "is this worth doing?" is no longer required, so most of the time it never happens.
But only the cost of starting fell to zero. The cost of finishing, maintaining, and even understanding what you actually built did not change. The curve split apart: entry became nearly free, while the tail stayed just as expensive. You get pulled in at the price of entry, but you pay at the price of the tail. The brain was calibrated for the old ratio, and the new one feels like a pit.
This is a trap, not a gift, and it works the same way reels do.
A short reward loop. Prompt — result — satisfaction. Press a button, get dopamine. Social media hacked the long reward cycle by training the brain to expect quick hits. Neural nets do the same thing, but with one important difference: what the loop produces looks intelligent.
Watching reels for eight hours is embarrassing. "I was working, look how much I got done" is not. That is why drifting with neural nets is harder to recognize in yourself, not easier. It disguises itself as productivity, and from the outside it is indistinguishable from it.
It is important not to collapse two different things into one. Going deep into details can be deliberate — you choose to go deeper, you know what it costs, and you pay that cost consciously. That is normal engineering work.
And then there is drifting — when the deepening happens by inertia, driven by the reward loop, without any act of choice. You did not decide to take one more step. It just happened, because the price was zero.
The difference is whether there was a decision. In the first case, you said yes. In the second, you did not say anything at all — you were simply carried along. From the outside, it looks the same. From the inside, it is a completely different thing.
Now comes the part that has to be said out loud, otherwise the whole article is pointless.
I know I should stop. I do not stop. Which means the problem is not knowledge. Advice like "prioritize better" does not work — I have already given myself that advice, and even now, while writing this text, I know that tomorrow I will sit down again and get buried in it again.
That matters, because most anti-spiral advice is aimed at awareness. "Become aware of what you are doing." I am aware. It does not help. Awareness and execution are different layers, and in this case the first does not control the second.
If the natural filter is gone and the internal one is not enough, the only option left is to restore the cost of entry artificially. These are crutches, but crutches are a perfectly reasonable response to a structural asymmetry.
There are roughly four things that work for me, and they are all really the same thing: putting the decision back where it disappeared. The most important one is a definition of done written before the task starts, not after. If I define in advance what "done" means, it becomes harder to renegotiate with myself in the middle; if I do not, "done" keeps sliding away forever, one more bug at a time. Then there are external limits instead of internal ones: a timebox, a token budget, "I work until lunch and then close the laptop." The brain respects walls more than intentions. Then there is a closing ritual, with no permission for "I'll just fix one bug"; one bug reliably turns into five hours, like a law of physics. And separately, there is a wishlist where everything of the form "we could also…" goes, instead of being implemented immediately. A week later, it usually turns out that most items on that list were not needed by anyone, including me.
None of this is new. All of it existed before.
And the main reason, I think, why this is worth writing about at all.
The scarce resource used to be the ability to build. To know the technology, to hold the system in your head, to carry something through to completion — all of that was expensive, and therefore valuable. A senior differed from a junior by the simple fact that they could.
Now everyone can. Projects that just three years ago would have been serious multi-month work — writing your own parser, an interpreter for a small language, a non-trivial CLI tool — can now be done in an evening. Not because it is a good idea, but because nothing is stopping you. And the scarce resource becomes the opposite: the ability not to build, even when you can. To choose what not to spend time on. To distinguish "interesting" from "necessary." To close a task at "it works," not at "it is perfect."
A senior used to be someone who could. A senior now is someone who can, but chooses not to. Saying no becomes a professional skill, not a sign of laziness or burnout. And it seems that this is a skill we will have to train separately — it does not arrive together with the technical ones.
And that project I started with — I did eventually close it. Not that day, of course. The next one. I left half the bugs I had found unfixed and told myself those were not my bugs today. It was unpleasant. But there were still tokens left for the week.
Comments