Your AI Feature Isn't Done When It Ships. It's Done When You Know What to Do When It Breaks.

You learned to ship software that acts like a vending machine. Money in, button pressed, soda out, same every time. AI features don't work that way. The same prompt gives different answers across users, sessions, and model updates you didn't plan for. That breaks how your team thinks about "done," how your design system feeds the model, and who fields the mess when output goes sideways. Let me catch you up on what's actually shifting and what to bring to your next review.

Done is now a range, not a checkbox

The old "done" lined up three things: tests pass, no P0 bugs, the demo worked. Jeff Gothelf says that's no longer enough. What you ship with AI isn't a fixed object. It's a spread of behaviors, and the surprises live in the ones you never saw.

So write acceptance criteria as distributions. Instead of "when the user inputs X, the system returns Y," try "for 80% of inputs in this category, the response meets the quality bar; for the other 20%, the failure is degraded but not embarrassing." Keep your old, binary criteria for the parts that still behave like vending machines, like auth, billing, and navigation. Use the probabilistic ones for the parts that don't.

The payoff is real. Gothelf says teams who do this ship fewer features, but they generate fewer support tickets per launch and less brand damage per incident. The ones who skip it ship faster and spend the rest of the week explaining why last week's "done" is broken now.

Plan for the failure before it ships

The old workflow was ship, watch the dashboard, triage when complaints get loud enough. Too slow for AI. By the time a complaint reaches engineering, the customer already has an opinion about your product.

Write the triage playbook before the feature launches. Decide who owns model-quality issues, who owns UX, who owns content, and who owns the PR mess if the model says something it shouldn't. The launch isn't the feature going live. It's the moment the people downstream are ready to handle what it does.

Then ship every AI feature with a tripwire. Pick a metric that matters for your brand, set the threshold, and decide what happens when it's crossed. Don't just write the rollback down. Rehearse it. The moment you find out your rollback doesn't work is the moment you need it most.

Your design system is the guardrail, if you let it be

Here's the part that hits your design org directly. AI prototypes come out inconsistent because of tiny messes scattered across your system: decisions made but never written down, hard-coded values nobody cleaned up, mock-ups the AI has to guess at. Smashing Magazine's guide, drawing on work from Atlassian's Hardik Pandya, says to treat design decisions as infrastructure. Every decision has to land in a spec file the AI can actually read.

The setup is three layers. Spec files in plain Markdown that hold your spacing rules, color choices, and component usage. A token layer so the AI picks from a closed set of named variables instead of inventing plausible values. And an audit script that flags every hard-coded value the AI sneaks in. A free Figma plugin called FigmaLint can catch detached instances, missing states, and hard-coded values before they spread.

Feeding the model text beats making it decode mock-ups. It's cheaper and more accurate. But it only works if you keep the specs current. When the system ships an update, a sync routine has to flag which spec files are now out of date.

The tool was the easy part

If you think training your team on the tools gets you there, Gothelf has bad news. Tool training is the easy part. You can count the seats and the prompts in the library, so it feels like progress. But point a faster tool at the same backlog and you get the feature factory on steroids. The customer feels none of it, because speed doesn't change whether you were building the right thing.

The deeper problem is permission. Gothelf points to research that roughly 84% of organizations haven't redesigned a single workflow around the AI they bought. They dropped a powerful tool on a process built for 2019, nothing shifted, and they filed it under "AI is the problem." The people running the pilot were never handed the authority to change the work around it.

So when AI gives a team a few hours back, ask where they're allowed to spend them. If the only answer is the backlog, you bought speed and nothing else.

The job that was always there

There's a name for the work that's left once the typing gets automated. Andrej Karpathy stood at a Sequoia event and called vibe coding obsolete, then listed what comes next: writing specs, supervising plans, inspecting diffs, building evaluation loops, holding the line on quality. Strip the engineering vocabulary and that's product management.

The bottleneck moved. Execution stopped being the hard part, so deciding what to build became the constraint. The agent writes the code. It won't tell you whether the code was worth writing. As Fabricio Teixeira puts it, we have extraordinary capability and almost no shared conventions for handing it to people. The ground is still soft. That's the part your judgment has to cover.

The deep cut

The through-line is that AI doesn't fix a sloppy system, it amplifies it. A messy design system makes messy prototypes faster. A broken process makes a broken process faster. An untested assumption gets shipped sooner and more confidently. Every one of these pieces points at the same move: clean up and write down the decisions the AI is going to act on, then decide in advance what you'll do when it gets one wrong.

So your next AI launch needs two artifacts most roadmaps don't have yet. A definition of done that names which behaviors you've decided to tolerate. And a rollback you've actually run, not just written. If you can't produce both, you haven't shipped a feature. You've shipped a demo and hoped.

Three questions for your team

1. Pull up the next AI feature on the roadmap and read the acceptance criteria out loud. Do they sound like vending-machine assertions, or do they name the failure modes you've agreed to live with?

2. If our top tripwire metric crossed its threshold tonight, who acts, and have we ever actually run the rollback?

3. Where in our design system are the undocumented decisions and hard-coded values that an agent will guess at, and who owns getting them into a spec file by the next sprint?