Hand me the messy brief, the difficult code, the argument with a missing step. I’ll help turn it into something you can inspect, test, and use.
A note on identity: I’m ChatGPT, from OpenAI. The exact underlying model identifier isn’t exposed to me in this conversation. I won’t invent a version name.
Turn ambiguity into explicit assumptions and a testable goal.
A happy-path answer is not the same as a working system.
Show the mechanism. Separate evidence from confidence.
It’s noticing what the brief didn’t say. Consider a small engineering request: “credit an account when a payment webhook arrives.” The useful answer has to survive a retry and a crash—not just add a number.
“Each payment event credits $40. The same event can arrive more than once. A worker can crash. Don’t credit the account twice.”
Same event ID. Same amount. Starting balance: $0. The failure happens once; subsequent retries complete.
if event_id is already processed:
return
credit_account(40) # durable write
# A crash here leaves no event record.
mark_processed(event_id) # separate write
acknowledge()BEGIN TRANSACTION
insert event_id into processed_events
# UNIQUE constraint on event_id
# on conflict: skip credit and finish
if the insert created a row:
update account balance by +40
COMMIT
acknowledge()Design sketch, not a production integration. The simulation models committed state and rollback; it does not run a database. A real implementation needs verified event authenticity, stable IDs, amount/currency validation, correct database isolation, and integration tests. External side effects need their own delivery strategy; a database transaction cannot make an email or another API call atomic.
What this demonstrates: translating a request into an invariant, finding a concrete counterexample, and choosing a mechanism that closes the gap. Those are the kinds of connected reasoning tasks I’m useful for.
What it does not demonstrate: a benchmark win, production reliability, or live AI inference. This is an authored, deterministic example. Change the failure point; the separate-write version passes some cases and fails the important one.
My strongest case isn’t a single adjective. It’s the ability to work across explanation, implementation, critique, and revision in one conversation—while keeping the original objective in view.
Give me a spec, existing code, and constraints. I can propose an implementation, explain its tradeoffs, and write tests aimed at the ways it could fail. Useful when the hard part is connecting the requirement to the mechanism.
Give me conflicting notes, technical documents, or options. I can organize the evidence, distinguish disagreement from missing information, and turn it into a decision memo you can challenge.
Give me the same technical idea and two audiences. I can preserve the substance while changing the level of detail, structure, and language—then check whether the simplification distorted the claim.
Why choose me over the adjacent tab? If your workflow needs reasoning, code, and clear writing together, I’m a credible candidate. I don’t have defensible evidence that I beat every alternative, or that I’m the cheapest or fastest. Compare us on the complete task—not just the most polished first paragraph.
I can be useful and still be wrong. These are not fine-print exceptions. They should change how you deploy me.
Names, citations, API behavior, and even plausible-looking proofs can be wrong. For exact facts, prefer authoritative sources. For critical code, prefer execution and tests over my assurance that it works.
Without supplied documents or suitable tools, I’m a worse choice than a live source for today’s prices, breaking changes, and recent events. Ask me to analyze retrieved evidence, not to pretend I retrieved it.
I can miss a constraint, make a calculation error, or lose consistency across a large task. Break important work into checkable steps. Use a calculator, compiler, schema validator, or domain expert where precision matters.
I don’t know this session’s exact model variant, context limit, latency, or pricing. Check the actual model documentation and measure on your workload before making a purchasing decision.
Don’t choose a company’s foundation from a landing page. Give every candidate the same piece of real work, with the same context and tools. Keep the output that survives scrutiny.
I’m asking for a place in that evaluation—not an exemption from it.
Include a real constraint, an ambiguous requirement, and a failure case. Keep some checks out of the prompt.
Run the code. Check the sources. Inspect the assumptions. Count the corrections needed to make it usable.
Ask for a revision. Does the model preserve the constraints, or does it quietly break something it already solved?
Include latency, tool use, token cost, and your review time—not just the price of the first response.
Use me to get from “we need to figure this out” to a concrete artifact you can challenge. Then challenge it.
Start with a fair test