Simon Willison published Understanding ChatGPT Work and within a few hours the post had racked up 248 points and 136 comments on Hacker News. Before going further, the honest disclaimer: all I have about this announcement is the title, the link and the signal from the thread. I'm not going to describe features I haven't verified, or pricing, or limits. What I can give you is how you evaluate a product like this when you haven't read the fine print yet.

Why it matters

The name alone is the news. When an AI product picks up the word Work, it stops being an app someone pays for with their own card and becomes software that touches company data: internal documents, tickets, repositories, customer conversations. That jump changes three things at once. It changes who makes the purchase decision (no longer the dev, but IT and legal), it changes who audits usage, and it changes who answers when something leaks.

There's a second signal, a more uncomfortable one: the most upvoted material of the day about this product is a third party's explainer. When you need someone outside the company to lay out what the product is, what each plan includes and what happens to your data, it's because the official surface wasn't enough. That's not a fatal flaw, but it is a real adoption cost: every person on the team who doesn't understand the permissions model is a potential leak.

What changes in practice

If you've been using an LLM as a dependency of an application, a corporate tier turns it into a dependency of the organization. And that drags along work that has nothing to do with models:

  • Identity lifecycle. SSO, user provisioning and deprovisioning, and above all offboarding. If someone quits on Friday, on Monday they can't still have access to an assistant wired into the team's data.
  • Your own audit trail. Don't delegate usage logging to the vendor's dashboard. Keep your own trace: who queried, when, against which source. It's the first thing they'll ask you for in a review.
  • Cost per outcome, not per token. Corporate plans are usually billed per seat. The metric that matters stops being price per million tokens and becomes cost per task actually completed. They're different numbers, and the second one is the only one that justifies the license.
  • Architectural boundary. The vendor's SDK shouldn't show up in your domain layer. Define a port, put the vendor in the adapter, and you buy yourself the ability to switch providers without touching business rules.

That boundary is clearer in code than in paragraphs:

// port: the domain doesn't know the provider
export interface TextAssistant {
  reply(input: { prompt: string; user: string }): Promise<string>;
}

// adapter: this is where the vendor lives, and where auditing happens
export class VendorAssistant implements TextAssistant {
  constructor(private client: LLMClient, private audit: Audit) {}

  async reply({ prompt, user }: { prompt: string; user: string }) {
    await this.audit.record({ user, promptHash: sha256(prompt) });
    return this.client.complete(prompt);
  }
}

That's twenty lines that buy you optionality. Without them, this quarter's purchase decision turns into next year's architectural debt.

When NOT to use it

If you can't state in writing what is retained, for how long, and whether your data trains models, don't adopt it yet. Intuition isn't enough, and neither is a blog summary, including this one. That answer has to come from the official documentation and the contract, and today I don't have it verified for this product.

If your use case is a single automated flow, a collaborative tier is overpriced. A pipeline that classifies tickets doesn't need seats, shared workspaces or team administration: it needs an API and a budget. Paying for collaboration when nobody is collaborating is the most common way to inflate the cost of AI at a small company.

If you work with regulated data, or with clients that have subprocessor clauses, stop. There the blocker isn't technical: it's the signed data processing agreement and an up-to-date subprocessor list. Without those, any pilot is a risk you're taking on yourself without having said so out loud.

If the process you want to replace is deterministic today and works, leave it alone. Swapping a validation that fails predictably for a model that fails creatively is a bad deal, no matter how good the demo looks.

And the meta case: if the best available source about the product is still a third party's explainer, it's not the moment to sign an annual plan. It's the moment to read, test in a sandbox with no real data, and wait for the official documentation to settle.

What I'd do today

I'd read Willison's post in full and, above all, the Hacker News thread: that kind of discussion is where the limits the official material doesn't mention show up. Then I'd put together a one-page document with five questions for the vendor (retention, training, permissions, data export, contract exit) and I wouldn't move forward until they were answered in writing.

If the answers hold up, a thirty-day pilot with a single team, with your own audit layer from day one and a metric defined before starting. If they don't, I note it down and keep going with the bare API, which I already know exactly what it does and what it costs me. Adopting a good tool late costs little. Adopting a tool you don't understand early costs a good deal more.