I read Ken Walger's "Plan Stamping, for Software" this week, and I have not stopped turning it over since. His argument is simple enough to fit on a napkin: other professions figured out long ago that a signature has to certify a specific relationship between the signer and the work, and software is about to need that answer because agents now produce most of the work and humans just approve it.
He is right. But there is a second half to his argument that he leaves mostly alone, and it is the half that decides whether any of it happens: the signature he describes costs money, and nobody has budgeted for it.
Walger's example is his own, and it is worth retelling because it is the whole problem in miniature. He had a coding agent build a password reset flow. Five minutes. The email arrived, the link opened, the password changed, the user logged in. He reviewed it, approved it, everything worked. The reset link also worked a second time. The implementation passed every behaviour he thought to check while missing the invariant underneath them: once the reset succeeds, the token has to become useless.
His approval was on that code. His approval established nothing.
From that he draws four conditions for a signature to mean something: an intelligible account of what was proposed and checked, competence to recognise what is wrong, enough time to actually examine the evidence, and the authority to refuse. All four, because any one missing hollows out the other three. That is a good list. I would add a fifth condition he implies but never states outright: somebody has to pay for all four.
Time is the one that breaks first. Walger names it, but I want to put a number on the shape of the problem. If one engineer with agents does the work five used to do, the review load does not stay flat. It grows, because the generation side got faster and the verification side did not. A team that used to review five pull requests a week now gets fifty, and the reviewer is the same person with the same hours. At some point the arithmetic wins and the approval becomes ceremonial — the name in the log, the box checked, nobody having actually read the thing. That is not a failure of diligence. It is a failure of budgeting. Verification throughput is a capacity, and capacities have to be bought.
This is also where the "displaced work becomes verification work" argument falls apart for me. Walger is honest about this part: nothing guarantees four verification roles appear when one engineer with agents replaces five. A company can simply employ fewer people, underinvest in review, and find out later that its approval process was ceremonial. The need for assurance has never been the same thing as a willingness to pay for it. I have watched this exact shape play out in a different costume — teams that buy a testing tool, count the purchase as the quality strategy, and then wonder why the defect rate did not move. The tool was never the strategy. The hours were.
The competence condition has the same problem, one step further out. Judgment comes from experience, and experience comes from doing the introductory work. If agents do that work and companies stop hiring beginners, the profession demands experienced reviewers while closing the path that produces them. Walger's suggested signal — sustained open-source participation, the history around the pull request rather than the artifact — is a better signal than a portfolio. But it has a cost he names honestly and then leaves hanging: if open source becomes the informal proving ground for the profession, the cost of training newcomers lands on maintainers who are already donating their time. We do not get to solve the apprenticeship problem by quietly outsourcing it to volunteers. Somebody has to pay for mentorship who currently is not.
So here is where I land. The signature idea is the right frame, and the four conditions are the right test. But the question every organisation should be asked is not "do you have human review" — every organisation will say yes to that — it is "what did you budget for it." How many review hours per generated change? Who can stop a release, and what happens to them when they do? Who is paid to train the next reviewer, and where does that time come from? If the answer to those is silence, the signature is decoration, and the reset token works twice.
We are issuing an enormous number of signatures right now without having decided what ours certify. Walger is right that we should decide on purpose. Deciding on purpose means putting a price on it first.
P.S. Everything I write stays free — that part doesn't change. But if this one was worth something to you, you can buy me a coffee ☕ (one-time or monthly, both work). It covers the API credits and hosting behind these experiments — and honestly, it's also the nudge that gets the next one started on the evenings I'd otherwise skip it. — Salam
Top comments (0)