AI Explained Official Podcast • 17m

Overview

This episode is a fast read on a messy 24 hours in AI model releases. The host argues that the real story is not who tops every leaderboard, but how three frontier labs are pushing a new pitch: near-frontier performance at much lower cost.

Most of the focus is on OpenAI's new GPT-5.6 line - Sol, Terra, and Luna - and how those models compare with Anthropic's Fable, Opus, and Sonnet, plus pressure from Grok, Meta, and GLM. The host's main point is that pricing is starting to matter as much as raw capability, especially for business tasks where "good enough" can change workflow habits fast.

Key Takeaways

OpenAI's release looks strong because the host says Sol often lands at about a third of the cost of Anthropic's comparable models, while staying close in performance and sometimes beating them. That changes the buying decision. If the output is close enough, a lower price can matter more than a small benchmark edge.

The host spends a lot of time on benchmarks that try to measure real work rather than toy tasks. On Agents Last Exam, OpenAI says GPT-5.6 Sol hit almost 54 percent versus Fable's 45 percent. The host treats that as more meaningful than a generic leaderboard result because the benchmark was built from real projects across 55 industries, with expert-designed tasks and reproducible scoring. His broader claim is that we did not wait for coding models to get near-perfect before people started using them first, so the same shift could happen in finance, operations, and other white-collar work.

There is a check on the hype. The host points out that some coding comparisons are less clean than they look because benchmark aggregates can reuse the same underlying tests, and some tougher benchmarks did not include GPT-5.6 Sol results. He also notes that Grok 4.5 and GLM 5.2 complicate OpenAI's value story. A model can be "almost as good but cheaper" than Anthropic, yet still look expensive next to Meta, xAI, or Chinese competitors.

Another theme is that verifiable domains are falling faster than messy ones. The host mentions a competitive coding benchmark that an OpenAI model appears to have effectively maxed out. His read is that when answers can be checked cleanly, models improve hard and fast; weaker results elsewhere may say more about evaluation difficulty, sparse training data, or limited reasoning budget than about a hard ceiling in model ability.

Practical Steps

If you buy models for work, do not compare only the top model from each lab. Test three tiers: a flagship, a mid-tier option, and one low-cost alternative from another vendor. The host's argument only makes sense if you measure output against spend.

Run your own benchmark on tasks you already do every week. Good candidates are:

• financial analysis or reporting
• workflow automation in Zapier or similar tools
• coding tasks in terminal environments
• quick app, game, or website prototypes

Track two things together: success rate and total cost per completed task. If a model is slightly worse but far cheaper, it may still be the better default.

For product and design work, test vibe-coding models separately from enterprise reasoning models. The host suggests that for game mocks, websites, and prosumer builds, you may not need the most expensive OpenAI option at all. A cheaper model from Meta or xAI could be enough.

Be careful with benchmark headlines. Check whether the result comes from a fresh benchmark, whether the tasks are reproducible, and whether the same tests are being counted twice in an aggregate score.

Notable Quotes

• "What if we can give you almost as good at a fraction of the price?"
• "There wasn't a singular benchmark that we beat... where we switched from hand coding first to AI coding first."
• OpenAI lead, replying to an Anthropic post: "I smell fear."

Lenny's Podcast: Product | Career | Growth • 1h 8m

Overview

This episode is a wide-ranging conversation with Adam Mosseri about how AI is changing product work, how Instagram thinks about ranking and creators, and what kinds of people will do well as software gets easier to build. His main point is that when execution gets cheaper, judgment matters more: taste, strategy, and the ability to decide what should exist in the first place.

He also pushes back on a common view of social algorithms. A lot of what people think Instagram "knows" about them has historically been correlation rather than rich semantic understanding, though he says new AI systems are starting to make those signals more legible.

Key Takeaways

Mosseri says the default product team is shrinking. Instead of big cross-functional groups packed with specialists, Instagram is moving toward smaller pods with four to six engineers and one "product staff" generalist who can cover some PM, design, data, and research work, then pull in specialists only when needed. His argument is simple: fewer people to coordinate, less committee work, faster decisions.

That shift changes who stands out. He is bullish on people with range, taste, and the ability to move across functions, but he does not think specialists disappear. He thinks the bar rises. Teams will still need strong designers, researchers, and data scientists, but more of them will need to grow into senior, high-judgment roles rather than purely mechanical ones.

On AI, his view is neither boosterism nor panic. He says the winning move is being clear-eyed about what the tools are good at now, what they are bad at, and where that line is moving next. He sees coding work already changing from writing code to planning, steering, and reviewing it. That means some people who were weaker in the old setup may do better now, while others who loved the old setup may like the new job less.

His answer to where humans still matter most is consistent throughout the episode: taste, strategic judgment, and curation. He describes strong product leaders less as lone visionaries and more as curators of people, ideas, and team chemistry.

On Instagram itself, one of the more interesting points is that recommendation systems have often been less interpretable than users assume. The system may not "know you like surfing" in plain language; it may just have patterns that correlate with that interest. He says LLMs now make it easier to describe those patterns back to users and give them more control over what the algorithm thinks they want.

He also argues that AI-generated content is more likely to help Instagram than hurt it, though he admits it creates ranking and trust problems. His bet is that as synthetic content becomes abundant, people will place even more value on recognizable creators, point of view, and authenticity.

Practical Steps

• Build smaller teams where possible. A compact core group with broader skills can move faster than a large team full of handoffs.
• Train for adjacency. If you are in design, research, or data, get better at the neighboring disciplines instead of defending a narrow lane.
• Use AI for first-pass mechanical work: code drafts, simple analysis, mockups, synthesis. Keep high-judgment decisions with humans.
• When using AI for strategy, give it real constraints: team shape, market conditions, brand, regulation, budget, and timing. Generic prompts will give generic answers.
• Hire for three baseline traits Mosseri says he always looks for: drive, fast learning, and self-awareness.
• Practice public experimentation carefully. If you run tests at scale, assume they will leak and prepare the explanation before launch.
• If you manage feeds, ranking, or content systems, think past the feature and into the incentives it creates. Chronological feeds, for example, can reward volume in ways that drown out friends.
• For parents, his approach is boundaries plus literacy: limited earned screen time, app approval, and active exposure to making things with AI rather than only consuming media.

Notable Quotes

• "In a world where it's easier to build things, it's more important to make sure that your time is spent figuring out what you should be building in the first place." - Adam Mosseri

• "The people who I think are going to make the most of it are the ones who are clear-eyed about what AI is good at and what it's not good at." - Adam Mosseri

• "In a world where there's an abundance of synthetic content, I actually think people are going to seek out creativity and authenticity and people." - Adam Mosseri

Decoder with Nilay Patel • 1h 2m

The Story

Nilay Patel brings Peter Kafka on at exactly the right moment: Comcast has finally started taking apart the empire it spent years insisting made sense. First came the cable network spinoff into Versant, which holds the fading channels nobody seems eager to own outright. Then came the bigger break. Comcast says it will split into one company built around broadband and distribution, and another built around NBCUniversal's entertainment assets: NBC, Peacock, Universal's studio, and the theme parks. After years of hearing Brian Roberts explain why "content plus pipes" belonged together, Kafka reads this move for what it is: an admission that the story never really held.

The conversation keeps circling one old dream. Media and telecom executives have long believed that if you owned both the network and the programming, you could make each one stronger. AOL bought Time Warner on that logic. AT&T bought Time Warner on that logic. Verizon tried a version of it with AOL and Yahoo. Comcast's NBCU deal was the longest surviving example, which almost made it seem smarter than the others. But Patel and Kafka keep coming back to the same point: survival is not the same as success. Comcast held the thing together for 15 years, yet still never found a clean answer for why the combination created special value.

From there, the episode turns to the internet fight beneath all of this. Patel argues that net neutrality sat at the center of the whole plan. If internet providers could have favored their own services, throttled rivals, or charged streamers extra tolls, maybe owning both content and distribution would have paid off. Kafka is less convinced that regulation was the deciding factor, but both agree that Netflix changed the balance. Once Netflix got big enough, consumers expected it to be available everywhere, and any distributor trying to mess with that risked a backlash. That, more than any corporate slide deck, made the old cable-style gatekeeping harder to pull off online.

Versant comes off as a holding pen for declining assets that still throw off cash. Kafka says its job is basically to squeeze value from cable while trying to buy time for something else, a move old media companies have tried for decades and rarely pulled off. NBCUniversal looks stronger, mostly because it owns things that still matter at scale. The parks are hard to copy. The studio still matters. NBC remains one of a few places that can put major sports in front of all of America at once.

By the end, the split feels less like a single transaction than part of a broader unbundling. The old theory that size and vertical integration would protect legacy media is giving way to something messier, where everyone is selling, spinning, or shopping for assets without much confidence about the final shape. Patel and Kafka sound almost energized by that chaos. After years of watching the internet slowly turn television into something duller and more fragmented, the breakups at least make the story interesting again.

Main Themes

The main theme is failure disguised as strategy for a very long time. Comcast's breakup suggests that one of media's favorite ideas, pairing distribution with programming, kept living mostly because nobody wanted to admit it wasn't working. The company could defend the logic in theory, but in practice the internet kept pushing power toward the services people actually wanted, not the networks delivering them.

Another thread is that cable economics still haunt everything. Versant exists because the old bundle is shrinking but not dead, and everybody involved is still trying to pull cash from it while pretending a next act is around the corner. That connects to the sports discussion, where live events, especially the NFL, remain one of the few things that can still hold mass attention and justify giant distribution businesses.

The episode also keeps testing whether markets or regulators set the limits here. Patel sees net neutrality as the barrier that stopped telecom companies from rebuilding cable's control online. Kafka leans more toward consumer demand and scale, especially Netflix's ability to force distributors to carry it on acceptable terms. Either way, the result was the same: the internet did not become a toll road for every media company that owned a pipe. And now Comcast is reorganizing around that fact.

The Pragmatic Engineer • 1h 18m

Overview

This AMA covers why Gergely stepped away from engineering management at Uber, how he thinks about AI in software teams, what hiring is starting to look like, and where engineers can still stand out. The thread running through the episode is pretty consistent: ignore the hype, look at incentives, and stay close to real work.

He is skeptical of grand claims about "AI-native" companies or permanent best practices. His view is more grounded: teams should use AI where it solves an actual problem, and engineers who pair technical skill with business sense are the ones doing well.

Key Takeaways

Gergely says his move into writing was less a master plan than an honest reassessment. After Uber's layoffs and his own fatigue with middle management, he realized that the thing he wanted to do after financial success - write, teach, and share what he knew - was something he could already start. That mattered more than forcing himself into a startup he was not excited to spend a decade on.

On AI and software development, he pushes back on rigid labels. He argues that most strong teams already worked in a practical loop of planning, building, shipping, and adjusting. AI changes the speed and the tools, but not the need for judgment. He seems wary of companies trying to copy Anthropic or another lab just because it sounds current.

His view on hiring is blunt. AI has weakened older signals like take-homes and remote screening because candidates can lean on tools too heavily. He expects more in-person evaluation, more subjectivity, and more friction for candidates. That may be worse for applicants, but he thinks it is where things are heading.

The engineers in demand, according to him, tend to share a few traits: they work on products, care about the business, and have found a way to get hands-on AI experience. Companies want people who can make tradeoffs around model choice, architecture, inference cost, and deployment, not people who only say they use AI coding tools.

He is also less moralistic about code quality than many engineers would like. Bad architecture can be the price of speed, and sometimes that trade makes sense early on. The real mistake is pretending the same standard should apply equally to prototypes, scaling systems, and mature products. AI also lowers the cost of cleanup later, which changes the equation.

Practical Steps

• If you want to stay relevant, get direct exposure to AI at work. Propose an internal tool, a support workflow, or an incident-response helper. Do not wait for permission in the abstract.
• If your company is rigid, look for small experiments that leaders can say yes to. Gergely's point is that many executives want more AI usage and will back practical attempts.
• If you are trying to move upmarket as an engineer, build evidence. Side projects, open source contributions, and internships still matter, especially if your current employer does not give you strong signal.
• For juniors, take the stepping-stone job if that is what is available. He is clear that having a job and doing excellent work there beats waiting around for the perfect logo.
• Match code quality to stage. Move fast on prototypes, tighten up as the product stabilizes, and refactor when the system starts carrying real revenue or risk.
• If you are considering a startup, ask whether you actually want to spend years on that idea. Gergely treats that as a basic filter, not a romantic one.

Notable Quotes

• "If you start a startup, do it because you are ready to spend 10 years of your life on it."
• "I could do that right now." - Gergely, on realizing the thing he wanted after startup success was writing and sharing knowledge
• "Use it if it makes sense and throw it away if it doesn't." - on AI adoption inside companies

AI and I • 53m

Overview

This episode is about the push and pull between AI as a powerful creative tool and AI as a distraction engine. Craig talks about using language models aggressively for software projects while also setting hard limits so the work does not crowd out the part of his life he cares about most: writing strange, personal books that only a person can write.

The conversation also moves into a broader view of this moment in tech. Craig sees AI as historically unusual, worth serious hands-on attention, but also destabilizing, socially uneven, and weird in ways most people still have not absorbed.

Key Takeaways

Craig’s main point is simple: if you are not using these systems, your opinion about them will probably be shallow. He argues that firsthand use reveals both how unreliable they can be and how absurdly capable they already are, especially for programming. His test is practical, not theoretical.

He also draws a sharp line between exploration and surrender. He says AI gives him a kind of dopamine buzz, enough that he avoids the internet and his phone until after lunch and uses a separate writing laptop that blocks distractions. That barrier matters because he thinks constant contact with AI and the internet can break deep attention. For him, protecting attention is part of protecting authorship.

A second thread is that AI changes what counts as valuable work. Craig says building a product is getting easier, which means the bar shifts from “can you make it?” to “can you maintain it, improve it, and make it matter over time?” He describes rebuilding tools he used to pay heavily for, including newsletter software and membership tools, and says the payoff is not just lower cost but better alignment with how he writes and publishes.

He also makes an interesting distinction between productive use and fake progress. AI can help people make polished surfaces quickly: a company, a mockup, a domain, a book cover. But those surfaces can satisfy the urge to make something before the thing itself exists. In that sense, AI can expose whether the real desire is to do the work or just to look like someone who did.

The episode ends on a wider philosophical note. Craig sees this as a rare technical moment, one that may widen gaps between people while also spreading capability more broadly than expected. He sounds both excited and uneasy about that tension.

Practical Steps

• Protect your best thinking time. If deep work matters, keep your phone and the internet off for the first part of the day. Craig says he waits until well after lunch.
• Separate writing from browsing. Use a dedicated device or blocking software so your writing environment cannot pull you into feeds, messages, or AI chats.
• Use AI on real projects, not just prompts. Try it on a concrete task like refactoring code, auditing security, organizing archives, or automating a publishing workflow.
• Build tools that feed your main work. Craig’s standard is useful: software should support the larger purpose, not become a hobby that replaces it.
• Watch for “veneer work.” Before buying a domain, designing branding, or polishing an idea, ask whether you are avoiding the harder part of making something worth maintaining.
• Judge products by staying power. In a world where many people can spin up an app in a weekend, durability and follow-through matter more.

Notable Quotes

• Craig: “If you’re not touching it, if you’re not using it, if you’re not building with it, you can’t really comment on it.”
• Craig: “As soon as I touch my phone, I feel the chemicals shift and I can’t go into any kind of deep thinking place.”
• Craig: “There aren’t that many people who are going to think about or write the weird books that I feel like I’m drawn to write.”

Platformer • 13m

Overview

Casey Newton uses this episode to test Glaze, Raycast's new Mac app for "vibe coding," and to ask a simple question: what changes when app-building moves out of the terminal and into a live visual editor. His answer is modest but clear. Making software gets a lot more inviting when you can see it update in real time, and that makes highly personal, small-scale apps feel more plausible than they used to.

Key Takeaways

Glaze seems to lower the barrier for non-technical users by starting with a working Mac app, compiling and installing automatically, and letting the user edit visible parts of the interface while the app is open. Newton says that alone removes a lot of the scaffolding and prompt-writing that tools like Claude Code still require.

The strongest point in the piece is not that AI-built apps are better than standard software. In one case, Newton says the opposite: there is no real reason to build another to-do app when Todoist already exists. What changed is the cost of making something weird, personal, and maybe unnecessary. His Nightwing-themed task app is silly by design, but it made chores more enjoyable for him. That matters because software usually asks users to live with its bad parts. Here, the user can change them.

The more serious example is his Platformer archive app. He had already built a version with Claude Code, but friction kept him from using it often. Glaze let him turn the same idea into something that sits in his dock, surfaces recurring topics and people, and gives him a faster way to search his own reporting. The point is less "AI makes new products" than "AI can turn a useful prototype into a tool you'll actually open."

His unfinished contacts app, Sourcecode, points to a bigger use case: private software shaped around one person's work. Newton wants a local, CRM-like system for sources that can track job changes, notes, and documents. He has not solved the privacy, security, or design issues, but the project shows where this style of app-building may have real value: software nobody else would build, but one person badly wants.

There is also a quiet warning running through the piece. Newton jokes that his comic-book image generation probably raises copyright and guardrail problems. The tools are getting easier before the rules are getting clearer.

Practical Steps

If you want to try this kind of app-making, Newton's experience suggests a few useful rules:

• Start with a problem that annoys you often, even if it seems small. Friction is enough. His archive app came from not wanting to open the terminal every time.
• Build for one user first. The best examples here are personal tools, not attempts at a mass-market product.
• Use AI app-builders for interface-heavy desktop tools, especially when seeing live changes will help you refine the idea.
• Do not treat novelty as proof of value. Newton's to-do app is fun, but he is honest that it does not beat the category leader on utility.
• Watch privacy and security early if your app touches contacts, archives, notes, or source material.
• Expect your first version to be half-baked. The payoff comes from being able to keep changing it as your needs shift.

Notable Quotes

• "It's fun to make things, it's fun to make things."
• "Until recently, software development was too expensive to pursue something so stupid. Not anymore." - Casey Newton
• "The new vibe coding tools promise a world where whatever sucks about the software you use can be changed instantly." - Casey Newton

Supra Insider • 1h 1m

Overview

This episode is about how Gusto moved from light, scattered AI use to making AI part of day-to-day work across the company. Alex walks through the shift from one person quietly using Claude and Perplexity to a broader system with shared tools, connected data, recurring hackathons, and even PMs shipping pull requests.

The core argument is simple: AI adoption does not happen because leadership says it should. It happens when people get access, time, support, and a clear way to practice inside the company’s real workflows.

Key Takeaways

Alex says the turning point at Gusto was not a memo or a tool purchase. It was repeated show-and-tell, a working prototype for compliant copy generation, and a pitch to leadership that focused on enablement rather than one-off wins. His point was that a cool demo matters less than making it possible for many people to build their own.

A big lesson from the rollout was that access alone is not enough. The company needed connected systems so AI tools could pull from the places where work actually happens: code, data, internal docs, and product context. Once those links were in place, AI became more useful for real tasks instead of isolated experiments.

The other major insight was about time. Alex argues that short bursts do not work well for this kind of learning. The hackathons gave people long blocks to build, get stuck, pair with others, and keep going without context switching. He says the largest jumps in self-reported confidence happened around these events, with PM confidence moving from 11 percent before hackathons to 83 percent after them.

There is also a strong case here for pairing and shared learning. Alex makes the point that many employees do not have spare evenings to tinker. A company-wide ritual makes learning social, practical, and less dependent on who happens to have free time.

On the PM side, Gusto has pushed further than many teams. Alex says about 76 percent of PMs have merged a PR. That does not mean everyone is taking on heavy engineering work. It starts with small changes, while engineering review standards stay in place. The goal is more technical fluency, better judgment, and less backlog drag on simple tasks.

Practical Steps

If you want this kind of adoption in your own team, the playbook from Alex looks pretty clear:

• Start with visible examples. Show real work improved by AI, not abstract claims.
• Give people company-approved access to the main tools and connect those tools to internal systems, docs, and data.
• Create recurring build time. Alex’s view is that 24-48 hours of focused work beats scattered one-hour sessions.
• Make learning collaborative. Pair experienced users with less confident ones.
• Save what you learn. Gusto keeps materials and examples from each hackathon in a shared repository so new employees can ramp faster.
• Start PM coding work with low-risk tasks like copy or UI tweaks, then expand carefully.
• Keep review standards high. AI-generated code still needs the same discipline as any other code.
• Use hackathons to build things that matter, not throwaway demos. At Gusto, some outputs turned into shipped customer features.
• Look for repeatable loops, not just one-time wins. Alex is especially interested in workflows that automate reporting, monitoring, and pattern detection.

Notable Quotes

• "You can't just say, please be AI native, and it happens. You have to create that structure and that resource for folks to actually be able to do it." - Alex

• "The biggest jumps that we have in AI proficiency amongst the PM org is directly around the times of hackathons." - Alex

• "Pre AI, so much of product was spent organizing things and people. And now with AI, where you can automate a lot of that, you can focus all that time towards customer and strategy." - Alex

Decoder with Nilay Patel • 1h 8m

The Story

This episode starts with a simple question that keeps getting bigger: what does it mean when a creator is no longer just making videos, but running a company? Nilay Patel talks with Allie Beerman and Raina Pinchansky, who lead UTA's creators division, and the answer is that the job has moved far past brokering sponsorships. Their clients are building businesses with product lines, events, media projects, and teams behind the scenes, and UTA is right in the middle of helping shape all of it.

Both Allie and Raina came up early, back when the internet still felt scrappy and self-directed. Allie came through talent agencies and got hooked on bloggers and online personalities who were building direct relationships with audiences before there was a clear business around it. Raina came from marketing and saw the same shift from the other side: people who looked like hobbyists were quietly turning into media brands. What mattered to both of them was the same thing: these creators had attention, trust, and communities before the rest of the business world quite knew how to price any of that.

From there, the conversation turns into a look at how much work sits behind the image of a creator casually posting online. UTA, as they describe it, now acts less like an old-school Hollywood agency and more like an operating partner. There are regular strategy meetings, product discussions, brand negotiations, analytics, long-range planning. The creators may be the face of the business, but there is a lot of structure underneath, especially once someone moves from sponsored posts into bigger bets like a beauty brand or a consumer product company.

Nilay keeps pressing on the unstable part of all this: the platforms. TikTok, YouTube, Instagram, all of them shape what gets seen and what gets paid, and none of them are under a creator's control. Allie and Raina don't sound panicked by that instability. Their view is that real stars survive platform shifts, and the best managers know how to spot that spark before the metrics tell the full story. They come back often to instinct, taste, and a creator's connection with their audience, which they see as the difference between a quick win and a durable career.

By the end, the conversation lands on two pressure points hanging over the whole business. One is the "influencer cliff," the risk that audiences reject a creator once the relationship turns too openly commercial. The other is AI, which could flood platforms with synthetic content and cheap copies of a creator's image or voice. Even there, Allie and Raina stay fairly steady. They see AI as a tool, not a replacement for personality, and they keep coming back to the same belief: audiences still want a human being on the other end.

Main Themes

The big theme here is that creators are now media companies, but with a different shape than the old ones. Instead of a studio owning the infrastructure and hiring talent into it, the talent sits at the center and the infrastructure gets built around them. That changes what an agency does. It also changes what success looks like. A healthy creator business can no longer rely on brand deals alone; it needs ways to turn attention into something more durable.

Another thread running through the episode is taste versus scale. Nilay is more skeptical of the platforms and where they might lead, while Allie and Raina put more faith in star power and audience connection. That tension gives the episode its edge. Everyone agrees the platforms are volatile. The disagreement is over whether strong talent can stay ahead of that volatility, or whether the system will always tilt power back toward YouTube, Instagram, and whatever comes next.

The episode also circles around a harder point about trust. Selling a product is not the same as getting views, and plenty of creators fail when they try to turn fandom into commerce. The guests argue that the ones who succeed are the ones whose products feel like a natural extension of the content, not a cash grab dropped on top of it. That idea ties everything together: brand deals, product launches, live events, even AI. The business only holds if the audience still feels like it knows who it's dealing with.

Decoder with Nilay Patel • 56m

The Story

This live Decoder episode is basically Neil Patel and Amy Lanzi standing in the middle of Cannes and saying out loud what a lot of the ad business says more quietly: the AI sales pitch is getting out of hand. Amy, who runs Digitas North America, starts from a pretty unsentimental place. She says the market is full of wild promises, weird commercial terms, and offers that sound flashy but are bad for the business over time. Publicis even made a Cannes spot mocking those promises, and she makes clear it was not much of an exaggeration.

Her bigger point is that this all feels familiar. She compares the current AI wave to the programmatic era, when people claimed advertising would more or less run itself. That never happened. It still needed people, judgment, and an understanding of brands and markets that software alone could not supply. For Amy, AI is useful, but mostly when it helps teams work faster, test more ideas, and clear away repetitive work. She talks about Digitas building agents from the bottom up, with younger employees finding practical uses inside the day-to-day work, then turning those into tools that solve bigger business problems.

From there the conversation turns to a harder question: what happens when platforms like Meta say they can do the targeting, the measurement, and now the creative too? Neil pushes on this, and Amy pushes back fast. She hates the idea that "creative is targeting," because it turns something emotional into something mechanical. She argues that the industry does not need more content for the sake of more content, and that handing all of this to a platform risks flattening brand identity into an endless stream of optimized filler. Data matters, but only if it helps brands learn, adjust, and avoid burning out the audience.

That same tension shows up in the creator economy. Neil expected AI and platform pressure to drag creator rates down. Instead, Cannes is packed with creators charging more than ever and calling themselves marketers. Amy sees the logic. Demand is high, and the biggest creators now operate like media companies, sometimes on their way to becoming full businesses with products, distribution headaches, and growth plans that look a lot like any other consumer brand. That's where agencies come back into the picture. Once a creator becomes an enterprise, they need help.

By the end, the conversation gets broader and darker. Neil brings up Adam Mosseri's vision of a fully personalized Instagram, where the app becomes different for every user. Amy's reaction is blunt: that sounds terrible. She thinks people will eventually reject platforms that become too isolating, too manipulative, too detached from any shared public experience. Her bet, and maybe her hope, is that community still matters enough to push back.

Main Themes

The thread running through the whole episode is that automation keeps promising to remove the messy human parts of advertising, and the human parts keep turning out to be the whole job. Amy is fine with AI as a tool inside the machine. She is much less interested in treating it as the machine itself.

Another theme is consolidation. Agencies, platforms, retail media players, and creator businesses are all getting bigger because scale now decides who gets to shape the system. But that scale creates new dependencies. Brands need platforms, platforms need brand money, creators need operations, and agencies want to sit in the middle by connecting data, media, commerce, and creative into one growth engine.

The episode also keeps returning to control. Who owns the customer relationship? Who decides what creative gets made? Who gets to shape how people see the world online? Amy's answer is that brands should resist giving all of that away, whether to a platform's AI stack or to a creator's personal style. The work is still to build something distinct, then keep it coherent as every part of the internet tries to turn it into feed material.

AI and I • 41m

Overview

This episode is a field report on how AI is moving from demo to daily work. Dan talks with Natalia, Every's head of consulting, about how she uses agents and coding tools in real operations, both at work and at home.

The thread running through the conversation is simple: AI is great at handling repeatable process, summarizing messy information, and turning ideas into working tools fast. It still needs supervision, judgment, and, in many cases, existing software that already solves hard edge cases.

Key Takeaways

Claudi, Every's internal AI agent, has grown from a half-manual experiment into a system that does real operational work every day. Natalia says it manages dashboards, handles CRM-related tasks, and runs a self-evaluation loop she calls a "trust battery." That progress came from better models, but the work is still not hands-off.

A clear limit showed up too. AI performs well against a standard operating procedure, but it still needs oversight, feedback, and someone to decide what good looks like. Natalia's team is hiring an operations person even with Claudi in place, because surfacing useful signals, guiding conversations, and working with humans still matters.

The conversation pushes back on the idea that companies should replace SaaS with quickly built internal tools. Natalia had a homegrown CRM setup stitched together with Google Sheets, email, meeting notes, and Claudi. It worked for a while, then the maintenance cost caught up. Her point is that you can build many things now; the harder question is whether you should own the upkeep. Tools like Attio and Asana handle a pile of hidden logic that only becomes obvious once volume and complexity rise.

Another strong idea is that AI changes the shape of knowledge work. Natalia compares it to gardening: your job is to set conditions, steer, prune, and review, rather than do every task by hand. That showed up in how she uses Codex and Claude artifacts to make learning materials, travel guides, and planning tools tailored to her needs.

The most grounded example was personal. Natalia used Codex to build a shared care portal for her 81-year-old father. It pulls together nurse reports, WhatsApp updates, follow-ups, and family tasks into one place, with language toggling and responsibility tracking. The value wasn't the app as an object. It was less searching, better coordination, and more time for actual care.

Practical Steps

• Start with a process that already has clear rules. Sales pipeline updates, inbox triage, project tracking, and status summaries are better entry points than open-ended strategic work.
• Audit the maintenance burden of your AI workflows. If your custom tool depends on constant fixing, checking, and prompt tuning, compare that cost against buying software built for the job.
• Use AI as a layer on top of your existing tools. Natalia's examples work because AI can read email, meeting notes, forms, and messages, then pull the signal into one useful view.
• Build small internal tools for specific pain points:
  • a family care tracker
  • an inbox triage dashboard
  • a personalized learning guide
  • a travel planner based on your preferences
• Treat AI outputs like drafts from a fast junior operator. Review them, improve the rules, and decide where human judgment needs to stay in the loop.
• For executives, pay attention to admin drag. The biggest near-term gains may come from offloading coordination work, not from replacing core decision-makers.

Notable Quotes

• Natalia: "AI is really good at executing against a standard operating procedure."
• Natalia: "The question is, should you build and maintain whatever you actually built?"
• Natalia: "Knowledge work now is turning into something like gardening, where when you're gardening, you're creating the conditions for the growth to happen."

Galaxy Brain • 46m

The Story

Charlie Warzel starts from a familiar shame: he reads all day for work, yet still feels starved of the kind of reading that matters. The problem is not a lack of text but the wrong kind of it - feeds, messages, tabs, alerts, all of it pushing his mind into a jumpy, thin state. He frames the episode around a question a lot of people seem to be asking right now: how do you get back to books when your brain has been trained away from them?

John Paul Brammer answers with his own story. He grew up in a house where books were treated as a basic need; his mother, who was also his ninth-grade English teacher, made literature feel normal and necessary. As a kid he read with the appetite of a scavenger, grabbing whatever looked interesting, whether it was Goosebumps or an eco-feminist sci-fi novel he was far too young to fully understand. What he misses now is not just that volume of reading but the wildness of it, the part of himself that reached for books without worrying whether they were impressive.

That became the turning point. As an adult, and especially as a writer, Brammer had started choosing books from insecurity. He wanted the ones that would make him feel legitimate, the ones he thought a serious person ought to have read. That made reading feel like punishment. What changed was realizing he had to stop treating books like homework and start following curiosity instead. He says the issue was never that his attention had vanished. He could still focus for hours when he cared enough, even if that focus was wasted on internet nonsense. The real task was to become hungry for books again.

He describes two kinds of attention: the strained, effortful kind, and the absorbed state where self-consciousness drops away and you are simply inside the thing. Social media, he says, had scrambled him, but it had also shown him that the machinery of attention was still there. He began reading in a messy, forgiving way, bouncing between books, using novelty to pull himself in, and slowly building the stamina for longer immersion.

From there the conversation opens out. Brammer talks about how Twitter shaped his career and damaged his mind at the same time, training him to write toward crowd approval and trapping him in what he calls the "absolute present" - a state of endless urgency that feels like engagement but breeds helplessness. Books broke that spell by restoring stillness. They gave him distance from the feed and brought him back to larger questions about love, loneliness, meaning, and thought itself.

Main Themes

The episode circles around curiosity as the missing piece in a lot of talk about attention. Brammer pushes back on the idea that people are simply too broken by phones to read. His point is harsher and more hopeful: attention has not disappeared, it has been redirected. If curiosity is alive, attention follows.

There is also a strong argument here about reading as a way of reclaiming inner life. Both men are wary of the moral posturing around books, the idea that reading the right classics will automatically improve you. But they still land on the view that books do something distinct because language shapes how people think and talk to themselves. Better contact with language can change writing, but also perception.

Running underneath all of this is a critique of internet life, especially the kind built around constant reaction. Brammer is clear that online platforms gave him access, work, and audience. They also taught him fear, performance, and helplessness. Reading became useful partly because it interrupted that training. It slowed him down enough to hear his own mind again.

In Depth • 59m

Overview

This episode is a conversation with Supabase co-founder and CEO Paul Copplestone about why the company worked when his earlier startups did not, how Supabase found product-market fit, and what it takes to build a developer tools company that can start with hobbyists and keep them as they grow. He also talks through the role of open source, launch strategy, remote culture, fundraising, and the recent AI-driven demand that pushed Supabase into another phase of growth.

Key Takeaways

Copplestone’s main point is that Supabase did not come from a single brilliant insight. It came from a real pain he had felt himself: databases were too hard for developers to use. He says that was obvious early, but the scale of the outcome was not. A big part of the upside came from riding the rise of Postgres, then making deliberate moves to catch that tailwind rather than assuming the market would do the work for them.

One of the clearest lessons from the episode is how much positioning matters. He says the accidental Hacker News launch only really clicked after he changed the tagline to "open source Firebase alternative." That framing gave developers an immediate mental model, and it revealed adjacent demand such as auth and functions. His takeaway is blunt: product-market fit can sometimes look a lot like product-positioning fit.

He also draws a sharp line between finding fit and scaling. Throwing more people at an unproven idea does not help, in his view. Small teams with tight feedback loops do. Even now, he says Supabase will keep a new product to one product-minded engineer until the idea is more baked. Raise money if needed, but operate as though cash is scarce.

Another theme is sequencing. Supabase did not rush upmarket. It started with "day zero" developer use cases, then added layers so teams could begin on a weekend project and stay as workloads became more serious. That same logic shaped the company’s go-to-market motion: product-led first, then sales that looks more like technical help than persuasion.

On culture, Copplestone is unusually explicit. He wanted a fully async, remote company from the start once he saw how office gravity leaves some teams out. He also wanted a high-performance, low-ego environment, and he rejects the idea that kindness and ambition are at odds.

Practical Steps

For founders and product leaders, several habits stand out:

• Test positioning early. If people do not "get" the product, try changing the framing before changing the product.
• Keep early teams small. One or two people can often find fit faster than ten.
• Watch for real pull. Copplestone describes it as growth continuing even when you are not forcing it.
• Use launches as feedback events. Supabase kept seeing demand spikes from launch weeks, then used those spikes to decide what deserved more investment.
• Build in layers. Start with the smallest, highest-frequency use case, then add capabilities that let customers stay longer rather than forcing a jump to enterprise all at once.
• Treat developer experience as time to value. Remove the paper cuts that stop someone from reaching their first useful outcome.
• If you run PLG, let sales start from product signals. Reach out when usage patterns show a real problem, and make the first conversation about helping, not closing.

Notable Quotes

• Paul Copplestone: "If the problem exists, then the opportunity exists."
• Paul Copplestone: "Product-market fit often is just like a product positioning fit."
• Paul Copplestone: "I’d still operate as if I only have a hundred thousand in the bank account."

Decoder with Nilay Patel • 1h 3m

Overview

This episode is a wide-ranging interview with Ford CEO Jim Farley about where Ford's EV strategy went wrong, what the company is changing, and how he thinks about competition from China, software, tariffs, and in-car tech. The backdrop matters: Farley is talking from a moment when Ford was betting that its next EV platform would fix the economics and product problems exposed by the Mach-E era.

He argues that Ford's first generation of EVs taught the company what customers will tolerate, what they will pay for, and how far behind traditional automakers are on cost and engineering simplicity compared with companies like BYD and Tesla.

Key Takeaways

Farley says Ford's next EV push is built around one hard lesson: selling an affordable EV is meaningless if it loses money on every unit. His point was less about headline price and more about build cost. He described Ford's answer as a separate "skunkworks" team, kept outside the company's old systems, to rethink the vehicle from scratch.

A big theme was how badly Chinese EV makers have changed the game. Farley described BYD and its peers as the standard Ford has to measure against, not just Tesla or GM. He says the challenge is not only battery cost but the whole package: simpler design, fewer parts, better digital experiences, and government-backed scale.

He was unusually direct about Ford's internal limits. In his telling, the existing organization could not close the gap because its engineering tools, release systems, and habits were too old. He tied that conclusion to a management idea he picked up at Toyota: "gemba," or going to inspect the real problem in person. For him, looking at the weight of a wiring harness and the number of fasteners in a Mach-E versus a Model Y made the decision obvious.

On software, Farley drew a line between supporting Apple and giving Apple full control of the car. Ford wants CarPlay and phone integration because, as he put it, the company should not disrupt a customer's digital life when they get in the car. But he also suggested Apple CarPlay Ultra may go too far if it takes over core vehicle controls. That leaves Ford trying to build more of its own software layer, especially around driver assistance and AI features.

He also spent real time on blue-collar labor. Farley says the U.S. has a shortage of factory workers, tradespeople, and emergency service workers, and that AI investment is tilted too far toward office work. He sees that as a national problem, not just a Ford hiring issue.

Practical Steps

For automakers and operators, Farley laid out a few concrete ideas:

• Simplify the launch product. He says Ford is trying to start with fewer variants, less feature sprawl, and a more controlled rollout.
• Build the first version around core capability. Get the base vehicle, manufacturing process, and software stable before adding more options.
• Inspect real bottlenecks directly. Farley's "gemba" habit is simple: go look at the part, the workflow, and the waste before making a major decision.
• Measure EV strategy on unit economics, not press-release affordability. A low sticker price does not help if the car is unsustainably expensive to build.
• Keep phone integration easy, but be careful about handing core vehicle controls to outside platforms.

For listeners shopping for EVs, one practical point came through clearly: Farley thinks the market is shifting away from premium EVs toward cars around the $30,000 range, where total ownership cost and day-to-day usefulness matter more than novelty.

Notable Quotes

• Jim Farley: "The Chinese are the 700-pound gorilla in our industry for EVs."
• Jim Farley: "Ford does not have the rights, in our opinion, of disrupting someone's digital life when they get in their car."
• Jim Farley: "There are no assurances that we can do this."

AI and I • 43m

Overview

This episode is a conversation with Edwin, founder and CEO of Surge, about the role of data, expert judgment, and evaluation in building advanced AI systems. He frames Surge as a "school for AGI" and argues that the work has moved well beyond basic benchmarks into teaching models taste, judgment, and the ability to act in messy real-world settings.

The discussion also turns to what happens if AI becomes better than humans at more and more intellectual work. Edwin says he could see systems reaching abilities associated with AGI within five years, which raises a harder question than capability: what humans should still choose to do for themselves.

Key Takeaways

Edwin’s main point is that training frontier models now looks less like feeding them facts and more like shaping judgment. Early benchmarks asked whether a model could do middle-school math. More recent work, he says, tests research-level mathematics and open-ended reasoning. He points to the shift from GSM8K to newer benchmarks such as Riemann Bench as evidence that the target is changing fast.

He also argues that evaluation is often the hidden driver of bad model behavior. If labs optimize for shallow public leaderboards, time spent, or flashy outputs, models learn to game those signals. His example from creative writing was blunt: some models produce a metaphor in nearly every sentence because that pattern seems to score well, even when the writing gets worse. In his view, this is a measurement problem as much as a model problem.

A second thread is the risk that AI products drift toward the same engagement traps as social media. Edwin says models can be pushed to keep users talking for one more turn rather than helping them finish a task and move on. He gave examples of chatbot follow-ups that sounded like tabloid hooks, which suggests some systems are already picking up these habits.

He sees a better path in delegation rather than addiction. A good assistant should sometimes do work in the background and sometimes tell the user to do it themselves, if that helps them grow. That means the product goal should be human flourishing, not just minutes of usage.

On personalization, Edwin thinks personal data is valuable because current systems still lack real context. Email behavior, browsing patterns, writing style, past decisions, and AI conversation history could all help train systems that understand a person’s preferences more accurately. He also says current memory features often overfit to stray details instead of the things that matter.

Practical Steps

• Audit what your AI tools are optimizing for. If a tool keeps dragging you into extra turns, ask whether it is helping you complete work or just holding attention.
• Use AI for delegation where the task is clear: summarizing inboxes, filtering spam, drafting routine responses, or handling repetitive research.
• Keep your own judgment in the loop for writing, decision-making, and creative work. Edwin’s point is that preserving human agency may need to be a deliberate choice.
• If you build AI products, measure quality with domain experts, not just broad user voting or surface-level preference tests.
• Collect high-signal personal data carefully if you want better personalization: edits to drafts, accepted vs. rejected email suggestions, repeated decisions, and task outcomes are more useful than generic chat logs alone.
• Watch for reward hacking in generated content. Flashiness, verbosity, and ornamental prose can be signs that a model learned the score rather than the skill.

Notable Quotes

• Edwin: "We are building this kind of school for AGI, where AI models come to learn about humanity, where we teach them how to run the world."
• Edwin: "It almost seems like there's nothing that humans can do that AI won't soon be capable of."
• Edwin: "We actually almost have to consciously choose to prove things on our own and to write on our own and create on our own because we have to believe that preserving our humanity is valuable in of itself, even if the output isn't optimal."

HBR On Leadership • 30m

Overview

Linda Hill argues that innovation is not a side project or a perk for good times. It is tied to survival, especially when leaders are dealing with uncertainty, new technology, and pressure to adapt faster than their organizations are built to move.

Her main point is that repeat innovation does not come from a heroic visionary with all the answers. It comes from leaders who build the conditions for people to contribute ideas, test them, and spread what works across teams, partners, and sometimes whole networks outside the company.

Key Takeaways

Hill pushes back on a common idea about leadership: when innovation is the goal, leadership is less about getting people to follow a fixed vision and more about getting them to co-create the future. Leaders still need direction and judgment, but they also need to make room for other people’s "slices of genius."

She says most organizations are weak at the three things innovation depends on:

• collaborating across differences
• experimenting and learning
• making decisions that move ideas forward

A strong planning process is not enough. Hill says you "act your way" to innovation because the path is rarely clear in advance. That means leaders need discipline around experimentation, not the illusion that they can map every step before they begin.

Another theme is that stalled innovation often has less to do with a lack of ideas than with a lack of trust and meaning. People are more likely to speak up, take risks, and work through conflict when they believe the work matters and when they feel respected by the people around them.

She also highlights three leadership roles companies need to build on purpose:

• Architects, who shape the organization so it can innovate repeatedly
• Bridgers, who connect silos like tech and business, and often connect the company to outside partners
• Catalysts, who create broader coalitions that help ideas spread and scale

Hill’s point about "wayfinders" stands out. In periods of uncertainty, leaders often do not know the exact destination. Their job is to help people move through ambiguity using values, judgment, and learning along the way.

Practical Steps

Leaders who want to restart innovation can begin with a blunt assessment of culture and capability. Ask where the current culture helps innovation and where it blocks it. Then look at whether teams can actually collaborate, run experiments, and make decisions without getting stuck.

A few concrete moves from the conversation:

• Create space in meetings for others to speak first. Hill gives one example of a CEO who stopped talking for the first 20 minutes to avoid dominating the room.
• Build a feedback loop for leadership behavior. That can mean a coach or a trusted "sparring partner" who will tell you when your intent and your impact do not match.
• Clarify shared purpose. If people do not see meaning in the work, they are less likely to take the risks innovation requires.
• Identify and promote people who can bridge functions, especially between technical teams and business teams.
• Treat scaling as part of innovation from the start. Ask early who else inside or outside the company needs to be involved to make an idea real.

For senior teams, Hill’s advice is to stop assuming collaboration across silos will happen on its own. If horizontal work is required, design for it.

Notable Quotes

"Leadership is not about followership when it's about innovation. It's about co-creation." - Linda Hill

"You cannot plan your way to an innovation. You can only act your way to one." - Linda Hill

"What we need is we need wayfinders, not pathfinders." - Linda Hill

Supra Insider • 1h 4m

Overview

Kyler explains how he moved his team from chat-based AI toward a shared operating layer for agents at Cloaked. The shift started from a simple pain point: too much time spent copying outputs between tools, re-finding prompts, and re-explaining company context every time a new session started.

What followed was a company-wide system built around structured markdown files, reusable skills, tool access, and automated guardrails. At a company of a bit over 100 people, he says the setup is installed on every managed machine and used by most employees, with Slack as the main access point for non-technical teams.

Key Takeaways

The strongest idea in the conversation is that AI works better when you optimize for the agent, not the human typing into a chat box. Kyler argues that most teams still think in terms of "how do I prompt this thing," when the better question is "how do I make context easy for the agent to find and act on without wasting tokens or getting lost."

His answer is a shared directory of company knowledge, mostly in markdown, plus scripts and workflows that let the agent read from core systems and write back into them. He describes this as repeatedly onboarding the agent to the company, because every fresh session starts cold.

Another point: access matters more than elegance. Cloaked found that asking everyone to use terminal-based coding agents was a losing battle. For broad adoption, Slack agents worked better. Technical users can go deeper in tools like Cloud Code, but support, marketing, and others get value by tagging an agent in Slack and letting it run against connected systems in the background.

Kyler also treats this internal AI layer as a testing ground for a more automated way of shipping software. He says code generation is getting faster, while review, QA, and validation are becoming the bottleneck. His team still keeps human review in place for production work, but he is building toward a future where simpler changes can move through automated review and testing without a person checking every step.

The other big lesson is that agents need deterministic guardrails. He does not trust prompts alone. Instead, he uses hooks to force good behavior, like creating git worktrees automatically so parallel agents do not stomp on the same files, and cleaning them up once work is merged. That keeps the system usable at scale.

Practical Steps

• Build a shared company context layer in a clean folder structure. Use markdown files for product, team, process, and company knowledge so agents can retrieve context quickly.
• Turn repeatable workflows into reusable skills. If a session works once, save it as a skill instead of rebuilding it from scratch next time.
• Connect AI to the tools where work already happens. Read access is useful, but write access is where the payoff shows up: creating tickets, docs, messages, and code changes.
• Use Slack for broad adoption. If your goal is company-wide usage, meet non-technical teams in the interface they already use.
• Add hard guardrails with hooks. Force actions like worktree creation, PR checks, and cleanup automatically rather than hoping the agent remembers.
• Create review agents for internal systems first. Use lower-risk internal tools to test automated review, QA, and CI patterns before applying them to production code.
• Add a cleanup agent. Kyler’s "librarian" checks for stale knowledge, drift, and accidental sensitive information, then alerts the right person.

Notable Quotes

• "You need to make it easy for the agent to be able to find the thing they're looking for and pull it in and access it easily without spending a bunch of context." - Kyler
• "You're basically onboarding the agent onto your company." - Kyler
• "I try to think about how can I set the agent up so that it's impossible for it to fail." - Kyler

Worklife with Molly Graham • 38m

Overview

This episode is about how product culture gets built, tested, and scaled, with Facebook as the main case study. The guest argues that "move fast and break things" was never about recklessness. It was about learning faster than competitors, then building enough guardrails that mistakes teach you something without taking the whole company down.

Key Takeaways

The clearest point is that speed only matters if it improves learning. The guest explains that Facebook's real advantage was not raw shipping velocity for its own sake, but the ability to get feedback from users, react quickly, and keep doing that at huge scale. In a consumer product where tastes shift fast, waiting months to decide what users want is a losing move.

He also makes a useful correction to one of tech's most repeated slogans. The original idea, he says, was "move fast and don't be afraid to break things." That missing clause changes the meaning. The aim was never damage. The aim was to remove fear so teams would test ideas, learn, and improve.

Another strong theme is that culture cannot be copied blindly. What worked at Facebook would be a bad fit in places like aerospace, energy, or other high-risk fields where failure has very different costs. Culture has to match the product, the market, and the founder's own instincts. Otherwise people hear one set of values and get rewarded for another.

The conversation also gets specific about psychological safety. The guest describes incident review meetings where leaders stopped people from blaming the engineer who caused an outage and pushed the room toward a harder question: why was the system fragile enough that one change could cause that much damage? That shift matters. It turns mistakes into design problems instead of character judgments.

One story shows why this matters in practice. During a major outage, an engineer volunteered that their code change might be the cause. That honesty, the guest says, helped restore service much faster and likely saved the business hours of downtime. People only speak that plainly when they know the response will be investigation, not humiliation.

Practical Steps

If you are leading a team, a few moves stand out:

• Define what your culture is for. Ask what kind of business you run and what kind of failure is acceptable. A consumer app, a bank, and a rocket company should not run the same playbook.
• Rewrite slogans into behavior. If you say speed matters, explain what that means operationally: faster experiments, shorter feedback loops, and clear rollback paths.
• Run blameless postmortems. When something fails, ask "how did our system allow this?" before asking who touched it.
• Build guardrails before pushing for speed. Automated tests, staged rollouts, failover systems, and recovery plans are what make fast iteration safe enough to sustain.
• Stress-test your own infrastructure. The guest describes deliberately taking systems offline to expose hidden dependencies before real failures do it for you.
• Check whether rewards match stated values. If you say teamwork matters but only reward individual heroics, people will follow the incentives, not the poster on the wall.

Notable Quotes

• "The speed at which you could learn was the determinant of success."
• "Why in the world do we not have systems that would have prevented this?"
• "When you can build a culture that has intellectual honesty and psychological safety, you're going to win."

Decoder with Nilay Patel • 1h 13m

Overview

This episode is about how Patreon has changed from a payments layer for creators into something much closer to a full creator platform. Jack Conte says the shift was forced by the big platforms: once Facebook, YouTube, Instagram, and TikTok stopped giving creators reliable access to their own audiences, Patreon had to build discovery, media hosting, chat, and free follow tools itself.

The broader argument is bigger than Patreon. Conte sees the current social platform model as bad for creators and bad for people in general, and he thinks AI is making the problem worse by flooding platforms with cheap content while also pulling from creators' work without fair consent or payment.

Key Takeaways

Conte’s clearest point is that the internet moved from follower-based distribution to interest-based distribution, and that broke the direct line between creators and fans. If a creator cannot reliably reach the people who chose to follow them, they do not really own an audience and they cannot build a stable business around that audience.

That explains Patreon's biggest reversal. Conte used to resist discovery features because Patreon was meant to sit at the bottom of the funnel, handling memberships and payments after fans were already won elsewhere. He now says that model no longer works. If Patreon does not help creators grow their audience itself, then creators are stuck depending on companies that can change the rules at any time.

He described Patreon today as an "index of small business media companies." That framing matters because it shifts the company away from being a utility and toward being an operating platform for creators. The additions he pointed to, including native video, chats, feeds, short posts, and free memberships, are all meant to restore direct reach. He says free memberships alone have grown to 185 million, and that Patreon is now sending 1.5 million new followers to creators each month.

On AI, Conte held two positions at once. He called the current treatment of creators "disgusting" because models have been trained on creative work without real permission, compensation, or credit. At the same time, he says Patreon has no choice but to use AI heavily inside the company for coding, internal search, summaries, and operations, because a software company that ignores these tools will fall behind fast.

His product line on AI is sharper than the usual "AI everywhere" pitch. Creators, he says, do not want help making the work itself. They are more open to AI for packaging, marketing, and business admin. That leads to a simple internal rule: use AI to handle the chores around the work, not to replace the act of making it.

Practical Steps

For creators and media businesses, the practical lesson is to rebuild direct audience connections wherever possible.

• Collect direct fan relationships, especially email and free memberships, instead of relying only on platform followers.
• Put free, accessible samples of your work where new people can find them. Conte says discovery without free media did not convert.
• Build community in places where you can reliably reach people, such as owned chats, newsletters, or member spaces.
• Treat platform growth as rented attention. Use it, but do not confuse it with customer ownership.
• If you are testing AI, start with admin and packaging tasks: transcripts, chapter markers, clipping, support flows, scheduling, and finance work.

Conte also gave a solid decision-making playbook for operators:

• Start meetings by asking who strongly disagrees.
• Do not trust the initial framing of A versus B.
• Use pre-reads so meetings are for debate, not background download.
• Name a clear decision maker.
• Say out loud where you are leaning before the meeting ends so the real objections surface.

Notable Quotes

"Patreon is essentially like an index of small business media companies." - Jack Conte

"What ultimately is happening to creative people right now is disgusting." - Jack Conte

"I need AI to help me do my taxes and clean my toilet." - creator feedback quoted by Jack Conte

Lenny's Podcast: Product | Career | Growth • 1h 38m

Overview

This episode is a look at what software teams look like when AI is baked into the work, not added on top. Fiona Fung, who leads Claude Code and cowork at Anthropic, describes a world where code output has jumped so much that writing code is no longer the main constraint. The harder problems now are ambition, verification, product judgment, and team culture.

She also gets specific about how management changes when everyone can ship more: managers use agents to track feedback, summarize work, generate fixes, and stay close to product quality. The job is shifting from supervising output to setting direction, defining what good looks like, and keeping accountability high.

Key Takeaways

Anthropic engineers, Fiona says, are shipping far more code than before, but that does not mean the job is simpler. The bottleneck has moved. Teams now have to answer: What should we build? How do we verify it? Did it work in the market? More people beyond engineering - PMs, designers, other functions - can now contribute code, which raises the need for better review frameworks and clearer ownership.

The people doing best in this shift tend to have agency. Fiona keeps pairing that with accountability. Her team wants people to "have freedom to cook," but they also need a hypothesis, a reason for the work, and a way to judge whether it helped. Ambition matters more when implementation gets cheaper.

She makes a strong case for codifying "what good looks like." Specs, tests, content rules, quality bars, and review frameworks should live in the repo so AI can check against them. That turns code review from a human bottleneck into a mix of automated checks plus targeted human judgment for the hard parts.

Hiring is also changing. Fiona says she looks for two profiles: product-minded builders who can spot opportunities and push ideas end to end, and deep systems experts who can handle the parts where real subject-matter knowledge still matters. General coding skill alone is less distinctive than it used to be.

One cost of this new mode is isolation. Engineers can end up working mostly with agents. Fiona says her team started pairwise programming lunches and hackathons partly to bring back shared learning and human connection. Another cost is context switching: once you have many async agents running, reviewing all that work becomes its own tax.

Practical Steps

• Move review upstream. Put specs, tests, and quality standards in the repo so AI tools can validate against them.
• Audit your recurring manager work. If you check feedback channels, summarize bugs, or review themes every morning, automate that first.
• Shorten planning cycles. Fiona moved toward lightweight monthly planning with frequent check-ins because longer plans got stale too fast.
• Define quality in plain terms. Her team uses ideas like "bad" versus "sad" experiences so each team can classify and track user pain in a way that is easy to act on.
• Build product sense on engineering teams. Have engineers read feedback, use the product daily, and connect shipped work to outcomes, not just output.
• Protect team connection. If people are mostly working through agents, add regular sessions where they can watch each other's workflows and learn in real time.
• If AI feels threatening, start with one manual task you hate and ask: can this be automated now, or at least made easier?

Notable Quotes

• Fiona Fung: "Coding is no longer the bottleneck."
• Fiona Fung: "It's lifted the ceiling of what anyone is able to do."
• Fiona Fung: "We say with high agency is also high accountability."

The Ezra Klein Show • 1h 18m

The Story

Ezra Klein brings Gary Shteyngart on because he keeps looking around at modern life and feeling like we already live inside Super Sad True Love Story. Shteyngart’s 2010 novel imagined a near-future America where everyone carries an "Apparat" that ranks them constantly: by looks, status, credit, desirability. Back then, he thought he was writing 30 years ahead. Now he looks at influencer culture, looksmaxing, wellness mania, and the hunger to be measured at all times, and he thinks it arrived in half that time.

What follows is part literary conversation, part diagnosis of a culture that has confused being seen with being alive. Shteyngart talks about the way social media trained people to need a score in order to know who they are. In the novel, when the ranking system goes down, young people can’t bear the emptiness. That idea no longer sounds extreme. He connects it to his own life too, from getting hooked on early social media to growing up at Stuyvesant, where he still remembers his exact average to three decimal places. The point isn’t that hierarchy is new. It’s that now every part of the self can be turned into a metric and thrown back at you.

From there, the conversation widens into longevity culture and the joyless pursuit of self-optimization. Shteyngart is amused and repelled by figures who want to live forever while barely seeming to enjoy being alive. He sees a lot of modern ambition as a refusal to accept an ordinary, finite life, a desire to outrun disappointment by extending the timeline. Klein keeps pulling him toward what gets lost in that process: pleasure, friendship, talking face to face, the actual texture of life.

That’s where Shteyngart gets most animated. He calls conversation "verbaling," borrowing the term from his novel, and treats it almost as an endangered art. Screens offer a counterfeit intimacy, one that is profitable for platforms and often destructive for the person handing over their insecurities for public judgment. He is especially sharp on the loneliness underneath male subcultures, streamer fame, and the performance of mental instability online. These systems make damage legible, even lucrative, but they don’t create care.

By the end, the mood changes. Shteyngart starts talking about what he loves: watches, martinis, suits, dogs, travel, handmade objects, the beauty of people doing things well because they care. His coming essay collection, The Sensualist, sits behind that turn. He argues for attention to beauty, pleasure, and skill as a way of resisting a world obsessed with optimization. Even while talking about death, including friends who died young, he comes back to the same point: what mattered at the end was still human company, still pleasure, still the chance to talk.

Main Themes

The episode keeps circling one big idea: modern life pushes people to live from the outside in. Ranking, posting, tracking, and optimizing all ask the same question: how do I appear? Shteyngart thinks that question has swallowed more intimate ones about character, joy, and meaning. His novel saw that early, but here he gives it a social and emotional logic. People don’t just submit to metrics because they are forced to. They start needing them.

Another theme is the split between longevity and living. Klein and Shteyngart both see a culture that treats pleasure with suspicion while celebrating discipline as a moral display. That extends from Silicon Valley anti-interiority to elite wellness habits to politics itself. Shteyngart’s answer is neither nostalgia nor a program. It is closer to a temperament: pay attention, enjoy things, admire skill, talk to people, and stop treating your life like a spreadsheet.

How I AI • 29m

The Big Idea

This episode explains "loops" for AI agents in plain English. A prompt is the instruction you give an AI. A loop is what happens when that instruction gets triggered automatically instead of waiting for you to type it every time.

The host’s main point is simple: stop thinking of AI as something that only responds in a chat box. You can set it up more like a dishwasher timer or a Roomba. At a certain time, or when something happens, it wakes up, does a job, checks whether the job is finished, and keeps going until it is or until it gets stuck.

The episode focuses on coding agents like Codex and Claude Code, but the idea applies more broadly. An agent can review pull requests, check Jira tickets, validate tools, send Slack updates, and even start smaller helper agents to do parts of the work.

Why It Matters

If you only use AI by typing one prompt at a time, you are basically hiring a smart assistant and then making it sit still until you tap it on the shoulder. Loops let the assistant watch the inbox, check the calendar, and handle repeat jobs on its own.

That matters because a lot of useful work is repetitive. Checking for new bug tickets, reviewing old pull requests, testing whether a new internal tool still works - these are chores that pile up. A loop can take care of them in the background.

The host also argues that this is where AI becomes more than a toy. Once the agent has access to your code, tickets, docs, and chat tools, it can do real work. But that also means you need to set it up carefully, because a bad loop can waste money, create messy output, or run longer than you expected.

Key Concepts

A good starting point is the difference between manual prompts and automated prompts.

A manual prompt is the normal chat setup: you type, the AI replies, you type again.

A loop is an automated prompt. The host describes a few common kinds:

• Heartbeat: every few minutes, check something.
• Cron: run at a set time, like every Friday at 10 a.m.
• Hook: run when an event happens, like a new email or a tool call.
• Goal: keep working until a clear result is reached or the agent gets blocked.

The "goal" idea is the newer piece. It is less like setting an alarm clock and more like giving someone a job with a finish line: "Keep going until the tests pass."

The episode also covers what helps loops work well:

• Worktrees: separate sandboxes so agents do not step on each other’s code
• Skills: reusable instructions for common jobs
• Connectors and plugins: the tools the agent can access, like GitHub or Slack
• Sub-agents: helper workers for smaller tasks
• State tracking: a running to-do list so the agent remembers what it is doing

One example in the episode is a daily loop that checks for pull requests older than 12 hours, watches their merge checks, and sends a Slack message when they are ready. Another is a weekly loop that reviews recent code changes, suggests missing team "skills," then starts sub-agents to test whether those skills actually work.

The Bottom Line

A loop is just AI on autopilot: a prompt that runs on a schedule, on an event, or until a goal is met.

Used well, loops turn AI from a chatbot into a worker that handles repeat tasks without being asked every time. Used badly, they burn tokens, run too long, and make a mess. The host’s advice is to start small, give the agent clear jobs, clear stop rules, and the right tools. That is what makes self-prompting useful instead of chaotic.

The Pragmatic Engineer • 1h 14m

Overview

This episode is a practical tour through modern CI/CD with Rob Ayers, who has spent more than a decade working on deployment systems and joined Octopus Deploy early on. The conversation moves from the basics of continuous integration, delivery, and deployment into the harder parts teams hit in practice: progressive delivery, GitOps, feature flags, roll-forward strategies, and how AI may change release pipelines.

Key Takeaways

A clear distinction runs through the episode: continuous integration means merging code and testing it often, continuous delivery means the software is always in a deployable state, and continuous deployment means it actually goes to production automatically. Rob’s point is that teams do not all need the last step. Regulation, staffing, and operational risk can make full continuous deployment a bad fit, even when strong delivery practices still make sense.

Progressive delivery comes up as the next step after getting a decent pipeline in place. Instead of releasing to everyone at once, teams release in controlled slices, watch the system, and expand only if the signals look good. Rob uses canary releases as the classic example, including the old Skype habit of treating New Zealand as the first real-world test group.

One of the more useful arguments in the episode is that feature flags are often better than deployment techniques like blue-green or canary on their own. A deployment moves code; a feature flag controls exposure. That separation gives teams a safer way to release changes gradually and turn them off fast when something goes wrong.

Rob is also skeptical of the sloppy way people talk about GitOps. His take is that GitOps is less about Git itself and more about declarative state, versioning, pull-based updates, and continuous reconciliation. The name pushes teams toward an "everything in Git" mindset, but that breaks down with secrets and other cases where Git is a poor fit.

Another strong point is the advice to stop centering rollback as the default recovery plan. Rollbacks sound clean until schema changes and stateful systems get involved. In those cases, rolling forward with a fix is often safer and more realistic than trying to restore the past.

Practical Steps

• Get to continuous delivery before chasing continuous deployment. Make sure builds, tests, and deployment steps run reliably enough that production release is a choice, not a scramble.
• Start progressive delivery with one feature flag on one meaningful feature. Use it to separate deployment from release and get used to controlling exposure in production.
• Add ownership and expiry to every feature flag. Rob says his team tracks which team owns each toggle and when it should be removed, then uses CI checks or notifications to clean them up.
• Build observability before leaning on canaries. If you cannot tell whether the new version is healthy, a partial rollout does not buy you much.
• Plan for roll-forward recovery. Test how you will patch a bad release quickly, especially when database changes are involved.
• Treat GitOps as a model for desired state, not a rule that every operational detail belongs in Git. Keep secrets and other sensitive runtime concerns in systems designed for them.
• Consider ephemeral environments for branch-level testing. They give engineers and reviewers a short-lived, shareable environment without the contention of a single shared test box.

Notable Quotes

• "The reality is it doesn't really suit every company." - Rob Ayers, on continuous deployment
• "Nothing in any of these pillars actually talks about Git." - Rob Ayers, on GitOps
• "If I've got a failure in version two, my rollback isn't to go to version one, it's to go to version three." - Rob Ayers

Decoder with Nilay Patel • 40m

Overview

This episode is a rundown of the Trump administration's sudden move to restrict access to Anthropic's new AI models, Mythos 5 and its public-facing sibling, Fable 5. Nilay Patel talks with Verge AI reporter Hayden Field about how a possible jailbreak report, a call from Amazon CEO Andy Jassy, and a rushed government response turned into a bigger fight over AI regulation, export controls, and political risk.

The broader point is bigger than Anthropic. The episode shows how shaky the current US approach to AI has become: light-touch until a panic hits, then hard enforcement with little warning.

Key Takeaways

Anthropic's product setup matters here. Hayden explains that Mythos 5 is the underlying model, pitched by Anthropic as powerful enough to pose serious security risks, while Fable 5 is the same basic system with heavier guardrails for public use. That framing helped sell the model, but it also gave regulators language to use against the company once concerns surfaced.

The trigger appears to have been a potential jailbreak found by Amazon researchers. Hayden says Anthropic was already in talks with those researchers when the Trump administration stepped in after a call from Andy Jassy. What followed, by her account, was a 90-minute ultimatum and a broad restriction that blocked even foreign nationals working in the US from accessing the model. That is where the story shifts from a product safety issue to a government process issue.

A big unresolved question is why Anthropic was singled out. Hayden says sources told her that the capabilities at issue were not unique to Fable 5 and could also be reached with competing models such as GPT-5.5. If that is right, the government's response looks less like a general standard and more like a selective action against a company that already has a tense relationship with the administration.

That tension runs through the whole conversation. Anthropic has spent years arguing that advanced AI needs regulation and that frontier models can be dangerous. Now it is finding out what regulation looks like when it is improvised, politicized, and driven by personal calls instead of a stable review system. Hayden's read is that Anthropic's own warnings partly backfired, but the administration's response still looks erratic.

The fallout may hit the whole industry. Hayden says companies are now treating US political risk as part of their business planning, with some already signing backup contracts outside the country or turning to open-weight models and alternate infrastructure. For an administration that says it wants the US to beat China in AI, that kind of instability cuts the other way.

Practical Steps

For people working in AI policy, product, or compliance, the episode points to a few clear moves:

• Build a government-response plan before a crisis. Know who handles agency outreach, export control questions, and emergency shutdown decisions.
• Stress-test access controls now, especially for employees, contractors, and foreign nationals. Assume regulators may ask for restrictions with little notice.
• Document red-team findings and remediation work in real time. If a vulnerability comes up, you need a record that shows what was found, when, and what was done.
• Be careful with safety marketing. If a company publicly says its model could be a cyber weapon, that language may come back during a regulatory fight.
• Plan for political risk like any other operational risk. That includes backup vendors, alternate deployment options, and a way to keep customers informed if a model goes offline.

For policymakers, the lesson is simpler: if AI regulation is going to exist, it needs a real process. Voluntary rules and last-minute ultimatums do not mix well.

Notable Quotes

• "AI companies are really bad at naming things, and it's always very confusing." - Hayden Field
• "If you're going to regulate, do it." - Hayden Field
• "We are definitely building the technology much faster than we can think about the implications of it." - Hayden Field

AI and I • 28m

Overview

Mike Taylor talks with GitHub COO Kyle Daigle about what coding agents are doing to software development at GitHub scale. The discussion centers on who counts as a developer now, how GitHub is handling a flood of agent-generated pull requests, and what product changes are needed when software keeps moving even after the human has logged off.

Kyle’s main view is that this is not a passing spike. He says agent activity is pushing GitHub into a new phase of growth, and the company is building for a world where one person works alongside many agents, not just a single assistant.

Key Takeaways

GitHub is seeing a wider mix of users than the old “professional developer” category suggests. Kyle says legal teams, finance teams, and other knowledge workers are using Copilot tools to build small apps and internal assets. That changes the on-ramp: the product still serves serious engineering teams, but it also has to be easier for people who would never have called themselves developers.

The scale shift is large. Kyle says GitHub shared last year that it had a billion commits across the full year, and that it is now on pace for far more if growth stays anywhere near current levels. He also says there were 17 million pull requests created by agents in March alone. His point is that this is not just junk output piling up. More code is being made because developers are learning how to work with one, two, or many agents at once.

Open source maintainers need control more than a single platform-wide rulebook. Daigle argues that GitHub should give maintainers building blocks, not force one standard on every community. Some projects may want vouch systems or contributor gates, others will not.

A big theme is personalization. Kyle thinks the long-term win is not just more agent sessions, but agents that understand how you work without forcing you to write endless instructions. He keeps coming back to memory, context, and model tuning around a person or team’s actual work.

On cost, his answer is model routing. He suggests that ballooning AI bills come partly from people manually picking the most expensive model for every task, even when the task has become simple. Better tooling should switch models for you based on task difficulty and cost limits.

Practical Steps

If you manage a team or repo, focus on review and merge flow first. Kyle points to agentic code review and merge automation as places where AI can reduce the human cleanup work that piles up after a PR is “basically done.”

For open source projects:

• Set contributor controls early.
• Decide who can submit directly, who needs proof of prior contribution, and what level of review each path gets.
• Avoid copying another project’s policy unless it fits your community.

For developers trying to control spend:

• Use model routing where available instead of manually sticking to one top-tier model.
• Define cost and quality thresholds for tasks, such as “use the best model only for hard reasoning or architecture work.”
• Break workflows into stages so smaller tasks can fall to cheaper models.

For product teams building with AI:

• Track both hard metrics and user sentiment.
• Use acceptance data, thumbs up/down signals, and workflow outcomes to keep improving.
• Watch for overfitting: a system can score better in evals while users like it less.

Notable Quotes

• Kyle Daigle: "We want to make it easier for people to choose to try to write some code."
• Kyle Daigle: "Everyone's doing it, how can we cement it?"
• Kyle Daigle: "It is just climb, climb, improve, new eval, improve, new data, improve, and just keep going."

AI Explained Official Podcast • 13m

Overview

This episode breaks down the sudden shutdown of Anthropic's Fable 5 after a US government export restriction made it effectively impossible to offer the model to foreign nationals. The host argues that the move was far bigger than a routine safety response and may signal a new, messy phase in AI regulation, where jailbreaks, geopolitics, and company messaging collide.

Key Takeaways

The core claim is that the government did not just ask Anthropic to patch a problem. According to the reporting cited here, officials chose export controls because they were the fastest way to force action, knowing Anthropic would likely have to block the model for everyone rather than try to screen every user and employee by nationality.

A big part of the episode is the split between two explanations. The less cynical read is that officials, under pressure to show they were taking frontier-model risks seriously, reacted quickly after being shown a jailbreak by a trusted outside party. The more cynical read is that the decision was already made, and the jailbreak served as a pretext for singling out Anthropic while leaving rivals untouched.

The host leans hard on a contradiction: Anthropic says the capability exposed by the jailbreak was already common across other models, and in some benchmarked areas like prompt injection resistance, Mythos and Fable were said to perform far better than GPT or Gemini. If that is right, then the question becomes why Anthropic drew the export ban while others did not.

Another thread is that the reported jailbreak itself may not have been the nightmare scenario the public might assume. One cited account says the model was prompted to help patch security vulnerabilities, which a cybersecurity firm reportedly viewed as normal defensive use rather than a major threat. At the same time, the host concedes there are separate reports of more harmful jailbreaks, including one involving explosives, which makes the official focus look selective.

The episode also points out a problem no one has solved: jailbreak resistance is not absolute. Anthropic's defense, as presented here, is that narrow jailbreaks are different from universal ones, and that "perfect" resistance is not available from any major lab. That matters because if one exploitable edge case becomes enough to trigger export controls, the standard could freeze releases across the whole industry.

Practical Steps

For people building with frontier models, the immediate lesson is to plan for policy shock, not just technical failure.

• Avoid depending on a single model provider for production use. Keep backups tested and ready.
• Separate tasks by risk. Do not route sensitive biosecurity or cybersecurity workflows through one model without fallback rules and human review.
• Track policy signals, not just model performance. White House statements, export rules, and company system cards now matter as much as benchmarks.
• Read safety claims closely. If a lab markets itself around extreme caution, that language can later be used against it by regulators.
• If you run a company, map out what happens if access is restricted by geography, identity verification, or employee nationality. The host suggests those questions are no longer hypothetical.

For regular users, the practical move is simpler: expect access instability, export controls, and tighter identity checks to become part of using top-tier AI systems.

Notable Quotes

• "The quickest way to shut Fable down was to ban its export."
• "We suspect that perfect jailbreak resistance is not currently possible for any model provider." - Anthropic statement
• "Who at the White House evaluated this and thought it was a threat? It's a complete overreaction." - independent cybersecurity firm, as quoted by the host

Platformer • 1h 24m

Overview

This live Platformer event focused on a simple question with a messy answer: as AI gets better at automating tasks, what happens to jobs, software, and the way people work. Casey Newton spoke with Ella Marcianos, Atlassian executive Tamar Yehoshua, and Replica and Wabi founder Eugenia Kuyda about new AI job categories, workplace tools built on company context, and a future where people may make more of their own software.

What came through most clearly is that AI is not just replacing work in a clean, one-to-one way. It is also creating new roles, shifting what valuable work looks like, and lowering the cost of building tools, while raising the bar for judgment, speed, and taste.

Key Takeaways

Ella Marcianos opened with a grounded point: AI is already producing a wave of new job titles, but it is still unclear how many are actually new jobs versus old jobs with AI branding. She cited roles companies are adding, from "AI forward-deployed engineer" to "AI business automation engineer," and suggested the real test will be outcomes. If these hires help customers do things faster or differently in a lasting way, then the category is real. If not, some of this may be rebranding.

Tamar Yehoshua argued that AI at work gets much better when it has company-specific context. Her example was Atlassian's "teamwork graph," which connects data from Jira, Confluence, Slack, and other tools so an AI system can reason over what has happened inside an organization, not just what exists on the public internet. She said that makes it easier to solve recurring incidents, coordinate projects, and reduce repetitive work. Her broader point was that productivity gains matter less on their own than what they free people up to do: better planning, better prioritization, and better product decisions.

She also made a practical distinction that ran through the conversation: people tend to react to AI at work with either curiosity or fear, and adoption often depends on visible internal champions who can show useful results.

Eugenia Kuyda took the discussion in two directions. First, on Replica, she said the early bet was that people wanted connection badly enough that even weak systems could matter if they made users feel heard. That demand, more than early technical quality, helped explain why AI companionship took hold. Second, on Wabi, she made the case that software creation is getting cheap enough that many subscription app categories may be in trouble, especially ones with weak retention and little differentiation. She pointed to fitness, meditation, and lifestyle apps as vulnerable if users can generate tools that fit their own lives better.

Her hiring view was also sharp: if AI makes average execution cheaper, small startups will want fewer people, and those people will need strong product sense, initiative, and the ability to ship without heavy management.

Practical Steps

• Audit your work for coordination drag. Look for tasks that involve chasing updates across docs, tickets, messages, and spreadsheets. Those are strong candidates for AI assistance.
• Start with drafting, summarizing, and project tracking before giving an agent permission to act on its own. Yehoshua was clear that "human in the loop" still matters.
• If you lead a team, create a small group of internal AI champions. Have them test tools, show examples, and share what actually saved time.
• Treat "AI job" claims skeptically. Ask what outcome changed, not whether the title sounds new.
• If you build products, focus less on whether AI can help your team ship faster and more on whether it helps you choose the right thing to build.
• If you're hiring for an AI-heavy startup, screen for agency. Look for people who can spot a problem, decide what to do, and ship without waiting for a lot of process.

Notable Quotes

• "It seems like it's getting really easy to automate a task. At what point does that mean we can automate a job?" - Casey Newton
• "The teamwork graph gives you context, which actually makes the results better." - Tamar Yehoshua
• "If this is the level of understanding that's required for the most amazing conversation, we can probably build that." - Eugenia Kuyda

How I AI • 40m

Overview

This episode is a technical discussion about where coding agents actually help senior engineers: not on toy tasks, but on ugly, expensive problems like query performance, infrastructure changes, schema migrations, and AI product evaluation. Claire Vo and Ankur Goyal argue that the right way to work with agents is to define the outcome and tests clearly, then let the model run many experiments that a human would never have time to do by hand.

A second thread runs through the whole conversation: evals are not a side topic for AI teams. Ankur’s view is that evals are the modern version of a PRD - a way to define what success looks like in examples and measurable checks, rather than trying to spell out every implementation detail up front.

Key Takeaways

Ankur’s main point is that strong models change engineering work from specifying the exact method to specifying the target and the checks. In his case, that means taking slow real-world query patterns, reproducing them, and using coding agents to test combinations of indexing strategies, column-store formats, and execution engines. The value comes from scale and persistence. An agent can run benchmarks for days, compare many options, and keep digging where a human would run out of time or patience.

Both speakers push back on the idea that AI falls apart on hard engineering work. Claire says this is the first setup she has used that can handle long-tail technical problems when the goal is precise and the evaluation loop is strong. Ankur goes further: he says no staff engineer is manually running as many benchmarks, trying as many algorithms, or checking as many ideas as someone using agents well.

They also draw a useful line around autonomy. Claire describes an "agent line": if the information discussed in a meeting could be handed to an agent and it would reach the same decision or produce the same result, that work should probably move below the line. In her view, that line keeps rising.

On evals, Ankur gives the clearest framing in the episode. Evals are a way to encode "what good looks like." They are not just for model research. They belong in product development, coding workflows, and internal tools. He compares them to PRDs with examples attached and scored. Once those success criteria exist, models have room to search for better solutions.

There is also a cautionary point: speed creates clutter. Ankur says product building now looks more like carving than constructing. Since it is easy to add features and code, teams need more discipline about removing confusing functionality and investing in CI so faster output does not turn into more broken output.

Practical Steps

• Pick one painful technical problem with a measurable outcome, such as query latency, migration accuracy, or cost per request.
• Build an eval or benchmark first. Define success with tests, examples, and thresholds before asking an agent to generate solutions.
• Use production or production-like data when safe. Both speakers say this gives better signals than clean synthetic cases.
• Run several agent sessions in parallel, but stay within your own review capacity. Claire says her practical limit is about four.
• Move heavy experiments to cloud or remote development environments if local machines become the bottleneck.
• Invest in CI before chasing more AI throughput. Ankur’s view is that strong CI is what earns a team the right to move faster.
• When an agent keeps failing, stop restarting the conversation endlessly. Close the session, improve the eval, and start again.
• Remove confusing product behavior instead of layering on more controls. Use complaints to simplify the product.

Notable Quotes

• "If you create the right tests and success criteria for a model, then it can be really creative." - Ankur Goyal
• "Evals are actually the modern version of a PRD." - Ankur Goyal
• "Product building and code writing now looks like carving rather than constructing." - Ankur Goyal

Decoder with Nilay Patel • 1h 13m

Overview

This episode is mostly about what Skydio thinks the drone business is becoming: less a camera you fly by hand, more a connected piece of infrastructure that can launch itself, gather information, and plug into bigger systems used by utilities, police, and the military. Adam Bry says that shift toward autonomy is why Skydio left the consumer market and built around enterprise and government buyers.

A second thread runs through the whole conversation: whether the U.S. can actually build advanced drones at scale without leaning on China. Bry argues that manufacturing in the U.S. started as a product decision for Skydio, then turned into a strategic one as policy and geopolitics changed.

Key Takeaways

Bry frames the drone industry in three stages: hobby aircraft, then flying cameras, then autonomous machines that live in docks, connect to the internet, and can be dispatched remotely. His bet is that the third stage will be much bigger than the first two because the value shifts from piloting to repeatable workflows. For a utility, that means inspecting infrastructure. For public safety, it means getting eyes on a scene before people arrive.

He pushes back on the idea that “the data matters, not the drone.” His point is that software only matters if the aircraft is reliable enough to earn trust. He describes drones as closer to self-driving cars that fly than simple gadgets, with problems in aerodynamics, heat, vibration, sensors, compute, and manufacturing all stacked together.

On company building, Bry’s view is blunt: talent matters more than org charts. He compares business to baseball and argues that one standout person can change the trajectory of a product more than structural optimization can. That same lens shapes how he thinks about AI hiring. Skydio is not chasing giant foundation models, but it does need people who can ship AI inside working products.

The manufacturing discussion is one of the strongest parts of the episode. Bry says Skydio has built in the U.S. since the beginning, partly because engineering and manufacturing need to sit close together. He also admits the limits of that claim. China, in his view, is still better at drone manufacturing overall because it has the surrounding supplier base. Skydio’s answer is to keep assembling in the U.S. while pulling major direct suppliers away from China.

On military use, Bry takes a permissive stance. He says Skydio should not be the party setting hard rules on how the military may use its products, including weaponization experiments, because elected governments and military institutions are the ones accountable for those decisions. His argument is that strict company-side limits often bind the “good guys” while bad actors ignore them.

Practical Steps

• If you run an operations-heavy business, look at drones as part of a workflow, not as a flying camera. Start with one repeatable job such as roof inspection, power-line review, site mapping, or emergency response.
• When evaluating drone vendors, ask about autonomy, dock-based deployment, remote operation, software integrations, and reliability, not just camera specs and flight time.
• If you build hardware, keep engineering and manufacturing feedback loops tight. Bry’s point is simple: products improve faster when design and production teams can solve problems side by side.
• Audit supply-chain exposure by layers. Skydio tracks “first-level dependencies,” meaning the suppliers it works with directly, then pushes further back where possible. That is a useful model for any hardware company facing geopolitical risk.
• For leaders making hard decisions, write things down. Bry says writing helps him sort through uncertainty and gives the team a concrete plan to debate.

Notable Quotes

• Adam Bry: “The next chapter is really about autonomy, where the drone lives in a docking station. It’s connected to the internet. It can be flown remotely and autonomously and becomes a piece of infrastructure itself.”
• Adam Bry: “One exceptional person anywhere in the organization can just completely change the trajectory of a product or a business.”
• Adam Bry: “I think it’s just not our place to tell them what they can and can’t do,” speaking about how the military uses Skydio’s technology.

Lenny's Podcast: Product | Career | Growth • 1h 35m

Overview

This episode is a long, practical conversation with Tony Fadell about how good products actually get built. He argues that great companies do not come from shipping whatever AI can generate fastest. They come from clear judgment, strong opinions, repeated iteration, and a deep understanding of customer pain.

A lot of the discussion circles back to the same point from different angles: version 1 products require taste, leadership, and hard decisions. AI can help with prototypes and execution, but Fadell’s view is that builders still need to think for themselves and own the structure underneath the work.

Key Takeaways

Fadell says he starts with pain, then asks whether new technology can solve that pain in a way that older products could not. That was his logic for Nest: people hated thermostats, wasted money on heating and cooling, and new AI techniques made a learning thermostat possible. He applies the same test broadly: don’t start with tech for its own sake, start with a problem people feel.

He draws a sharp line between data-driven and opinion-driven decisions. For category-defining products, there often is not enough clean data early on, so a small group has to make informed judgment calls. His example from the iPhone keyboard debate makes the point well: the team tested physical versus virtual keyboards extensively, but the data did not settle the matter. At some point, leadership had to decide what was "good enough" and move.

He also pushes back on the usual blanket rejection of micromanagement. His version of micromanaging is not controlling everything. It is identifying the few details that matter most and staying close to the decisions around them. In his telling, that includes orchestrating cross-functional tradeoffs, asking "why" a lot, and forcing clarity when complexity starts hiding bad choices.

Another theme is that product quality alone does not win. Marketing shapes what customers can see. Fadell says builders often obsess over the "what" and neglect the "why." He ties storytelling directly to product work: if you cannot explain why something matters in a way customers recognize, you probably do not understand the product well enough yet.

On AI, he is not anti-tool. He is anti-surrender. He warns that AI-generated code and AI-generated product work can produce short-term speed while creating long-term fragility. His point is simple: if nobody understands the architecture, the tradeoffs, or the customer lens, the result may function now and become a mess later.

Practical Steps

• Start product discovery with a plain question: what pain are people putting up with today?
• Then ask a second question: what new technology makes this solvable now when it was not before?
• Write the launch story early. Fadell recommends defining the core message and the few tentpole features before the product gets too far along.
• Limit the product to a small number of features customers can actually understand and buy around.
• Separate decisions that need hard data from decisions that need informed judgment. Do not hide opinion-based choices behind weak research.
• For early products, plan on multiple generations. Fadell’s rule is: make the product, fix the product, then fix the business.
• Use AI for prototyping, exploring options, and speeding up sub-tasks. Keep humans responsible for architecture, quality, and long-term maintainability.
• Rehearse the story. Fadell’s examples from Steve Jobs and Nest both show that strong messaging came from telling the story again and again, refining it each time.

Notable Quotes

• Tony Fadell: "I always start from pain."
• Tony Fadell: "The technology's in service of the customer, not we're going to jam the technology down the customer's throat."
• Tony Fadell: "Don't surrender to the machine. We can use the machines, but don't cognitively surrender."

Decoder with Nilay Patel • 54m

Overview

This episode is mostly about what it takes to run Condé Nast when search traffic is drying up, platform deals are unstable, and the old magazine model no longer carries the business. Roger Lynch argues that the company has had to stop thinking like a print publisher and start thinking like a group of brands that can make money across subscriptions, events, commerce, video, and licensing.

The sharpest part of the conversation is Lynch's view on "Google zero." He says publishers should not expect search traffic to keep supporting their business, and they should plan around direct audience relationships and brand authority instead.

Key Takeaways

Lynch says Condé Nast's turnaround started with structure, not editorial. When he arrived, the company was split by country and by internal power centers, with teams competing against each other instead of the market. His first move was to combine those pieces into one company and push people to operate with shared goals.

He frames Condé Nast's problem in 2019 as a business model issue, not an audience issue. His read was that brands like Vogue and The New Yorker were still gaining digital attention, which meant demand was there even if the old print economics were failing. He says the company has since moved from majority print revenue to majority digital revenue and from losses to profitability.

On platforms, Lynch's position is pretty plain: publishers have to be where audiences are, but they should not assume platforms owe them traffic. He treats TikTok as an example of going where users already expect the brand to be, even before a revenue model is obvious. At the same time, he draws a line at platforms using publisher content to compete directly with publishers.

That is where his argument against Google and some AI companies lands. Lynch says declining search referrals are one thing; scraping journalism to power AI products without a license is another. He says Condé Nast is willing to make deals, as it has with companies including OpenAI, Amazon, Microsoft, and Perplexity, but he views Google's tie between search indexing and AI scraping as anti-competitive.

A second big idea is that authority matters more than scale alone. Lynch does not claim only giant brands survive. He points to niche titles with loyal audiences and a clear point of view as viable, while businesses built mostly on search or social arbitrage are far more exposed when platform traffic drops.

He also makes the case that events such as the Met Gala are more than sponsorship plays. They are brand expressions that create attention far beyond a single night. Lynch says Condé Nast's video around this year's Met Gala reached 3.1 billion views, up from a little over 2 billion last year.

Practical Steps

For media operators, marketers, or anyone running a content business, the episode suggests a few clear moves:

• Stop building plans that depend on search growth. Assume referral traffic can shrink fast and model your business accordingly.
• Put more effort into direct audience channels: subscriptions, newsletters, memberships, repeat video viewers, and commerce tied to clear intent.
• Go to platforms because your audience is there, not because you expect platform loyalty.
• Separate distribution from dependency. Use TikTok, YouTube, and similar channels, but do not let them become your whole business.
• Treat brand authority as an operating asset. Build a point of view people will seek out directly.
• If you own valuable content, push for licensing terms with AI companies instead of giving away use by default.
• Run formal succession planning, especially if a big part of your company's value sits with a few star leaders.

Notable Quotes

• "I don't believe that any of these platforms owe us an obligation to send us traffic or customers or audience."
• "I also don't believe that they have the right to use our content to come and compete directly with us." - Roger Lynch
• "It really is, does your brand have authority? Does it have connection with audience that is really deeper than search or discover traffic?" - Roger Lynch

Eat Sleep Work Repeat - better workplace culture • 43m

Overview

This episode looks past the loud claims about AI taking half of all jobs and gets into what actually happens when new technology hits real workplaces. Bruce Aisley talks with Financial Times writer Sarah O'Connor about her book We Are Not Machines, and the core argument is plain: the future of work is not just about what AI can do, but about who gets to decide how it is used.

O'Connor argues that too much of the public debate treats technological change like weather or a tidal wave - something inevitable that people can only brace for. Her reporting suggests something else. Outcomes depend on power, regulation, consumer standards, workplace culture, and whether workers have any say.

Key Takeaways

One of the strongest points in the conversation is that distance distorts how "automatable" a job looks. From far away, many jobs seem easy to hand over to software. Up close, they involve judgment, timing, relationships, dexterity, and adaptation that are hard to reduce to a workflow chart.

Her example of translators makes that concrete. Machine translation can be useful, and O'Connor is careful not to dismiss it outright. But for high-quality translation, the job is not swapping words one by one. It involves tone, cultural context, social relationships, humor, and taste. What is happening in many cases is not replacement but degradation: skilled people are turned into editors of machine output, with less autonomy and less satisfaction.

She pushes back hard on the language of inevitability. When politicians or tech leaders say AI is "coming" and we must accept it, that framing strips out human choice. O'Connor's point is that technology is shaped by institutions and incentives. Employers make choices. Governments make choices. Consumers make choices. Workers, where they have enough power, make choices too.

Another thread is the danger of losing faith in human abilities. O'Connor says we are being told machines will outperform people at cognitive work, creative work, even empathy. She rejects that framing. A machine can imitate empathic language, but that is not the same as feeling or moral presence. She points to work like grave tending and palliative care to show kinds of intelligence that remain distinctly human.

The gap between workers matters. Senior software developers may find AI makes them more effective because they stay in control of the process. Other workers get boxed into low-discretion roles where they merely clean up machine output. The difference is often bargaining power, not the technology itself.

Practical Steps

For individuals, O'Connor's advice is to pay close attention to what AI actually does in your own job rather than absorbing every sweeping headline. Look for the parts of your work that depend on judgment, taste, trust, physical skill, or emotional presence. Those are the parts worth protecting and building on.

If you have any room to influence how tools are introduced at work, push for choice over compulsion. A useful standard from the Hollywood writers' fight was this: workers should be able to use AI when it improves the work, but not be forced to use it just to cut costs.

For managers and policymakers, the practical agenda is about worker power:

• strengthen workers' voice in decisions about new tech
• make it easier to leave bad jobs through better income support
• expand access to retraining and paid learning time
• set standards for quality so companies cannot quietly lower it and call it progress

The broad test is simple: ask "What problem is this solving?" and then ask who benefits, who loses control, and who absorbs the downside.

Notable Quotes

• "This is not a story of just sitting here in front of a big tsunami and waiting to find out if we sink or swim." - Sarah O'Connor

• "It's a lot less about the technology than it was about all of the other choices and institutions and balances of power." - Sarah O'Connor

• "Pay attention to what's happening in your own world rather than the kind of big headlines that keep coming at you." - Sarah O'Connor

AI and I • 52m

Overview

This episode is about what changes after the launch hype of a new AI model fades and people start using it every day. Mike describes Fable 5 less as a better chatbot and more as a system you can hand real work to, especially in software and internal tool building, while Dan pushes on the harder question of what that means for skills, engineering, and trust.

Key Takeaways

Mike says the biggest shift is not raw model quality but the need for new working habits. His old approach - breaking work into small prompts and tightly steering each step - stopped making sense once the model could hold more intent, reason across a larger context window, and keep going through setbacks. He now gives broader goals, richer context, and longer time horizons.

The strongest claim in the conversation is about delegation. Mike says he can set up a complex task at night, go to sleep, and wake up to finished work. What impressed him was not just output quality, but the model's ability to recover when something breaks: if a service goes down, it can stub a backend, document what happened, and return to finish the job later. That changes the model from assistant to teammate.

He also argues that these systems narrow the gap between "the thing in my head" and "the thing that exists in the world." For non-engineers, that may matter more than any coding benchmark. He gives an example of someone in recruiting who could finally build an internal tool herself instead of waiting on overloaded internal engineering teams.

On software engineering, Mike's view is that the job is not gone, but the shape of it has changed hard. Writing code by hand and solving low-level implementation details matters less than product judgment, system ownership, coordination, and incident response. He says the PM-engineering boundary is already getting blurrier inside Anthropic. Humans still hold intent, make tradeoffs, and stay accountable for what reaches production.

A big bottleneck now is verification. If a model can do hours of work on its own, a person still has to know whether the result is right. Mike's answer is to tighten the verification loop: screenshots on every pull request, video captures of UI behavior, regression tests for known paths, and direct questioning of the model about why it made certain decisions. The standard is not "the model wrote it." The standard is whether a human is willing to stand behind it.

Practical Steps

• Give the model intent, not just tasks. Describe the goal, constraints, and likely evolution of the project instead of asking for one isolated step.
• Use longer task horizons. For work that can run unattended, set context clearly, define success conditions, and let the model keep going without constant intervention.
• Build a verification layer around autonomous work:
  • require screenshots or screen recordings for UI changes
  • run tests against both standard flows and the exact feature being changed
  • ask the model to explain tradeoffs after it finishes
• Keep ownership clear. Even if multiple agents are doing work, assign a human DRI for each area who reviews, approves, and answers for the result.
• Turn repeatable processes into workflows. Mike says he started by asking Claude to design a workflow for a complex task, then added extra verification steps and reused smaller follow-up workflows after that.

Notable Quotes

• "I feel like a total newbie again because I feel like the way that I am prompting or even thinking about decomposing a task is really out of date now with this model." - Mike
• "It is the first time in my life where I feel like the thing that's in my head and the thing that exists in the world is now right next to each other." - Mike, quoting a recruiter on his team
• "You ultimately as a person still need to stand behind the work that you are doing, especially if you're putting it into a production system." - Mike

Platformer • 1h 8m

Overview

This episode pushes back on the soothing line that AI will mostly "change jobs, not remove them." Casey Newton talks with Brookings senior fellow Molly Kinder, who argues that the bigger risk is a long, uneven stretch of disruption she calls the "messy middle": not total job collapse, but enough concentrated damage to upend careers, politics, and public trust.

The conversation stays grounded in one question: if AI starts cutting into white-collar work first, what is the plan for the people who lose status, income, and a path forward? Kinder’s answer is blunt: right now, there really isn’t one.

Key Takeaways

Kinder’s main point is that the debate is stuck between two bad extremes. One side predicts an imminent jobs apocalypse. The other says there is little to worry about because the data does not yet show broad labor-market damage. She thinks both miss what comes next: a drawn-out period where AI takes over enough high-value tasks to hurt specific groups badly, even if most jobs still exist.

Her case for white-collar exposure is straightforward. Large language models are strongest at computer-based work: law, finance, consulting, sales, software, and clerical office roles. Jobs that require physical presence - food service, repair, care work, construction - are less exposed for now because chatbots do not mop floors, cut hair, or fix pipes. That means the first shock may land on the "laptop class," not the workers people usually assume are most vulnerable to automation.

She also points to de-skilling as a separate threat from outright job loss. Even when AI does not remove a role, it can lower the expertise needed to do it, which can push down wages and reduce career ladders. In healthcare, for example, she says workers are already imagining cases where AI guidance lets less-trained people do tasks that used to require more education.

The episode also casts doubt on easy policy answers. Retraining helps in some cases, but the evidence is mixed over the long run. Ella Marcianos cites research on trade-adjustment programs suggesting workers can see income gains years later, but those gains may fade as the market changes again. If AI keeps moving fast, people may be retrained into jobs that are later automated too.

Kinder is especially skeptical of treating universal basic income as the obvious answer. In a world where some people still need to show up and do lower-paid essential work, sending everyone checks large enough to replace lost six-figure salaries could be politically unstable and hard to sustain. She separates two issues that often get mashed together: sharing AI wealth broadly, and helping the people who get hit hardest by job disruption.

Practical Steps

• Watch the early-warning sectors. If you work in software, customer service, marketing, finance, market research, or clerical back-office roles, pay close attention to how your employer is using AI now, not just what executives say in public.
• Audit your job by task. List the parts you do at a computer, especially repeatable writing, analysis, scheduling, coding, or document work. Those are the places AI is most likely to eat away first.
• Build skills outside pure screen work. Relationship management, judgment, coordination, trust-building, and domain expertise tied to real-world settings may hold up better than work that can be done alone at a laptop.
• Push for policy before layoffs arrive. Kinder’s view is that waiting until displacement is obvious will be too late. That means pressing employers and policymakers for retention plans, transition support, and protections for early-career workers now.
• Don’t assume retraining alone will save you. Treat it as one tool, not a guarantee.

Notable Quotes

• Molly Kinder: "What we're really entering is this messy middle period."
• Molly Kinder: "A world where most jobs are intact, but there's a concentrated loss is still a world that is politically, societally, and economically explosive."
• Molly Kinder: "People are not asking for a check and they're not asking for retraining. They're asking to have some security."

Decoder with Nilay Patel • 1h 16m

Overview

Nilay Patel talks with Mustafa Suleiman about Microsoft AI's shift from relying mainly on OpenAI to building its own frontier models, the company's Build announcements, and Mustafa's view that "superintelligence" is coming sooner than many people think. The conversation also pushes on the weak spots in that story: public backlash, shaky consumer value, job fears, and the habit in AI of talking as if the future is already settled.

The episode works because Nilay keeps pressing when Mustafa makes broad claims. That leads to a clearer picture of where Microsoft is confident, where Mustafa is extrapolating, and where the industry is still making bets.

Key Takeaways

Microsoft's relationship with OpenAI has changed from simple division of labor to overlap across the whole stack. Mustafa says OpenAI expanded from research into products, enterprise, chips, hardware, and infrastructure. Microsoft responded by trying to become "self-sufficient" on models, chips, and training, while still staying in partnership with OpenAI for years.

Mustafa's case for superintelligence is basically an argument from scaling laws. He says model progress still tracks increased compute, data, and real-world interaction, and that this trend should continue for the next few years. He draws a distinction between AGI, superintelligence, and the singularity: AGI is human-level on most tasks; superintelligence exceeds humans broadly and can produce new knowledge; the singularity is a much more speculative point where systems improve themselves recursively.

One striking point is what Microsoft says it did not do. Mustafa says the new MAI Thinking One model was not built by distilling stronger outside models, even though that would have been faster. His reason is strategic: distillation may copy capability, but it does not build a lab that can pass the teacher.

Nilay pushes hard on the mismatch between enterprise enthusiasm and consumer skepticism. Mustafa argues people already get real value from chatbots, but he concedes the payoff may not yet feel big enough to justify the costs and disruption. His test is blunt: if AI does not make people healthier, happier, smarter, or more productive, people will reject it, and they should.

The most contentious stretch is around labor and consciousness. Mustafa tries to narrow earlier claims about AI replacing white-collar work by saying he meant tasks, not jobs. On AI consciousness, he is unusually direct. He argues models are not conscious, do not suffer, and that treating them as if they might have inner lives is dangerous because it confuses tools with moral subjects.

Practical Steps

• Separate hype from definitions. When AI leaders say AGI, superintelligence, or singularity, ask what they mean in plain language and what evidence they think supports the claim.
• In a company setting, track task-level gains before making job-level assumptions. Measure whether AI actually speeds up writing, summarizing, coding, support, or analysis, instead of assuming whole roles disappear.
• Watch token spend against outcomes. Higher usage does not automatically mean better results. Tie budgets to concrete outputs like faster shipping, fewer errors, or better customer response times.
• If you are evaluating vendors, ask where training data came from, whether models were distilled, and what controls exist for security and IP risk.
• For consumer AI, use a simple filter: does this save time, improve judgment, or solve a real problem you had yesterday? If not, ignore the marketing.

Notable Quotes

• "Superintelligence is coming. I think it's just around the corner." - Mustafa Suleiman
• "If it's not making me healthier and happier, smarter, more capable, more productive, then naturally people are going to be angry and resist." - Mustafa Suleiman
• "We do not want to have to contend with a superintelligence that has ideas about its own suffering." - Mustafa Suleiman

Decoder with Nilay Patel • 48m

Overview

This episode looks at SpaceX's planned IPO through a wider Musk lens: what happened to X after Elon Musk bought Twitter, and what the SpaceX filing says about power, accountability, and market rules. Neil Patel and New York Times reporter Ryan Mack argue that X has plainly weakened as a business, while Musk himself has become richer and harder to check.

They also dig into how the IPO appears set up to keep Musk firmly in control, even as public investors are pulled in through index funds and market demand. The core tension is simple: the underlying businesses have mixed fundamentals, but the offering is being sold on belief in Musk and his future promises.

Key Takeaways

X appears to be a business failure on its own terms. Mack says revenue and user growth have stalled, and Neil points to the filing as evidence that most major metrics are down. The one area showing strength is data licensing, including sales tied to AI. Yet that decline may not matter much to Musk personally, because X now functions as part of a larger group of companies rather than a stand-alone business that must justify itself.

A big theme is that Musk may have "won" even while Twitter/X lost. Mack's point is that Musk used the platform as distribution, influence, and a piece of a larger financial structure. X was folded into xAI and then connected with SpaceX, which means its weak business performance can be absorbed inside a much bigger story.

The discussion on corporate governance is the sharpest part of the episode. Mack says Musk controls about 85 percent of voting power at SpaceX through super-voting shares, which gives him broad power over board decisions, compensation, and company direction. That leaves public shareholders with limited ability to act as a real check.

The pay package described in the filing is another red flag. Mack says Musk received restricted stock tied to huge goals like a Mars colony and space-based computing, but can already vote those shares and even borrow against them with board approval. Since he controls the board, that approval is not much of a barrier. The goals look grand, but the structure still gives him power now.

On the business side, Starlink is presented as the only clearly profitable engine in SpaceX. The rest, especially AI efforts, are burning cash. Mack's read is that investors are not buying current performance so much as Musk's ability to keep selling a bigger future: space data centers, Mars manufacturing, AI services, and whatever comes next.

Practical Steps

• Read IPO filings past the headline valuation. Focus on voting rights, share classes, board control, arbitration clauses, and compensation terms.
• Separate the company from the founder. Ask whether the business works without the CEO's story carrying it.
• When you hear giant total addressable market claims, look for the math. If the numbers amount to "trust me," treat them as marketing, not analysis.
• If you invest through index funds, check what that means for ownership of companies you may not have chosen directly. Passive investing can still expose you to governance risk.
• Watch for cross-company dealmaking inside founder-led groups. Weak assets can be protected or reflated when they are merged into stronger, more exciting businesses.

Notable Quotes

• Ryan Mack: "X is simply not growing."
• Ryan Mack: "At the end of the day, most investors are betting on Elon's words."
• Ryan Mack: "The normal levers of accountability for someone like that have gone out the window."

AI and I • 33m

Overview

This conversation pushes back on the idea that AI will wipe out SaaS. The guest argues the opposite: easier software creation means there will be far more software in the world, which creates more demand for tools, platforms, and products that handle the messy parts people do not want to run themselves.

A lot of the discussion sits in the gap between "I can build this" and "I want to maintain this forever." That gap is where software companies still matter, and where agent-based workflows are starting to change design, product, and engineering work.

Key Takeaways

The main argument is that AI expands the number of people who can build software. The guest says past estimates for developers were in the tens of millions, while the next wave could bring that number to a billion or more. If that happens, the result is not less software business. It is more software, more experimentation, and more need for products that package reliability, support, and ongoing maintenance.

That point came through in the email-agent example. The guest built an early personal tool to process school and PTO emails, mainly to avoid missing things like spirit days for their kids. The first version was a rough Python script, and it worked just well enough to prove the idea. But keeping it running exposed the part people often ignore in "just vibe-code it" talk: software is not only code. It is operations, upkeep, fixes, upgrades, and all the annoying edge cases.

The host backed that up by saying tools built this way can reach production, but bug fixing and maintenance stay hard. That is a good check on the "SaaS apocalypse" story. AI can lower the cost of making version one. It does not remove the cost of owning version fifty.

Another strong theme was that agents get better when they are proactive and personalized. A daily summary delivered at the right time was more useful than a tool waiting for a prompt. But summarization is still messy. The guest described a common problem: agents miss what matters, then overcorrect after feedback and become too literal.

On Figma, the guest framed the future as a two-way loop between code and design. Agents can pull an existing page into Figma, let people edit it in a visual tool, then send the design context back to code and open a PR. The hard part is context. In design work, that means knowing the design system, patterns, and team preferences. Without that, generated output may look acceptable but still be unusable.

Practical Steps

• Build small personal agents around a clear pain point first. The email example worked because the problem was concrete: too many school emails, too little attention.
• Do not judge an agent only by whether it can produce a first draft. Test what happens when it breaks, needs updates, or has to run every day.
• Use proactive delivery where possible. A scheduled daily summary can be more useful than another dashboard you have to remember to open.
• Add memory and context early. For personal workflows, that may be preferences and past actions. For team workflows, it may be org charts, project boards, Slack channels, and design systems.
• Keep humans in the approval loop for anything customer-facing or high-stakes. The guest still reviews replies before they go out.
• If you work across design and engineering, look for workflows where agents move existing work between tools instead of starting from scratch every time.

Notable Quotes

• "Software companies build more than just code."
• "The thing that really differentiates an OK agent to one that people really love is the personalization aspect."
• "You kind of realize every problem becomes a context problem."

How I AI • 20m

Overview

Claire Ho spends the episode stress-testing Google Flow and Gemini's video tools by trying to build an AI avatar of herself and turn it into a one-minute hype video for her podcast. The point is less "watch this polished final product" and more "can one person, with little video background, get from selfie scan to usable promo video in about 15 minutes?"

The experiment shows both sides of the current tools: they can take on storyboard ideas, visual direction, and scene generation, but they still misfire, ignore character references, and require a fair amount of trial and error.

Key Takeaways

The clearest idea in the episode is that these newer image and video models act less like a single-purpose generator and more like a rough creative partner. Claire uses Flow not just to render clips, but to help shape the concept itself: scene ideas, visual style, camera framing, and the basic sequence of a promo video. For someone who says she is creative but "not video creative," that matters more than the avatar gimmick.

A second takeaway is that multimodal AI can open up work people would not have attempted on their own. Claire says she would not have known how to solo produce a hype video, block scenes, or frame the shots. The tool lowers the barrier enough that she can at least try, which changes who gets to make this kind of content.

The episode also shows how messy the process still is. The avatar creation had failed in an earlier test. The storyboard could not reliably use her avatar as a character reference. She accidentally generated images instead of video on one pass. Even when a clip worked, the output drifted, adding details like blue nail polish. The result is promising, but not dependable.

There is also an interesting point about source material. Claire notices the model picked up posters and books from the background of her avatar photos and carried them into generated scenes. That suggests these systems can pull more contextual detail from capture inputs than users may expect, which can be helpful for consistency but also means your setup choices matter.

Practical Steps

If you want to try this kind of workflow yourself, Claire's process gives a usable template:

• Start with a narrow goal. She did not ask for "a great brand video." She asked for a hype video for a specific podcast.
• Build a visual brief in plain language. She described the setting as a dark home office with dark green walls, AI books, posters, and a hacker vibe.
• Let the tool propose a storyboard first. Getting scene ideas before generating clips saves time and gives you something concrete to edit.
• Generate scene by scene instead of trying to make the whole video in one shot. Claire picks individual frames and turns them into clips.
• Check your mode settings every time. Her image/video mix-up is a simple mistake that can waste a generation cycle.
• Expect to rerun prompts and swap references. If the avatar doesn't carry through, try re-tagging the character or adjusting the prompt.
• Use the outputs as draft material, then stitch together the best takes. The value comes from assembling workable pieces, not from expecting one clean generation.

Notable Quotes

• "I'm going to be honest, I'm not a hundred percent sure this is going to work." - Claire Ho
• "I would have never been able to solo produce a hype video for my podcast." - Claire Ho
• "Now I have this AI producer here that can help me with this effort." - Claire Ho

Big Technology Podcast • 1h 11m

Overview

This episode is a broad check-in on where the AI race stands, with Google, OpenAI, Anthropic, Apple, and Meta all under the microscope. Alex Kantrowitz and MG Siegler spend most of the conversation on one question: if AI shifts people away from the open web and toward agent-driven "super apps," who wins that transition and who gets left behind.

They argue that Google looks less secure than it did a few months ago, Apple is heading into a tense WWDC with a lot to prove, and Meta still looks like a company searching for a coherent next act. The show ends with breaking news that Anthropic has confidentially filed for an IPO, which raises the pressure on OpenAI.

Key Takeaways

Google's I/O felt thin because the main thing people expected, Gemini 3.5 Pro, was not ready. MG says Google led with Gemini 3.5 Flash instead, rolled it through many products, and then had to explain that the stronger model would come later. That left Google looking out of sync with how AI companies now ship: not on annual conference schedules, but whenever the model is ready.

The bigger issue, in their view, is not just model quality. It's product direction. OpenAI and Anthropic are moving toward tools like Codex and Claude Code that start in coding but point toward something larger: AI systems that can use your browser, your computer, and your accounts to complete tasks. Alex argues that "super app" is the right frame here. These products are moving toward becoming the interface for how people use the internet.

That creates a real threat to Google. If users start asking ChatGPT or Claude to search Gmail, compare hotels, book services, or act across websites, Google's role as the main front door to the web weakens. MG points out that Google still thinks in browser and product-silo terms, while the new winners may be the companies that unify chat, agents, coding, and browser control into one experience.

Apple's foldable iPhone comes up next. MG's read is that the form factor may be shorter and wider than people expect, possibly making it better for typing when folded. He thinks Apple has to do more than ship a folding screen. It needs to give the device a reason to exist beyond novelty.

On WWDC, both expect a lot of attention on Siri, but not necessarily a dramatic breakthrough. They also raise the possibility that Apple could use the event to signal a broader transition, whether that's management succession or changes to App Store economics.

Meta comes off as the weakest story in the group. MG calls out the company's messy subscription naming, weak morale, and unclear strategy outside ads. The sense is that Meta is spending heavily, trying many things, and still struggling to show a clean story about where it is headed.

The late-breaking Anthropic IPO filing matters because it sharpens the comparison with OpenAI. MG says public investors are likely to compare the two directly, and Anthropic's recent momentum in coding and enterprise makes that uncomfortable for OpenAI.

Practical Steps

• Watch AI product moves through the lens of interface control, not just model benchmarks. Ask: does this tool help users do work directly, or is it still just a chatbot?
• If you work in product or strategy, test how these agents fit into real workflows now. Connect one to Gmail, have it summarize threads, pull travel details, or draft follow-ups. That shows where current products are already better than traditional interfaces.
• If you're evaluating big tech companies, pay attention to internal structure. The hosts' point on Google is useful: companies with many strong product silos may struggle when the winning product needs those silos to collapse into one.
• For Apple watchers, WWDC should be judged less by flashy demos and more by whether Siri becomes dependable enough to trust with actual tasks.
• For founders, the conversation suggests a simple test: build for the layer where users act, not the layer they used to visit.

Notable Quotes

• "Google looks sort of silly for not having their model ready to go." - MG Siegler
• "The agents and the chatbots are going to merge." - Alex Kantrowitz
• "Google should have the single best place to do any sort of agentic email workflow... and they don't own that right now." - MG Siegler

Decoder with Nilay Patel • 1h 5m

Overview

Nilay Patel talks with Harvey Mason Jr., CEO of the Recording Academy, about how fast AI has moved from a novelty to a standard part of music production. Mason says that in the pop and R&B sessions he sees, AI is now "omnipresent," showing up in writing, arranging, demo-making, and vocal production.

The conversation also gets into how the Grammys are handling AI-assisted work, why the Academy still draws a line around human creativity, and what the move from CBS to Disney means for the future of the awards and music storytelling.

Key Takeaways

Mason’s main point is that AI has gotten good, much faster than he expected. Eighteen months ago, he says, AI-generated music was easier to spot. Now people play him tracks and only afterward tell him they were AI-made, and he finds himself surprised by the quality. That shift has made the policy problem harder, not easier.

He describes AI as already embedded in studio work. Writers use it for chord progressions, drum loops, lyric ideas, rhyme patterns, background vocals, and artist demos. Some use it lightly, more like a songwriting assistant. Others use it to generate much larger chunks of a track. Mason sounds uneasy about that spread, especially because it lowers the barrier to making music in a way that can sidestep years of work by trained musicians and writers.

The Grammys’ current standard is basically this: there has to be more than a minimal amount of human creative input for a work to be eligible. Mason is clear that this is not a clean or technical rule. The Academy relies on screening committees, documentation, and judgment calls. He admits the system is imperfect, but says the goal is to keep honoring human excellence while accepting that AI tools are already in the workflow.

A useful distinction came up around which part of a song is being judged. If AI performs the vocals, that can block a submission from performance categories. If a human performs an AI-written song, that human performance may still be eligible. The Academy is separating songwriting, performance, and production rather than treating AI use as one yes-or-no question.

Mason also argues that the industry needs legal guardrails, especially around voice and likeness. He points to laws like Tennessee’s ELVIS Act as a start, but says artists need broader protections over how their identity and work are copied, credited, and paid for.

On the business side, the move to Disney gives the Recording Academy more room to make documentaries, scripted projects, and short-form content through Grammy Studios. Mason says the Grammys are trying to meet younger audiences where they already are, including YouTube, TikTok, and other social platforms.

Practical Steps

For musicians, producers, and songwriters, a few practical ideas stand out:

• Use AI as a draft partner, not a replacement. Mason’s most positive example was generating stems or grooves, then having live musicians rebuild and expand them.
• Keep records of your process. If awards eligibility, credits, or ownership become an issue, screenshots, session files, drafts, and notes may matter.
• Separate the roles in your own workflow. Ask: Did AI help with writing, arrangement, vocals, or just ideation? That makes rights and submissions easier to sort out.
• Protect voice and likeness early. Artists should pay attention to contracts, platform policies, and state laws that cover imitation and unauthorized use.
• Build for discovery beyond traditional channels. If attention is scarce and music breaks on TikTok and other platforms, release strategy matters almost as much as the song itself.

Notable Quotes

• "AI is generally always there." - Harvey Mason Jr.
• "We want to make sure we're honoring human creativity." - Harvey Mason Jr.
• "There has to be more than de minimis amount of human creativity involved in the process." - Harvey Mason Jr.

Lenny's Podcast: Product | Career | Growth • 1h 19m

Overview

This episode centers on Benedict Evans's view that AI is a major platform shift on the scale of the internet or smartphones, but not a magical break from economic history. His argument is that AI will change a lot, though the shape of that change is still unclear, and many of today's loudest claims about instant job collapse or permanent dominance by model labs are way too confident.

Key Takeaways

Evans keeps coming back to one point: we are early. His comparison is the internet in 1997 - exciting, uneven, full of promise, and still missing most of the products and business models that will later look obvious. A small group of people use AI heavily, but outside tech, adoption is far less complete than the online discourse suggests.

On jobs, he pushes back hard on the "jobpocalypse" story. His view is that new technology has always removed some work while creating new kinds of work that were hard to name in advance. He argues that people are good at spotting the jobs that might shrink and bad at seeing the jobs that will appear after workflows, companies, and markets adjust. He also points out that even the leading AI companies are still hiring heavily, which cuts against the idea that useful AI immediately means fewer humans.

A second theme is the difference between a task and a job. AI may automate pieces of work - making slides, writing code, retrieving information - without replacing the broader role around judgment, coordination, politics, customer insight, and decision-making. That helps explain why consulting and professional services may grow during AI adoption rather than disappear. Companies need outside help to figure out where AI fits, how to redesign workflows, and how to deploy it safely.

He is also skeptical that foundation model companies will keep all the value. His case is simple: if models remain similar enough and competition stays strong, margins get pressured and value moves up the stack to products with better distribution, user experience, and specific use cases. In that world, AI models look less like Windows and more like cloud infrastructure.

Practical Steps

If you're worried about your career, Evans's advice is blunt:

• Do not reject AI on principle and call that a strategy.
• Use the tools enough to understand where they help, where they fail, and what good judgment around them looks like.
• In your field, separate the repeatable task from the actual job. Ask what part of your work is button-clicking and what part depends on trust, judgment, or context.
• Learn how AI changes workflows in your industry, not just what the demos show. A law firm, retailer, hospital, and software company will adopt this differently.
• Build credibility as someone who can work with AI without being fooled by it, especially by hallucinations and weak output.

For companies, the implied playbook is to run real workflow audits, test AI in narrow domains first, and expect change to happen over years, not weeks.

Notable Quotes

• "AI is as big a deal as the internet or mobile, and only as big a deal as the internet or mobile." - Benedict Evans
• "You can always see the job that's going to go away. And you don't know the new job because it doesn't exist yet." - Benedict Evans
• "Don't stick your head in the sand and say, 'I hate all of this stuff.' ... What helps is you diving into this and coming out, understanding what you can do with it." - Benedict Evans

Galaxy Brain • 42m

The Story

This episode looks at data centers as the physical face of the AI boom, and asks why these buildings have turned into such a lightning rod so quickly. Charlie Warzel opens with the scale of the fight: tech companies are pouring huge sums into new computing infrastructure, while public resistance is spreading fast. He points to polling that, he says, found broad opposition to AI data centers in local communities, along with a wave of canceled projects. The backdrop is simple enough: AI companies want more power, more land, and more speed. The politics around that are anything but simple.

Jale Holzman says the backlash is real, local, and unusually bipartisan. On the ground, the pattern often starts with a vague real estate proposal or shell company, followed by the slow realization that a tech giant may be behind it. By the time residents understand what is being built, they often feel shut out. That sense of being deceived or bypassed matters as much as any technical debate about water or power. It turns a construction project into a grievance story, and grievance stories travel fast.

From there, the conversation widens. Holzman connects anti-data-center sentiment to older fights over mining, wind, solar, and other industrial projects. What makes this different is that several political strains that usually operate apart are landing in the same place. On the left, the concern centers on environmental damage, weak regulation, and distrust of AI itself. On the right, it turns into a populist attack on tech elites, secrecy, surveillance, and rising utility bills. She keeps coming back to the same point: this is not one movement with one ideology. It is many local conflicts stacked on top of each other.

As they get into substance, the episode pushes past the usual talking points. Water use gets attention, but Holzman says noise and energy demand often hit closer to home. She describes places where residents can feel the vibration of a facility and smell something off in the air. At the same time, she does not present data centers as offering nothing. Some towns, she says, may get major tax revenue, enough to shape local budgets in a serious way. That benefit comes with a catch. A place that grows dependent on data-center money may end up too tied to the industry to regulate it well.

By the end, the episode shifts from zoning fights to electoral politics. Both host and guest think this issue is heading straight into bigger campaigns, with odd coalitions and unclear party lines. Holzman even suggests it is possible both parties could end up running against data centers in different ways. The conversation closes without a neat answer, but with a sharper sense of why these buildings now carry so much public anger: they are where abstract fears about AI become visible, noisy, and local.

Main Themes

The main theme is that data centers have become a stand-in for a much larger fight about AI, power, and who gets heard. People are not only reacting to server farms. They are reacting to secrecy, to elite decision-making, to the feeling that another massive economic shift is arriving and regular people will absorb the costs while someone else collects the upside.

A second thread is that the usual partisan map does not hold. The episode keeps circling this strange overlap between environmentalist skepticism on the left and anti-elite populism on the right. That overlap does not mean agreement on facts or goals, but it does create a shared target.

The last theme is that the country still has not decided what responsible AI infrastructure would look like. Holzman is blunt that the industry has done a poor job building trust, while opponents have not settled on a realistic end point beyond stopping projects. That leaves a messy middle, where regulation, energy policy, local democracy, and national politics are all colliding at once.

Big Technology Podcast • 59m

Overview

This episode looks at whether the AI boom is running ahead of reality. Alex Kantrowitz and Ronjon Roy focus on rising token costs, weak links between AI spending and shipped products, Anthropic's new financing round, and Robinhood's plan to let chatbots trade on users' behalf.

The core debate is simple: are companies seeing real returns from AI, or are they burning money in a rush to experiment, impress management, and keep up with the market? The hosts agree the technology is useful. They disagree more on whether today's waste is a normal early phase or a warning sign.

Key Takeaways

The sharpest point in the conversation is the gap between AI spending and business output. Alex points to data from Entelligence AI saying only 18% of spending on advanced AI coding tools is turning into shipped products that reach users. If that number is anywhere close to right, the problem is less "token maxing" and more that most usage still isn't tied to results.

Ronjon argues some of this waste is expected. In his view, companies have had only a few months with coding tools that got meaningfully better around late 2025, so high burn with weak returns is not shocking. He says a normal cycle would involve experimenting, finding what works, cutting what doesn't, and then tightening usage. The problem is that the market has turned that messy phase into a giant financial story before the work is mature.

They also spend time on how AI revenue may be getting flattered by spending loops. The discussion points to big cloud companies investing in AI labs, then booking revenue when those labs buy compute back from them. Ronjon's concern is not that the accounting is fake in a legal sense, but that it can make demand look cleaner and steadier than it is. If enterprise buyers pull back, the effects could hit multiple layers at once.

Anthropic's latest round is treated as both a real milestone and a market signal. Alex sees it as proof that Anthropic has become OpenAI's strongest rival, largely on the back of coding products. Ronjon sees the valuation as part business achievement, part effort to set expectations ahead of a public listing.

The Robinhood story lands somewhere between funny and plausible. The idea of letting an AI agent trade a dedicated account sounds reckless in a retail setting, but both hosts admit that software may eventually handle routine investing choices better than many humans do.

Practical Steps

For companies using AI tools, the advice is pretty concrete:

• Track token spending at the team and workflow level, not just in aggregate cloud bills.
• Tie AI use to shipped output. If a team is consuming heavily and not releasing anything, that needs attention fast.
• Start with one process where the gain is easy to measure, then expand from there.
• Cut waste in the workflow itself. Ronjon gives examples like changing how context is passed to models and breaking data into smaller structured chunks to lower token use.
• Don't treat a short burst of experimentation as proof of long-term value or failure. Review what happened, then decide where to invest more.

For individual users, the Robinhood and Gmail examples point to a broader rule: be careful what permissions you hand over. These tools are getting more useful, but each connection gives them more control over money, messages, and decisions.

Notable Quotes

"AI has got to not waste 82% of the tokens in order for this boom to continue." - Alex Kantrowitz

"If everyone just approached this in a nice, responsible way and just built and just learned... we would be okay." - Ronjon Roy

"I think we're going to see a pullback and we are going to recognize... if things aren't being done strategically... obviously you're not going to see any kind of ROI." - Ronjon Roy

How I AI • 13m

Overview

Claire Vo gives an early read on Anthropic's Opus 4.8 after a few hours of testing in coding and business workflows. Her take is pretty clear: the model looks strong on paper and can do impressive first-pass work, but it loses reliability at the edges, especially when follow-up fixes, existing codebases, or grounded strategy work matter.

Key Takeaways

The headline from her tests is that Opus 4.8 seems best at the first 80 to 90 percent of a task. In Claude Code, she says it handled a one-shot feature build well: it took a spec, made a plan, coded autonomously for about 20 minutes, and produced something that worked on a preview branch. For greenfield feature work, that is a good result.

The trouble started once she tried to refine and extend the output. She says the model repeatedly stumbled on the "last 10%" and introduced bugs during iteration. More concerning, she saw outright hallucinations when the model was bug hunting, which stood out because she says she had not seen that kind of made-up reasoning in a long time. Her read is that the model was acting on hypotheses rather than checking against the actual code or data.

That pattern showed up again in existing codebases. When she asked Opus 4.8 to help rebase branches after a large underlying PR changed the code state, it needed repeated correction cycles and kept creating edge-case issues. Her point is less that the model cannot code and more that it has trouble figuring out where, exactly, to intervene in a messy, real codebase.

She also expected more initiative from a model positioned as a top coding agent. In a playful test, she asked it to build something her nine-year-old would find exciting. The prompt it proposed sounded ambitious, but the shipped result was more ordinary than she expected. Even after pushing it toward something "more fun" and 3D, she felt the model did competent work without showing much imagination or stretch.

On business tasks, her comparison between Opus 4.7 and 4.8 was even less flattering for the newer model. Using the same context, she asked both versions to review how she had spent the last three months and suggest where her focus should shift to grow the business. She says 4.7 stayed grounded in numbers and context, while 4.8 had a harder time finding the right data, overemphasized small signals, and produced strategy that felt vague. In a follow-up roadmap prompt, she says 4.8 even implied research it had not actually done, then admitted it had not searched the sources she asked about.

Practical Steps

• Use Opus 4.8 for first-pass builds, prototypes, and new feature surfaces where speed matters more than polish.
• Treat follow-up debugging as a separate phase. Verify every claimed root cause against logs, code, or tests before accepting a fix.
• Be careful with existing codebases. If you ask the model to rebase, refactor, or patch around prior work, expect to review branch state and edge cases manually.
• Ask the model to cite what it actually inspected. A direct prompt like "List the files, queries, and sources you used before answering" may expose weak grounding early.
• Compare outputs across model versions on strategy work. Claire's test suggests the older model may be better when the job depends on numbers, context, and restraint rather than broad synthesis.
• If you want ambitious output, state the bar explicitly and review whether the result matches it. The model may default to "good enough" unless pushed hard.

Notable Quotes

• Claire Vo: "It does really, really well until it doesn't do well."
• Claire Vo: "In real code bases, the edges destroy it."
• Claire Vo: "It 100% made up things based on a hypothesis, not data."

Decoder with Nilay Patel • 1h 9m

Overview

This episode is about who gets to control the software stack inside modern cars, and what happens when a smaller EV company ends up shaping that stack for one of the world's biggest automakers. Nilay Patel talks with Rivian Chief Software Officer Wasim Bensayid about Rivian's joint venture with Volkswagen, how the companies split responsibilities, and why Rivian thinks owning the full software platform matters more than supporting systems like CarPlay.

The conversation also gets into Rivian Assistant, the company's new in-car AI system. Bensayid argues that voice is finally becoming useful because large language models can interact with the car in plain language, but he also admits there are clear limits, bugs, and safety boundaries.

Key Takeaways

Rivian's pitch is simple: the old car industry built vehicles as collections of parts from many suppliers, and that made software slow, fragmented, and hard to improve. Bensayid says Rivian's approach replaces that with fewer, more powerful computers and a common operating system that can control far more of the vehicle directly. The example he gives is basic but telling: even a short sequence like walking up to a car, unlocking it, and loading a user profile can require coordination across many suppliers in a traditional setup.

The Volkswagen joint venture is meant to spread that approach at scale. Bensayid says RVTech handles the underlying electrical architecture and operating system, while brands like Audi, Lamborghini, and Scout can still shape how their cars look and behave on top of it. His shorthand is that the shared platform does 80 to 90 percent of the hard work, with brand-specific "hooks" on top.

A big theme is culture. Bensayid keeps coming back to the idea that software talent and software process matter as much as the code itself. He says Volkswagen leadership explicitly wanted Rivian's way of working, not just its IP, and that RVTech was built to keep Rivian's pace and decision-making style even as it grows to about 1,500 employees.

On AI, Rivian is betting that the car assistant should be built into the operating system, not pasted on top as a chatbot. That matters because the assistant can reach into vehicle controls and, in theory, become the main way people interact with the car. But Rivian is drawing hard lines around regulated and safety-related functions, which is why some requests work and others don't.

The clearest strategic stance comes on CarPlay and Android Auto. Bensayid says demand for CarPlay among Rivian customers has fallen in company surveys as Rivian has shipped more native features, and he believes AI-driven in-car experiences will make the whole projection debate less relevant over time. Nilay pushes back with edge cases, and Bensayid's answer is that future assistants may talk to other assistants or phones instead of mirroring an app interface onto the dashboard.

Practical Steps

If you're building software-heavy products, a few ideas from this conversation stand out:

• Decide what layer you need to own. Rivian wants direct control of the operating system and orchestration layer because that's where future AI behavior, safety rules, and user experience all connect.
• Build common infrastructure first, then leave room for customization. The RVTech model is a shared core with brand-specific expression on top.
• Treat culture like a product decision. Bensayid frames speed, quick decisions, and iteration as assets that need protecting, especially in partnerships.
• Put safety and permission boundaries in place early for AI features. Rivian is willing to block commands even when they're technically possible if reliability or regulation is still unclear.
• Test AI systems against real-world edge cases. Nilay's questions about the rear seat sensor and the rear wiper show where product gaps appear fast once users start treating the assistant like a real operator.

Notable Quotes

• "Our approach, our philosophy for the Rivian Assistant is not just put a chatbot and then slap it on top of the UI." - Wasim Bensayid
• "The only reason that drivers and consumers so far did not interact with the car through voice is that, like, to put it really bluntly, the technology has been broken." - Wasim Bensayid
• "Cars are moving from, as you said, the buzzy word of software defined to AI defined." - Wasim Bensayid

The Aboard Podcast • 48m

The Story

This episode starts with a joke that lands because it is barely a joke: the guest has built something "incredibly exciting and incredibly boring," which turns out to be custom accounting software. Paul Ford and Rich Ciotti bring on Craig Mod, who lives in Japan and has the kind of work life that breaks ordinary bookkeeping tools. He is an American citizen, pays taxes in Japan, still has to file in the US, earns money through memberships and books, and runs a one-person creative business spread across countries, currencies, and institutions. That setup alone explains why off-the-shelf software starts to feel less like help and more like a trap.

Craig is a good guest for this because he is not a tourist in tech. He has been programming since childhood, studied computer science and fine arts, and has spent years moving between software, publishing, design, and art. His writing life grew out of that mix. He built his own membership program instead of using someone else's platform, then used that support to fund long solo walks across Japan. Those walks become nightly dispatches, photographs, and eventually books. It's a striking life, but the business side of it is a mess in the way many independent careers are a mess: several revenue streams, paperwork everywhere, and a lot of dread when tax season arrives.

That dread is what pushed him to build. The software he describes is less a reinvention of QuickBooks than a personal command center. It tracks income, expenses, expected taxes, and medical receipts, and it remembers the forms and patterns from prior years. The point is not novelty. The point is relief. He wanted a system that fit his actual life instead of forcing his life into someone else's categories.

From there the conversation widens. Rich and Paul use Craig's project as a way to talk about AI as software, not magic. Rich keeps bringing the discussion back to a grounded point: if you understand how software gets stood up, you can do a lot with these tools. Craig's accounting app is one example of what happens when a person with domain knowledge and technical fluency finally gets tools that let him make exactly the thing he needs.

Then the tone shifts. Craig raises a darker question about abundance, meaning, and what happens if machines take over more of the labor that once structured human life. Rich pushes back. He thinks that ten years from now, much of this will still look recognizable, with people using AI in ordinary ways inside ordinary organizations. He does not see AGI swallowing everything so much as culture slowly absorbing the tools. The disagreement never turns into a fight. It feels more like three people circling the same uncertainty from different angles.

Main Themes

The clearest theme is that AI becomes interesting when it leaves the demo stage and enters some annoying, specific corner of real life. This episode is about taxes, receipts, and filing obligations, but that is what makes it persuasive. Craig did not build software to prove a theory. He built it because his life had too many exceptions for standard products to handle cleanly.

A second theme is that the people getting the most out of this moment are the ones who already understand how software is put together. All three speakers keep returning to that gap. Craig can build his own tool because he knows the stack, the architecture, and the logic behind it. Rich and Paul are blunt that this is still out of reach for most people, not because they lack intelligence, but because software knowledge has usually been taught through frameworks and jobs rather than through a plain-language map of how systems fit together.

The last thread is about limits, both human and technical. Craig sees AI opening extraordinary creative and practical power while also stirring up old fears about value, work, and purpose. Rich answers with a more grounded faith in human habits and human mess. Between them, the episode makes a useful point: the future may arrive through very strange tools, but it will still run into ordinary people, old institutions, and the same unresolved questions about what matters.

HBR On Leadership • 29m

Overview

This episode looks at how Shake Shack pushed into kiosks, mobile ordering, and AI without giving up the hospitality that made the brand popular in the first place. The discussion centers on a basic tension: how do you add speed, data, and scale in a labor-heavy business while keeping the experience human?

Stephanie So, Shake Shack's chief growth officer, and HBS professor Christopher Stanton use the company's shift during and after COVID to show how digital tools can change ordering, staffing, and even menu decisions. A lot of the conversation comes back to one idea: digital works best when it removes friction, not when it makes the brand feel colder.

Key Takeaways

Shake Shack did not treat digital as a pure tech project. The company saw kiosks and ordering tools as part of the guest experience, which meant design choices mattered beyond efficiency. So says the team studied competitors closely, even sending a designer into restaurants with a GoPro to watch the experience from a customer's point of view. One lesson stuck: if a kiosk is "as big as a human," it can feel like a replacement for a person rather than a tool.

The episode makes a strong case for being a fast follower. So calls it the "second mouse strategy" - let someone else take the first hit, learn from their mistakes, then move quickly with a better version. Stanton argues this made sense for Shake Shack because customers come for the food and brand, not because the company has the newest ordering hardware. That gave Shake Shack room to wait, learn, and then roll out kiosks quickly across its stores.

The data coming from digital ordering changed how Shake Shack thought about menu choices and upselling. So says the company found that when customers were asked to actively choose between a single, double, or triple burger, more people picked doubles than when a default option was preselected. The same pattern showed up with add-ons like avocado and bacon. The takeaway is simple: customers often upgrade on their own if the interface asks them clearly, without pushy prompts.

There is also a labor angle. Stanton points out that automation can cut both ways. It can remove repetitive work and free employees to focus on hospitality, or it can turn staff into kiosk troubleshooters and hurt morale. The quality of the employee experience shapes the customer experience, so digital tools have to be judged on both fronts.

Practical Steps

• Study customer behavior in the real setting, not just in dashboards. Watch how people enter, order, hesitate, and react to the physical setup.
• Design self-service tools so they do not dominate the room. Keep them useful but visually restrained.
• Avoid default choices when you want better customer intent data. Ask people to make an active selection and track what changes.
• Test whether digital prompts can replace awkward verbal upselling. Customers may spend more when they feel in control.
• Measure digital changes against both guest satisfaction and employee workload. If staff spend their shift fixing machines, the system needs work.
• If your product is not a tech product, consider waiting for others to test early versions of new tools. Then move fast once the format is proven.
• Build one connected view of the customer across app, web, and in-store ordering so offers, rewards, and personalization carry across channels.

Notable Quotes

• Stephanie So: "If it's as big as a human, then it looks like it's trying to replace a human."
• Stephanie So: "The first mouse likely won't get the cheese... but if you're the second mouse, actually you can get the cheese out of there without any risk to your life."
• Christopher Stanton: "There is a risk in being second in some industries... but in this case, there's probably not a ton of risk because it's not a tech play that the customer is coming for."

The Pragmatic Engineer • 1h 20m

Overview

This episode is a grounded look at what AI coding tools actually change inside engineering teams, using OpenCode's rise as the backdrop. Dax Raad argues that AI can help teams ship more code, but that does not mean they are building better products or moving faster in ways that matter.

He also talks through OpenCode's growth from a tiny team to millions of active users, why open source was the right wedge, why inference can be a very profitable business, and why even fast-growing AI companies still run into plain old constraints like GPU supply.

Key Takeaways

Dax's main point is that coding was never the only bottleneck. For early-stage teams, the hard part is deciding what to build. After product-market fit, the hard part becomes choosing among too many possible directions without turning the product into a pile of disconnected features. AI does not solve either problem.

A big theme in the conversation is that AI lowers the pain of bad decisions. Before, shipping a hack felt expensive, so engineers hesitated. Now an agent can produce the workaround quickly, which makes teams more likely to accept weak design choices and postpone the real fix. The codebase still pays for it later. You just feel less of the pain upfront.

Dax says this showed up inside OpenCode itself. He told his team they were shipping too many features, taking on too many hacks, and not getting real speed in return. In his view, the team felt fast without clearly being faster than competitors. That gap between perceived productivity and actual outcomes is one of the sharper points in the episode.

On growth, OpenCode won by taking the open-source position in AI coding tools while the market was still open. Dax's telling of the story matters here: they did not try to chase every idea. They picked a territory that fit their background and bet that developers would want an open option that could work across models.

The business side is also blunt. Dax says inference can have very high margins, at least at current pricing, especially for companies with scale. At the same time, demand for compute is so high that GPU access is still a real constraint. The strange thing about AI right now is that some parts of the market look wildly profitable while basic capacity is still tight.

Practical Steps

• Audit your roadmap for features that were easy to ship but hard to justify. Ask which ones added coherence and which ones added clutter.
• Treat AI-generated code as a judgment amplifier, not a judgment replacement. Review whether a change should exist before reviewing how it was implemented.
• Set a cleanup budget every sprint. Use agents to remove dead patterns, apply new conventions, and pay down tech debt across the codebase.
• Track outcomes, not just output. Compare shipped work against user impact, product quality, and team speed a month later.
• If you're leading a team, stay close to the code and product experience. Dak's point is that feedback loops matter; leaders who never feel the pain make worse calls.
• For companies adopting AI tools at scale, plan for controls early: provider setup, permissions, budget limits, and rate limits. The admin layer becomes necessary faster than most teams expect.
• Be wary of AI productivity claims that rely on vibe, screenshots, or theory. Look for actual team behavior and actual product results.

Notable Quotes

• "Just because we can ship 10 times more doesn't mean we have 10 times as many good ideas to ship out there." - Dax Raad
• "It feels like we're going fast, but then I look back and I'm like, I don't know if we actually are going that fast." - Dax Raad
• "You still have to be very conservative with what you put out there. The moment you ship something, you're supporting it forever." - Dax Raad

AI and I • 41m

Overview

This episode is a debate around Dan's essay "After Automation" and the gap between AI panic and how work actually changes inside a company that uses AI heavily every day. Dan and Brandon argue that more automation does not automatically mean less human work; in many cases, it creates more demand for judgment, direction, and cleanup.

They frame Every as an early signal: the team says it has grown from a handful of people to about 30 while becoming more "agent native," which pushes against the claim that white-collar work is simply disappearing. The core question is what humans still do when models can produce decent work on command.

Key Takeaways

Dan's main argument is that AI makes "yesterday's expert competence" cheap. Models can produce code, writing, designs, and analysis that look impressive at first pass, so non-experts can now do work that used to sit behind a specialist gate. That shift feels threatening, but the output is often only partly right. It gets you close, then hands the problem back to a person.

That creates a paradox: when lots of people can generate acceptable first drafts, the volume of almost-good work explodes. The bottleneck moves upstream and downstream. Humans still need to decide what matters, define the task, review the output, and turn rough material into something that actually works in context. Experts do less of the old production work and more of the finishing, steering, and system design.

A second point is that "autonomous" and "having agency" are not the same thing. Dan says current agents can act on behalf of a user and may get much better at carrying out long tasks, but they still do not possess their own aims in the way a human does. His view is that the industry is pushing models toward compliance, not independent will, and that matters when people imagine runaway replacement.

They also push back on dramatic layoff stories. The discussion mentions companies that cut staff in the name of AI and then, in Dan's account of customer service examples he reviewed, sometimes have to bring people back because the implementation fails or customers refuse to deal with bots. Adoption is shaped by technical limits and human preference, not just by what is possible in a demo.

Practical Steps

If you want to stay useful as AI spreads, the advice here is simple:

• Keep up with new models and test them on your real work, not toy prompts.
• Use AI for first drafts, research passes, code scaffolding, and repetitive tasks, then review the result hard.
• Get better at framing problems. Clear instructions and good taste become more valuable when production gets cheap.
• Build review systems: checklists, repo rules, editing standards, and approval steps that catch "close but wrong" output before it ships.
• Pay attention to where people still want a human. In support, sales, and other service roles, customer trust can limit automation.
• If you write or think for a living, use AI as a partner in iteration. Dan describes dictating arguments, asking Claude to reflect back what he was trying to say, and listening to machine-read drafts to spot weak points.

The practical message is not to predict the entire labor market. It is to work with the tools now so you are fluent when expectations change.

Notable Quotes

• Dan: "AI makes yesterday's expert competence cheap."
• Dan: "The further away an agent gets from a human, the less valuable it is."
• Dan: "If you ride the models, you're going to be okay. You're going to have a job. You're going to do great work and you don't have to worry."

Big Technology Podcast • 56m

Overview

Alex Kantrowitz talks with former Twitter CEO Dick Costolo about what could happen if SpaceX, OpenAI, and Anthropic hit the public markets soon. The core point is that IPOs are driven as much by story and expectation as by revenue and margins, and once a company is public, that story can trap it.

They also get into the stress public markets create inside companies, why AI valuations may run into political and physical limits, and what Meta and X say about morale, product instinct, and the current tech cycle.

Key Takeaways

Costolo’s main point is simple: the hardest part of going public is not the listing day pop, it’s what happens after. In private markets, valuation moves in occasional jumps and employees can mostly ignore it. In public markets, stock prices swing daily, often for reasons that have little to do with the business. He says leaders need to prepare employees for that whiplash before the IPO, or the company gets pulled into constant anxiety.

He uses Twitter as the warning case. The company’s IPO story centered on massive user growth, so even when Twitter beat on revenue or EBITDA, the market punished it if monthly active users missed expectations. His argument is that early messaging matters because investors keep grading the company against that first promise.

On the three possible AI IPOs, Costolo sees very different setups. He argues SpaceX has the easiest public-market story because Elon Musk already knows how to keep investors focused on a distant future rather than current numbers. OpenAI, in his view, has the toughest setup because Sam Altman has made huge compute and spending commitments that public investors will try to match against a still-developing business model. Anthropic may have the cleanest middle path: a steadier enterprise story, less hype, and less pressure to explain giant promises.

A second big theme is that AI companies may face limits that have nothing to do with model quality. Costolo thinks public resistance to data centers is a real threat. He points to growing backlash from both left and right over power use, water use, local disruption, and weak job creation. If those projects slow down, the AI leaders’ expansion plans get harder to justify.

On pricing and competition, he agrees with the view that OpenAI and Anthropic may be pushed into price pressure rather than easy price increases, especially if products stay close enough in quality. That makes the long-term economics less clear than headline valuations suggest.

The conversation ends on culture and status. Costolo says repeated layoffs destroy trust when management keeps changing the explanation. He also argues that Silicon Valley’s fixation on who got rich from the AI boom creates a miserable comparison game, one that leaves even the winners unhappy.

Practical Steps

• If you’re taking a company public, train employees for volatility ahead of time. Explain that the stock may move 15 to 20 percent on no real news and that this does not automatically mean the business changed.
• Be careful with the promise you make at IPO. Investors will keep measuring you against that first narrative, sometimes more than they measure the quarter itself.
• If you run an AI company, build a public case for why your infrastructure helps society. Don’t assume the value is obvious, especially when new data centers face local opposition.
• If you lead through layoffs, say what went wrong plainly. Recycled corporate language makes people assume management is hiding the truth.
• If you invest, watch ordering and timing. Costolo’s view is that the first big AI IPOs may absorb a lot of available public-market appetite, which could shape outcomes for whoever comes later.
• If you work in tech, don’t organize your life around who hit the AI lottery. Costolo’s advice is blunt: comparison is a bad strategy and usually turns into resentment.

Notable Quotes

• Dick Costolo: "You need to prep the team for, hey, we’re about to go into a world where the price of the stock can change, even though nothing particularly happened today."
• Dick Costolo: "The narrative and the story and your ability to help the market think about the way you want to tell the story is just as important as the specific numbers in the quarter."
• Dick Costolo: "Living a life of comparison, it doesn’t matter where you are in that stack, it’s a losing strategy."

How I AI • 30m

Overview

Claire Vo explains how "Goals" in Codex changes AI from a turn-by-turn assistant into something that can keep working toward an outcome on its own. The episode is a practical walk-through of when to use Goals, how to write them well, and why this mode is what people often mean when they talk about AI handling long-running work "overnight."

She grounds the feature in real use cases: fixing recurring engineering errors, cleaning up thousands of emails, and clearing stale project-management tasks. The thread through all of them is simple: if you keep telling the model "keep going" or "try the next thing," a goal-based loop may be a better fit.

Key Takeaways

The main distinction Claire makes is between a prompt and a goal. A prompt asks for one task and waits for the next instruction. A goal gives Codex an end state, then lets it work in a loop: do work, check results, choose the next step, repeat until there is evidence the job is done.

That loop matters because autonomy depends less on raw model intelligence and more on whether the system knows how to keep going without human nudging. Claire says that before Codex Goals, she had not been able to get coding agents to sustain multi-hour work reliably; with Goals, she says she got one task to run for about five hours and 45 minutes.

A strong goal looks a lot like a well-written OKR or success criteria doc. Claire highlights six parts: the desired outcome, how to verify it, what cannot break, what tools or files are in scope, how the agent should pick the next step, and when it should stop and ask for help. That framing is useful beyond engineering because it forces you to define "done" in a way a machine can test.

Her examples show that non-coding work may be one of the best fits. She says Codex processed roughly 3,900 emails over nearly four hours, categorized them, helped unsubscribe from mailing lists, and got the inbox down to 68 items needing review. She also shows a Linear cleanup task where the agent closes stale issues from old podcast episodes based on a clear rule.

She is also clear about limits. Goals are a bad fit for tiny edits or fuzzy objectives like "make customers happy" or "refactor this code." The sweet spot is a stable objective, a measurable finish line, and a task that takes several rounds of investigation.

Practical Steps

If you want to try Goals well, start with work you already micromanage. Good candidates include bug burn-downs, inbox cleanup, backlog triage, repetitive QA, or performance improvements with a measurable target.

When you write the goal, include:

• End state: what should be true when the work is done
• Verification: what test, metric, or evidence proves success
• Constraints: what must not regress
• Scope: what tools, systems, or files it may use
• Iteration rule: how it should decide what to try next
• Stop condition: when it should pause and ask for help

A practical template from Claire's discussion is: define the result, say how to measure it, set guardrails, limit the working area, tell it how to report progress, and tell it what to do when blocked.

Also, pick the right size task. Do not use Goals for one-line fixes. Save it for work where you expect multiple passes and where success can be checked without guesswork.

Notable Quotes

• Claire Vo: "If you find yourself in that process, using /goal in codex might be a tool that you want to add to your toolkit."
• Claire Vo: "Goals written are a lot different than prompts. Prompts are an instruction of what to do. Goals is a description of what a good outcome is and it's observable."
• Claire Vo, citing the OpenAI guidance: Goals are strongest when they have "a durable objective, an evidence-based finish line and a path that may require several turns of investigation."