I am building a coupon comparison tool. The goal is straightforward: sort a pile of fast-food coupons by their actual value for money and display them.

But “value” gets stuck on a hard problem—each coupon only lists the total price, not the individual value of each item inside. To determine which coupon genuinely offers the best deal, I first have to reverse-engineer the implicit unit price of each item—a piece of fried chicken, an egg tart, a beverage.

The approach is to treat this as a system of equations: each coupon represents one equation, where the total price equals the sum of item quantities multiplied by their unit prices. Solving this system across many coupons yields the unit price for each item.

This task has an inherent flaw, which I noted during the planning phase: the derived unit prices have no control group, and no one will notice if the numbers are wrong. If the equations solve incorrectly, the results will just be silently wrong; they will not throw an error, and no tests will flash red.

As it happens, I already had an algorithm of my own.

Here is how I estimate the real price: reverse-engineering it from the promotional structure.

• Buy one get one free means the real price is roughly half the list price.
• 70% off the second item means it is roughly 0.65 times the list price.
• For a simple coupon containing just one type of item, simply divide the total price by the number of portions.

I derived these rules myself by reviewing coupons one by one, and I actively use them. But this approach has a flaw: it is a heuristic, entirely devoid of mathematical derivation. I have a sense of whether it works, but I have never had much confidence in whether it is actually “right.”

Therefore, when I decided to hand the task of reverse-engineering the unit prices over to Claude, I made a decision: I hid my own algorithm and did not provide it.

There were two reasons. First, my algorithm lacked mathematical derivation, and I was unsure if it held up; I worried that bringing it up would interfere with Claude’s reasoning and lead it astray. Second, I also wanted to see if Claude could find the correct solution relying solely on its own knowledge base.

So I only described the logic for “how I want to filter and how I want to sort,” and then I let go, allowing it to derive the math on its own. I did not mention a single word about my algorithm.

After Claude finished writing the specification, it repeatedly pointed out that the content at a certain stage required my validation. I did not read it carefully.

This was my dereliction of duty. I was so focused on making it work independently that I also skipped over the things it proactively handed back asking for my confirmation. My mind was focused on “do not interfere with it,” yet I failed to notice that it was already turning back to ask me.

Until it got stuck on the low-sample scenario and could not proceed.

It laid out the actual calculated numbers for me to see. Only then did I pause, bring out the algorithm I had been withholding, and discuss it with Claude. Oddly enough, if it had not laid the concrete numbers right in front of me, I probably still would not have mentioned it—I had always felt that this algorithm was just something I used personally, something not “orthodox” enough, and I felt embarrassed to use it to guide the derivation.

Then, the two paths converged.

I estimated the fried chicken using my algorithm at around 50. Claude used NNLS with ridge regression to reverse-engineer the unit price of the fried chicken from 25 coupons: 45.9.

The two sides shared absolutely no common assumptions. My side was the arithmetic of promotional structures—splitting buy-one-get-one-free in half, multiplying 70% off the second item by 0.65; its side was pure equation solving. The starting points were completely different, yet they landed in the exact same place.

Later, I took every item calculated by my algorithm and checked it against Claude’s solution. It was not just this single data point for fried chicken; the entire set of items aligned perfectly.

Two independent paths reached the same destination, and for the first time, the reverse-engineered unit prices had a point of comparison—going from “no one will notice if it is wrong” to “two unrelated paths both arrived here.”

But for me, the real takeaway was actually something else.

I never had much confidence in that algorithm of mine lacking mathematical derivation. I used it, and it worked, but I did not know if it was actually right. This time, it received an independent endorsement completely unrelated to me for the very first time.

This incident also helped me figure out a truth. When trying to validate a method that even I am half-skeptical about, the best approach is not to ask the model, “Am I right about this?”—it will be led by the provided answer, and at the end of the day, that is just seeking validation. The truly reliable approach is to let it derive the solution itself via a different path, without knowing the answer beforehand. When two paths lead to the same place, that is true evidence.