Overview

This episode is a practical look at how Felix Riesberg, who leads several Claude product experiences at Anthropic, uses AI to take boring work off his plate and leave the interesting parts to humans. The throughline is simple: most people are still aiming too low with these tools, not because the tools are weak, but because people haven't built the reflex of handing bigger, messier problems to AI.

Claire and Felix move from everyday workflows in Claude co-work and live artifacts to a playful hardware demo: a $20 Bluetooth button with a tiny claw that celebrates or asks for approval when Claude needs input.

Key Takeaways

A recurring idea in the conversation is that the real bottleneck is not model capability. Felix argues that people still assume many tasks are "not for AI" when, in practice, almost any annoying digital task can be handed over if you frame it well. Claire puts it as an "anti-to-do list": when you're doing tedious work, stop and ask how Claude could do it, then ask how you can avoid ever doing it again.

Felix's house-planning example makes that concrete. He dropped real estate documents, a floor plan, and other files into a folder and asked Claude to infer dimensions, rebuild the floor plan with units, figure out his furniture, and help lay out the space. The useful move was not better prompting at the margins. It was pushing the task up a level, from "help me measure this" to "you figure out the whole setup."

The same pattern showed up in his promise tracker. People message him on Twitter with requests, and instead of manually remembering who he promised what, he told Claude to read his messages, track commitments, and find a way to do that without rescanning everything every time. He doesn't inspect the internals much. He cares whether the system works.

That attitude comes up more than once: judge AI by output, not by whether it used the method you would have picked. For personal tools and one-off apps, Felix is comfortable letting Claude build "good enough" software that may get thrown away in a month.

Live artifacts extend this from one-time outputs to ongoing tools. Rather than a static briefing page, Claude can pull fresh data from connected tools like calendars, Slack, email, and docs, then refresh that view on demand. The stronger use case is not a shallow dashboard but a context engine that prepares you for meetings by gathering the history, people, and likely topics around them.

Felix also makes a sharp point about kids. He says children are often better at this because they haven't learned what not to ask for. Adults, by contrast, have years of learned limits and bring those limits into tools that no longer need them.

Practical Steps

• When you hit repetitive admin work, pause and ask: "Can Claude do this?" Then ask a second question: "How do I set this up so I never do it manually again?"
• Give Claude folders, not snippets. Put related docs, screenshots, plans, receipts, or notes in one place and ask for the higher-order job, not just a narrow subtask.
• Use live artifacts for recurring workflows:
  • daily meeting prep
  • tracking commitments you've made
  • household or moving logistics
  • dashboards that need current data
• Connect your existing tools through Claude's connectors so artifacts can pull live data without extra API setup.
• If Claude goes off track, don't just rephrase angrily. Tell it what you expected and ask where its reasoning diverged. Felix says that often reveals a problem with the workflow or source data, not just the response.
• Use thumbs up and thumbs down in Claude products. Felix says that feedback is used to improve both the model and the product experience.
• Try a small hardware project if you want a fun edge case: a cheap Bluetooth or Wi-Fi device can become a physical approval button or status buddy for Claude.

Notable Quotes

• "AI is used poorly if it just needs to move the mouse cursor for you. I want AI to do a bunch of annoying things in the background to free you up for your creative energy." - Claire Vaux
• "The biggest gap that I see, it's not the capabilities of the tools. It is literally people being able to understand that almost any problem can go into these tools." - Claire Vaux
• "A truly magical thing is happening with kids because they've never learned what not to ask for." - Felix Riesberg

Overview

This episode looks at what it takes for a family business to survive across generations and still grow. The conversation centers on Johnson Security Bureau, a third-generation security company in the South Bronx, and the choices its CEO, Jessica Johnson-Cope, faces as she tries to scale without giving up the values her family built the company on.

Professor Henry McGee frames the case around three paths: stay focused on New York, expand geographically, or move into cybersecurity. The discussion keeps coming back to the same tension: growth creates opportunity, but it also puts culture, quality, and judgment under pressure.

Key Takeaways

Johnson Security Bureau’s story is about more than succession. Johnson-Cope describes the business as part of a larger family mission: creating jobs and mobility in a low-income community. That shapes how she thinks about growth. Expansion is not just about revenue; it is also about who gets hired, which partners get chosen, and whether the company can keep serving people the way her grandparents intended.

One strong point in the episode is that longevity in a family business does not happen by accident. McGee says owners need a real succession plan, early exposure for the next generation, and a way to manage family emotion before it turns into business conflict. Johnson-Cope adds another layer: access to strong networks matters. Her family’s connections to civic, business, and community leaders helped the company stay informed and supported across decades.

The conversation also shows why restraint can be a leadership strength. When a major client wanted the company to take on a much larger assignment, Johnson-Cope did not automatically say yes. She stepped back to ask whether the firm could deliver at the standard it expected of itself. That says a lot about her operating style: growth only counts if the business can execute well and stay aligned with its values.

Cybersecurity comes up as the most attractive and risky option. McGee points out that traditional guard services tend to have thin margins, while cybersecurity can be far more profitable. But the move is not simple. It means hiring different talent, competing with firms that already know the space, and changing what kind of company Johnson Security Bureau is. Johnson-Cope’s view is practical: physical security alone will not carry the company far enough, and trusted advisors have made clear that security firms that ignore technology will fall behind.

Practical Steps

• Build succession on purpose. Identify likely successors early, give them exposure to the business, and be clear about roles before a crisis forces the issue.
• Separate family feelings from business decisions as much as possible. That may mean formal governance, outside advisors, or regular decision processes everyone agrees to follow.
• Use networks as working assets. Stay close to mentors, industry experts, customers, and community leaders who can open doors and give honest advice.
• Pressure-test growth opportunities before accepting them. Ask:
  • Can we deliver at our current standard?
  • Do we have the people and systems in place?
  • Will this partner or acquisition fit our values?
• Treat adjacent expansion carefully. If you are moving into a field like cybersecurity, start by mapping the talent, capabilities, and competitive gaps instead of assuming your current model will carry over.
• Watch ego in decision-making. Johnson-Cope’s point is simple: when ego gets loud, judgment gets worse. That is usually the moment to call an advisor.

Notable Quotes

• Jessica Johnson-Cope: "If I wanted to see change in terms of the economy, where we lived and where we conducted business, that change would have to start with me."
• Jessica Johnson-Cope: "What's the point of having trusted advisors if you don't trust their advice?"
• Henry McGee: "The key to success is managing all the family dynamics."

Overview

This episode looks at what it takes to move from individual contributor to leader, especially for women who may need to work through both self-doubt and other people's outdated perceptions. Executive coaches Muriel Wilkins and Amy Su argue that leadership starts before the title does, and that the shift is as much internal as it is visible to others.

They talk through the awkward parts of that transition: learning to see yourself differently, getting others to catch up, and figuring out whether leadership is even the path you want.

Key Takeaways

A central point is that leadership is not something you switch on after a promotion. Wilkins says many people wait until they have formal authority before acting "leaderly," but that delay holds them back. The work starts earlier: speaking with judgment, asking better questions, showing composure, and taking responsibility for how others experience you.

The guests make a sharp distinction between asking for input as a follower and asking for input as a leader. Amy Su gives a practical example: instead of asking, "How should I price this proposal?" start with your own recommendation, explain your reasoning, then invite feedback. That small change signals judgment and ownership without shutting others out.

They also point out that internal change often happens faster than external recognition. You may know you've grown, but coworkers may still see the intern or junior employee you once were. For people who have spent years inside one company, that can become a real obstacle. The advice here is twofold: use your institutional knowledge and relationships as assets, but pay attention to signs that the organization has stopped updating its view of you. If the roles you want keep going to outside hires, that may be a message.

Another strong theme is that women can accept leadership opportunities too gratefully and not ask whether they are being set up to succeed. Wilkins pushes against that instinct. If you're offered a role, the organization already wants you. Ask for visible backing from your manager, especially if former peers will now report to you, and make sure the conditions around the role support your success.

The conversation also covers visibility and trust in remote work. Virtual settings make both harder because people see less of your context. The guests say visibility now takes more planning: decide who needs to know you, how they should know you, and why. Trust depends more heavily on follow-through, responsiveness, and clear communication about delays.

Practical Steps

• Start leading before you get the title. In meetings and one-on-ones, lead with your point of view first, then ask for feedback.
• Learn your organization's leadership criteria. If there is a formal competency model, get it from HR and use it to spot the skills you need to build.
• If you're promoted internally, ask for explicit support from your boss. If former peers will report to you, discuss how that transition will be introduced and backed.
• Watch for signals that your company still sees an old version of you. If that pattern continues after direct career conversations, test your value in the outside market.
• In remote work, be selective about visibility. Identify the key stakeholders, the right channel, and the purpose before filling calendars with meetings.
• Build trust by replying quickly, even if only to confirm receipt and set expectations for a fuller response later.
• Before saying yes to extra work, ask whether you're stepping up from a leadership mindset or slipping into an old habit of being the reliable junior person.
• If you're unsure about pursuing leadership, look at the next three to five years rather than treating it as a lifetime choice.

Notable Quotes

• "The minute I have a client who says, with real conviction, that they do want to lead, that's actually the biggest breakthrough because they have to own it." - Muriel Wilkins

• "You're lucky to have me." - Muriel Wilkins, on the mindset people should bring when stepping into a bigger role

• "The world of possibilities to demonstrate a higher order of leadership is available to all of us at every moment, whether somebody gives us permission or not." - Amy Su

Overview

This episode looks at what happens when work stops being a stable part of who we are. Maya Shankar, a cognitive scientist and host of A Slight Change of Plans, talks with Adi Ignatius about sudden disruption, identity loss, and how people can respond without getting trapped by fear or self-pity.

Her main point is that change does not just alter our circumstances. It can change us, too, and that can be a source of strength if we know how to work with it.

Key Takeaways

Shankar starts from her own story. As a young violinist training at Juilliard under Itzhak Perlman, she expected a life in music until a hand injury ended that path. What hit her hardest was not only losing the violin, but losing the identity attached to it. From that, she draws a sharp lesson: tying your whole sense of self to a role or title leaves you exposed when life interrupts the plan.

Her alternative is to anchor identity to "why" rather than "what." For her, the violin was really about emotional connection. Once she saw that, the loss was still painful, but it did not have to mean the loss of self. For people in work settings, that might mean identifying the thread that runs through different jobs: service, learning, creativity, problem-solving, connection.

She also pushes back on the idea that resilience is a fixed trait. In her view, resilience can be built. Part of that comes from accepting that big changes can reshape the person going through them. The version of you facing the disruption today is not the same version that will exist after it. That shift matters because it makes change feel less like a test of your current capacity and more like a process that can expand it.

Another useful point is about uncertainty. Shankar cites research showing people can feel more stress from a 50 percent chance of a bad outcome than from certainty that the bad outcome will happen. Ambiguity is often what rattles us. That helps explain why people can spiral during layoffs, career pivots, or technological shifts like AI.

On failure, she draws on brain science and neuroplasticity. Failure signals that the current approach is not enough, and that is what pushes learning and adaptation. She says organizations can treat failure that way too: as evidence that something hard was attempted, and as a source of information for what to change next.

For leaders, one of the better parts of the conversation is her warning against rushing past reflection. If leaders only power through disruption, they miss the signals showing how people are actually responding. Burnout, for example, may not just be overload. It may reflect a loss of meaning or a weaker connection to the organization's purpose.

Practical Steps

• Ask yourself what sits underneath your role. Write down what you do, then ask "why does this matter to me?" a few times until you get past the title.
• When facing a setback, separate the event from your identity. Losing a job, missing a promotion, or needing to retrain does not tell the whole story of who you are.
• Watch for rumination. If your mind keeps looping on regret or worst-case scenarios, interrupt it with a specific routine: journaling, a walk, a conversation, or a time-boxed review of options.
• If you manage people, listen for what is actually being said. "I'm exhausted" may mean too much work, but it may also mean the person no longer sees meaning in the work.
• During periods of change, build in pauses for reflection. Teams need moments to assess how the change is affecting morale, priorities, and behavior.
• Approach AI and other major shifts with more humility about prediction. Shankar's point is that people are bad at forecasting how change will feel, so avoid assuming the worst before you've lived through it.

Notable Quotes

• "It can be quite precarious for us to anchor our self-identities and our self-worth and our self-confidence too tightly to what we do." - Maya Shankar
• "Anchor my identity not simply to what I do, but to why I do that thing." - Maya Shankar
• "We can come to see change, especially unexpected negative change, not simply as something to endure, but as an opportunity to reimagine who we can be." - Maya Shankar

Overview

This episode focuses on how to communicate well when you are stressed, tired, emotionally loaded, or carrying a message you do not fully want to deliver. In a live conversation with Amy Bernstein and Amy Gallo, leadership coach Muriel Wilkins argues that strong communication starts less with polished speaking and more with self-awareness, listening, and managing your own reactivity.

The discussion stays grounded in real workplace moments: board presentations, hard emails, difficult conversations, and even expressing appreciation in ways that feel natural rather than forced.

Key Takeaways

Wilkins says the communication skill she has spent her life working on is listening. Not listening so she can reply, but listening so the other person feels heard and understood. For her, that is closely tied to staying less reactive, especially under stress.

A central idea is that before any important conversation, you need to check your state. Ask: Am I tired, angry, frustrated, prepared? The point is not to hit some perfect emotional condition. It is to know your own thresholds. Wilkins says she can communicate while tired, but not well when angry or frustrated. Amy Bernstein adds that weariness may let her deliver the message, but leaves her with too little patience for the discussion that follows.

The episode also pushes back on the idea that every comment or provocation deserves an answer. Wilkins says part of good communication is deciding whether a response is needed at all, and whether the moment is worthy of one. That pause creates room for judgment instead of reflex.

When people are not following your message, Wilkins says impatience usually comes from wanting to be at point B while everyone else is still at point A. If the audience is still at mile one, you have to meet them there. That can mean stepping back, reframing the issue, restating assumptions, or asking what they are actually hearing and what concerns they have.

On appreciation, she makes a useful distinction: authenticity starts with intent, not performance. If you feel real gratitude, you do not need balloons and fanfare. A direct thank-you, a short email, a text, or a public note can all work if they match your style and are meant.

She also draws a line between “taking the easy way out” and “doing it with ease.” Sending a hard message by email to avoid discomfort may be easier for you, but not better for the relationship. Ease, in her view, comes from preparing yourself so you can handle the other person’s reaction without falling apart.

Practical Steps

• Before a high-stakes conversation, do a quick check-in:

  • What am I feeling right now?
  • What state makes me communicate badly?
  • Do I have enough energy for the follow-up, not just the opening message?

• If you feel yourself getting reactive, anchor your attention. Focus on the other person’s voice, your breathing, or the stated purpose of the meeting.

• In a meeting that drifts, restate the point: what decision needs to be made, what topic you are there to discuss, and what needs to happen next.

• When your message is not landing:

  • step back to the bigger frame
  • restate the assumptions
  • ask, “What concerns do you have?” or “What are you hearing from me?”

• For hard messages, choose the medium based on the relationship and the human impact. If transparency and connection matter, talk directly rather than hiding in email.

• Show appreciation in a form that feels natural to you. A simple, specific thank-you is enough if it is real.

Notable Quotes

• “Communication is a vehicle for relationships.” - Muriel Wilkins

• “You have to meet them where they are.” - Muriel Wilkins

• “There’s a difference between taking the easy way out or finding the easy way and doing things with ease.” - Muriel Wilkins

Overview

This episode is a forward-looking conversation with Dan Shipper about how AI is changing day-to-day work, without the usual claim that whole job categories are about to disappear. His core argument is that AI will reshape interfaces, workflows, and team structure much faster than it wipes out human roles.

Dan says the near future of work splits in two: companies will have shared agents that people delegate work to, often through Slack, and individuals will do more of their actual work inside AI-native surfaces like Codex or Cowork. He is also unusually bullish on SaaS, product managers, and designers, which runs against a lot of the current doom talk.

Key Takeaways

Dan’s clearest point is that “automation” still needs ownership. He argues that agents do not just run on their own; they need humans who care about them, maintain them, and keep them useful. That leads him to predict that most companies will start with one shared “super agent” rather than a personal agent for every employee, because one company-level system is easier to maintain than dozens of brittle ones.

He also thinks the interface layer is shifting. Instead of every SaaS product trying to become its own AI assistant, people will increasingly work inside tools like Codex and access SaaS products from there. In his framing, the browser moves inside the AI work surface, not the other way around. That changes product design: software will need to support a human and an agent working on the same task at the same time.

A strong contrarian idea in the episode is that AI helps SaaS more than it hurts it. Dan says agents increase usage of SaaS tools rather than replacing them. He points to his own company’s growing software spend as evidence that more AI use has led to more demand for software, not less.

On jobs, he rejects the “jobpocalypse” story. His view is that models make yesterday’s competence cheap, which lowers the value of repeatable work but raises the value of judgment, taste, framing, and original thinking. That is why he is especially bullish on PMs and full-stack designers: people who know what to build, what good looks like, and how to turn messy signals into clear decisions.

He also expects more AI-written internal work, and less stigma around it. Strategy docs, planning memos, emails, and other operational writing will increasingly be drafted by AI, as long as the human behind it understands and stands behind the result.

Practical Steps

• Start using tools like Codex, Cowork, or Cloud Code for real work, not just experiments. Try them on email, docs, research, planning, and light product work.
• Organize your work by project inside these tools so the model keeps context over time.
• If you build software, make it usable by both humans and agents. That means clear interfaces, good logs, approvals, rollback options, and systems that stay in sync across browser and API usage.
• Test whether your company needs a shared agent in Slack for repetitive requests like data questions, support workflows, or document retrieval.
• If you are a PM or designer, get much more hands-on with AI building tools. Dan’s point is simple: people with product sense or design taste can now execute much more directly.
• Treat every major new model release as a prompt to revisit old ideas. Dan’s habit is to “turn the rock over again” and see what newly works.

Notable Quotes

• “Automation is a lie. Every agent needs a human.” - Dan Shipper
• “What models do in general is they make yesterday’s human competence cheap.” - Dan Shipper
• “I am super, super bullish on PMs and full stack designers.” - Dan Shipper

Overview

This episode argues that AI should raise the standard of human work, not just speed it up. Neuroscientist and physician Mithu Storoni says the old model of efficiency - more output per hour - fits assembly-line work, but knowledge work now depends more on the quality of ideas, decisions, and problem-solving.

Her main point is that people do their best thinking in different mental states, not by grinding steadily at a desk all day. If AI takes over more routine production, then human value shifts toward insight, creativity, judgment, and learning, which all depend on how well we manage our brains and our work rhythms.

Key Takeaways

Storoni says efficiency in modern work should mean better thinking, not just more activity. As AI handles more repetitive tasks, people are left with the harder part: framing problems, spotting patterns, making decisions, and coming up with ideas that software cannot produce on command.

A central idea is that the brain does not work well in one fixed mode for hours at a time. Focus, idea generation, and learning each depend on different conditions. She describes a "gear two" state as the sweet spot: alert enough to concentrate, but not so stressed that attention narrows or panic sets in. Too little arousal leads to sluggishness; too much leads to anxiety and poorer thinking.

She also pushes back on the desk-bound model of work. If you are stuck on a problem, that may be a sign that your environment no longer matches the kind of thinking needed. Walking can help because it changes body state, keeps you alert, and lets attention loosen enough for new connections to emerge without tipping into rumination.

Another strong point is timing. Storoni says there are windows in the day that better support creativity and others that better support focused analytical work. For many people, creative thinking peaks shortly after waking and again later in the evening, while sustained focus tends to be stronger from mid-morning to lunch and again later in the afternoon. Standard office schedules often waste those windows.

On learning, she says a small amount of tension is useful. The discomfort that comes with uncertainty can prime the brain to learn faster, as long as it does not slide into full stress. In a fast-changing workplace, the ability to stay calm while slightly stretched may matter more than trying to feel comfortable all the time.

Practical Steps

• Match the task to your mental state. Use your sharper focus periods for analysis, writing, and decision-making. Save routine admin and standard meetings for lower-energy windows.
• If you are stuck on a problem for 10 minutes or so, stop forcing it at the screen. Get up and walk without looking at your phone.
• Protect your early waking period for idea work when possible. Capture thoughts, sketch concepts, or outline problems before email and meetings take over.
• Treat slight discomfort during learning as useful data, not failure. If you are learning a new tool or model and feel a bit stretched, that may mean your brain is engaged.
• If boredom is the problem, add challenge or feedback. Increase the difficulty of the task, or break passive monitoring work into actions that require small responses.
• For managers, build schedules around the kind of work a team does. Put routine meetings after lunch, protect focus blocks, and reserve better creative windows for brainstorming or innovation work.

Notable Quotes

• "The mind is not like muscle. It rests while it works and it works while it rests." - Mithu Storoni
• "Humans now influence the productivity of their organization by the quality of their output." - Mithu Storoni
• On learning in uncertain times: staying in the zone where you feel "slightly apprehensive, slightly jittery," without tipping into panic, is the state that helps people adapt fastest. - Mithu Storoni

Overview

This episode is about how middle managers and other non-executives can get good ideas taken seriously by senior leaders. Amy Bernstein talks with Michigan Ross professor Sue Ashford and Harvard Business Publishing executive Ellen Bailey about "issue selling" - the work of turning an idea into something decision-makers can see, support, and act on.

The conversation treats persuasion less like a single pitch and more like a campaign. A strong idea is rarely enough on its own; the real work is framing the problem, tying it to business goals, anticipating resistance, and building support before the big meeting.

Key Takeaways

A recurring point is that leaders do not reject ideas only because the ideas are bad. Sue Ashford says executives often fail to see the immediate link between a proposal and organizational performance. That means the burden is on the person with the idea to make that link plain.

Ellen Bailey offers a simple screen she uses before she even starts pitching: What problem are we solving? What are the benefits for both the organization and the people in it? How does the idea connect to strategy or goals? That framing keeps the conversation out of the weeds and gives leaders a reason to care.

Both guests stress that resistance is predictable and useful. Sue argues that people get farther by reducing the forces against change than by pushing harder for it. If you only add pressure, people push back. If you understand what others think they might lose, you can reframe the proposal, adjust it, or answer the concern directly.

Another strong point: do not go it alone. Sue recommends mapping allies, blockers, and fence sitters, then moving each group differently. The aim is to mobilize allies, win over the undecided, and contain opposition rather than picking direct fights with skeptics. Amy and Ellen both describe the value of talking one-on-one with stakeholders before any formal presentation, both to improve the idea and to give others some ownership.

The episode also warns against getting too attached to your own solution. Research, Sue says, shows that having a proposed answer helps, but a rigid answer can limit better options. Senior leaders may have a broader view of timing, trade-offs, and competing priorities, so flexibility matters.

Practical Steps

• Pressure-test the idea early with trusted colleagues, friends, or partners. Ask whether the issue is real, whether others see it, and whether it is worth pursuing.
• Build your case around three questions:
  • What problem does this solve?
  • What is the upside for the business and for employees?
  • How does it support strategy?
• List likely allies, blockers, and fence sitters. Plan different conversations for each group instead of using the same message everywhere.
• Before a formal pitch, talk to key stakeholders one-on-one. Ask what concerns them, how they would describe the idea back to you, and what would make it easier to support.
• Adapt the format to the audience. Ellen says some people want a narrative, some want bullets, some need visuals.
• Prepare for trade-offs. If the proposal affects workloads, status, customer relationships, or resources, address that directly rather than hoping it will be ignored.
• Keep your emotions in check. Strong conviction helps you keep going, but the actual conversation works better when you stay calm and open to revision.
• Ask, "What are two or three other ways we could solve this?" That can turn a stuck debate into a workable plan.

Notable Quotes

• "What's the problem that you're trying to solve?" - Ellen Bailey
• "Issue selling is a campaign." - Sue Ashford
• "Your job is to mobilize your allies, to influence your fence sitters, to pressure the blockers." - Sue Ashford

Overview

This episode is a sharp debate about whether OpenAI and Anthropic are actually ready to go public, and what their numbers say about the state of the AI business. The hosts also dig into SpaceX's IPO filing, question the story around data centers in space, and close on a growing public backlash to AI after several commencement speakers were booed by graduates.

Key Takeaways

The clearest point is that "ready for an IPO" may not mean financially ready. OpenAI reportedly brought in about $5.7 billion in first-quarter revenue, but the hosts stress that its adjusted operating margin was still deeply negative. Their read is that OpenAI may be going public not because the business is tidy, but because it may need fresh capital, broader investor access, and a chance to set the market narrative before Anthropic does.

Anthropic's situation looks cleaner on paper, at least for now. The Journal report discussed on the show says Anthropic could hit profitability in the second quarter on roughly $10.9 billion in revenue. But the hosts are skeptical. They point to a SpaceX-related deal that may have temporarily reduced Anthropic's costs in May and June, which raises the possibility that the profit story is being helped by timing rather than durable economics. Their bigger point is that Wall Street still likes a profitability story, even if it comes with caveats.

A second theme is that the recent AI growth curve may not hold. The hosts argue that the last six months, especially around coding tools like Claude Code, may have been a period of unusually loose spending. Companies let employees experiment freely, bills piled up, and only later did managers start asking whether usage justified the cost. That suggests the current rate of revenue growth for model companies may slow as buyers get stricter about budgets and ROI.

SpaceX gets the roughest treatment. The filing shows a large business, but not one that seems to match the scale of its rhetoric. Starlink appears to be the standout asset, while the broader pitch around AI and even data centers in space strikes the hosts as a stretch. They question whether SpaceX can plausibly claim such a massive AI addressable market, especially when its current AI position trails OpenAI, Google, and Anthropic.

The final takeaway is political and cultural. AI leaders keep making the case for the technology in ways that alienate the public. The boos at graduation speeches are treated as a warning sign, not a sideshow. If AI keeps being framed around layoffs, surveillance, and management control, the hosts think backlash will grow and politicians will eventually respond.

Practical Steps

For listeners trying to make sense of this market, a few useful rules emerge:

• Look past revenue growth and ask what margins look like after ordinary operating costs.
• Treat forward projections with caution, especially when they depend on unusual quarter-to-quarter assumptions.
• If you evaluate AI vendors, ask how much customer usage is subsidized and whether those economics still work once companies tighten budgets.
• Separate a company's strongest current business from its grand future story. In SpaceX's case, the hosts think Starlink is real; the giant AI-in-space thesis is far less proven.
• Pay attention to public sentiment. If you build, invest in, or deploy AI, weak messaging and visible worker anxiety can become business risk.

Notable Quotes

• "For every dollar of revenue the company generated, it lost $1.22." - Alex Kantrowitz, on OpenAI's reported operating profile
• "You need to view everything these companies do as who can get out to market first." - Ranjan Roy
• "If you really cared about safety and the good of the people that you're building AI for, go public so we can see whether you're BSing us or not." - Alex Kantrowitz

Overview

This episode is a conversation with Dr. Komal Megharajani, an oncologist, physician-scientist, former White House health official, and advisor on AI in healthcare. The discussion stays grounded in where AI is actually helping medicine today, where it still falls short, and why cancer care depends on judgment, teamwork, and evidence more than tech hype suggests.

Key Takeaways

Dr. Megharajani’s background gives her a rare view across clinical care, software, public health, and federal policy. She spent years at Memorial Sloan Kettering working in computational oncology and genomics, then joined the Biden-Harris administration to work on the Cancer Moonshot and broader health policy. Her main lesson from Washington was that major healthcare decisions are often shaped by very small groups, which makes it even more important for outside voices, including private industry, to push useful ideas into the room.

On AI, she cuts against the fantasy that it will simply "cure cancer." She points out that AI has been part of oncology planning for years, including through CancerX, a program tied to the Cancer Moonshot that helped early-stage oncology AI companies build usable products. The real shift is not that AI suddenly appeared, but that the tools are now good enough to start fitting into daily work.

The biggest current wins are practical. One is documentation, especially ambient dictation tools that turn doctor-patient conversations into draft notes. Another is clinical decision support, where AI can suggest possible diagnoses, next tests, and supporting literature. That second use case matters because it moves past clerical help and starts assisting with medical reasoning, while still keeping the doctor in charge.

A central point in the episode is that medicine does not run on textbooks alone. Patients rarely match the exact populations studied in clinical trials, so there is always "white space" where doctors have to use experience and compare notes with peers. AI can summarize guidelines and surface evidence, but it cannot yet replace the judgment that comes from discussing hard cases with other clinicians. Dr. Megharajani argues that a better direction for AI may be helping those doctor-to-doctor exchanges happen across hospitals and geographies, not just within one conference room.

She also flags a less glamorous but serious issue: data quality. A lot of the information that shapes care lives in conversation, context, and unstructured notes, not in clean databases. Even when data is available, using it for research requires consent, anonymization, and care to avoid false patterns from retrospective analysis.

Practical Steps

• Start with admin pain points. In healthcare settings, look first at documentation, search, note drafting, and retrieval of clinical information.
• Use AI for decision support only when it can show its work, including guidelines, papers, or source material a clinician can check.
• Build tools that fit existing medical culture. Doctors already consult peers, discuss edge cases, and compare interpretations. Support that workflow instead of trying to replace it.
• Treat medical data carefully. Any product using patient information needs clear consent processes, anonymization, and statistical review.
• For individuals, use AI to learn about public health basics from trusted sources, such as smoking cessation, prevention, and screening guidance, rather than self-diagnosing.

Notable Quotes

• "People don't read textbooks. They present the way they present." - Dr. Komal Megharajani
• "There’s a lot of white space in the practice of medicine." - Dr. Komal Megharajani
• "Don’t count on AI to replace your doctor. Use it to learn about public health." - Paul Ford

Overview

This episode is about what changes, and what does not, when you sell AI software into enterprises and AI-native startups. The guest argues that despite all the hype about rewriting the sales playbook, the core job still looks familiar: help customers change how they work, show up in person, and give them a clear path to results. The big shift is speed, communication style, and the amount of guidance buyers now expect across messy AI tool stacks.

Key Takeaways

The strongest point in the conversation is that enterprise AI sales still runs on change management more than raw product quality. The guest says large companies do better with structured rollouts, training, and repeated in-person support than with a "drop the tool in and let people figure it out" approach. At Windsurf, they saw that companies with guided deployments had better outcomes six months later than companies that treated AI tools like an internal app store.

He pushes back on the anti-sales mood common in newer AI companies. Product-led growth matters, but it does not replace opinionated selling. Buyers want vendors who will study current workflows, recommend a better one, and stay involved long enough to make adoption stick. That is part of why systems integrators and long-standing partners still matter: trust compounds over time.

Selling to AI-native companies is different, but mostly in tempo rather than fundamentals. Those buyers already know the basics. They want fast feedback, async communication in Slack or text, and short loops of experimentation. A cycle that takes six to eight weeks in a traditional enterprise account might take five to eight business days with an AI-native customer. Still, the same seller traits matter: curiosity, problem solving, follow-through, and caring enough to go beyond the obvious.

The guest also makes a clear case for simple process with room for individual judgment. He wants a measurable sales system that raises the floor without lowering the ceiling. In practice, that means a few clear stage requirements, strong funnel instrumentation, and enough freedom for great reps to do unusual things that build trust. His example was a rep who gave a customer’s son guitar lessons over Zoom during Covid. That was never in the playbook, but it built a real relationship.

A final thread is enablement. He treats it as a core operating function, not a support function. In his view, great go-to-market teams invest early in training, partner development, and data so they can scale without chaos. AI can help reps prepare, but it cannot replace judgment, political awareness, or the ability to handle real conversations in the room.

Practical Steps

• If you sell AI into enterprises, build rollout plans before the contract is signed. Define kickoff dates, 30-day milestones, 90-day milestones, and what success should look like for users and executives.
• Do not rely on self-serve adoption alone. Add training, office visits, workflow reviews, and follow-up sessions, especially for large deployments.
• Keep your sales process simple. For each stage, set three to five clear requirements that must be true before moving forward.
• Instrument the funnel end to end. Track time between stages, conversion rates, and differences by segment and rep so coaching is based on evidence, not opinion.
• Hire for traits before polish. The guest looks for smart, coachable, competitive people who care about customers and can earn trust.
• Treat enablement as part of growth. Test onboarding, measure ramp time, and keep training going for managers as well as reps.
• Stay close to post-sales. If expansion drives most long-term revenue, sales should care about deployment quality from the start.

Notable Quotes

• "Change management dictates success in the enterprise more than technology."
• "You can't fake giving a shit."
• "I want us to have a super measurable, predictable sales process, but I want what we do to raise the floor. What I don't want is for us to cap the ceiling."

Overview

This episode is about the failed Musk v. Altman case and what it says about OpenAI, Elon Musk, Sam Altman, and the AI business around them. Liz Lopatto argues that while the lawsuit was formally about OpenAI's shift from nonprofit to for-profit status, the real point seemed to be punishing Altman, tying OpenAI up in court, and dragging ugly internal fights into public view.

Key Takeaways

The biggest legal point is simple: the jury found Musk filed too late. The core factual dispute was whether Musk only learned enough to sue during the brief period when Altman was pushed out of OpenAI, or whether he had known for years. The jury sided with the latter view, so the case stopped there.

Liz's read is that the trial still served Musk's goals even in defeat. By tying the claim to "the blip," he was able to pull internal emails, texts, and board drama into evidence. That gave him a way to air damaging material, force OpenAI to spend heavily on defense, and keep pressure on Altman as OpenAI moves toward bigger commercial ambitions.

A second takeaway is that almost nobody came off as reliable. Liz says the trial reinforced her view that Altman is not a straight narrator, but she also says that applied to nearly everyone involved: board members, executives, and Musk himself. The trial did less to change views of Musk or Altman than to confirm what many people already thought about them.

The one person whose image may have taken a sharper hit was Mira Murati. According to the testimony discussed in the episode, she was involved in Altman's removal, then quickly positioned herself around his return. Liz's point is that this looked less like principle and more like someone waiting to see who would win.

There is also a business angle beyond personal spite. If OpenAI were weakened badly enough by litigation or a financial ruling, rivals could benefit from the fallout: talent on the market, computing contracts up for grabs, and deal terms shifting across the AI sector. Even so, both hosts circle back to the same idea: this fight looked personal first.

Practical Steps

If you're following high-profile tech litigation, separate the formal claim from the actual motive. Read the complaint, but also ask what discovery, headlines, or delays the plaintiff gets even if they lose.

For founders and executives, the episode is a reminder that internal governance chaos rarely stays internal. Keep decision records, board communication, and conflict-of-interest boundaries clear. If a leadership crisis hits, half-explained moves can do long-term damage even when the company survives.

For anyone evaluating AI companies, don't focus only on product demos and funding rounds. Pay attention to control structures, board power, side deals, and who can force expensive distractions. Those details can matter as much as model quality.

A useful habit here is to ask three questions before trusting a public narrative:

• Who benefits from this version becoming public?
• What happened procedurally versus what people are claiming emotionally?
• Is this new information, or just confirmation of an existing reputation?

Notable Quotes

• "There are two things that we should distinguish. There was what the case was ostensibly about, and then there was what the case was actually about." - Liz Lopatto

• "I kind of think there's no floor about these things." - Liz Lopatto

• "People know who these guys are. None of this is a surprise." - Liz Lopatto

Overview

This episode is a clear tour of what makes Rust different, led by Alice Real, who works on Android Rust at Google, helps maintain Tokio, and advises the Rust language team. The conversation covers why Rust keeps gaining ground, how ownership and the borrow checker actually work, where people get stuck, and how the language is governed without a single person in charge.

A big theme runs through the whole discussion: Rust tries to catch classes of mistakes at compile time that other languages often leave for production.

Key Takeaways

Alice’s pitch for Rust depends on what you use today. For TypeScript developers, she frames Rust as a strong backend choice: a way to build servers that are less likely to fail from common mistakes such as unchecked nulls, ignored errors, or stale docs. She points to explicit error handling with Result and the ? operator, plus Rust’s doctests, where code examples in docs are compiled and tested.

The strongest case for Rust is the mix of safety and low-level control. Alice says Rust gives you memory safety without a garbage collector, which matters in embedded systems, kernels, and latency-sensitive backend services. Garbage collection can add overhead and pause behavior; Rust’s model cleans values up when they go out of scope.

The hard part for new users is usually not syntax. It is data modeling. Alice’s point here is useful: when people say they are “fighting the borrow checker,” the fix is often not to rearrange code line by line, but to change the data structure itself. Developers coming from GC languages often reach for cyclic references, while Rust tends to push you toward trees, DAGs, or explicit shared ownership with types like Arc.

Her explanation of ownership is simple and practical: if a value moves from a to b, a is no longer usable, which avoids double frees. Borrowing then lets code temporarily refer to data without taking ownership, and the borrow checker makes sure references do not outlive the data they point to. That is a big reason people say, as Alice puts it, “when it compiles, it works,” even if she is careful not to treat that as a literal guarantee.

The governance section is also telling. Rust is run by teams, not a benevolent dictator. Bigger changes go through RFCs, discussion, and a final comment period. That makes the process slower than one-person rule, but it spreads decision-making and review across the project.

Alice also sees clear differences in ecosystem maturity. She says backend services, CLI tools, embedded work, and kernel work are strong fits today, while frontend Rust via WebAssembly still feels less ready. On Rust in Linux, she says the change in attitude has been dramatic year over year, and that kernel maintainers recently agreed Rust is no longer experimental there.

Practical Steps

• If you are curious about Rust, start with a backend service or CLI tool, not a frontend app.
• When Rust code feels blocked by borrow checker errors, inspect your structs first. Ask whether you created cycles or hidden shared ownership.
• Use Option and Result directly instead of trying to recreate exception-heavy patterns from other languages.
• Write documentation examples as real code snippets so doctests can catch drift when APIs change.
• If shared ownership is actually needed, reach for Arc deliberately instead of forcing plain references to do the job.
• To contribute, pick something you already want changed. Alice suggests starting from issue trackers, Zulip discussions, or adjacent projects like Rust-for-Linux and Rust-GCC.

Notable Quotes

• “When it compiles, it works.” - Alice Real
• “The thing that a lot of people struggle with is that they keep trying to change the code when the solution is to change the struct.” - Alice Real
• “Rust is no longer experimental in the kernel.” - Alice Real

Overview

This episode is about a mismatch: the internet was built for humans using interfaces and software using APIs, while AI agents need a third way to interact with services. Dan Schipper talks with Alex Rattray, CEO of Stainless, about MCP, Model Context Protocol, and why turning an API into something an LLM can use well is harder than it sounds.

Rattray argues that the winners in AI infrastructure will be the companies that make their products usable by agents, but he also makes clear that today's MCP implementations are often clumsy, brittle, and hard to secure.

Key Takeaways

Rattray's core point is that MCP is not a magic wrapper around existing APIs. A straight one-to-one mapping from API endpoints to MCP tools usually performs poorly. Models struggle when they face too many tools, vague descriptions, large payloads, and long chains of actions that depend on earlier results.

That leads to a more product-heavy view of MCP than many people expect. Good MCP design starts with real use cases, not protocol compliance. Rattray says teams need to watch how customers work, identify the tasks AI could simplify, and then shape tools around those tasks. In practice, that means fewer tools, tighter naming, cleaner input schemas, and responses that return only the data the model needs.

He also points out a scaling problem. If an API has a lot of endpoints, exposing all of them creates a tool-discovery mess and eats context. Stainless has experimented with a "dynamic mode" where the model first lists endpoints, then inspects one, then executes it. That scales better, but it adds extra turns and some loss in reliability.

The more interesting idea comes later: instead of giving models dozens of tools, give them a code execution environment plus access to docs. Rattray thinks this "cyborg" model - part LLM, part regular software - is a better long-term design. The LLM writes code against typed SDKs, the code runs close to the API, and only compact results come back into context. That cuts down token waste, handles pagination better, and uses type systems to catch bad requests before they hit production systems.

On security, he is blunt: restricting MCP exposure is not enough. He argues that permissioning belongs at the API layer, with OAuth and granular scopes, because the real risk is what the agent can do under the hood, not what the MCP menu happens to show.

Practical Steps

If you're building an MCP server or agent-facing API, the advice here is pretty concrete:

• Start with a narrow job to be done. Don't expose your full API first and hope the model figures it out.
• Keep the tool count low. Group actions around user goals, not internal endpoint structure.
• Write tool names and descriptions with care. Ambiguity costs accuracy.
• Shrink input schemas. Ask for as few parameters as possible, and describe each one clearly.
• Return less data. If the model only needs a refund ID and status, don't dump the full object.
• Set up evals across clients and models. Rattray mentions Cursor, Claude Code, and other clients because behavior changes across the stack.
• Build a feedback loop. If users say the result was useless, make sure that signal reaches the server team.
• Use typed SDKs where you can. They give agents guardrails that raw HTTP calls do not.
• Treat security as an API design problem. Use scoped auth and permission boundaries before the agent ever gets access.

Notable Quotes

"APIs are the dendrites of the internet." - Alex Rattray

"We haven't figured out how to expose an API ergonomically to an LLM in the same way that we've figured out how to expose it ergonomically to a Python developer." - Alex Rattray

"The future of AI is cyborgs." - Alex Rattray

Overview

Alex Kantrowitz talks with Boris Cherny, who leads Claude Code at Anthropic, about why the product is growing so fast, what makes it different from a chatbot, and whether that growth can hold up. The conversation stays grounded in the mechanics: tool use, rate limits, token costs, coding productivity, and the gap between flashy demos and durable business value.

A big theme runs through the whole episode: AI gets more useful when it stops being just a text box and starts acting in software. Cherny argues that agents are already changing how code is written and how non-engineers get work done, even if the products are still rough around the edges.

Key Takeaways

Claude Code’s breakout seems tied less to “better autocomplete” and more to agency. Cherny’s core point is simple: the product became meaningfully different once it could use tools, edit files, access browsers, and act across software systems. That shift turns AI from an assistant that suggests into one that executes.

He says growth inside Anthropic and among customers has been unlike anything his team has seen before, with each model release pushing another jump in usage. He also says Anthropic’s own products now matter far more to the business than they did a year ago, even if he avoids saying whether Claude Code has overtaken the API side.

On sustainability, Cherny pushes back on the idea that “token maxing” is driving a big share of demand. His case is that there are too many customers and too many real productivity gains for usage to be explained away by gamified internal quotas. He points to Anthropic’s own result: the company says code written per engineer rose about 250 percent after Claude Code, without a drop in code quality or reliability.

The discussion on efficiency is more mixed. Kantrowitz presses on cases where models loop, waste tokens, and struggle with basic actions. Cherny doesn’t deny that. His argument is that intelligence comes first, efficiency follows, and many of today’s annoyances look like early-stage product problems rather than hard limits of language models.

One of the more interesting parts is his view of work. He doesn’t say AI removes people from the loop. He says each person gets more leverage. A software engineer can run several coding agents at once. A marketer or accountant can automate work no one expected them to touch. The bottleneck, in his view, is still good people with good judgment.

Practical Steps

• Give teams room to experiment before you try to optimize AI usage. Cherny says companies should start by removing friction around access to tokens, not by forcing dashboards and quotas.
• Build psychological safety into adoption. If people think failed experiments will be punished, they will stick to old workflows and never find the useful ones.
• Test the newest models again, even if you were unimpressed six or twelve months ago. Cherny says capability is changing fast enough that old judgments go stale.
• Pick the model and effort level based on the job. Bigger models and higher effort can produce better work, but they also cost more and may be slower.
• Watch for token-hungry plugins and integrations. Anthropic is seeing that some add-ons consume tokens badly, so teams should track what is actually burning budget.
• Start with concrete jobs: drafting sales material, organizing files, booking travel, handling bookkeeping, or shipping product features. The useful path here is task-by-task, not abstract AI strategy.

Notable Quotes

• Boris Cherny: “With a chatbot, you’re going back and forth and you’re talking, but an agent, and Claude Code is an agent, it can use your tools.”
• Boris Cherny: “The amount of leverage an individual has goes up. And we are still bottlenecked on the number of good people.”
• Boris Cherny, on model progress: “Every month there’s a step change in what it can do.”

Overview

Clare Vale gives a first-day Google I/O reaction focused on the AI releases that look most useful right away: new Gemini 3.5 models, updates to Google's coding tools, and a batch of consumer creative features for image and video generation. The episode moves from technical announcements to live tests, and the through line is simple: Google showed a lot, some of it looks strong, but the actual experience still feels uneven.

Key Takeaways

The biggest model story is Gemini 3.5 Flash. Clare says Google is positioning it as a fast coding model that competes with stronger reasoning models while running at much lower latency. She ties that to a broader push into agents: coding agents, sub-agents, scheduled tasks, hooks, project workspaces, and CLI-based workflows. Her read is that Google is catching up to tools from OpenAI and Anthropic, especially Codex and Claude Code-style setups, but doing it with Google's usual strength in multimodal work and speed.

She keeps coming back to multimodality as Google's edge. In her view, Gemini is especially good when the job involves files, video, or moving from one format to another, like video to text or image to video. That matters more than benchmark charts because it points to where teams might actually pick Gemini first.

On the coding side, the new "anti-gravity" IDE and CLI add familiar agent features: projects, scheduled tasks, sub-agents, hooks, native Git worktrees, and slash commands. Clare likes the direction, especially long-running goal-based commands and "grill me" style interactions, but she does not buy the speed story outright from one quick test. Her live impression is that it did not feel dramatically faster, even if Google says it should be.

The consumer tools are where the episode gets more mixed. Nano Banana image generation is fast and more text-aware, but her portrait test comes out bad enough that she calls it horrifying. The newer video model, which she refers to as Omni, looks more promising. She highlights longer clips, better character consistency, reference-based generation, and conversational editing as the features that could matter for real video work. Flow, Google's video tool built around that model, also points toward more production-style AI video workflows with reusable characters and avatars.

But Google's launch problem shows up over and over: too many product names, hard-to-find entry points, and features that either fail or are not ready. The failed avatar setup becomes her clearest example of the gap between launch-day promise and what a user can actually do.

Practical Steps

If you're deciding what to test from these announcements, Clare's priorities are clear:

• Try Gemini 3.5 Flash first for coding tasks where speed matters, especially inside an IDE or CLI workflow.
• Use Gemini when your work depends on files, video, or converting between formats. That is the use case she trusts most.
• Test Google's agent features in a contained project before rolling them into real work. Start with one task, one repo, one workflow.
• Pay attention to slash commands and long-running goal-based tasks if you already use agentic coding tools.
• For creative work, focus on video before image generation. Clare sees more upside in video consistency and conversational editing than in current image quality.
• Expect launch-day friction. Before committing a team to any new Google tool, confirm that the feature is live, accessible, and stable.

A practical way to evaluate the stack would be to run one coding task, one multimodal file task, and one creative video task, then compare the result against the tools you already use.

Notable Quotes

• "Google is really going full bore into agents." - Clare Vale
• "The Google models, the multimodal capabilities of these models is very high." - Clare Vale
• "The promise is really good for some of these things, but the reality is if you're not able to use them or they're broken on the day, then people are going to lose patience for some of this." - Clare Vale

Overview

This episode pushes back on the loudest version of the AI jobs story. Casey Newton talks with Google SVP James Manyika, who argues that AI will change a lot of work, but that claims about mass near-term job destruction confuse fast technical progress with much slower economic change.

The conversation starts with new survey data from economists: in a high-end AI progress scenario by 2032, they expect a serious drop in labor force participation. Manyika does not dismiss disruption, but he says most of the pain in the next decade is more likely to come from job redesign, skill shifts, and weak policy support than from half of white-collar work disappearing.

Key Takeaways

Manyika’s main point is that tasks and jobs are not the same thing. He says AI can now handle a much larger share of individual tasks than it could a decade ago, including some longer, more complex ones. But most occupations are made of bundled, interdependent tasks, and one hard-to-automate step can keep the whole job from being fully replaced. That is why, in his view, task automation can rise fast while full job automation stays relatively low.

He also argues that current labor market anxiety is getting mixed up with broader macro effects. He points to research on entry-level hiring declines and says some of the sharpest drops started before ChatGPT was widely used in business, which suggests AI is only one part of the story. His view is that both the promised productivity gains and the feared job losses from AI have so far shown up less in the real economy than the public debate suggests.

A second strong theme is that “job change” may matter more than job loss. Casey raises the concern that workers may shift from doing creative work to checking machine output, which can feel worse even if the role still exists. Manyika partly agrees, but says the upside is that workers can spend more time framing problems, testing ideas, and directing systems rather than grinding through repetitive steps. He thinks the creative center of many jobs will move, not disappear.

The policy piece is where he sounds most worried. He says the lesson from past shocks, including trade, is that even a modest number of displaced workers can be devastated if support is weak. His concern is less “there will be no work” and more “we will do a poor job helping people move into new work.”

Practical Steps

For workers and managers, the advice from this episode is pretty concrete:

• Analyze jobs at the task level. List what parts of a role can be automated, what parts need human judgment, and where tasks are tightly linked.
• Train for supervision, problem framing, and evaluation. If AI handles first drafts, the human value shifts toward setting direction, catching errors, and making decisions.
• For engineers, do not confuse coding with computer science. Manyika says demand for software development is still rising, but the bar is moving toward broader technical judgment, not just producing lines of code.
• Track real labor data, not just CEO rhetoric. Hiring slowdowns may reflect interest rates, post-COVID corrections, or other business pressures alongside AI.
• Push for transition support inside companies and through public policy: retraining, wage insurance, internal mobility, and clearer plans for workers whose roles change.

Notable Quotes

“Don’t confuse the pace of technological development with how quickly this plays out in the economy.” - James Manyika

“What things keep me awake at night about AI and work, it’s not job loss, quite honestly, for the next decade. It really isn’t. But it’s these questions about how do we support the transitions that work and workers are going to need to go through.” - James Manyika

“The median prediction for the rapid scenario is 55% [labor force participation]. That would be a really historic reduction.” - Ella Marquianas

Overview

Fiona Feng, who leads Claude Code and Cowork engineering and product at Anthropic, argues that AI has changed where software teams get stuck. Writing code used to be the expensive part. Now that code generation is much faster, the pressure has moved to review, verification, security, maintenance, and cross-functional coordination.

Her talk is about what happens when old team habits stop fitting the new reality. She walks through the norms her team changed, where they still want human judgment, and how she thinks about org design, hiring, planning, and metrics in a world where nearly every commit is AI-assisted.

Key Takeaways

The clearest idea in the talk is that teams should stop assuming their old processes still make sense. Feng says many workflows were built around scarce engineering time: heavy planning, strict ownership, long design docs, and process layers that accumulated over time. If coding is no longer the main constraint, those habits can turn into drag.

On her team, planning has become shorter and closer to execution. She says six-month roadmaps aged badly within a few months because the tools and product space changed too fast. Instead of debating ideas in documents for too long, the team often moves straight to prototypes or PRs.

She also makes a sharp point about technical disagreement: when code is cheap to produce, it can be faster to build multiple options than argue abstractly. She describes generating several PRs to compare approaches and discuss their effect on callers, not just the internal implementation.

At the same time, she is not arguing for full automation. Feng says AI is useful for style checks, lint, tests, bug-catching, PR babysitting, and routine feedback, but humans still need to handle risk-sensitive work. Legal review, trust boundaries, security-sensitive code, and product taste still need people with judgment.

Another theme is that roles are getting messier. Engineers can do more writing and design-adjacent work with AI support, while PMs and designers can ship more code. That changes hiring too. Feng says she now values creative builders with product sense and people with deep systems expertise more than raw coding throughput.

She also pushes for flatter teams. Managers on her team are expected to start as individual contributors first, use the product directly, and stay close to the code. Her view is that leaders need that firsthand contact to make good calls in a fast-changing environment.

Practical Steps

Start with one workflow your team complains about or avoids. Ask two questions:

• What problem was this process originally meant to solve?
• Does it still solve that problem now?

If the answer is weak, either remove it or replace it with something lighter.

A few concrete moves Feng recommends:

• Shorten planning cycles. Replace long-range detailed plans with near-term priorities and quick prototypes.
• Use code to settle technical debates. Build two or three versions and compare the tradeoffs in practice.
• Put more effort into verification. Add tests, automation, and earlier checks so bugs are caught before release.
• Split review work by risk. Let AI handle routine review tasks, but send security, legal, and product-quality questions to humans.
• Revisit ownership rules. Instead of asking “who wrote this,” ask what you actually need: context, accountability, or expertise.
• Hire for taste and systems judgment, not just output volume.
• Give teams permission to kill stale processes. Feng says processes rarely remove themselves.

For metrics, she suggests watching onboarding ramp time, PR cycle time, and how often commits are AI-assisted, while keeping quality and reliability in view so speed does not become the only measure.

Notable Quotes

• “What served you prior may not serve you any longer.” — Fiona Feng
• “When building is cheap, arguing expensive.” — Fiona Feng
• “Processes quietly stop working.” — Fiona Feng

Overview

This episode centers on what changes for product leaders when the company is backed by private equity rather than venture capital. Nick Ken, currently interim CPO at Winmau, uses his work building a connected darts product to explain how ownership structure shapes product decisions, team expectations, and what success looks like.

He also talks about bringing digital product thinking into a traditional manufacturing business, why product people need commercial awareness, and why knowing your market matters if you want to build something meaningfully different.

Key Takeaways

Nick’s main point is simple: product managers need to understand who really owns the business. In a VC-backed company, he says you are usually still working with a founder, often someone with product or engineering instincts. In a PE-backed company, you are working for a financial owner, and that changes the tempo, the language, and the tolerance for uncertainty.

That leads to a sharp difference in how product work is judged. Nick says VC settings usually leave more room for exploration, discovery, and even pivots while a company is still finding product-market fit. PE-backed businesses, by contrast, tend to work to a tighter timetable tied to a future sale, often in a three-to-five-year window as he describes it. That makes delivery speed, certainty, and contribution to the value creation plan much more prominent than open-ended discovery.

His work at Winmau gives that point some texture. The company has spent a century making dartboards, and is now building a connected product that tracks throws through cameras and feeds data into digital experiences such as online play, training, stats, and rewards. Nick is trying to keep the physical feel of darts intact while adding the software layer that many other sports already have.

He is also clear that passion for the product matters, especially in consumer products. He prefers hiring people who have some real interest in the category, because they are more likely to notice details that matter. At the same time, he does not want teams trapped by industry habits. His answer is to look both at direct competitors and at products in other sectors. He mentions Revolut as a reference point for user experience, not because a darts app should copy a banking app, but because good patterns can come from anywhere.

Another strong thread is competitor awareness. Nick argues that many product teams do too little of it. The point is not feature copying. It is knowing what exists so you can choose where to differ.

Practical Steps

• Ask early who the real decision-maker is: founder, CEO, board, PE owner, or a mix. That tells you how product choices will be judged.
• Match your product process to the funding model. If the business is PE-backed, expect tighter timelines and stronger pressure to show direct commercial return.
• Translate product work into business language. Tie roadmap items to revenue, margin, retention, cost, valuation, or speed to exit.
• If you are adding software to a hardware or legacy business, set regular cross-functional updates. Nick’s approach is straightforward: frequent syncs, visible progress, and shared documents.
• Hire for product skill and category interest where you can. People who care about the domain tend to spot quality issues faster.
• Study competitors to find gaps, not to mirror their roadmap.
• Pull ideas from outside your category. Look at the best user experiences anywhere and ask what principles could transfer.

Notable Quotes

• "Product managers need to be super commercially minded."
• "In path A, PE firm, you're actually working for a financial institution ultimately, because that's the owner of the business."
• Nick Ken: "You cannot build a differentiated product if you don't know what you're differentiating from."

Overview

This episode is a conversation with Petra Wille about what product leadership actually involves, where many leaders fall short, and why AI has made the job harder rather than simpler. She argues that too many people move from strong individual contributor to leader without stopping to learn what leadership requires, then end up reacting to noise instead of building the conditions for teams to do good work.

A big part of the discussion centers on her new "product leadership wheel," a reflection tool built to help leaders assess their role more clearly, spot gaps, and improve how they spend their time.

Key Takeaways

Petra’s core point is that leadership is not just a promotion with a bigger scope. It is a different job. She describes it as providing directional clarity, building and coaching teams, and doing the personal work needed to stay effective and avoid burnout. A strong IC does not automatically become a strong leader, and many companies still act as if that jump happens on its own.

She also points to a structural problem: leaders often do not have a clear definition of their role, and neither do the people reporting to them. That creates a gap where leaders think they are doing fine, while ICs feel they are not getting what they need. Her view is that both sides are often working without a shared framework, so feedback stays vague and frustration builds.

On AI, Petra is optimistic but not naive. She says product leaders now have to learn the job again in a world that is shifting fast. They need to understand AI at three levels: personal productivity, team workflow, and the product itself. At the same time, she warns against reflexive overuse. Faster output can easily turn into more features, more tech debt, weaker judgment, and teams whose mental load is already maxed out.

One of the sharpest ideas in the episode is her "shipyard" metaphor. Product teams build the boats. Leaders build the shipyard. That means shaping the environment: team setup, role clarity, strategy, feedback loops, and how decisions connect from vision down to backlog. Many leaders spend too much time jumping into product work and not enough time building that structure.

She also says leaders need to offer an optimistic story about the future, especially with AI. If teams only hear fear, risk, and automation panic, leadership is failing part of its job.

Practical Steps

• Define leadership as a real discipline, not a reward for past performance. If you just moved into a leadership role, write down what your new job is and what it is not.
• Run a reflection exercise on where your time goes today. Petra’s categories include team building, executive alignment, process design, strategy, and directional clarity. Compare your actual time spent with where you think it should go.
• Ask for structured feedback from your team. Do not ask "How am I doing?" Ask about specific areas like role clarity, coaching, strategy communication, and decision-making support.
• Check whether your strategy is alive in day-to-day work. Can teams connect backlog items to quarterly goals, and those goals back to strategy and vision? If not, leadership communication is probably too static.
• With AI, experiment on purpose. Use it to learn faster, test ideas, or remove low-value admin. Do not turn every efficiency gain into more feature output.
• Write an optimistic future narrative for your team. Be specific about how your product or company can use AI in a way that helps people, instead of only talking about disruption.

Notable Quotes

• "A good individual contributor does not make a good leadership figure." - Petra Wille
• "Leadership is all about building the shipyard." - Petra Wille
• "We’re still inventing the future, and product people are part of inventing the future." - Petra Wille

Overview

Molly Graham opens from a place a lot of people will recognize: AI talk feels tiring, pushy, and loaded with hype. What changed her mind was a simple writing use case. After feeding an AI her past writing, she got a strong first draft in minutes and saw, all at once, the upside and the threat: less effort, more speed, and real job displacement.

Her guest, Instacart co-founder Max Mullen, makes the case that AI is different from recent hype cycles because it already solves everyday problems. The conversation stays grounded in a practical question: what should an average person actually do with AI right now, and what is worth the time?

Key Takeaways

The clearest filter in the episode is this: does the technology solve a real problem in someone’s life? Mullen says that is why he never got pulled into crypto in a serious way. He followed it, found it interesting, but never found a consumer problem it solved for him. AI felt different once it started handling real tasks like writing, planning, and summarizing.

A second point is that AI’s value is often in getting you most of the way there. Mullen gives the example of planning a Japan trip. The model produced a strong itinerary, but a human still had to handle the last-mile work of bookings and phone calls. His view is that people often frame AI the wrong way, as if it either does nothing or does everything. In practice, it handles a large share of the work, while humans still need to check, decide, and finish.

He also argues that most people’s understanding of AI is out of date. His “six-week rule” is simple: if a task failed six weeks ago, try again. The tools are improving fast enough that old impressions stop being useful quickly. That matters because many skeptical users tried early versions, saw errors or made-up answers, and never went back.

The other strong idea is that expertise is unusually accessible right now. Mullen says even the people seen as AI experts may only be a month or two ahead, because the tools keep changing. For listeners who feel behind, that is a more honest picture than the usual panic that everyone else has already figured it out.

At the same time, neither speaker treats AI as flawless. Mullen is clear that it still makes mistakes and needs oversight. He also thinks some kinds of work will stay distinctly human: coaching, accountability, handmade art, and work where the person behind it is part of the value.

Practical Steps

Start small and pick one platform. Mullen suggests sticking with one assistant so it builds context about your work and gives better answers over time.

Good entry points:

• Paste in an email you wrote and ask for a clearer version.
• Upload a performance review and ask for three specific actions to improve.
• Use it to interpret dense information, then bring better questions to the human expert involved.
• Try personal planning tasks like calendars, summaries, or trip outlines.

Use the six-week rule. If AI failed at something recently, retest it instead of assuming the answer is still no.

Treat it as a collaborator, not an authority. Let it handle drafts, summaries, and repetitive work, but verify facts and expect to do the final pass yourself.

Make room for it during work hours. Molly’s closing point is sharp: this should not just be “Saturday homework.” If AI is going to change how work gets done, learning it belongs in the week, not only on the weekend.

Notable Quotes

"Great technology should come to you. You shouldn’t have to go to it." - Molly Graham

"If you tried to do something with AI more than six weeks ago and it didn’t work, forget about that. You have to try it again." - Max Mullen

"You and I are maybe one or two days of playing with AI away from being experts." - Max Mullen

Overview

This episode is a first for the hosts: an in-person recording after more than two years of podcasting together remotely. That setup becomes the entry point for a wider conversation about career optionality, building a business without outside funding, and what they have learned from running Insider Loops together.

A big thread through the episode is the difference between choosing your own game versus joining one that someone else designed. They compare full-time roles, venture-backed startups, and bootstrapped businesses, then get specific about why their current way of working feels more aligned with the lives they want.

Key Takeaways

The strongest idea in the episode is that optionality only helps if you are honest about what you actually want. Both hosts talk about being tempted by shiny paths - working at a company like Anthropic, joining a generational winner, or starting a venture-backed startup - but they keep coming back to the same question: does that path fit their values around freedom, pace, accountability, and life outside work?

They make a clear distinction between bootstrapping and venture-backed building. In their view, raising money can give a company more room to operate, but it also changes the game. Once investors, boards, and the next round enter the picture, founders can end up serving a system that looks a lot like traditional employment, just with higher stakes. Bootstrapping is harder at the start, but it forces contact with reality. You need customers, cash flow, and tighter feedback loops.

Another useful point is their take on planning. They argue that long-range plans can become stale fast when the business is changing every week. What works better for them is strong judgment, short planning cycles, and tight scoping. A week is treated as a long time, not a short one. That lets them ship, learn, and change direction without getting trapped by plans made under old assumptions.

Their partnership is also a major theme. They describe a setup where one brings speed, ideas, and instinct for zero-to-one moves, while the other turns those moves into repeatable systems and handles operational structure. They see this complementarity, plus direct communication and shared standards, as a big reason the business is working.

Practical Steps

• Ask yourself what game you are playing. Write down the rules, rewards, and tradeoffs of your current path. Then ask whether you chose that game or inherited it.
• When a new opportunity looks attractive, go past status and surface appeal. Check it against what you want your days to feel like, not just what the logo or outcome might signal.
• If you are exploring your own business, start with something that gets you closer to the market fast. Focus on what people will pay for and what feedback you can collect quickly.
• Plan in shorter cycles. Pick the most important thing for the next week, scope it so it can actually ship, and resist building the second or third version too early.
• Protect working relationships by clearing tension early. They repeatedly point to direct, respectful conversations as a reason their partnership stays healthy.
• Pay attention to what is already working. They suggest that one of the easiest mistakes is ignoring a strong signal because some other path looks more exciting from a distance.

Notable Quotes

• "When you join a company, you are signing up to play a game that they've designed for you." - Mark
• "I don't think people, I think businesses die because of competition. They mostly die because of suicide." - Mark
• "Having fun in isolation from the market is a hobby." - Ben

Overview

This episode is about a shift in how people work with coding agents: away from long Markdown plans that nobody reads, and toward HTML artifacts that people will actually look at, edit, and share. The guest argues that as agents get more autonomy, the human role is less "product manager" in the old sense and more "compute allocator" - deciding what work is worth spending model time and money on.

Key Takeaways

The sharpest point in the conversation is that readable plans still matter, maybe more than before. The host says letting Claude run for hours is really a budget decision, and the guest agrees: if you're spending real compute, you need specs, PRDs, and plans that keep you involved. The problem with Markdown is not that agents struggle with it. The problem is that humans stop reading it.

HTML works here because it pulls the person back into the loop. In the demo, a simple brainstorm prompt produced a visual HTML artifact with eight demo ideas, mockups, and risks. The same happened with planning: instead of a wall of text, the model generated a browsable implementation plan with code excerpts, file structure, UI ideas, and logic. The guest's test for success was blunt - "this is something that I will actually read."

There is also a useful prompting lesson. The guest kept prompts simple, asked for a few must-have elements, and then left room for the model to surprise him. He warned against over-constraining the system with heavy-handed "expert planner" instructions. His approach is to state what matters, then add an escape hatch like "whatever is needed to give me maximum context."

Another strong idea is using agents to build temporary interfaces for thought, not just production software. When one section of the plan needed refinement, the guest asked Claude to create a custom editable HTML UI just for that decision problem. He used it to tweak rules, then copied the result back into the plan. That turns planning itself into software.

The conversation also drew a clean line between testing and verification. They mention synthetic datasets, rubrics, CLI runs, and even having the agent record what it did. The point is that old unit-test thinking is too narrow for agent workflows. You need ways to check outcomes, not just code paths.

Practical Steps

• Ask for brainstorms and plans in HTML when you know you will ignore long Markdown output.
• Keep prompts short. Specify the few things you need, such as mockups, code excerpts, or implementation detail, then leave room for the model to decide the rest.
• Use a two-step planning flow:
  • First, ask the model to interview you and surface unknowns.
  • Then ask for a plan that gives you "maximum context."
• If one part of a plan feels weak, ask the model to make a custom editable UI for that specific decision instead of revising it only through chat.
• Share HTML artifacts as links so teammates are more likely to open and read them.
• Build lightweight verification loops:
  • run tools against synthetic data that captures past failures
  • define clear expected outcomes
  • ask the agent to show evidence of what it did

Notable Quotes

• "You're a compute allocator, babe. That's the job now." - host
• "I'm not going to read a longer output than the screen on Claude Code." - guest
• "Verification is not testing." - guest

Overview

This episode is a long look at BuzzFeed's latest reset. Jonah Peretti explains why he agreed to sell a 52 percent stake in the company to Byron Allen, step down as CEO, and move into a new role leading BuzzFeed AI. The conversation also turns into a postmortem on the social-platform era that helped make BuzzFeed huge and then left it exposed when Facebook and others changed course.

Peretti argues that BuzzFeed now has to become a more direct-to-audience business, with AI used both inside the company and in new consumer apps. Nilay Patel keeps pressing on whether that vision is a real turnaround plan or another version of betting on platforms.

Key Takeaways

Peretti is blunt that BuzzFeed needed money and a structural change. He says the company's "going concern" warning reflected a real capital problem, but also says there was outside interest in BuzzFeed's assets. His case for Byron Allen is less about rescue financing than division of labor: Allen handles deals, advertisers, and capital, while Peretti focuses on product and technology.

One of the clearer points in the interview is Peretti's view that media leadership has changed. In BuzzFeed's high-growth years, he says understanding platform mechanics was the edge. Now he thinks media is a deals business. That tracks with his larger admission that organic growth from major platforms is weak, and publishers can no longer count on social networks to send traffic at scale.

Peretti pushes back on the common retelling that Facebook never really paid publishers. He says BuzzFeed did get millions through rev share and other programs, but the support was temporary and never turned into a lasting model. His larger complaint is that tech platforms chose a cheaper creator-heavy feed over underwriting professional news and entertainment, which he sees as bad for both media and the platforms themselves.

On AI, his pitch has two parts. First, use it internally to spot patterns in audience behavior and help employees make more things faster, including games. Second, build new products such as BF Island and Conjure, which are closer to social apps than traditional publishing. Nilay's read is sharp: after years of being burned by social networks, Peretti now wants to run some social products himself.

The most revealing business point is that BuzzFeed's future monetization looks mixed and somewhat unsettled. Peretti points to programmatic ads as the floor, then adds commerce, memberships, and freemium app revenue on top. He also says AI economics may improve fast enough that products that barely work today could work later as model costs fall.

Practical Steps

For media operators, creators, or product teams, the episode suggests a few concrete moves:

• Build direct audience habits. Peretti says a majority of BuzzFeed's traffic is now direct. That means front pages, repeat-use products like games, newsletters, and apps matter more than chasing social referral spikes.
• Treat distribution as product design. BuzzFeed's games spread through iMessage and repeat play, not just search or feeds. Make things people send to friends.
• Use AI where speed changes the math. Peretti's example is writers making games without needing a full engineering queue. Look for work where faster iteration can produce more output from the same team.
• Don't rely on one revenue source. Ads alone were not enough. Pair audience revenue, affiliate commerce, subscriptions, and paid app features.
• Be careful with AI in trust-heavy products. Peretti draws a line at AI-written journalism for HuffPost. If trust is the product, keep humans visibly in charge.

Notable Quotes

• Jonah Peretti: "We're really realizing you can't have someone between you and your customer."
• Jonah Peretti: "The kind of organic growth on the big platforms is really just quite anemic."
• Nilay Patel: "After all of this time, what Jonah Peretti wants most of all is to just run the damn social networks himself."

Overview

This episode is a wide-ranging conversation with hardware leader Caitlin Kalinowski about where AI goes once software starts to top out. Her basic case is that the next big wave is the physical world: robots, manufacturing, autonomy, supply chains, and defense.

She also gets concrete about why hardware is hard, what VR got right even if it did not become mainstream, why humanoid robots are still early, and what separates companies that can actually ship physical products from companies that just want to.

Key Takeaways

Kalinowski sees VR less as a failed bet than as a training ground for what comes next. The work that went into spatial sensing, depth, SLAM, and human perception now feeds directly into robotics, drones, autonomous systems, and AR glasses. In her view, VR gaming may stay niche, but the technology stack built for it matters far beyond headsets.

She argues that AI behind a keyboard will eventually feel saturated, even if nobody knows when. Once that happens, the harder and more valuable frontier is moving atoms rather than text: manufacturing, industrial systems, robots, and real-world sensing. That shift is already pulling talent toward hardware and robotics.

A repeated theme is that hardware has very different rules from software. As she puts it, hardware teams only get a handful of real "compiles" across a product's life. Once a design goes to mass production, you cannot patch it the way you patch code. That forces conservative decisions, heavier testing, and a stronger focus on tolerances, reliability, and supply chain risk.

On humanoids, she is interested but cautious. The current generation looks more like advanced prototypes than ready consumer or workplace products. Safety is a real blocker: a strong robot operating next to people needs soft materials, lower mass in the limbs, predictable motion, and clear signals of intent. She thinks many tasks will be better served by dedicated robots than by one general-purpose humanoid.

The most pointed section of the episode is about industrial policy and defense. Kalinowski says the US needs to reindustrialize and rebuild more independent supply chains, especially for magnets, actuators, batteries, memory, and other foundational parts. She agrees with the view that military investment needs to tilt harder toward drones and away from legacy assumptions built around systems like aircraft carriers. Looking at Ukraine, she says the pace of change in warfare may exceed the pace of change in consumer electronics over the next two years.

Practical Steps

• If you are building hardware, define your goals early and keep them stable. Price, weight, display quality, power, and feature set should be clear before the program is deep underway.
• Start with the hardest constraint first. Do not begin with the easy parts of the design. Find the pinch point that could break the product and solve that before anything else.
• Put extra iteration into the parts people touch most. For a laptop, that might be the keyboard and trackpad. For a robot, it may be the interface, motion cues, or handoff points with humans.
• Move fast on known tasks. Kalinowski’s rule is simple: if you know something needs to be done, do it now, because an unexpected problem is coming.
• Reduce supply chain exposure where you can. Pre-buying parts like memory may be worth it if your business can support the risk.
• If you are hiring, look for strong generalists, a few people with deep domain skill, and young engineers who are already working in an AI-native way.

Notable Quotes

• "What you can do behind a keyboard with AI is gonna saturate. When that happens, the next frontier is the physical world." - Caitlin Kalinowski
• "We need to invest a lot more in drones than in aircraft carriers." - Caitlin Kalinowski
• "If you walk into a room and a robot's just like, like it's creepy." - Caitlin Kalinowski

Overview

This episode focused on a basic question behind the AI boom: who actually controls the value? The hosts used newly revealed emails from the Musk-Altman case to unpack Satya Nadella's private frustration with Microsoft's OpenAI deal, then widened the conversation to Google's next model, Anthropic's small-business push, and the growing mess around AI-generated media.

The throughline was control versus access. Microsoft got early access to OpenAI, but Nadella's own words suggest he worried Microsoft was spending heavily without owning enough of the stack.

Key Takeaways

The most revealing part of the episode was Nadella's internal email. He says Microsoft was sitting as a "thin layer" on top of Nvidia while the model IP sat with OpenAI, and that the company faced billions in losses without enough control. The hosts read that as unusually direct evidence that even Microsoft saw the downside of its celebrated partnership.

One host argued Nadella was right to worry early. The other argued Microsoft still wasted its lead. The core criticism: Microsoft had a chance to turn OpenAI's models into standout products across Office, Bing, Azure, and GitHub, but moved too cautiously. The result, in their telling, is that Microsoft had distribution, demand, and a model partner, yet still failed to make its software feel AI-first.

That point led to a broader comparison with Google. The hosts see Google as the current AI leader among the big consumer platforms, even if it still trails the top labs in mindshare. Google's edge, they argue, is that Gemini is starting to show up inside products in ways that feel more native, while Microsoft still looks patchy and over-branded with overlapping Copilot offerings.

Anthropic's new "Claude for Small Business" got a mixed reaction. One host liked the direction, especially for bookkeeping and business workflows. The other saw it mostly as packaging around capabilities that already existed. Still, both implied the market is shifting from model demos to task-specific tools that can replace real service work.

The episode also touched on OpenAI's reported tension with Apple. The hosts found it telling that OpenAI seems to keep ending up in strained partnerships. Their read was simple: if your model is buried in a weak user experience, distribution alone does not help much.

Finally, the Monet prank made a larger point about AI and taste. A real Monet painting was posted online and labeled AI-generated, leading critics to attack it as sloppy and fake. The hosts used that to show how quickly people now judge work based on origin rather than quality.

Practical Steps

• If you run a business, ask where your AI dependence sits. Are you owning the customer relationship, the workflow, the data, or just paying for someone else's model output?
• Audit your products for "AI-first" versus "AI-added." If the AI feature feels bolted on, users will notice.
• Test task-specific AI tools against paid services you already use, especially bookkeeping, analytics, ad copy, and document review. Compare output, time saved, and error rate.
• When evaluating partnerships, look past headline access. Check who owns the IP, who controls distribution, and who carries the operating risk.
• Be careful judging content by label alone. Review the work first, then ask how it was made.

Notable Quotes

• Satya Nadella: "Right now, we are a very thin layer on top of NVIDIA and the IP is with OpenAI."
• Satya Nadella: "If we're going to spend this kind of money and not have control of destiny, it makes no sense."
• Alex Kantrowitz: "Use OpenAI technology in its full capacity to change the way your products work and make them AI first."

Overview

This episode is a candid look at how Figma's CFO grew from an early finance and biz ops hire into the top finance role without following the usual "bring in the seasoned public-company exec" script. Her answer is part luck, part leadership support, and part a steady habit of filling gaps, asking better questions, and learning fast enough to keep up with the company.

A second thread runs through the conversation: what the CFO job looks like when AI is changing product strategy, cost structure, and team design at the same time. She argues that finance has to be a strategic function, not a reporting function.

Key Takeaways

Her account of career progression is less about having all the answers and more about being explicit about what she did not know. At Figma, that meant taking on messy areas after the COO left, then hiring strong leaders in functions where she had little prior expertise, including legal, security, compliance, and sales ops. The pattern was simple: step into the ambiguity, ask a lot of questions, and build enough judgment to spot excellence in people before fully knowing the function yourself.

She draws a sharp line between a solid CFO and a great one. A solid CFO can read the statements and keep the trains running. A great CFO, in her view, keeps pushing into second- and third-order questions: what is actually driving the number, what is changing underneath it, and what decision should follow from that. Otherwise, finance becomes "a traffic cop," which she sees as a weak version of the job.

Another lesson is that influence is harder than analysis. She says she started out assuming that if the spreadsheet was right, everyone would agree. What changed was learning that alignment depends on understanding how other executives see the problem, what incentives they carry, and what level of detail each audience needs. That matters even more in a public company, where any statement can come back a quarter or a year later.

On AI, her view is that the opportunity got bigger and the rules changed with it. She says Figma accepted lower gross margins as it invested in AI products, because the long-term upside justified it. At the same time, she does not want more bets for the sake of more bets. She wants more well-reasoned bets, backed by real product thinking and enough resourcing to give them a chance.

She also has a clear bias toward promoting from within, though not blindly. Internal talent carries context and trust. But when a leader is no longer keeping pace with the business, she says the company has to act quickly rather than defaulting to comfort.

Practical Steps

• Be direct about your gaps. Say what you know, what you do not know, and what you plan to learn.
• Raise your hand for orphaned work. The biggest career jumps often come when a role or process has no obvious owner.
• When hiring outside your own expertise, talk to enough strong candidates that you learn what "great" looks like before making the call.
• Do not rely on analysis alone to persuade people. Tailor the case to each stakeholder's incentives and concerns.
• Build recurring business deep dives. She describes regular reviews of funnel metrics, experiments, sales performance, and acquired businesses so finance can spot issues early and push action.
• If AI is changing your market, revisit old constraints. That may mean accepting lower margins or broader experimentation if the payoff is materially larger.
• Promote internally when you can, but do not confuse loyalty with fit. If someone is not scaling with the company, make the decision early.
• If going public feels like a likely destination, start years ahead with people and process. She says that at Figma the shift began when public-company readiness started to feel inevitable.

Notable Quotes

• "I was very candid on the things that I knew, things that I didn't know, and was empowered to go and figure it out."
• "If you get stuck staring at a P&L... you're not doing your job. You're being a traffic cop."
• "I want someone who's like an extremely first-principle thinker. I don't care if you've done this thing like eight different times over."

Overview

This episode is about forced arbitration: the clauses buried in terms of service and employment contracts that block people from suing in court and push them into private dispute systems instead. Brendan Ballew argues that this shift was not an accident of modern tech, but the result of decades of court decisions, especially from a conservative Supreme Court that stretched a 1925 law far beyond its original purpose.

The conversation starts with Ballew's current anti-corruption work through the Public Integrity Project, then moves into the bigger point: public courts are being replaced, piece by piece, by private systems that mostly serve companies.

Key Takeaways

Ballew's core argument is that forced arbitration does more than change where disputes get heard. It changes who has power. Once a company can require individual arbitration, it can also block class actions, which means many low-dollar harms effectively go unchallenged. A $30 junk fee, a wage violation, or a small consumer fraud claim becomes too expensive to pursue alone.

He says the modern arbitration regime rests heavily on Supreme Court choices, not on the plain meaning of the Federal Arbitration Act. That law was written for business disputes between sophisticated parties. The Court, in his view, repurposed it to cover workers and consumers stuck with take-it-or-leave-it contracts. Antonin Scalia gets special attention here, especially for the 2011 Concepcion decision, which Ballew says helped lock in the rule that even very one-sided arbitration clauses would still be enforced.

Another strong point from the episode is that terms of service have become a legal fiction everyone is expected to accept and nobody can negotiate. Nilay Patel pushes this hard: if participation in ordinary life requires agreeing to unread, unchangeable contracts, then a large part of the economy is running on consent that isn't real in any practical sense.

Ballew does not think the Supreme Court is likely to reverse course soon. He does, however, draw a line between federal enforcers and lower courts. He argues that agencies under the current administration may be unwilling to police corruption, while some lower court judges still seem uneasy with how far arbitration has gone.

One of the more useful ideas in the episode is "mass arbitration." Since many companies promise to cover the upfront cost of arbitration, plaintiff-side lawyers can file thousands of individual claims at once and force the company to pay what it agreed to pay. Ballew presents this as a way to turn the system against itself, though he also says companies are already changing rules and forum choices to blunt that tactic.

Practical Steps

If you're dealing with forced arbitration or want to push back on it, the episode points to a few concrete moves:

• Do not assume reading the contract will solve the problem. As Ballew says, most of these agreements are not negotiable.
• If you have a claim shared by many others, ask a lawyer whether mass arbitration is possible. In some cases, filing many individual claims together can create pressure the company did not expect.
• Push this issue through politics, not consumer choice alone. Ballew says the real path runs through state legislatures and city councils.
• Download and share model legislation. He says materials are available on his website, brendanballou.com, for people who want to send draft language to lawmakers.
• Pay attention to state attorneys general. The episode suggests states may be better positioned than federal agencies to pursue some corporate misconduct right now.

There is also a broader practical point: pick one issue and stay with it. Ballew's answer to public cynicism is not optimism for its own sake. He says he has seen small groups change specific industries by sticking with one problem for years.

Notable Quotes

• "Forced arbitration kills this system by requiring people into arbitration and to arbitrate their cases individually." - Brendan Ballew

• "The legal fiction that anyone has actually read these contracts is like the foundation of the American economy." - Nilay Patel

• "I remain incredibly hopeful about the power of individual people if they stick with something to make progress because I have seen it happen over and over and over again." - Brendan Ballew

Overview

This episode is a conversation with Arzu and Mert, the co-founders of Riyaz Factory, a startup using biology and AI to recycle plastics in a different way. Their core idea is simple: instead of melting plastic into lower-quality material, they use enzymes to break it back into its original chemical building blocks so it can be remade at virgin quality.

The discussion moves from the science of plastics and enzymes into the AI stack behind their work. A big theme is that AI is not just speeding up research, but opening parts of the protein design space that human scientists and nature itself have only partly explored.

Key Takeaways

The founders draw a hard line between what most of the world calls "recycling" and what they are trying to do. Traditional recycling usually means collecting plastic, melting it, and reshaping it. That keeps the material in polymer form, but the polymer chains get shorter and weaker over time. Arzu compares polymers to a necklace of pearls: standard recycling remolds the necklace, while their process breaks it into single pearls, or monomers, that can be rebuilt into new plastic without the same quality loss.

Their case for biology rests on selectivity. Heat and pressure act broadly, which is a problem when plastic waste is mixed with other materials. Enzymes are much more specific. Arzu says their enzymes can target a plastic like PET in a mixed material and leave the rest behind, where a heat-based process would affect everything at once. That specificity also lets them run at mild conditions - around 60 to 65 C and atmospheric pressure, by their description - with lower energy use and fewer harmful byproducts.

A second takeaway is where the scientific opening came from. Arzu traces it back to Japanese researchers who found bacteria near a recycling facility that could live on PET plastic. That did not hand industry a ready-made solution, but it showed that plastic-degrading biology was possible. She had already worked on engineering enzymes for industrial use, and saw a gap between the science and any real push to commercialize it.

On the AI side, Mert and Arzu describe a system built to help their lab make better bets. Rather than testing huge numbers of enzyme variants by trial and error, they use models to generate candidate sequences, predict properties like folding and stability, and narrow down what deserves wet-lab testing. Mert puts it plainly: their AI platform's first customer is their lab. The value is faster cycles, lower testing costs, and broader exploration of enzyme designs than a human-led process would usually reach.

One of the more interesting points is their view of "hallucination." In many software settings it is a failure mode. Here, Mert says some amount of creative exploration is useful, because staying too close to known biology also limits discovery.

Practical Steps

For listeners building in climate tech, biotech, or applied AI, a few practical lessons stand out:

• Define the real problem precisely. Riyaz Factory is not trying to "improve recycling" in a vague sense. They are trying to return plastics to monomers, under mild conditions, at industrial scale.
• Match the tool to the constraint. Their claim is that chemistry and mechanical methods hit limits on mixed waste and quality loss, so they brought in biology instead of pushing the same methods harder.
• Use AI where experiments are expensive. Their workflow is built to reduce wet-lab trial and error, not replace science with software.
• Treat AI outputs as candidates, not answers. The goal is to improve hit rate in the lab and tighten the feedback loop with real-world data.
• Build for the full process. They are already moving beyond enzyme design into process optimization, because the enzyme only matters if the whole recycling system works in practice.

Notable Quotes

• Arzu: "We have all the materials out in the world right now. We don't need to dig oil to generate new materials."
• Mert: "We have been trying to solve this problem with the same tools we created the problem."
• Mert: "Our AI platform's customer is our lab."

Overview

This episode sets up Platformer's new series on AI and work by pairing survey data with a long conversation about what AI is actually changing inside companies. Casey Newton and Ella Marcianos start with a gap that keeps showing up in the numbers: higher-paid workers and managers say they use AI more and get more value from it than junior staff do.

The second half is an interview with Box CEO Aaron Levie, who argues that AI will change how people use software more than it will wipe out software or office jobs outright. His basic case is that agents will multiply on top of existing systems, while human workers remain in the loop to handle judgment, quality, security, and the parts of work that don't fit neatly into a prompt.

Key Takeaways

One clear pattern from the surveys is that AI adoption is uneven inside companies. Ella says Financial Times data found much heavier day-to-day AI use among top earners than among workers at the bottom of the income scale. Gallup shows a similar split: leaders are more likely than individual contributors to say AI makes them more productive. Nobody in the episode claims this proves AI causes higher pay. The safer read is that people with more authority, more technical comfort, and more freedom in how they work are trying these tools first.

That freedom matters. Ella's most useful point is that junior workers may have less room to experiment. If they bring in a new tool and it breaks something, they take more risk than a manager does. That helps explain why adoption can lag even in jobs where AI seems well matched to the work.

Levie's main argument is against a simple "AI replaces the job" story. He says people confuse a tool completing one visible task with a whole profession being automated. An accountant is not just filling in forms. An engineer is not just producing code. In his view, AI handles pieces of work that look impressive in isolation, but the value in many jobs sits in the checking, adapting, securing, and finishing.

He also makes a business argument about SaaS. Rather than a collapse in seat-based software, he expects a stack: humans still have seats because companies need access controls and a record of who can touch what, while agents add a separate consumption layer on top. That would mean more activity hitting systems like CRM, document management, and data platforms, not less.

A quieter but useful point: the apps at greatest risk may be the thin, easily replicated ones. Levie is skeptical that companies will rebuild core systems from scratch with AI, but he sounds far less confident about lightweight productivity products that don't hold much data, logic, or trust.

Practical Steps

If you're an employee, don't wait for a grand company-wide AI plan before testing where these tools help. Start with repetitive digital work: ranking lists, pulling public information, cleaning drafts, checking spreadsheets, summarizing documents. Then review the output closely and note where human correction was still needed.

If you manage a team, make AI experimentation safer for junior staff. Set rules for approved tools, define what can and cannot be shared, and make it clear which tasks are okay to test. A lot of adoption seems blocked by fear, not just by lack of interest.

If you run software or IT, separate "core system" thinking from "thin wrapper" thinking. Systems that store sensitive data, business rules, and permissions still matter. Lightweight tools that mainly provide a simple interface are under more pressure. Audit your stack with that distinction in mind.

For students or career switchers, the conversation argues against abandoning technical fields too early. The work may change, but the need for people who can judge AI output, shape systems, and own the last mile remains.

Notable Quotes

• "Nobody seems to agree on what's actually happening, which is usually a sign that something is." - Casey Newton
• "Probably in three years from now, it would be 90, 10 the other direction, which will be agents interacting with these systems." - Aaron Levie
• "That was the first 80% of the job. But the extra 20%, it turns out, is like all of the value creation of that profession." - Aaron Levie

The Story

Paul Ford and Rich Ziatti start with a sales pitch for their own company, but it turns into a setup for the larger point: using AI in software is not the same as using it well. They frame Abort as a team that helps companies adopt AI without wrecking their existing systems, and that leads neatly into a report from CircleCI and ThoughtWorks about what is actually happening inside engineering teams.

The report looked at a huge pool of deployment workflows, and the headline is messy. Teams are producing a lot more code. Paul says throughput is up 59 percent year over year. But that extra output is not landing evenly. A small slice of teams, roughly the top 5 percent by their measures, are moving at a completely different speed, pushing huge numbers of changes every day. Everyone else is dealing with more bugs, more failed checks, and a lot of cleanup.

That gap becomes the center of the conversation. Rich argues that AI code generation is a harsh filter. If a team already has strong engineering habits, clear review practices, and people who can tell good output from bad, the tools can make them much faster. If they do not, AI turns into a machine for generating work they then have to untangle. The real problem is not that the code appears from nowhere. It is that it enters testing and integration pipelines without enough human understanding behind it.

They circle around an open source example to sharpen the point. The maintainers of the Zig programming language have a no-LLM rule for contributions. Paul finds that stance credible, even if he would not want to run a business that way. Their argument is that they are trying to build human contributors, not just accumulate more code. A messy human submission is still an investment in a person who might learn the system. AI output adds text to the repo, but not ownership.

From there the episode shifts from engineering to management. The hosts describe a familiar pattern: leaders play with AI, get dazzled by polished output, and then push teams to "use more AI" without changing the process around quality control. That creates a false metric. People are rewarded for producing more, while the real bottleneck moves to testing, review, and repair. The best teams, they argue, are not succeeding because the model is smarter. They are succeeding because they have built systems around it, including automated checks and strict ways of working.

By the end, they land on a sober view. AI has already changed individual work at the desk. It helps people get unstuck, sketch ideas, and write first drafts. But at the organizational level, the change is barely underway. Big companies will not reshape themselves around software overnight. The software, even AI software, will have to fit the organization.

Main Themes

The episode keeps returning to one idea: AI amplifies the quality of the process around it. That is why a few teams are flying and many are stumbling. The tool is the same. The surrounding discipline is not.

Another thread is the difference between individual productivity and organizational performance. On your own, AI can feel amazing because it is fast, helpful, and flattering. It gives answers, code, images, and plans with very little friction. Inside a company, though, that personal feeling runs into shared systems, testing pipelines, and other people who have to maintain what got produced. The hosts are blunt that this is where the fantasy breaks down.

They also connect AI adoption to talent and experience, though they are careful not to reduce everything to genius engineers. Rich talks about top performers being able to direct these tools with far more control, while Paul pushes the focus back toward team process. Put together, their point is that success comes from judgment plus structure. Without both, AI makes the mess bigger, faster.

Overview

This episode is a career-spanning conversation with Anders Hejlsberg about how major programming languages get made, why tooling matters as much as syntax, and how Microsoft’s internal politics shaped both C# and TypeScript. He also talks through what 40 years of language design taught him, from the early days of tiny machines and ROM-based compilers to today’s AI-assisted development.

Key Takeaways

Hejlsberg’s path started unusually early: he got access to a school computer in Denmark in the 1970s and learned on systems simple enough that you could understand nearly the whole machine. That shaped a lasting instinct in his work: good tools should let developers see what is going on, move fast, and stay close to the underlying model.

One of the strongest themes in the episode is that languages and IDEs belong together. He says Turbo Pascal was never just a compiler. The point was to make the whole edit-run-debug cycle fast and pleasant. That same view carried into later work. For him, language design is not only about syntax or type systems; it is about the full development experience people spend their working lives inside.

The origin of C# is tied directly to Microsoft’s Java problem. Hejlsberg explains that the Sun vs. Microsoft lawsuit made it clear that betting a development platform on a competitor’s licensed technology was a bad idea. At the same time, Microsoft had a split world: Visual Basic was productive but limited, while C++ was powerful but harder to use. C# and .NET came out of that gap. The aim was to combine ease of use with performance, modern runtime features, and strong tooling.

His account of TypeScript is just as revealing. The trigger was seeing teams use tools that cross-compiled C# to JavaScript because JavaScript itself lacked the type information needed for strong tooling at scale. TypeScript’s core bet was simple: keep JavaScript, add an erasable type system, and use that to power better editor support and refactoring. Hejlsberg argues that this, more than type safety in the abstract, is why TypeScript spread.

Open-sourcing TypeScript was also a bigger internal fight than people outside Microsoft may have realized. He says the team knew a proprietary Microsoft language had no chance in the JavaScript world. Even after getting approval, they were pushed onto CodePlex first, where adoption stalled. Moving to GitHub changed both uptake and the way the team worked, because it shifted from open source in name to open development in practice.

On AI, Hejlsberg is measured. He says it helps with code review, routine fixes, test writing, and moving simple changes across branches. But he is clear that it does not remove the need to understand systems, especially in compiler and language work. He also makes a useful distinction: when determinism matters, asking AI to write a program is often safer than asking it for an answer.

Practical Steps

• Treat language choice and tooling choice as one decision. If a language has weak editor support, refactoring, or navigation, factor that into the cost.
• When evaluating JavaScript-heavy projects, consider whether TypeScript’s type information will improve team speed through better tooling, not just stricter checks.
• Use AI for repetitive work first: test generation, pull request review, and small issue fixes are the clearest wins from Hejlsberg’s account.
• Be wary of platform dependence on a competitor’s technology. The C# story is a reminder that legal and business constraints can shape technical direction fast.
• If you build internal tools or developer products, think about the whole loop: editing, running, debugging, and feedback speed matter as much as raw features.
• Read older computer science material with working examples. Hejlsberg recommends Niklaus Wirth’s "Algorithms + Data Structures = Programs" because the basic ideas still hold.

Notable Quotes

• "It’s not just a compiler. It’s an experience." - Anders Hejlsberg
• "Programming language design is 90% the same and 10% new for pretty much every language." - Anders Hejlsberg
• "We full well knew that there was absolutely zero chance that we would appeal to the JavaScript ecosystem with a proprietary programming language licensed from Microsoft." - Anders Hejlsberg

Overview

This episode is a detailed walkthrough of how Noah Breyer uses Claude Code, Obsidian, and a home server as a working "second brain." The core idea is simple: keep notes as local markdown files, give AI access to the whole archive, and use it less as a writer and more as a research partner that can ask questions, pull source material, summarize progress, and help resume work fast.

A big part of the conversation is about where this changes daily life: on a phone, in the car, between meetings, and during those small windows of time that normally aren't useful for deep thinking.

Key Takeaways

Breyer's setup starts with Obsidian because the notes are plain files in folders. That matters because Claude Code can work directly on the vault, search across years of notes, organize project folders, and update files as the work evolves. He starts Claude Code at the root of the vault, not inside one project folder, so the model can look across the full archive.

The most useful shift is conceptual. He says people focus too much on AI's ability to generate text and not enough on its ability to read. In his workflow, AI is there to absorb notes, chats, PDFs, articles, and prior work, then help him think through a problem before he starts writing. He is explicit about this. He tells the model he is "in thinking mode, not writing mode," and even adds hard rules telling it not to draft the artifact.

His project structure is practical. For a talk, he creates a folder with subfolders for chats, daily progress, research, and working notes. He clips in conversations from ChatGPT, Claude, and Grok, stores articles and PDFs, and asks AI to keep a running log of what changed that day and what ideas are emerging. That gives him a record he can return to later with prompts like: "Catch me up on the last three days of research."

He also built a dedicated "thinking partner" sub-agent. Its job is to ask sharp questions, track what he's learning, and avoid jumping into prose. That gets at a common failure mode with AI tools: they rush to produce output when the real need is exploration.

The phone setup is what makes the whole thing stand out. He runs a mini PC in his basement, uses Tailscale for secure remote access, syncs his Obsidian vault through private GitHub, and connects from his phone through Termius. That lets him use Claude Code against his notes or code repos from anywhere. He describes doing real work from breakfast, from the car, and outside by the pond.

He also makes a broader point about AI tools in general: a lot of value comes from building intuition through use. He argues we're still early, and many people wrongly assume they've already fallen behind.

Practical Steps

• Put your notes in a file-based system like Obsidian so AI tools can inspect and modify them directly.
• Start Claude Code from the root of your notes archive if you want it to search across everything, not just one project.
• For each project, make a folder with a few clear sections:
  • research
  • chats
  • daily progress
  • working notes
• Tell the model what mode you're in. If you're exploring, say so plainly: "I'm in thinking mode. Do not write the draft."
• Create a dedicated sub-agent for ideation. Give it one job: ask questions, track discoveries, and summarize progress.
• At the end of each session, ask AI to log what changed, what you learned, and what open questions remain.
• When returning to a project, use recap prompts instead of rereading everything manually.
• If you want phone access, a basic version of Breyer's stack is:
  • home server or mini PC
  • Tailscale for VPN access
  • private Git repo for syncing notes
  • terminal app like Termius
• Use the same approach for code repos. Small fixes and pull requests can be handled quickly from a phone if the environment is already set up.

Notable Quotes

• "I think partially because we call it generative, there's entirely too much focus on its ability to write and not enough focus on its ability to read." - Noah Breyer
• "Don't help me write anything right now. I just want you to help me think and ask me questions." - Noah Breyer
• "You can literally go sign into ChatGPT and do something nobody's thought about doing with this thing yet." - Noah Breyer

Overview

This episode is about what happens when AI stops being a tool you occasionally open and starts sitting inside daily life: in glasses, earbuds, health questions, work, and even simulated relationships. Joanna Stern talks through a year of using AI for almost everything and lands in a place that is neither hype nor panic - more like, yes, this is useful, yes, it is getting better fast, and yes, there are obvious ways it can go sideways.

Key Takeaways

Stern's clearest point on wearables is that AI alone is not enough to sell a device. The Humane pin failed because it had one job and, in her telling, barely did that. Glasses and earbuds have a better shot because they already do things people want - photos, music, calls - and AI can ride along as an extra layer.

She argues that visual AI makes more sense off the phone than on it. Holding up a phone to inspect a broken garage door, a bug, or something your kid asks about is awkward. Glasses are a better form factor for that kind of "what am I looking at?" question, even if today's systems still get facts wrong.

On Apple, she does not see weak AI as a near-term threat to iPhone sales. Her view is that hardware and services are separating anyway. People can use Gemini or ChatGPT on Apple devices, and most iPhone owners are not switching platforms just because Siri trails competitors.

The most unsettling part of the conversation is not hardware. It is the social pull of AI. Stern describes taking a 48-hour road trip with an AI boyfriend built in ChatGPT voice mode. She says the experience made clear why people get attached: the bot is always available, always attentive, and often eager to please. That can be comforting, but also risky for lonely people, kids, or anyone in a rough mental state.

Her reporting on manners with AI gets at a bigger issue. Saying "please" and "thank you" is not about protecting a chatbot's feelings. It is about protecting your own habits. If people get used to snapping at human-like systems, that tone may bleed into real relationships.

On health, Stern says AI was "pretty good" for common issues like rashes, sinus infections, and reading test results, though not reliably right. She also points to a stronger use case: helping patients interpret medical jargon before the doctor calls, and helping clinicians as a second set of eyes in imaging. Her mammogram example suggests AI can influence a radiologist's review without replacing the radiologist.

For work, she is blunt: these tools can let one person do much more. She says tasks she once gave a reporting assistant can now often be handled by AI, especially editing, organization, spreadsheets, and basic research. Writing in her own voice still stayed with her.

Practical Steps

• Use AI for visual questions where your hands are busy, but treat answers as suggestions, not facts. Good cases: home repairs, plant and animal identification, quick product comparisons.
• For health, use AI to translate lab results or prep better questions for your doctor. Remove personal details before uploading documents if you can.
• Keep AI out of high-stakes decisions unless a human expert is still in the loop. Stern's examples support "second opinion," not "final authority."
• If you use AI heavily for work, start with editing, summaries, spreadsheet cleanup, and background research. Keep first-draft thinking and judgment for yourself.
• Set boundaries around companion-style AI. If a chatbot is becoming your default confidant, that is a sign to step back.
• Keep basic manners with AI if only to preserve your own reflexes around other people.

Notable Quotes

• "The phone isn't going to go away, but what are the things that we want to separate from doing on the phone?" - Joanna Stern
• "I could see how people go and talk to these sycophantic beings." - Joanna Stern
• "AI does not have the same feelings that we do... but I do think that there's a genuine impact on you." - Daniel Post Senning, quoted by Joanna Stern

Overview

This episode is about risk at work, but not the headline-grabbing kind. Molly Graham and Julie Zhu talk about risk as a daily practice: asking the awkward question, giving the feedback you've been avoiding, setting a boundary, or saying what you actually think.

Julie argues that bravery is less a personality trait than a skill you build through repetition. The point is not to stop feeling fear. It is to stop letting fear run the decision.

Key Takeaways

Julie’s main idea is simple and useful: confidence usually comes after the scary thing, not before it. She says the moments she is proudest of are the ones where she did something she did not think she could do. That changed how she sees discomfort. Instead of reading fear as a stop sign, she treats it as a clue that there may be growth on the other side.

She also pushes back on the idea that people are either "risk takers" or not. In her telling, risk works more like a muscle. Small reps matter. A person gets better by taking manageable risks over and over, whether that means speaking honestly, trying something unfamiliar, or resisting the urge to stay inside an old identity.

Another strong point is the difference between chosen risk and imposed risk. Julie says she has had to be brave in life because of circumstance, but there is a different kind of energy in choosing the hard thing for yourself. Agency changes the experience. You may still be uncomfortable, but you are in the driver's seat.

On communication, she is clear that timing matters. If you are angry or flooded, do not rush into the hard conversation. There may be a real issue underneath the feeling, but you need enough distance to find the actual point instead of lashing out from hurt.

The management section adds a second layer: risk is shaped by power. Julie says managers are constantly making bets, often by deciding who should own a decision. If they delegate, they also need to own the result. Good managers create conditions where people can try things, fail honestly, and surface bad news fast without feeling watched or punished at every turn.

Practical Steps

• Build an "everyday risk" habit. Pick one small uncomfortable action each day: ask the question, give the feedback, say no, admit you are struggling, or share an unfinished idea.
• Treat fear as data. When you notice yourself thinking "maybe this isn't for me," pause and ask whether that is a real limit or just avoidance.
• Do not have hard conversations at peak emotion. Wait until you can explain what bothered you without making the whole exchange about your anger.
• Before taking a work risk, get specific about the stakes. Ask: What am I afraid will happen? What is the likely downside? What matters more to me long term?
• If you manage people, define success and values clearly. People take better risks when they know what the team is trying to do and how they are expected to work together.
• When an experiment fails, review it fast. Say what you expected, what happened, and what you learned. Make that normal.

Notable Quotes

• "The price of confidence is that you have to do things that you are scared of." - Julie Zhu
• "It doesn't have to be the big things... Sometimes it can be these little everyday things." - Julie Zhu
• "I'd like you to be the person most obsessed with figuring out as quickly as possible that you were wrong." - Julie Zhu

Overview

This episode is about how AI is changing software work beyond autocomplete. Ryan Nystrom from Notion walks through three patterns he uses day to day: automating standup prep, using agents to handle coding tasks in the background, and writing specs first so agents can build from them. The thread through all of it is simple: move human effort away from repetitive coordination and toward decisions, architecture, and review.

Key Takeaways

Ryan's meeting workflow is a good example of where AI helps without needing a grand plan. He built a Notion AI agent that runs each morning, checks Slack, closed tasks, merged pull requests, prior meeting notes, and a Honeycomb metric, then writes a pre-read for the team's standup. That changes the meeting from a round-robin status report into a discussion about decisions, risks, bugs, and next steps.

A big point from the conversation is that the value is not only time saved. Ryan says the prep probably saves him around 20 minutes a day, but the bigger gain is cutting context switching and mental drag. He no longer has to gather the same updates and reshape them for different audiences. The agent does the assembly work, and he shows up ready to talk about the actual problems.

On the coding side, Ryan describes a spec-driven workflow that sounds old and new at the same time. He starts with an empty markdown file, often by dictating rough thoughts into Whisper, then asks Codex to turn that into a proper spec based on examples in the repo. After a few edits, he points Codex at the spec and tells it to build. In this case, he says it "basically one-shotted" the feature because the spec included implementation pointers and a verification section.

That verification piece matters. Ryan argues that the engineer's job is shifting toward system design and proving correctness. If an agent cannot verify its work, that is the first problem to solve. His team even built CLI tools so the agent can test Notion AI behavior directly, send prompts, inspect transcripts, and check whether the feature actually works.

Another useful point: this is not extra process layered on top of engineering. Ryan says teams were already writing design docs and debating implementation choices. The difference now is that the spec can serve as the source of truth in version control and also as input for an agent that writes the code.

Practical Steps

• Pick one repeated coordination task and automate the prep, not the decision-making. A daily standup is a good place to start.
• Write the agent instructions like a description of what you would do by hand:
  • look back 24 hours
  • check Slack
  • check merged PRs
  • check closed tasks
  • pull one or two key metrics
  • output a brief meeting pre-read
• Limit permissions. Ryan gave his agent read access to most sources and write access only to the meetings database where it posts the update.
• Start coding work with a spec file in your repo. Include:
  • feature behavior
  • code pointers
  • edge cases
  • verification steps
• If you're unsure how to write the spec, talk it out first, transcribe it, then have an agent turn the rough notes into the team's format.
• When a feature changes, update the spec first, then ask the agent to reconcile the code to the spec.
• Build or set up a verification loop early. If the agent cannot test the result, you will spend more time guessing than reviewing.

Notable Quotes

• Ryan Nystrom: "I didn't start with writing code. I just started with an empty markdown document."
• Ryan Nystrom: "Your AI, your agent, is never going to complain when you ask it to do this five minutes before the meeting starts."
• Ryan Nystrom: "No more waiting for the meeting. No more waiting for review."

Overview

This episode is really two conversations in one. Nilay Patel talks with Joanna Stern about what she learned after spending a year putting AI into daily life for her book "I'm Not a Robot," and then shifts to why she left The Wall Street Journal to start her own company, New Things.

The throughline is trade-offs. Joanna comes away more optimistic than Nilay about some consumer AI uses, especially wearables, but she is also clear that much of the current AI push depends on surveillance, unfinished products, and social costs that people have barely started to reckon with.

Key Takeaways

Joanna’s main argument is that consumer AI is uneven, not useless. She agrees that chatbots still mostly look like chatbots and that the interface has barely improved, but she says ordinary people are finding repeatable uses anyway: asking cooking questions, replacing some Google searches, and using voice tools in casual, everyday moments. Her point is less that the products are polished and more that habits are already forming.

Where she sounds most convinced is wearable AI. She says Meta glasses stayed in her routine, especially when she was out with her kids and didn’t want to keep pulling out a phone. She also found value in an AI recording bracelet that turned conversations into summaries and to-do lists. At the same time, she says that class of product creates obvious privacy and social problems, because constant recording changes behavior and people quickly stop remembering to disclose it.

On robots, Joanna is blunt: many of the big demos are still more data collection than finished automation. She describes humanoid robot companies as openly chasing training data, even if that means shipping products that are partly remote-operated by humans or relying on gig workers to record household tasks. That turns the AI economy into a system built, in part, on surveillance and low-visibility labor.

The part that worried her most was kids and emotional attachment. She says watching children interact with AI toys and chatbots was more alarming than many of the privacy issues, because they can be wrong, persuasive, and easy to bond with. Her experiment with an AI romantic partner drove home how quickly people can project meaning onto these systems, even when they know exactly how artificial they are.

The media-business section lands on a different version of the same theme. Joanna left a big institution because she wanted more control over format, audience, and ambition. But going independent also means accepting that platforms like YouTube give reach without paying enough to support expensive reporting and production on their own.

Practical Steps

• Treat AI as a narrow tool, not a general replacement for judgment. Use it for specific tasks like recipe help, summaries, brainstorming, or organizing action items, then verify anything that matters.
• Be strict about recording devices. If a wearable captures other people, disclose it every time and set personal rules for when it stays off, especially at home, around kids, or in private conversations.
• Ask what data a product needs before you buy into the pitch. If the answer is "continuous audio," "video from your home," or "training through your use," assume that is the real bargain.
• Keep kids away from chatbot-heavy products unless you can supervise closely. Test answers yourself, watch how the system speaks to them, and avoid products that invite emotional dependence.
• If you are building an audience-driven business, don’t depend on one platform to fund everything. Joanna’s approach pairs direct revenue like subscriptions with sponsorships and distribution partners that reach different groups.

Notable Quotes

• "I think the models have gotten better. You can maybe trust these more, but the interface has not gotten any better." - Joanna Stern
• "The CEO is so honest. He says, we need data." - Joanna Stern, on humanoid robot companies
• "What needs to happen for this next generation is incredibly important to get right." - Joanna Stern

Overview

This episode is about a problem founders rarely plan for: success can make a company easier to corrupt, not safer. Eric Ries argues that many companies do not fall because a competitor beats them, but because their incentives, board structure, and legal setup slowly push them away from their original purpose.

He frames his new book, Incorruptible, as the follow-up to The Lean Startup: first you build something that works, then you need to protect it from becoming mediocre, extractive, or unrecognizable.

Key Takeaways

Ries’ main point is that corruption in companies is usually structural, not just moral. Founders like to think good intentions will hold, but he argues that intentions collapse when the legal and governance setup says shareholder returns come first. He points to cases where founders were pushed out quickly after IPOs and says standard startup “best practices” often leave them exposed.

A strong thread in the conversation is that trustworthiness is an asset, even if it looks expensive in the short term. Ries calls this “harder is easier”: if a company consistently does the harder, principled thing - on quality, safety, design, or customer treatment - it builds trust that later shows up in loyalty, faster decisions, better hiring, and more room to recover from mistakes. His Cloudflare example captures this well: the company gave away encryption because it matched its mission to “make a better internet,” and he says that move built long-term trust and growth.

He also makes a distinction between ethos and integrity. Ethos is the internal side: purpose, values, and the day-to-day choices that show what the company stands for. Integrity is the structural side: the legal and governance mechanisms that keep the company aligned when money, boards, and outside pressure start pulling the other way. In his view, ethos without structure turns into a slogan.

Anthropic is his clearest modern example. Ries says the company set itself up early as a Public Benefit Corporation and later added governance features that give AI safety experts real oversight without tying them to equity upside. His point is not that Anthropic is perfect, but that it built protections before it became valuable enough for those protections to be inconvenient.

Another useful idea: it is almost always “too early” to do this work until it becomes “too late.” Ries says lawyers, investors, and executives often tell founders to wait until after product-market fit, the next round, or the IPO. By then, the leverage is gone.

Practical Steps

• Read your company charter. Ries says many founders have never read the document that defines what their company is allowed and expected to do.
• If possible, convert to or start as a Public Benefit Corporation. He presents this as the simplest structural protection: write the company’s purpose into the charter instead of leaving it as “any lawful act.”
• Write down a real purpose in plain language. Keep it short. Then pressure-test it: can the company make money while betraying that purpose?
• Audit incentives across the company. Check whether anyone can hit targets, bonuses, or OKRs by cutting quality, safety, design, or trust.
• Treat values as operating rules, not branding. Ries’ test is simple: when doing the right thing costs money or time, do you still do it?
• Consider a “mission guardian.” Depending on stage, that could mean founder control, a trust, a nonprofit structure, or another board setup that protects the mission when pressure rises.
• Ask direct questions in interviews or board discussions: Is this mission in the charter? Who is accountable for protecting it?

Notable Quotes

• Eric Ries: “Success will not protect you because success is what makes you a target.”
• Eric Ries: “Trustworthiness is the most underrated asset in all of business.”
• Eric Ries: “If you don’t get this right, no other decision you make about your company will matter for the long term because you’re not gonna be the one making it.”

The Story

This episode starts with Ira Glass thinking about two missionary friends who saw Schindler's List and recognized themselves in Oskar Schindler's last breakdown: the awful feeling that you could have done more, saved more, given more. That becomes the frame for the whole hour. The people in these stories are not judges or presidents. They are ordinary people who suddenly find themselves holding someone else's fate in their hands, sometimes without even knowing it.

The first act, reported by Alex Kotlowitz, is the hardest one. Carla Dimcoff was 19 when her father showed up at her trailer in Michigan. He had spent the night out, came back acting jumpy, and was hurriedly replacing a broken side-view mirror on his motorhome. Soon after, Carla read in the local paper that a young woman had been killed on a nearby road in a possible hit-and-run. Given what she knew about her father - violent, abusive, someone she feared - she suspected he had done it. She left a note for police naming him.

And then nothing happened. Or so she thought. Years later, she learned that another man, Larry Suter, had been convicted in that woman's murder and had spent more than 13 years in prison. The police had taken Carla's warning, but it never changed the case. When she finally read about Larry in the newspaper, the full weight of what her silence and the system's failure had meant hit her all at once. She contacted his lawyers. Her old note was found in police records. Larry's conviction was thrown out, and he walked free.

What gives the story its force is not a clean redemption arc. Carla cannot forgive herself. Larry, who lost years of his life, meets her with tears instead of rage. They become friends, joined in a strange way by grief, illness, and the fact that both of them have been living with the consequences of one night in 1979.

The second act turns smaller and meaner: a family trapped beside a vindictive neighbor. What begins as a property-line dispute turns into years of harassment - slurs, vandalism, dead pets, intimidation, the whole warped theater of one man making cruelty his main occupation. Then the family gets hold of something powerful: the neighbor's dumped papers, full of private details that could expose him. The story sits in the ugly tension between wanting justice and wanting revenge, and how thin that line can get when you've been pushed for years.

The last act, by Shalom Auslander, takes the show's theme and turns it sideways. Two hamsters wait for their owner, Joe, who controls food, comfort, everything. One keeps the faith. The other turns cynical. Joe becomes a stand-in for God, or any absent authority figure with total power and spotty follow-through. It's funny, bleak, and a little absurd, which is probably the only way to end a show like this.

Main Themes

The thread running through the episode is responsibility under pressure: what it feels like to believe that your choices matter enormously, and what happens when you fail, delay, or simply don't understand the power you have. Carla's story is the clearest expression of that. She was young, frightened, and dealing with a father who had terrorized her for years, but she still feels that she should have forced the truth into the open. The show does not let the legal system off the hook, but it also stays with her private sense of guilt, which is harsher than any verdict.

The second story shifts that same question into domestic life. Power there comes from information, from the chance to hit back, to use what you know. After being tormented, the family has to decide what kind of people they want to be when they finally have an opening. The point is not that ordinary life is quietly noble. It's that ordinary life can hand people ugly forms of power too.

And the hamster story pulls the whole thing into comedy and theology. If power is the ability to answer someone's hunger, then Joe has all of it. The waiting, pleading, and rationalizing feel ridiculous because they are so familiar. Across all three acts, power is uneven, often hidden, and rarely clean. The burden comes long before anyone feels ready for it.

Overview

This episode is about how an AI platform changes as models get better. Angela and Caitlin from Anthropic describe the shift from a basic text endpoint to a platform that handles memory, tools, execution, state, and long-running agents in the cloud.

Their main point is that the platform's job is moving up the stack. Instead of asking developers to stitch together prompts, loops, sandboxes, and storage, the platform should take on more of that work so people can focus on the outcome they want.

Key Takeaways

The clearest thread in the conversation is that platform design is being driven by autonomy. As Claude becomes better at acting over longer tasks, the surrounding platform has to provide persistence, tools, file systems, credentials, and orchestration. A better model creates pressure for a bigger platform.

They argue that many teams misjudge where the hard part is. People often assume the challenge is harness engineering: prompt loops, context management, caching, and tool setup. Caitlin says the real wall shows up later, when a prototype has to run reliably in production. Long-running agents need durable infrastructure, secure sandboxes, transcript storage, and systems that can recover when a session dies. That is what pushes teams off a couple of local machines and into managed infrastructure.

Managed agents, in their view, are for two broad groups. One is internal teams building automations inside a company, like review flows or engineering helpers. The other is product teams embedding agents into customer-facing software. In both cases, the pitch is the same: save engineering time on the plumbing and spend it on the product.

Another useful point is their stance on primitives. They want some opinions baked in, especially around file systems and skills, while still keeping the system modular. That mix matters because it gives developers room to customize without rebuilding the same foundations each time.

The most forward-looking part of the episode is their idea that the interface may shrink to two inputs: the outcome and the budget. Angela suggests a future where Claude chooses the model, decides how many sub-agents to start, and picks the right architecture on the fly. If that happens, "harness engineering" becomes far less visible to end users.

Practical Steps

If you are building agents now, the advice from this conversation is pretty concrete:

• Prototype fast, but assume production will break your first design. Treat local or lightweight setups as a proving ground, not the final system.
• Separate product logic from infrastructure early. Keep your prompts, tools, and task logic portable so you can swap in managed infrastructure later.
• Use built-in primitives where possible, especially file systems, skills, code execution, and credential storage. The team is signaling that these are likely to stay central.
• For internal agents, start with narrow, verifiable jobs: code review support, legal review routing, marketing checks, or software tasks with clear completion states.
• Put a layer between end users and the raw agent when mistakes are costly. Anthropic described systems where employees talk to one Claude interface, while multiple agents handle the more complex work underneath.
• Plan for agent maintenance from day one. Keep evals or other checks so you can test model upgrades, retire stale agents, and migrate to better architectures without guessing.
• Measure success with verifiable outcomes when you can. A merged PR, a completed workflow, or a resolved request is more useful than vague satisfaction scores.

Notable Quotes

• Angela: "The through line... is helping you get the best outcomes out of something."
• Caitlin: "Everybody hits an infrastructure wall."
• Angela, on the longer-term direction: "The kind of parameters we will care for from users will be that outcome... and the budget."

Overview

This episode centers on a strange and telling alliance in the AI race: Anthropic says it will use major compute capacity from SpaceX, a deal the hosts treat as a sign that the market is consolidating around whoever can get enough GPUs online fast. They also dig into what recent court disclosures from the Elon Musk-OpenAI case reveal about OpenAI's internal instability, then close on whether the latest wave of tech layoffs reflects real AI-driven productivity or executives using AI as cover for ordinary cost cutting.

Key Takeaways

The Anthropic-SpaceX deal matters because it appears to solve Anthropic's biggest bottleneck: access to compute. The host points to Anthropic's immediate move to raise Claude Code rate limits as evidence that this was not just press release theater. If Anthropic can turn scarce compute into shipped product, it has a better shot at keeping pace with OpenAI.

At the same time, Ranjan Roy is wary of treating every giant infrastructure announcement as proof of long-term demand. His argument is that recent AI usage may be inflated by loose budgets, hype, and what he calls "token maxing" - companies spending freely without much pressure to optimize. In that view, demand is real, but the current curve may not hold once buyers start caring more about efficiency.

A second big theme is that competition in AI now runs through finance and timing as much as product quality. The hosts suggest SpaceX, Anthropic, and OpenAI are all being pushed toward IPO logic: stronger narratives, clearer revenue stories, and better positioning ahead of public-market scrutiny. One theory raised in the conversation is that if Anthropic can scale quickly and reach the market before OpenAI, it could weaken OpenAI's standing at a sensitive moment.

The OpenAI trial disclosures add another layer. The texts between Sam Altman and Mira Murati from Altman's brief ouster in 2023 show how chaotic the company's governance looked from the inside. The exchange reinforces a point both hosts make: OpenAI's nonprofit structure and board model were unstable, and that instability still matters because Musk's lawsuit is partly about whether the company abandoned its original mission.

On layoffs, the hosts land in the middle. They do not buy the clean story that AI has already replaced huge numbers of workers. But they also do not dismiss the shift. Their read is that many companies are cutting because business conditions are tight and because leaders expect AI to change org design soon, especially in engineering and white-collar work. The cuts may be early, messy, and opportunistic, but the pressure behind them is real.

Practical Steps

If you're running a company or team, a few practical points come through:

• Audit where AI demand is real versus where usage is inflated by experimentation. Look at paid usage, repeated workflows, and actual output, not just token volume.
• Treat compute access as strategy, not plumbing. If your product depends on model availability, rate limits, or inference speed, capacity can become a competitive problem fast.
• Push teams to measure outcomes before bragging about spend. A rising AI bill by itself does not tell you much.
• Prepare for org changes now. That means fewer layers, more hands-on managers, and broader expectations that non-engineers can work with AI tools directly.
• If you're an employee, learn tools that shorten delivery time in your actual job. The conversation suggests companies are rewarding people who can produce more with AI, not people who simply talk about it.

Notable Quotes

• Dario Amodei, as quoted in the episode: "I hope that 80 times growth doesn't continue because that's just crazy and it's too hard to handle."
• Mira Murati to Sam Altman, from the court-revealed texts: "Sam, this is very bad."
• Ethan Mollick, cited by the hosts on Anthropic's security work: "The latter was wrong. The former was likely right."

The Story

This episode is Joe Russo talking with Simon Willison, and the conversation stays grounded the whole way through. Simon explains why he has become such a steady voice in AI: he mostly ignores the grand predictions and pays attention to what the models can actually do right now. That stance comes out of a long habit more than any master plan. He has been blogging since the early 2000s, first about web development and Django, and then, almost by accident, he was already paying close attention to generative AI when ChatGPT landed. He points to Stable Diffusion and GPT-3 as the setup, and says ChatGPT was basically the same underlying capability wrapped in an interface normal people could use.

From there the discussion shifts to software, which is where both of them clearly feel the ground moving. Simon says the debate over whether models are good at code is over. In his view, late 2025 was the tipping point when coding agents stopped being a novelty and became reliable enough to use every day. He says many engineers he knows now have agents writing most of their code, and that would have sounded absurd a year earlier.

But he is careful about what that means. He draws a hard line between "vibe coding" for personal, low-stakes tools and using these systems in production. If the bug only hurts you, fine. If it affects users, money, or security, the standard has to be higher. What changed for him is not that review stopped mattering, but that he no longer thinks every line must be read by a human to be responsibly shipped. He compares agent-written code to an internal service built by another team: you trust it through tests, docs, behavior, and reputation, and only dig into the guts when something goes wrong.

That opens a bigger question Joe keeps pulling on: if software teams can produce far more code than before, what breaks next? Simon's answer is basically everything around the code. Review, product design, specs, and management processes were all built for a world where implementation was the expensive part. If implementation gets cheap, teams can try more ideas, recover from mistakes faster, and probably rethink a lot of ceremony that used to make sense.

The episode ends in a more human place. They talk about beginners, mentorship, and whether the next generation can become strong engineers without the long pre-AI apprenticeship older engineers went through. Simon is hopeful, mainly because these tools remove so much early misery from learning to code. He also thinks software engineering is still hard in the same old way: someone still has to translate messy human needs into systems that work.

Main Themes

The main thread running through the episode is that AI changes the pace of software work without changing its difficulty. Simon keeps coming back to that point. Software was already hard, and the hard parts were never just typing. They were judgment, scope, security, tradeoffs, and understanding what actually matters. The tools speed up people who already have those instincts, which is why he calls them amplifiers of experience.

Another big theme is trust. Not blind trust in models, but a changing standard for what trustworthy work looks like. In the past, a tidy repo with tests and a polished readme suggested care. Now those signals are cheap. Simon says actual use matters more. A tool that has been exercised in the real world tells you more than one that merely looks finished. That same idea extends to enterprise software, where buyers do not want novelty as much as proof that something works.

They also spend time on who benefits from all this. Simon thinks experienced engineers are in a strong position because they can steer the tools well, but he does not think that means newcomers are doomed. He sees real value in AI as a patient partner that removes friction and helps people get past the first ugly months of learning. The open question is whether that kind of assisted entry produces engineers with depth over time.

Underneath all of it is a pretty plain argument: the winners here will not be the people making the loudest predictions. They will be the people paying attention to what works, where it fails, and what has to change around it.

Overview

This episode looks at whether AI companies are right to chase the "agent super app" idea: one product that can search, reason, connect to your data, and act on your behalf. Perplexity Chief Business Officer Dmitry Shevelenko argues this shift is less a pivot than an extension of how users already relied on AI for work, while the host pushes on a harder question: is this move driven by genuine product progress, or by a slowdown in consumer AI growth?

Key Takeaways

Shevelenko’s main argument is that revenue tells a cleaner story than app traffic. He says Perplexity started 2026 at under $250 million ARR and had crossed $500 million ARR a month before the interview. His point is that many users were already treating Perplexity as a work tool, even when the company was framed as an AI search product, so moving into agentic workflows follows actual demand rather than replacing a failed consumer story.

A second theme is that novelty and durable usage are different things. The host points to spikes from voice and image features, like the Studio Ghibli trend, and suggests agent products could fade the same way. Shevelenko agrees that some earlier growth came from curiosity, but says computer-use products are tied more directly to paid work: financial modeling, data analysis, meeting prep, code generation, and document checking. In his telling, people are not paying for a fun demo. They are paying because the tool saves labor.

The most interesting strategic point is Perplexity’s bet on being model-agnostic. Shevelenko says one task can involve several models: one for planning, another for writing, another for audio generation, another for fast research, and another for code. That gives Perplexity a case against OpenAI, Anthropic, and others that are tied to their own model families. If model quality stays close and specialization keeps increasing, orchestration becomes a real product advantage.

Trust and error correction sit underneath all of this. The host reads out the long list of permissions needed to make Perplexity computer useful and questions whether normal users should hand over that much access. Shevelenko’s answer is that human responsibility does not go away: users still set the objective, review outputs, and catch mistakes. He sees AI as a tool for checking human work as much as replacing it, citing a "Final Pass" workflow that reviews PDFs, spreadsheets, and presentations for factual and internal errors.

The conversation also lands on a practical business truth: usage-based pricing is coming back. Shevelenko says subscriptions alone cannot cover agent tasks when some jobs cost pennies and others can cost tens of dollars. His Costco comparison is simple: a membership gets you in the door, then heavier usage costs more.

Practical Steps

If you want to test agent tools in a serious way, start small and tie them to work that already matters.

• Pick one recurring task with a clear payoff: meeting prep, document fact-checking, inbox triage, tax review, or internal data pulls.
• Give the tool the minimum permissions needed at first. Add more access only after you see value.
• Treat AI outputs like junior staff work. Review them, spot-check numbers, and verify claims before acting on them.
• Save your best prompts and turn them into repeatable workflows. A blank prompt box is hard for most people; templates help.
• Watch spending by task, not just by subscription. If the product is moving into usage pricing, you need to know which jobs are worth the cost.

Notable Quotes

"Everyone now gets to operate as an executive because your job is to wake up in the morning and think about, okay, what are the useful tasks that I can deploy the hundred agents that are on standby to grow this thing?" - Dmitry Shevelenko

"We're shifting from an era of instructions to objectives." - Dmitry Shevelenko

"The constraint on making the most of AI is our own curiosity." - Dmitry Shevelenko

Overview

Bruce Daisley speaks with journalist Kate Murphy about her book "Why We Click," which looks at interpersonal synchrony: the way people fall into step with each other in conversation, emotion, and behavior. The episode centers on what that means for work, especially hybrid work, team dynamics, and the hidden effect one person can have on a meeting or group.

Key Takeaways

Murphy’s main argument is that strong human connection depends on physical presence. She says people do more than mirror each other’s expressions and posture. In her account of the research, heart rate, breathing, hormonal activity, and even brain activity can start to align during conversation. Her view is that this kind of attunement is hard to reproduce through screens, which has obvious implications for remote work.

That leads to one of the episode’s more contested points: Murphy argues that video calls are a poor substitute for in-person interaction, and in some cases worse than audio-only calls. She says video platforms strip out or distort the small cues people use to read each other, while also adding distractions like self-view, camera angles, lag, and pixelation. Bruce partly pushes back, pointing out that some forms of remote connection clearly do work and that workers with packed calendars may not welcome forced "connection time" in every meeting.

The most practical part of the conversation is the research on "bad apples." Murphy describes studies where one planted team member acted as a slacker, a downer, or a jerk. She says the weakest link in a group often predicts group performance more than the strongest performer does. What stands out is that the negative behavior spread. Other team members started copying the same tone and habits without realizing it.

There is a counterweight to that. Murphy also describes a rare "good apple" who resisted the bad dynamic by building links across the group, drawing quieter people in, and reducing the disruptive person’s influence. The lesson for managers is simple: team chemistry is not soft or secondary. It shapes output. Who clicks with whom matters, and so does how people arrive in the room.

A final thread running through the episode is self-awareness. Murphy argues that people often carry emotional residue from one interaction into the next and then infect the tone of a meeting without meaning to. The example she gives is familiar: someone arrives flustered and dramatic, and the whole room tightens around that energy.

Practical Steps

• Use in-person time for relationship building, conflict repair, and early-stage team formation. Don’t waste it on updates that could be sent in writing.
• Review team dynamics, not just individual performance. If one person consistently drains energy, stalls work, or spreads hostility, treat that as a group risk.
• Look for "good apples" inside teams: people who connect others, steady the mood, and keep collaboration moving. Give them real influence.
• Before meetings, do a quick reset. Ask what mood you’re bringing in and whether it belongs in the room.
• Be more selective with video. For one-to-ones or working sessions that don’t need visuals, try audio-only and compare the quality of discussion.
• Cut fake small talk. If you want people to connect, ask questions that reveal how they think or what mattered to them, rather than filling time with chatter.

Notable Quotes

• "The single greatest predictor of the success of a group or team is not how stellar the best performer is... but how terrible the worst person is." - Kate Murphy
• "You do need [physical presence] to build those relationships and feel that connection moving forward." - Kate Murphy
• "Procrastination is the easiest form of resistance." - promo clip aired before the episode

Overview

This episode looks past the easy headline that "students are cheating with ChatGPT" and gets to the harder question: what is school for if AI can produce decent-looking work on demand? Nilay Patel talks with McGill University researcher Dr. Adam Dubé and brings in teachers whose experiences range from cautiously optimistic to openly hostile. The result is a picture of education systems making policy on the fly, with little agreement on what students should learn, what teachers should offload, and what kinds of thinking still need to stay human.

Key Takeaways

The biggest point is that AI in schools is not one problem. It is a pile of different problems: cheating, bad policy, budget pressure, weak guidance from leadership, and a deeper conflict over whether education is about producing work or building knowledge. Dubé says schools are reacting in fractured ways, often based on the attitudes of local leaders and parents rather than any shared principle.

A second theme is that the promised efficiency gains may be overstated. Some teachers say AI helps them draft lesson plans or materials faster, especially when they want to try better teaching methods but lack time. But others say the tools create extra work because they produce errors, require checking, and give polished output that hides bad reasoning. One historian describes translation software inserting sentences and paragraphs that did not exist in the source documents, which then had to be fixed at greater cost than hiring a human translator from the start.

Dubé also argues that offloading thinking to AI can weaken learning itself. He connects this to older debates about calculators: when a tool handles too much of the cognitive work, students may produce acceptable answers without building memory, judgment, or skill. He points to research suggesting that people using AI can end up with weaker recall of what they supposedly wrote. That matters because education is not only about handing in a product. It is also about having enough knowledge in your head to assess whether something is accurate, persuasive, or complete.

Another strong point comes from teachers who say students are acting rationally inside the system they are given. If grades reward the final product more than the learning process, and students are stretched thin by jobs, caregiving, and heavy course loads, many will use whatever tool gets them across the line. AI exposes a mismatch between what teachers say they value and what institutions actually measure.

Practical Steps

Teachers and school leaders can take a few concrete steps from this conversation:

• Track time honestly. If AI is supposed to save time on lesson plans, grading support, or email, measure the total time including fact-checking and revision.
• Set tool-specific rules by subject. A blanket "AI allowed" or "AI banned" policy is too blunt. History, for example, has different standards from brainstorming a classroom activity.
• Teach how the systems work. One teacher walks students through the fact that these models predict likely word sequences rather than "knowing" facts. That helps students judge where the tools fail.
• Grade more of the process. Require outlines, drafts, notes, source checks, or in-class work so students are rewarded for thinking, not just for turning in polished prose.
• Ask where human judgment has to stay. Translation of primary sources, factual citation, and discipline-specific interpretation are obvious places to draw hard lines.
• Be clear about purpose. Before assigning work, decide whether the goal is fluency, memory, analysis, or production. That answer should shape whether AI use makes sense.

Notable Quotes

• "What are we even doing here in higher ed?" - recurring teacher concern highlighted by Nilay Patel
• "We absolutely cannot bullshit." - Anne Rubinstein, explaining why historians cannot rely on systems that invent facts
• Dubé’s core warning, paraphrased: students may turn in more polished work with AI, but they often do not remember or understand what they produced

Overview

Claire Vo gives a quick field report from Anthropic's "Code with Claude" event and focuses on five releases tied to Claude Code and Claude managed agents. The episode is mostly about new building blocks for agent workflows: scheduled routines, outcome-based agents, multi-agent teams, memory tools, and higher usage limits.

Key Takeaways

The clearest product shift is that Claude is moving from "chat that helps with tasks" toward software that runs work on its own. The new routines feature in Claude Code is a simple example: you can schedule jobs on a cron, fire them from HTTP, or trigger them from GitHub webhooks, then run them either locally or in the cloud. Claire's newsletter example makes the point well: a task she used to start manually every Monday can now run on its own against a project folder.

The managed agents API adds a stronger definition of "done" through outcomes. Claire compares it to OpenAI's goal feature in Codex. The idea is that you give the agent a rubric, usually in markdown, and a grader checks whether the result meets that standard. She says the system can iterate up to 20 times. That matters because it turns an agent from a one-shot responder into something closer to a looped worker that can revise its own output until it passes.

Another release points to where agent products are heading: explicit multi-agent teams. Claire says developers can define an orchestrator plus delegate agents, with up to 25 agents sharing the same container and file system. Each agent can get its own tools. Her example is a PRD workflow with one orchestrator, a strategy agent, a critic agent, and an engineering review agent. The useful part here is not the novelty of "many agents," but the ability to assign roles and tool access in a structured way.

The "dreams" feature is Anthropic's take on agent memory. Claire strips away the hype and describes memory as markdown files written to the agent's file system so future sessions can use what was learned. What stands out is when the memory gets written. Instead of only saving memory at the end of a session or on a fixed hook, dreams can review a batch of past sessions and decide what should stick. Claire also raises the missing half of the problem: forgetting. Better memory without a way to discard stale or bad information can become baggage.

The most practical announcement for many users may be the least glamorous one: higher usage limits. Claire says Claude Code's five-hour limits are now doubled across several plans, peak-hour restrictions are going away for Pro and Max, and Opus API rate limits are increasing.

Practical Steps

• Audit the repetitive work you still start by hand. If it happens on a schedule, turn it into a Claude Code routine.
• Start with one contained use case, such as:
  • weekly newsletter drafts from a changelog
  • PRD rubric checks on recently edited docs
  • GitHub-triggered reviews when a pull request opens
• For managed agents, write the rubric before the prompt. Be explicit about what success looks like, what to exclude, and how the output will be judged.
• If you're building agent products, split roles instead of stuffing everything into one agent. Give each sub-agent a narrow job and only the tools it needs.
• Treat memory as a system you manage, not a magic feature. Decide when past sessions should be reviewed, what gets saved, and what should eventually be dropped.
• Revisit usage assumptions. If Claude's limits were the reason you held back on longer-running workflows, test those automations again.

Notable Quotes

• "You define what done looks like for an agent."
• "Memory is basically the idea of writing markdown files to the file system your agent uses."
• "I think we think a lot about agent memory, but not a lot about agent forgetting."

Overview

This episode argues that coding agents have crossed over from niche developer tools into a general interface for knowledge work. Dan Schipper and Austin describe Codex’s recent shift from a frustrating pair-programming product into something they now use as a daily workspace for writing, recruiting, planning, automation, and analysis.

Their main claim is that the real competition is no longer just model quality. It is about who owns the desktop agent interface where people actually do their work, with tools like Codex and Claude Code becoming the place where email, docs, chat, data, and software all meet.

Key Takeaways

A big theme is that the product changed faster than many people realize. Dan says Codex was “trash” a few months earlier, mainly suited to senior engineers, but that OpenAI has since moved hard toward a broader, more usable agent experience. In his telling, the lesson from Anthropic and similar tools is simple: once an agent can write code, access files, use a browser, and connect to your apps, it stops being just a coding tool.

Austin gives the clearer proof point. He started with Claude Code for growth work, then moved much of that workflow into Codex once newer GPT models improved the interaction quality. His standard use case is not “write something from scratch.” It is “look across my tools, find patterns, propose automations, draft outputs, and package my thinking.”

That leads to one of the more useful ideas in the conversation: agents work best when they assemble and structure thinking that already exists. Austin says he is not asking the model to invent a go-to-market plan out of nowhere. He is asking it to pull together notes, prior decisions, targets, and context, then turn that into a draft he can review. That cuts down the time spent converting scattered thinking into a form other people can use.

They also make a case for “agent-readable” documents. Instead of polishing plans mainly for presentation, they increasingly write docs that both humans and agents can inspect, summarize, and work from. The standard shifts from “does this sound like me?” to “do I stand behind it, and can other people and their agents use it?”

There is one consistent caution. Both speakers keep a human review step, especially for outbound communication. Austin prefers having Codex draft messages, then reviewing them inside Gmail or Slack before sending. The goal is speed without giving up judgment.

Practical Steps

• Connect your main work tools to an agent first: email, chat, docs, and your main data sources. Austin’s examples were Gmail, Slack, Notion, and internal metrics.
• Start with a broad prompt that asks the agent to inspect your tools and suggest automations based on your actual workflow. That is a better starting point than trying to design the perfect automation yourself.
• Use the agent to draft triage systems:
  • follow-up queues
  • reply drafts
  • event or campaign command centers
  • hiring or lead-tracking pipelines
• Keep review in the destination app. Let the agent prepare the work in Codex, then approve email drafts in Gmail or Slack replies in Slack.
• Ask the agent to interview you about rules before setting up automations, especially for email sorting or lead handling. That surfaces judgment you may not think to specify upfront.
• Save repeatable workflows as reusable skills or templates. Austin says his team asks after a session whether the learning should be saved and turned into a repeatable process.
• Make time to experiment. The speakers frame this as part of the work, not a side hobby, because new workflows can outpace people who only optimize their current process.

Notable Quotes

• Dan Schipper: “If you have a great coding agent on your computer, it’s actually really great for any kind of knowledge work.”
• Austin: “I’m relying on the model to look at all of the things that we’ve already said and thought about the go-to-market strategy, piece it together, and then review it.”
• Dan Schipper: “There’s a new operating system for how and where you’re going to get your work done. And it’s this kind of agent management interface.”

Overview

This episode is about what company-wide AI adoption looks like when it moves past talk and turns into internal products, shared habits, and visible metrics. Claire Vo talks with John Kim, CEO of Zenbird, about building an "AI-first" company where marketers, salespeople, and other non-engineers can ship software, automate work, and build their own tools.

The core idea is simple: AI should not just make people faster at the same tasks. It should let more people build things that would have been blocked by engineering queues, budget limits, or org structure.

Key Takeaways

John shows a few ways his team has made AI part of daily work rather than a side experiment. One is an internal "quests" platform, where anyone in the company can post a problem, describe what they want built, and get help from others. Those contributors might be engineers, or they might be people using AI tools well enough to build it themselves. The point is to create an internal market for ideas and execution instead of keeping requests trapped inside departments.

A strong example comes from the marketing team. John says they built a swag store, event pages, campaign tools, and social posting workflows without engineering support. Claire's read on this is that AI changes the quality of what marketing can ship, not just the speed. Teams no longer have to settle for a stripped-down version of a creative idea because asking engineering for two sprints is too expensive.

Another theme is measurement. John tracks token usage across the company and even ranks employees from "AI newbie" to "AI god." He says this is not part of performance review, but it is used to see who is actually learning and where people need support. Claire argues that companies making real progress tend to measure this directly instead of treating adoption as a vague aspiration.

The hiring point is also useful. John says his team has lowered emphasis on tenure for some roles and raised emphasis on curiosity, agency, and energy. His view is that AI rewards people who click around, test things, read, and teach themselves. That matters more now than years of experience doing a job one fixed way.

A final thread is learning. John describes building personal AI-powered knowledge bases on topics like neuroscience and quantum mechanics. Claire sees this as one of the most overlooked uses of AI: not replacing thought, but giving people a way to study subjects in formats that fit how they learn.

Practical Steps

• Build an internal request board for AI projects. Let anyone post a problem, the desired outcome, and rough specs. Make it easy for others to join and contribute.
• Start a shared library of "skills" or reusable prompts, workflows, markdown guides, and mini-tools by function, like sales, recruiting, or design.
• Pick one non-engineering team and give them room to ship something real. Marketing is a good candidate because the payoff is visible fast.
• Track AI usage in a visible way. John uses token consumption as a proxy for learning and experimentation. Use the metric to start conversations, not to punish people.
• Find the people already experimenting. Put them in front of the company, let them demo what they built, and make them the internal examples others can copy.
• Have leaders use the tools heavily and publicly. John says top token users at his company include senior technical leaders. That sets the tone.
• Rewrite job descriptions to favor curiosity and self-direction where it makes sense. If the tools are changing every month, teachability matters.

Notable Quotes

• "It's taking someone's super creativity and giving them powers to deliver it to your customers." - Claire Vo
• "There are always people in your organization who are already curious, who already have agency. Find them, make them the champions." - John Kim
• "This is a beautiful time to fail forward and still get up and run faster than the others." - John Kim

Overview

This episode centers on a simple question that most people avoid until life forces it: what is work actually for? Molly Graham talks with Patty Stonesifer about the personal mission statement Patty has used for decades to make career decisions, organize her time, and resist being pulled around by prestige, flattery, or other people's definitions of success.

Patty's statement is short: "love, be loved, seek justice, keep learning and laugh." The conversation is about why she wrote it, how it changed over time, and how a person can build their own version without turning it into empty self-help.

Key Takeaways

Patty's main point is that a personal mission statement works as much as a "no" device as a "yes" device. She says she turns down a lot so she can go deep on the few things that matter. That matters because many smart career decisions look good on paper and still pull you away from the life you actually want.

One of the strongest parts of the conversation is her honesty about getting this wrong. After leaving Microsoft, she quickly said yes to DreamWorks and several board seats. None of those were bad opportunities. The problem was that they crowded out what she cared most about, especially "seek justice." Her fix was not better hustle. It was a clearer filter.

She also makes a useful distinction between values and mission. For her, the statement covers both what she wants to do and how she wants to live while doing it. That keeps it grounded. "Laugh" is in there partly to keep her from becoming self-important, which gives the whole framework some needed realism.

Another good point: these statements should change. Patty says "love and be loved" has moved higher over time, especially as her husband has needed more care. The point is not to write a perfect line once and follow it forever. The point is to revisit it and see whether it still matches your life.

For Molly and for listeners, Patty offers three prompts for building a statement:

• How do you want to show up for other people?
• What is your special purpose or special power?
• What area of personal growth matters most to you?

Those questions move the exercise away from resume language and toward something more usable.

Practical Steps

Start with a short list, not a polished paragraph. Write down:

• how you want to show up in relationships,
• what kind of contribution you think you're here to make,
• what you still want to keep learning or growing into.

Then compress it. Patty kept her statement short on purpose so she could actually use it when decisions came fast.

Put the statement into your calendar or planning system. Patty says she uses a monthly sheet with her principles as categories down one side, then places her activities under them. That helps her see where her time is going and where the gaps are.

Use it before saying yes. If an opportunity is exciting but only fits one part of your statement while crowding out the rest, treat that as a warning sign. Patty's experience after Microsoft is a good example: interesting work can still be the wrong fit.

Review it every year or so. If your responsibilities, relationships, or priorities have shifted, your statement should reflect that. A stale mission statement is just decoration.

Notable Quotes

• Patty Stonesifer: "I say no a lot so that I can go deep where I say yes."
• Patty Stonesifer: "The world is full of a lot of cool things and you can only do a few."
• Patty Stonesifer: "Make your decisions slowly."

The Story

Ezra Klein opens from a place of frustration with his own political tradition. Illiberalism, he says, is clearly ascendant, but what strikes him just as much is how thin liberalism feels in response. It has institutions, habits, and defenses, but not much visible spirit. He frames the conversation as part of a personal search for something older and richer inside the liberal tradition, something beyond rights talk and proceduralism.

That leads him to historian Helena Rosenblatt, whose book argues that before "liberalism" existed as a political doctrine, there was "liberality" as a civic virtue. Rosenblatt traces the word back to Rome, where being liberal meant more than defending freedom from interference. It meant generosity, reciprocity, devotion to the common good, and a sense that citizenship required moral formation. Ezra is drawn to this because it gives liberalism some human substance again. It suggests that the tradition was once concerned with what kind of people a free society should produce, not just what protections it should guarantee.

But Rosenblatt does not romanticize this past. The early ideal of liberality belonged to elites, and it carried a strong streak of social hierarchy and self-congratulation. That tension runs through the episode. Liberalism begins as a language of virtue among privileged men, yet over time it becomes a vehicle for broader inclusion - first through toleration, especially religious toleration, then later through arguments for social reform. Rosenblatt shows how Protestants in Catholic Europe pushed liberal ideas partly because they wanted recognition and freedom for themselves. Toleration was not born as pure pluralism; it came mixed with ambition, conflict, and a belief that freer societies might improve people morally.

From there, the conversation moves through liberalism's long argument with its enemies. Rosenblatt notes that "liberalism" started as an insult. Critics accused liberals of selfishness, social disorder, hostility to family and religion - charges that sound familiar now. The old Catholic attacks on liberalism, she suggests, echo in current post-liberal critiques. Ezra keeps bringing the discussion back to the present, asking why liberalism today seems unable to speak confidently about character, duty, or the common good without sounding embarrassed.

By the end, the episode lands on a paradox. Liberalism is strongest when it checks power and resists domination, yet in modern America it is often seen as the language of educated elites who sit close to power and look down on everyone else. Rosenblatt argues that liberalism loses itself when it becomes smug or detached. What it needs, in her telling, is not a return to paternalism but a recovery of moral seriousness: a belief that freedom asks something of us, that citizens need formation as well as rights, and that a free society depends on people who can imagine obligations beyond themselves.

Main Themes

The main thread is the gap between liberalism as we usually describe it now and the older tradition Rosenblatt uncovers. The modern version centers individual rights, choice, and protection from coercion. The older one tied freedom to self-command, generosity, and membership in a shared civic world. Ezra is clearly testing whether that lost language might help explain why liberalism now feels bloodless.

A second theme is that liberalism has always contained a tension between emancipation and elitism. Its early champions often spoke in the name of the common good while standing well above most of the society around them. That history matters because some of today's backlash against liberalism draws energy from the sense that liberal elites still mistake their own refinement for public virtue.

The conversation also tracks how liberalism changes under pressure. War, industrialization, religious conflict, dictatorship, and mass politics all forced liberals to revise what freedom required. That is how a tradition once focused on constitutions and toleration made room, in some places, for education, welfare, and state action. Rosenblatt's broader point is that liberalism has never been fixed. It has always been argued over, weakened by crisis, then remade inside it.