30 秒看懂
两位嘉宾做过五十多次企业 AI 落地,认为非确定性和「自主权—控制权」的权衡,让 AI 产品跟传统软件根本不是同一类东西。他们的对策是一套叫「持续校准、持续开发」的循环:先做低自主权版本,记下人怎么改,等意外变少再放开。他们还认为评测和生产监控各抓一类问题,领导力和文化跟技术同样重要,真正能留下来的是对问题本身的执着。
- 1AI 产品跟软件差在两处:非确定性,以及自主权和控制权的权衡你既不知道用户会怎么说,也不知道模型会怎么回;每交出一分自主,就放弃一分控制。
- 2先高控制、低自主,再一步步挣上来客服 Agent 应该先给人建议回复,再直接答客户,最后才去退款或给工程提需求。
- 3竞赛不是谁先上线第一个 Agent,而是谁建对了飞轮他们对「一键 Agent」很怀疑,即便数据层很好,有意义的回报也要几个月。
- 4评测和生产监控抓的是不同问题评测数据集编码的是你已经知道重要的事;监控隐式信号,比如用户点重新生成,指向你没料到的失败。
- 5「持续校准、持续开发」借用了 CI/CD 的精神先圈定能力、整理数据、部署,再分析行为、发现新错误模式,直到一轮校准几乎带不来新信息。
- 6「痛苦才是新护城河。」赢的公司不是最先上线或功能最花哨的,而是慢慢摸清什么管用、什么不管用的那些。
按章节阅读完整文稿
怀疑消退了,但 AI 产品的执行仍然一团乱
Aishwarya Naresh Reganti says 2025 looks very different from 2024. Last year many leaders suspected AI was another crypto wave, and many use cases amounted to a chat interface on top of company data. This year, she sees companies rethinking user experiences and workflows, and recognising that processes have to be deconstructed and rebuilt to make AI products succeed.
The bad news, she says, is execution. This is a three-year-old field with no playbooks or textbooks, and the pre- and post-deployment lifecycle differs sharply from traditional software. Old handoffs between product managers, engineers and data people have broken down, and teams now need to look at agent traces together and own one shared feedback loop.
非确定性和自主权—控制权的权衡,改变了产品必须怎么建
Reganti explains that traditional software maps a user's intent through buttons and forms, as in booking a hotel, to a predictable action. In AI products that layer becomes natural language, so users can express intent in countless ways, and the LLM on the other end is a probabilistic black box sensitive to phrasing. Teams are therefore working with input, output and process that they do not fully understand.
The second difference is the agency-control trade-off. Many people obsess over building autonomous agents, she says, but every time you hand decision-making to a system you give up some control, so it must earn trust through reliability. Lenny sums it up: the software is both non-deterministic and sits on a dial between how much the AI does and how much the person stays in charge.
Kiriti Badam compares this to training for a hike up a big mountain: you do not start at the summit. You begin where impact is minimal and human control is high, learn what the current capabilities can do, then add context and tools and lean into more agency. He sees this pattern repeat across everyone he works with.
先高控制、低自主,并记下人实际做了什么
Badam uses customer support as a worked example, drawing on OpenAI's experience with spikes in support volume after launches. First the AI only suggests actions to human agents, who give feedback on which suggestions were good. Next it answers customers directly, and only after that does it gain abilities like issuing refunds or raising feature requests with engineering.
Reganti frames the goal as behaviour calibration, since you cannot predict a system's behaviour up front. She offers insurance pre-authorization as another example: routine approvals like blood tests or MRIs can go through AI, while an invasive surgery should stay with a human. Throughout, you log what humans do, which both protects the user experience and feeds a flywheel for improvement.
Lenny adds more progressions from their post: a coding assistant moves from inline completions to larger reviewed blocks to autonomous pull requests, and a marketing assistant moves from drafting copy to running campaigns to auto-optimising them. Badam says starting small forces a problem-first mindset, because it is easy to get lost in the complexity of the solution. Reganti cites a Berkeley paper in which roughly 74 or 75% of enterprises named reliability as their biggest barrier, which she links to why so many AI products today are productivity tools.
成功团队靠上手的领导、赋能文化和死磕工作流
Reganti describes a success triangle of leaders, culture and technical approach. Leaders have built intuitions over ten or fifteen years that AI forces them to relearn, so they need to get hands-on again. She recalls a CEO who blocked 4 to 6 a.m. every day for catching up on AI and who held weekend vibe-coding sessions, and she argues AI adoption is almost impossible to drive bottom-up.
On culture, she notes that fear of being replaced keeps subject matter experts from sharing the knowledge AI products need. Leaders should create a culture of empowerment, where people use AI to multiply their own output. Technically, the winners understand their workflows well enough to pick the right tool, whether that is an LLM, a machine learning model or deterministic code.
She is wary of one-click agents that promise gains within days, because enterprise data is messy, with tangled taxonomies, duplicated functions and tech debt. In her view, meaningful ROI takes four to six months of work even with a strong data and infrastructure layer, and a vendor selling out-of-the-box replacement of a critical workflow is doing pure marketing. Lenny adds that Dan Shipper told him the CEO using AI tools many times a day is the top predictor of success.
评测和生产监控都要,因为它们抓的失败不一样
Badam calls the debate over evals versus monitoring a false dichotomy. Evals are your product knowledge encoded into datasets, such as things the agent must never do. Production monitoring tracks metrics from live use, including implicit signals like a user regenerating an answer in ChatGPT, and tells you which traces are worth examining.
He walks through a loop in which monitoring surfaces failure patterns, you build an eval dataset for something that matters, such as an agent wrongly offering refunds, then ship a change. Because the second version can fail in new ways, monitoring is still needed. Lenny restates the point as not simply doing both, but recognising that each catches things the other will not.
Reganti says the word eval is now stretched across too many meanings: data labelling firms mean expert error analysis, some say product managers should write evals as the new PRDs, and others mean the whole feedback loop. She cites Martin Fowler's idea of semantic diffusion and says complex cases make LLM judges hard to maintain, so sometimes it is better to look at user signals and fix issues directly. She also tells of a client who said they did evals but only consulted public benchmarks like LM Arena.
Codex 把评测、客户信号、A/B 测试和大量手感绑在一起
Asked about Boris's remark that Claude Code runs on vibes, Badam says Codex takes a balanced approach. Coding agents are meant to be customised and used in many integrations, which makes it very hard to build an evaluation dataset covering every way customers will use them. He stresses that nobody can bet their life on one concrete set of evals.
He gives the example of a code review product that has gained a lot of traction and catches bugs inside OpenAI and at external customers. When changing the model or its reinforcement learning setup, the team A/B tests to see whether it still finds real mistakes and how users react, because annoyed users may simply switch the product off. The team also watches social media for problems, and for each new model, engineers test their own hard problems, a kind of custom eval per person.
「持续校准、持续开发」把迭代变成飞轮
Reganti says she and Badam devised the framework after building fully autonomous agents that were hard to fix because nobody knew how users would interact with them. In one customer support project, constant hot fixes and unforeseen problems forced them to shut the product down. She also points to the Air Canada case, where an agent hallucinated a refund policy the company then had to honour.
The development half of the loop is to scope capability, curate a dataset of expected inputs and outputs, set up the application, design evaluation metrics, deploy and run them. Curating the data often shows that team members disagree on how the product should behave, which is where product managers and subject matter experts contribute. The calibration half is to analyse real behaviour, spot new error patterns, apply fixes and design new metrics only where a pattern warrants it, since a badly defined tool is just fixed and forgotten.
She applies it to a customer support agent in three versions: routing tickets, then a copilot that drafts replies from standard procedures, then end-to-end resolution. Even routing can be hard in enterprises, where retail taxonomies are messy and undocumented rules abound, and the draft stage gives error analysis for free by showing what humans keep or edit. Lenny notes the name echoes CI/CD, with running evals and iterating on metrics in place of unit tests and deployments.
校准不再带来意外时再升级,情况一变就要重新校准
There is no rule book for when to graduate to the next stage, Reganti says; it is about minimising surprise. If you calibrate every day or two and see no new data patterns and consistent user behaviour, you are gaining little information and can go further. She stresses that it also comes down to feel at that point.
Events can throw calibration off again, such as a model deprecation that forces teams onto a model with different properties, or users changing how they talk to systems. She tells of an underwriting assistant at a bank that impressed users for three or four months, after which underwriters began asking deeper questions, such as what previous underwriters did for a case like this one. What seemed a natural extension to users required a very different build, which is when you recalibrate.
多智能体被误解,编程 Agent 被低估,动手本身被高估
Badam says multi-agent systems are misunderstood rather than overhyped. A supervisor agent directing sub-agents can work well, but dividing responsibilities by function and expecting agents to cooperate through some peer-to-peer protocol is not something current methods or models support. In a support setting it would be hard to control which agent replies to a customer. He thinks coding agents are underrated, since outside the Bay Area penetration is still low despite the online chatter.
Reganti jokes that evals are misunderstood rather than overrated, and calls jumping between tools and rushing to build overrated. Building is cheap, she argues, while design, understanding the pain point and deciding what to build are the valuable parts. AI is only a tool and the business problem comes first.
For 2026, Badam expects background or proactive agents that plug into where work happens and report back, such as a coding agent that has fixed five tickets for review at the start of the day, as ChatGPT Pulse already does with daily updates. Reganti is betting on multimodal experiences, arguing humans take in many signals beyond language, and that better multimodal understanding could unlock messy handwritten documents and PDFs that models still struggle to parse.
品味、主人翁感和韧性,才是把构建者分开的技能
Asked which skills to develop, Reganti says implementation will become very cheap, so design, judgment and taste matter most. The first years of a career once centred on execution mechanics, but AI now speeds that up, and later it is about what is uniquely you. She tells of a new hire who showed up with his own vibe-coded replacement for a task-tracking tool they paid heavily for, which she sees as the kind of agency and ownership that sets people apart, while acknowledging such apps carry maintenance costs.
She argues this will be the end of the busy-work era, where you can no longer sit in a corner doing something that does not move the needle. Lenny recalls a recent guest who replaced most of his sales team with agents, and a salesperson who quit when an agent took over the task of updating Salesforce. Badam adds that persistence is valuable and coins "pain is the new moat".
Badam explains that successful companies are not simply first or feature-rich; they went through the pain of working out the non-negotiables and trading them off against model capabilities. There is no textbook, so the knowledge built through iteration becomes the moat. The guests close by urging listeners to be obsessed with customers and the problem, to look at their data, and to spend most of their time understanding workflows, which Reganti says is what 80% of AI engineers and product managers actually do.
同频道的其他文章
1:10:27EN → 简体中文
1:30:46EN → 简体中文
1:42:04EN → 简体中文
1:21:44EN → 简体中文
1:01:00EN → 简体中文
1:25:13EN → 简体中文