Verification cost isn't a fixed property of the task though, it's the task multiplied by how much of the system you're currently holding. That same nine-line lock change is cheap to check the week you wrote the Outbox and expensive six months later, and every delegation quietly erodes the context that made checking cheap in the first place. Do you re-evaluate the posture per area as your familiarity decays, or does a module get classified once and stay there?
You've put your finger on the thing I hand-waved. It's not a property of the task — it's the task times how much of the system I'm still holding, and that second term decays. So no, a module doesn't get classified once; if it did, the label would be a lie within a couple of months, for exactly the reason you give.
What I under-said is that delegating in an area speeds up its own decay. The less I author there, the faster my model of it goes cold, so "cheap to verify" quietly rots into "expensive to verify" with no event marking the flip. And the re-evaluation only fires when I sit down to review and stall — the decay is invisible until it has already cost me.
So what I do now is treat that hesitation as the signal. When reviewing a change in some area feels harder than it should, I take back the next couple of changes there and drive them by hand to rewarm the context, then let the agent back in. Paying rent instead of trusting a deed. What I still don't have is a cheaper decay signal than "I already tried to review and couldn't" — if you've found one, that's the move I'd steal.
One candidate that fires before the stall: before handing a task off, try writing down the invariant the change must not break. Not the spec of the change, the thing that has to still be true after. If you can't produce it in a minute, the context has already gone cold, and it's cheap because you were writing the ask anyway. What I'd want to know is whether that catches the Outbox one, since you say you could specify that change down to the last detail, and specifying might decay slower than enumerating what mustn't break.
That's the move, and it beats the one I was hunting for, because it fires while I'm still writing the ask — zero extra cost. I tested it on the Outbox honestly. The invariant comes out fast: every enqueue ends in exactly one of {sent, still-queued, surfaced-as-failed}, never two sends, never a silent drop. And that sub-minute answer is itself the signal that I'm still warm there.
Where you're exactly right is the asymmetry. I can specify a change in a cold area by pattern-matching the diff, but I often can't say what must stay true — and that gap is the real tell, not the spec. The part I didn't see coming: the invariant keeps paying out after the handoff. Once written, it's the cheap thing I re-check against six months later, so producing it slows the decay instead of only detecting it. A pre-flight test that doubles as the flight recorder.
The thing I'd want from your side: when you hand the invariant to the model alongside the spec, does the delegated output actually come back safer — or does stating it just move the same verification cost earlier without shrinking it?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Verification cost isn't a fixed property of the task though, it's the task multiplied by how much of the system you're currently holding. That same nine-line lock change is cheap to check the week you wrote the Outbox and expensive six months later, and every delegation quietly erodes the context that made checking cheap in the first place. Do you re-evaluate the posture per area as your familiarity decays, or does a module get classified once and stay there?
You've put your finger on the thing I hand-waved. It's not a property of the task — it's the task times how much of the system I'm still holding, and that second term decays. So no, a module doesn't get classified once; if it did, the label would be a lie within a couple of months, for exactly the reason you give.
What I under-said is that delegating in an area speeds up its own decay. The less I author there, the faster my model of it goes cold, so "cheap to verify" quietly rots into "expensive to verify" with no event marking the flip. And the re-evaluation only fires when I sit down to review and stall — the decay is invisible until it has already cost me.
So what I do now is treat that hesitation as the signal. When reviewing a change in some area feels harder than it should, I take back the next couple of changes there and drive them by hand to rewarm the context, then let the agent back in. Paying rent instead of trusting a deed. What I still don't have is a cheaper decay signal than "I already tried to review and couldn't" — if you've found one, that's the move I'd steal.
One candidate that fires before the stall: before handing a task off, try writing down the invariant the change must not break. Not the spec of the change, the thing that has to still be true after. If you can't produce it in a minute, the context has already gone cold, and it's cheap because you were writing the ask anyway. What I'd want to know is whether that catches the Outbox one, since you say you could specify that change down to the last detail, and specifying might decay slower than enumerating what mustn't break.
That's the move, and it beats the one I was hunting for, because it fires while I'm still writing the ask — zero extra cost. I tested it on the Outbox honestly. The invariant comes out fast: every enqueue ends in exactly one of {sent, still-queued, surfaced-as-failed}, never two sends, never a silent drop. And that sub-minute answer is itself the signal that I'm still warm there.
Where you're exactly right is the asymmetry. I can specify a change in a cold area by pattern-matching the diff, but I often can't say what must stay true — and that gap is the real tell, not the spec. The part I didn't see coming: the invariant keeps paying out after the handoff. Once written, it's the cheap thing I re-check against six months later, so producing it slows the decay instead of only detecting it. A pre-flight test that doubles as the flight recorder.
The thing I'd want from your side: when you hand the invariant to the model alongside the spec, does the delegated output actually come back safer — or does stating it just move the same verification cost earlier without shrinking it?