David Robinson and OpenAI: Questions for AI Product Builders

• David Robinson’s first-person essay in The Atlantic

A personal statement can explain the author’s reasoning. It does not, by itself, measure the failure rate of a model in your application. Avoid turning a personnel story into either a blanket rejection of AI or an endorsement of a competing provider. Evaluate the task, the evidence, and the consequences of an error.

For internal discussion, create two columns: what the source actually says, and what your team proposes to do. Keeping those columns separate makes it easier to disagree constructively. A recommendation should have its own rationale, owner, and verification step.

The record should be short enough that the team updates it when the model or workflow changes. Store representative successes and failures alongside it. A collection containing only attractive examples makes it hard to understand what the product will do with ordinary or difficult requests.

Revisit the decision when you add new inputs, broaden the audience, or allow the system to take a new action. Reusing the same model does not make those product changes equivalent. An assistant that drafts a message and one that sends it have different failure consequences.

For SJolt image and video tasks, your application receives a task identifier and queries for completion. Save that identifier with the model, request revision, and user-visible job before continuing. A finished task establishes that output is available; your application still needs to determine whether it meets the brief.

• Keep API credentials in the server environment and give the browser only the information needed to display progress.
• Separate a request timeout from a confirmed task failure. If you already have a task ID, check that task before creating another.
• Record the output selected for delivery and the person or rule that accepted it.
• Provide a clear failure state so a user can revise the request instead of waiting indefinitely.

• SJolt authentication and task documentation

Apply the same discipline to LLM outputs. Keep user instructions distinct from retrieved documents, and parse the actual response format rather than treating every returned block as display text. When a response is incomplete, make that state visible to the application.

Review is most useful at a concrete boundary: approving a brief, choosing a generated asset, or authorizing publication. Asking a person to approve every trivial intermediate step can create noise while the important decision remains hidden. Present the final candidate with the evidence needed to judge it.

For example, show a proposed product image next to its approved reference and a short list of requested edits. An editor can then check whether the package shape and label survived. A generic success badge cannot answer those questions. If the reviewer rejects the result, preserve the reason as a specific instruction for the next attempt.

Choose a small number of operational signals that can trigger investigation: repeated task failures, unusual submission volume, missing output, or a rise in rejected assets. Implement those checks in your own application according to its needs; this article does not claim they are automatic SJolt features.

Take a representative job and interrupt it after submission. Ask another person to recover its state using only the saved record. Then supply a result that is technically complete but visibly wrong. Check whether the system and the reviewer distinguish those two cases.

The exercise should end with an observable improvement: a saved identifier, a clearer error message, a review screen, or a documented stop procedure. These are concrete ways to make an AI application easier to understand and correct, regardless of the model provider you choose.