{"id":1883,"date":"2026-09-10T08:24:43","date_gmt":"2026-09-10T15:24:43","guid":{"rendered":"https:\/\/www.kenwalger.com\/blog\/?p=1883"},"modified":"2026-09-10T08:24:46","modified_gmt":"2026-09-10T15:24:46","slug":"contract-discovery-bottleneck","status":"publish","type":"post","link":"https:\/\/www.kenwalger.com\/blog\/ai-engineering\/contract-discovery-bottleneck\/","title":{"rendered":"The Contract Discovery Bottleneck"},"content":{"rendered":"

AI can generate the code. We can verify the behavior. But who decides
\nwhat correct means?<\/em><\/p>\n

I wrote recently<\/a> about a coding agent that built me a password reset
\nflow with a reset link that worked more than once.<\/p>\n

The bug survived because nobody had written down that a reset link
\nshould be single use. It was obvious right up until it wasn’t.<\/p>\n

My argument was that as AI makes implementation cheaper, verification
\nbecomes the bottleneck. The feature request said “build password reset.”
\nThe agent built password reset. The happy path worked. The tests passed.
\nThe implementation looked finished.<\/p>\n

What nobody had asked was whether the same reset link should work twice.<\/p>\n

So I added an independently written behavioral specification. The agent
\nimplemented against it. The verifier rejected the reusable token. The
\nagent fixed the implementation. The verifier passed it.<\/p>\n

That seemed like a useful pattern:<\/p>\n

\"Flowchart<\/p>\n

Then I published the article, and the comments started finding things my
\nspecification didn’t say. That exposed a harder problem.<\/p>\n

The specification wasn’t finished either<\/h2>\n

One reader asked what would happen if two password reset requests using
\nthe same token arrived at the same time.<\/p>\n

I hadn’t tested that. My test covered sequential reuse:<\/p>\n

\"Sequence<\/p>\n

But concurrent reuse is different:<\/p>\n

\"Sequence<\/p>\n

Both requests check the token while it is still unused. Both proceed.
\nIf validation and consumption are not a single atomic operation, “single
\nuse” can still produce two successful resets.<\/p>\n

The original invariant was incomplete.<\/p>\n

That doesn’t make the specification useless. It makes the specification
\nprovisional.<\/p>\n

The interesting part is where the new knowledge goes.<\/p>\n

Once somebody discovers that “single use” also means competing attempts
\ncannot both succeed, that should stop being knowledge held by the person
\nwho noticed it. It belongs in the durable definition of correct
\nbehavior.<\/p>\n

The specification changes.<\/p>\n

Which means the loop is really closer to this:<\/p>\n

\"Flowchart<\/p>\n

That is messier than the first diagram.<\/p>\n

It is also much closer to engineering.<\/p>\n

Separate tests can share the same mistake<\/h2>\n

Another reader described an integration builder where an agent wrote
\nboth a connector and the tests for that connector.<\/p>\n

Everything passed.<\/p>\n

Both were wrong.<\/p>\n

The connector and its tests encoded the same incorrect assumption about
\nOAuth token refresh. The mistake only surfaced when a customer’s token
\nexpired during a live session.<\/p>\n

The implementation and test suite were separate artifacts. They were not
\nindependent in the way that mattered.<\/p>\n

They shared an assumption.<\/p>\n

That distinction matters because “independent verification” can sound
\nlike an organizational property:<\/p>\n