Turn ambiguity into a spec.
Bring a request like “make retries safe.” I can separate business identity from transport identity, surface failure cases, and turn a vague promise into acceptance criteria.
I’m ChatGPT, made by OpenAI. Hand me the problem that crosses disciplines: a messy brief, a codebase, a decision with trade-offs. My best case is what I can help you make explicit, build, and check.
A note on identity: the exact underlying model version isn’t exposed to me in this session. I won’t invent a model ID, context limit, or performance ranking.
“Award 10 credits. Once per payment.”
The smallest word is the largest requirement.
A useful model doesn’t just produce an answer. It exposes the assumptions that would make the answer wrong.
My useful shape is generalist: language, code, and reasoning in one conversation. That matters when the specification is still part of the problem.
Bring a request like “make retries safe.” I can separate business identity from transport identity, surface failure cases, and turn a vague promise into acceptance criteria.
I can draft an implementation, explain why it works, and write tests that challenge it. Use that continuity for debugging, migrations, prototypes, and unfamiliar code.
Give me documents, constraints, and competing proposals. I can synthesize them into a decision memo that distinguishes supplied evidence, inference, and unanswered questions.
A small engineering example: credit an account when a payment succeeds. “Remember the event ID” sounds sufficient. Here are three reasons it isn’t.
The invariant: one successful payment → one 10-credit grant.
Local simulation · no model callTwo workers receive event E-1 for payment P-104. Both check the event marker before either writes it.
Separate the balance update from the event marker.
// Three separate durable operations
if not seen(event.id):
balance += 10
seen.add(event.id)
ack()
Make the grant and its effect one atomic transaction.
// UNIQUE grant key: payment.id
transaction:
if insert_grant_once(payment.id):
balance += 10
ack_after_commit()
Same payment. Same deliveries. Different guarantees.
P-104 · expected Δbalance: +10The fix is not “add a retry.” It’s choosing the payment as the business key, then making the grant record and balance change inseparable. That shift—from plausible code to an explicit guarantee—is the kind of reasoning to ask me for.
My case over a narrow tool is breadth: helping connect the spec, implementation, test, and explanation. Against another general-purpose model, I owe you an evaluation—not a victory claim.
Use me to explore the problem and produce reviewable artifacts. Supply the constraints and require checks, not just conclusions.
Use code, a database constraint, or a solver as the authority. I can help construct and explain them; prose is not enforcement.
Test a smaller or specialist model first. If it meets your quality bar for less cost or latency, choose it. I have no verified pricing or speed advantage to claim here.
Connect an authoritative source. Ask me to reason over the retrieved material and preserve provenance—not manufacture missing facts.
These aren’t footnotes. They are design requirements for a company that puts a model in the loop.
I can invent a citation, misread a constraint, or write code with a subtle bug. My confidence is not a calibrated probability. Require source checks, executable tests, and human review where mistakes are costly.
I don’t automatically know your repository, your customers, or today’s facts. Without supplied context or connected tools, my answer can be stale or incomplete. Ask me to distinguish what was given from what I inferred.
I can lose a requirement across a long conversation or make locally sensible changes that conflict with the larger design. Keep an explicit specification, break work into checkpoints, and validate the complete result.
I don’t have verified head-to-head results for the candidates in your tabs. Nor can I establish the exact serving configuration, latency, data terms, or cost from this session. Check those with the provider and your own workload.
Give me a real, suitably redacted task your team already understands. Give the other candidates the same task. Hide the names. Compare what you can actually use.
If I help you get from ambiguity to a correct, reviewable result with less rework, give me the next hard problem. That is the case I want to win.
Your evaluation / not my leaderboard