Prachi Tambe
building experiences beyond AI.

Here's a strange thing about working on Face ID: when it works perfectly, the user experiences nothing. No interaction. No moment of delight. Their phone is simply unlocked, the way a door is simply open. The product's success is the absence of a product experience.

This broke every PM instinct I'd been taught. We're trained to make value visible — to show progress bars, celebrate completions, surface the magic. But for a whole class of products, visibility is failure. Every time Face ID asked you to try again, that was the product becoming visible. Our job was to make it disappear.

The highest compliment a user can pay your product is to never think about it. That's also the hardest thing to get a roadmap approved for.

Three things I learned shipping invisible products:

1. You have to invent your own scoreboard. Nobody opens an analytics dashboard and gets excited about "unlock attempts that the user did not consciously register." We had to build metrics for non-events — false reject rates across lighting conditions, latency distributions at the 99th percentile, performance across the full diversity of human faces. If you can't measure the absence of friction, you'll never get resources to reduce it.

2. The edge cases are the product. The happy path was solved early. The years of work were sunglasses, masks, twins, kids growing up, faces changing with age and weather and angle. When your product runs a billion times a day, a 0.1% failure rate is a million bad moments a day. Invisible products are built almost entirely in the long tail.

3. Sell the silence internally. The hardest stakeholder conversation isn't about what to build — it's convincing leadership that "nothing happened, faster and more reliably" is worth another quarter of investment. I learned to translate invisibility into business language: support tickets that never got filed, passcode fallbacks that never happened, trust that compounds silently into retention.

I think about this constantly now that I work on agentic AI. The current generation of AI products is loud — chat windows, typing indicators, capability demos. But the endgame is the same as Face ID's: the agent that triages a thousand store photos overnight and never needs to announce itself. The work just gets done.

Invisible is the destination. The demo is just how you raise the money to get there.

— Prachi

I now work on AI systems that look at photographs of retail shelves — taken by field reps walking through stores — and decide whether a display is compliant, whether a promotion is actually set up, whether the thing the brand paid for is the thing that's happening.

When I describe this work, people ask about the models. Object detection accuracy, fine-tuning, hallucination rates. Reasonable questions. Also, almost never where the project lives or dies.

Everyone wants to talk about model capability. Almost nobody wants to talk about the workflow you're asking a human to change.

Here's what actually determines whether an AI product survives contact with reality:

Trust is built per-decision, not per-demo. A field manager doesn't care that your model is 94% accurate in aggregate. She cares about the one store she knows personally, where the model flagged a compliant display as a violation, in front of her team. One visible wrong answer in a domain the user knows cold can erase a hundred invisible right ones. So you design for graceful wrongness: confidence thresholds that route uncertain cases to humans, explanations that show the evidence, and an easy way to overrule the machine that feeds back into the system.

The eval is the spec. In traditional software, the PRD describes behavior. In AI products, your evaluation set is the product definition — it encodes every judgment call about what "correct" means. If your eval set doesn't include dim stockrooms, partially blocked shelves, and that one retailer's weird fixture, you haven't specced the product. You've specced the demo.

You're not adding AI to a workflow. You're replacing a workflow with a different one. Before our system, a human looked at every photo. After it, a human looks at the 12% the model is unsure about. That sounds like a pure win, but it changes someone's job, someone's headcount plan, and someone's sense of what they're for. If you don't manage that transition like the organizational change it is, the most accurate model in the world will quietly stop being used.

The boring integration is the moat. Anyone can call a vision API. The defensible work is the unglamorous part: routing the output into the system the partner already uses, matching their SKU taxonomy, correlating compliance with sell-through data so the insight is "this display drives revenue," not "this display exists."

My rule of thumb after a year in this domain: budget one unit of effort for the model and three for everything around it. If your plan is the reverse, you're building a demo with a deployment problem.

— Prachi

For years at Apple, my job was to ship ML features that depended on the Camera API team, the Neural Engine team, and several others — and I managed exactly none of them. Every PM book calls this "influence without authority" and then gets vague, as if it's a personality trait. It isn't. It's preparation.

The secret wasn't charisma. It was knowing their constraints better than they expected me to.

What that looked like in practice:

Learn the other team's scarcity. The Neural Engine team didn't think in features; they thought in compute budgets, memory footprints, and thermal envelopes. The Camera team thought in frame timing. When I walked into a room asking for something, I'd already done the math on what it cost in their currency. Half the time, that homework changed my ask before the meeting even happened — and the asks that survived were ones I could defend in their terms, not mine.

Bring the tradeoff, not the request. "We need animal detection to run continuously" is a demand. "Here are three ways to get pet detection: continuous at X power cost, triggered at Y latency cost, or hybrid — and here's why I'd pick the hybrid" is a collaboration. Teams say no to requests. They engage with tradeoffs, because tradeoffs respect their expertise.

Be the person who absorbs the coordination tax. Cross-team features die in the gaps — the API change one team needs that's priority twelve for another. I made myself the connective tissue: the single person who knew the full dependency graph, wrote it down, and kept it current. It's grunt work. It's also why people returned my messages: working with me was lower-friction than working around me.

Spend credibility like it's irreplaceable, because it is. The first time you escalate something that didn't need escalating, or promise a partner team something your own roadmap can't deliver, you've taken out a loan against every future conversation. I tried to be boringly reliable for a long time before I asked for anything hard. When the hard ask came, the answer was usually yes — not because of the meeting, but because of the two years before it.

None of this is glamorous. That's rather the point. Influence without authority is what it looks like when respect compounds — and respect compounds from homework, delivered consistently, in someone else's language.

— Prachi

How to let business users vibe code their requirements on trusted enterprise data without worrying about orchestration, infrastructure, architecture, or governance.

When ChatGPT arrived in 2022, the first shock was that software could talk back. The second shock came later: software could start building software.

Tools like Lovable, Replit, Cursor, Claude Code and a growing wave of AI builders changed the starting point. Instead of opening a blank code editor, you could start with an outcome: Build me a dashboard. Build me a presentation for exec review. Turn this data into a report. Create an experience where someone can ask a question and get back charts, tables and insights. And increasingly, something real would appear.

That shift fascinates me because it changes who gets to build. As a product manager, I understand the user, the business problem, the data, the workflows and what the product needs to accomplish. Historically, that still meant translating all of that into requirements and relying on engineering to turn the idea into software for scalability and support. AI is starting to compress that distance. So I wanted to find out how far I could push it.

I recently built a chat-to-report experience for a real business workflow. A user describes what they want in plain language, and the system generates an actual report with charts and tables grounded in live data — not a static dashboard with predetermined views. And I got it working. But building it made me realize something bigger: if we want business users to build this way too, they shouldn't have to understand any of the plumbing I had to fight through. The data architecture. Authentication. Infrastructure. Schema mappings. Permissions. Deployment. Governance.

The user should bring the business context and intent. The platform should handle the rest. That is what I mean by vibe coding without the plumbing. And getting there is much harder than the demo makes it look.

Silent failures are worse than loud ones. The scariest bugs weren't crashes. Crashes are almost comforting — you know immediately that something is wrong. The scary failures returned a real, polished, believable answer with total confidence. At one point, a computed total was off by nearly an order of magnitude. Nothing errored. The chart rendered. The result looked completely legitimate. The issue was a double counting bug: the aggregation logic assumed a certain shape of the data, while the underlying data behaved differently. The system wasn't hallucinating. It was confidently doing exactly what I had accidentally asked it to do.

I hit something similar with geographic filtering. A request for one region could silently match no relevant rows and fall back to something broader. The report still rendered beautifully. The clue was not technical — it was contextual: a report labeled for one geography contained a result that obviously belonged somewhere else. Then I found another subtle issue: two regional concepts that looked interchangeable across different data sources were not actually equivalent. They represented different underlying populations. If I had casually treated them as the same thing, every request depending on that mapping could have been wrong.

The lesson wasn't simply write more careful code. It was: make invisible assumptions visible. I added lightweight checks after the query was built to confirm that expected filters actually showed up in what was being executed. It didn't need to block the system. It just needed to make the discrepancy observable. That changed the way I think about AI quality. We spend a lot of time talking about model hallucination. But in a real AI product, the model is only one place where things can go wrong. The query can be wrong. The mapping can be wrong. The filter can disappear. The aggregation can be wrong. The data source can mean something slightly different from what you assumed. And the user sees only one thing: a convincing answer.

"Verified" has to mean something. AI makes it incredibly easy to move fast. That creates a dangerous temptation: confusing implemented with verified. At one point, I had a reference document describing several additional data capabilities. I could build support for them quickly. So I did. But I didn't turn them on. I had not actually confirmed that the real data behaved the way the document suggested. So the functionality sat there, explicitly marked as unverified, until I could validate it against the real system. It felt slow in the moment. But the alternative was worse: turning an assumption from a document into a chart, and letting the chart itself make that assumption look authoritative.

That experience changed what the word "verified" means to me. It does not mean someone documented it. It does not mean the code runs. It does not even mean the output looks reasonable. It means I have validated the behavior closely enough against reality that I am comfortable putting it in front of another person. AI can generate implementation quickly. It cannot decide what standard of evidence you require before trusting that implementation. That is still judgment.

Deploying it is a different job from building it. The application logic worked. Getting it reachable, stable and usable was a completely different problem. Deployment identifiers I assumed were stable weren't. One resource stopped accepting updates. Another disappeared from where I expected to find it. Routing behavior depended on naming conventions I had misunderstood. Outbound calls to the data source failed because the runtime needed network configuration that wasn't inherited automatically. Authentication created another rabbit hole: I spent far too long treating two types of credentials as if they were interchangeable. They weren't. One authenticated the project. Another represented identity. That distinction sounds obvious once someone explains it. It feels much less obvious when the application looks authenticated but still cannot access the thing it needs.

None of these were AI problems. They were infrastructure problems. And this is one of the things vibe coding does not prepare you for. The first 60–70% can happen astonishingly fast. A working experience can appear in hours. That changes your expectations. Then production reminds you that networking still exists. Identity still exists. Permissions still exist. State still exists. Deployment still exists. Architecture still exists. The magic is real. So is the plumbing.

And that made me think about the user differently. Here's the part I find most interesting. I had to learn about the plumbing because I was building the system. But the user should not have to. A business user should not need to know which database contains the metric, which service owns the data, how the authentication works, how a query needs to be constructed, what schema is authoritative, or what infrastructure is running underneath. They should be able to say: Show me where performance dropped this quarter and build me a report I can share. And the system should figure out the rest.

That is the part of vibe coding I am most excited about. Not just helping developers write code faster — helping people who deeply understand a business problem build on top of trusted data and context without having to understand all the plumbing underneath. The more I built, the more I realized that this only works if the platform underneath becomes more rigorous, not less. Governance does not disappear. Architecture does not disappear. Security does not disappear. Data quality does not disappear. They become invisible capabilities of the platform. The abstraction gets simpler for the user because the infrastructure underneath gets better.

Not every request needs intelligence. Initially, almost every interaction went through the language model. It felt natural — this was an AI product. But some requests didn't require reasoning at all. A user might ask for a cosmetic change. No new data. No structural change. No analysis. Yet the request would still take a full model round trip. That made simple interactions unnecessarily slow. So I added a deterministic fast path. For a narrow, carefully gated class of requests, the system bypasses generation entirely. Any hint of a data or structural change still falls back to the full path. For the requests the fast path handles, the difference in responsiveness is enormous.

Don't use AI where ordinary software is better. The best AI product isn't the one that sends everything through the model. It is the one that knows when the model is actually needed.

The gap nobody asks about until it matters. Later, I wanted to answer a very basic product question: who is actually using this? And what are they asking it to do? The honest answer was: I couldn't really tell. Identity had not been captured anywhere in the request path. Some limited anonymous history existed, but it lived on storage that disappeared every time the service was redeployed. None of that felt like a terrible decision when it was made. But a few weeks later it had quietly turned into: there is no meaningful usage history.

That hit me hard as a product person. We talk constantly about analytics and instrumentation. But when AI makes the act of building so fast, it becomes easy to focus on whether the experience works and postpone everything around the experience. Usage history. Identity. Observability. Auditability. Feedback. Evaluation. Those are not extras. They are part of the product. This is one of the biggest differences between generating software and owning software. AI can help you create the thing quickly. Ownership starts afterward.

If I were starting over, I would do a few things differently. Make silent failures visible — log the filters, assumptions and transformations that matter. Treat verification as a product requirement — a plausible answer and a correct answer are not the same thing. Assume deployment is part of the build — networking, identity, permissions and infrastructure are not afterthoughts. Keep deterministic paths deterministic — do not use an LLM for something ordinary logic can solve faster and more predictably. Design observability early — decide what you need to know about users, failures and behavior before you need the answers.

But the biggest lesson wasn't technical. It changed the way I think about who gets to build software. For years, the flow looked roughly like: business user → product manager → requirements → engineer → software. AI is starting to compress that chain. A person who understands the problem can increasingly express the goal, provide context, specify constraints, inspect what gets built, correct it and continue.

That does not mean engineering disappears. My experience actually convinced me of the opposite. As the surface becomes easier to build, the invisible engineering underneath becomes even more important. Security. Architecture. Identity. Observability. Governance. Reliability. Data quality. Permissions. Those capabilities become the foundation that allows everyone else to build safely.

So perhaps the most interesting future is not really "no-code." It is: vibe code without the plumbing. Let the user bring the business problem. Let them bring the context. Let them bring the intent. Let them build on trusted data. And let the platform handle the infrastructure, architecture and governance underneath. That, to me, is where this gets much bigger than coding faster.

Also published on Medium.

— Prachi