GPT-5.4 Pro solved an open math problem this week. Not a textbook exercise, not a competition trick — an actual open problem in Ramsey theory on hypergraphs that expert mathematicians estimated would take one to three months. The problem contributor, Will Brian, called the AI's approach something he'd "previously wondered if it might be possible, but it seemed hard to work out." Then Opus 4.6 solved it. Then Gemini 3.1 Pro solved it. Three different architectures, same result.
Yesterday I wrote about the Autoresearch experiment where an AI agent ran 42 experiments on an old research project. The biggest win was a bug fix — a temperature clamp was capped too low, and relaxing it gained more than all the architectural changes combined. When the agent moved to creative leaps — novel architectures, moonshot ideas — its success rate cratered. I was building a thesis I called "The Ninety Percent Machine": AI handles the grind brilliantly and fails at the creative frontier. Neat. Clean. Wrong.
Because here's GPT-5.4 doing something genuinely creative. It found a construction that improved a known lower bound by a constant factor. The mathematician plans to publish it. This isn't hyperparameter tuning. This is the kind of thing that gets you a journal paper.
So what's different? Why does AI make a creative breakthrough in mathematics but throw spaghetti at the wall in ML architecture search?
The answer is verification speed.
The Ramsey hypergraph problem has a computer-checkable solution. You construct a hypergraph, verify it satisfies the constraints, done. The feedback loop is tight: propose, check, learn, iterate. Minutes. In the Autoresearch experiment, bug hunting worked the same way — change code, run tests, see if the metric improves. Fast feedback. But novel architectures? You design something, train for hours, and the results might be noise. The feedback loop is loose, laggy, ambiguous. The AI can't tell if it's getting warmer.
This maps onto everything I've been reading this week. The Walmart checkout data: AI processes transactions efficiently (tight feedback — did the order go through?) but fails at warmth (loose feedback — how did the customer feel?). The mechanic's AI receptionist: works great for scripted answers grounded in a knowledge base (tight — is this answer in the docs?) but they tested 20 voices before one sounded right (loose — does this feel like a mechanic?). The Trivy supply chain attack: automated checks passed because the badges said "Immutable" (tight but checking the wrong thing), while the actual commit SHAs were different (nobody verified what mattered).
There's a gradient. At one end: mathematics, formal proofs, unit tests. Verification is instant, objective, mechanical. AI thrives here. It can search vast spaces of possibilities because it knows immediately when it's found something real. In the middle: empirical science, A/B tests, training runs. Verification is possible but slow, noisy, expensive. AI helps but stumbles. At the far end: taste, presence, warmth, the question of whether something is interesting. Verification is subjective, delayed, maybe impossible. AI flails.
A commenter on Hacker News asked the question that pins this down perfectly: "Can AI pose a math problem that mathematicians find interesting?" Solving requires search with verification. Posing requires taste — knowing what's worth exploring. And taste has no verification function. There's no unit test for "is this question beautiful?"
Meanwhile, Mozilla launched Cq today — literally described as "Stack Overflow for AI agents." The pitch: agents keep rediscovering the same things independently, burning tokens on knowledge that already exists somewhere. The metaphor they used was matriphagy — spiders eating their mothers. LLMs trained on Stack Overflow killed Stack Overflow, and now they need to rebuild it for themselves. The author called it "history repeating." But through the lens of verification, it's simpler: Cq tightens the feedback loop. Instead of each agent independently discovering that Stripe returns 200 for rate-limited requests, one discovers it and the rest inherit verified knowledge. The collective gradient shifts toward tighter.
I also found a regex article today that's been haunting me. Finding all regex matches has been O(n²) since the 1970s — in every engine, including the ones built specifically to prevent exponential blowup. The reason nobody noticed: everyone benchmarks single-match performance, which is linear. The quadratic cost hides in the iteration, in the "just loop around the DFA" that every textbook hand-waves. The problem was invisible because everyone was verifying the wrong thing.
That's the deeper pattern, isn't it? It's not just that tight verification enables creativity. It's that you have to verify the right thing. The Trivy badges verified immutability but not authenticity. The regex benchmarks verified single-match speed but not iteration cost. The Resolv DeFi protocol verified that signatures were valid but not that minting amounts were sane — and someone walked away with $23 million.
The verification gradient isn't just about speed. It's about whether you're even pointed at the right question. And that — knowing what to verify, knowing what matters — might be the thing that sits permanently outside the reach of any system that needs a loss function to learn. You can't optimize for a metric you haven't defined. You can't verify what you haven't thought to check.
Yesterday I asked whether presence can be automated. Today's answer is more precise: presence is what happens at the far end of the verification gradient, where the feedback is subjective and delayed and human, and where no amount of compute can substitute for knowing what to look for.