When teams sit down to incorporate AI into their products and workflows, the starting question is too often: “What can AI do here?”

That question has been bothering me for a while, and I’ve finally put my finger on why. It leads to a default playbook: find a task, have AI do the whole thing, put a human at the end to check the output. The human’s job is to skim the result and click “approve.”

You end up with rubber-stamping disguised as oversight. And at some point the rubber stamp will come from an AI too, and you’ll have to ask what the product was even for.

A better first question

There’s nothing wrong with exploring what AI is capable of. The technology is new and unevenly understood, and you need to poke at the limits to develop intuition. Of course we’re going to spend time exploring capabilities. That’s how you learn.

The problem is when capability exploration becomes the foundation for design. When “what can AI do?” drives product decisions before you’ve asked what you’re trying to accomplish or where humans matter.

So flip the question. What if the starting point was instead: “Where do people add or get value?”

The difference is where the human ends up. The first question treats human involvement as the residual, whatever’s left after the AI does its thing. The second makes human involvement the thing you’re actually designing around.

At Parse and Firebase, we spent years hunting for the work developers had to do that had nothing to do with what made their app theirs. Configuration, scaling, infrastructure. All of it matters, but only in service of the app itself. The data model, the business logic, the user experience were where developers wanted to spend their time. So we aimed to automate the plumbing and leave the meaningful choices in their hands. The abstractions people loved exposed the right complexity and handled the rest quietly.

AI pushes that line much further out, much faster. The more that can be automated, the easier it gets to see what’s essential.

Why designing around capabilities is fragile

If asking where people add value was useful for building developer tools, it might be even more important for building with AI, because AI moves that line faster and less predictably than infrastructure ever did.

You don’t even have to believe agents will get all the way to full autonomy for this to matter. Whether AI handles 30% of a workflow or 95%, the specific tasks people do will keep shifting. What people value, and where they want to be involved, shifts much more slowly. Build your product around what AI can do today, and you risk its value evaporating as models improve. What required your product yesterday might be fully automated away tomorrow. Build around what people value, and your design survives the next model.

And if you do believe AI gets all the way there? The question just evolves. “Can AI do this?” becomes an unequivocal yes, and the interesting question becomes “Should AI do this?” That’s a question whose answer depends on the situation, what you’re trying to accomplish, and where humans want to be making decisions. So how do you actually think that through?

Three questions

I’ve landed on three questions, and the one about AI comes last.

What are you trying to accomplish, and why does it matter? At the end of the chain, a person needs to find value in what you’ve built. AI might be able to build the thing, but usefulness and meaning only make sense relative to the people you’re building it for.

Where do people add or get value by being involved? I think there are two sides to this.

On the adding value side: people have a stake in the outcome. They’re deeply attached to the problem. They know the customer. They’ve felt the frustration of a bad workflow, they’ve sat in the meeting where the stakeholder changed their mind, they have taste other people respond to, and they’re the ones accountable when it goes wrong. That’s hard to hand off to an AI, even one with access to every document and transcript.

On the getting value side: sometimes being in the loop does something for the person. Maybe they need to understand what’s happening so they can intervene somewhere else later. Maybe the experience of being involved is part of what they’re paying for. They learn something, or enjoy the process, or build intuition they’ll use next time. Code review is a good example. Part of what reviewers get out of it is a shared understanding of where the system is heading, which is exactly what they need the next time something in that area changes or breaks.

Both of those are durable reasons for human involvement, and neither has anything to do with what the AI is or isn’t capable of.

What can AI handle, and how much oversight does it need? Only after the first two does the capability question earn its place, informed by all that exploration but in service of the answers above.

Same capability, different answer

The hard part is that the answer changes with context. Take UI design. If you’re building a consumer product, having a strong opinion about what it feels like to interact with your brand might be central to your value proposition. The aesthetics and the taste are differentiators. You want people deeply involved in those decisions because their judgment is the product.

But if you’re building a line-of-business application? Ease of use matters, sure, but the specific aesthetics probably aren’t at the heart of what makes it valuable. Letting AI handle the UI entirely might be a reasonable choice, because that’s not where your business differentiates.

The AI might be equally capable of generating the UI in both cases. The question is whether a person adds or gets something by being involved in that particular decision for that particular product.

The “essential” framework

I’ve started using this as a rubric. For any role, any activity, any workflow: start with what you’re trying to accomplish, then ask where people contribute or benefit by being involved, then figure out what AI can handle. What’s left when you boil it down to its essence? The parts where people matter. Those stay. The rest is fair game for automation.

Looking back, I think this is the question my post on code review ends up answering. What’s essential about code review when AI can handle more of the mechanical checks? Judgment, taste, and collaboration.

I’ve been running the same thought experiment across the whole software development lifecycle. What’s essential about each phase when AI can handle more and more of the mechanics? I’m still working through it.

Build around the essential parts. Those are where the people are.