Talking To Yourself Isn't Crazy. It's One Of The Most Underrated Mental Tools You Have.

For most of my life, I assumed talking to myself was something I should hide. You catch yourself muttering in the mirror, narrating your to-do list out loud in the kitchen, rehearsing a difficult conversation in the shower — and the cultural reflex is to feel a little embarrassed about it. "Don't let anyone catch you doing that."

Turns out, the people who do this regularly might be quietly running one of the most effective self-regulation hacks the human brain has.

The Research Nobody Told You About

Ethan Kross runs the Emotion and Self-Control Lab at the University of Michigan. He's spent the better part of two decades studying what he calls "the inner voice" — the running monologue that lives in all of our heads. His research, summarized in his book Chatter, lands on something counter-intuitive:

The problem isn't talking to yourself. The problem is how you talk to yourself.

Specifically, Kross found that when people refer to themselves in the second or third person — "Kumar, you've got this" instead of "I've got this" — three things happen, measurably:

1. Cortisol drops. Stress hormones decrease within minutes.
2. Performance under pressure goes up. Public speaking, hard conversations, high-stakes decisions all improve.
3. Problem-solving gets clearer. People give themselves better advice than they give themselves when stuck in first-person rumination.

He calls this self-distancing. Stepping back from your own experience just enough to look at it like you'd look at a friend's problem.

Why Speaking It Out Loud Matters

Thinking and speaking aren't the same thing.

Silent thoughts loop. They're vague, emotional, half-formed. You can spend forty minutes "thinking about" a problem and emerge with nothing because your brain was just churning the same anxiety over and over.

The moment you say it out loud, three changes happen:

• It has to become a sentence. Vague dread turns into "I'm worried this client will churn next month." That alone is half the work.
• You hear it. Auditory feedback engages a different processing system than internal thought. Your brain reacts to your own voice the way it reacts to someone else talking to you — which means you can actually consider the statement instead of just being inside it.
• It externalizes the load. Journaling works for the same reason. Once a worry is outside your head — on paper, in the air — your working memory frees up.

This is why people who narrate their work out loud often code faster, debug better, and make fewer mistakes during complex tasks. Rubber-duck debugging is a real engineering technique for a reason.

The Founder Angle

I run a company. Most days I'm shifting between four or five completely different contexts — an Amazon listing crisis, a new hire decision, a tech product roadmap, a cash flow question, a sales call. Each one demands a different mental model.

What I've noticed — and what Kross's research backs up — is that talking to myself is the cheapest possible context switch. Walking from one room to another, narrating "okay, we're done with ops, now we're thinking about hiring," is doing actual cognitive work. It's flushing the previous frame and loading the next one.

It's also the cheapest possible therapist. A two-minute monologue while making coffee, where I literally say "Kumar, what is actually bothering you right now?" — out loud, second person — surfaces things that hours of silent worrying never would.

When To Worry, And When Not To

The line between healthy self-talk and something concerning is actually pretty clear:

Normal and healthy:

• Narrating tasks
• Rehearsing hard conversations
• Venting and problem-solving
• Motivating yourself
• Processing emotions out loud
• Running through plans before executing

Worth paying attention to:

• The voice feels like it isn't yours
• You're hearing responses you didn't generate
• It's replacing, not supplementing, human connection
• The tone is consistently cruel and you can't stop it

The first list is just thinking with your mouth open. The second list is when it's worth talking to someone.

The Practical Takeaway

If you already do this, stop being embarrassed about it. You're not the weird one — the people who don't do this are missing a tool.

If you don't, try the smallest version: next time you're stuck on a problem, walk into a room alone and describe the problem out loud, in second person. "Okay, you're stuck on X. What's actually the blocker here?" Two minutes. Watch what happens.

The most useful conversations of my week are usually the ones I have with no one in the room.

Inspired by Ethan Kross's work at the University of Michigan and his book Chatter: The Voice in Our Head, Why It Matters, and How to Harness It.

Code Is Cheap. Taste Is Expensive.

Cat Wu runs product for Claude Code at Anthropic. Her team ships features in a day. Not a sprint. Not a week. A day. And she just told Lenny Rachitsky something that should rewire how every operator thinks about building right now: the cost of writing code has collapsed, and the skill that matters is deciding what to write.

That is the entire shift. Everything else is a consequence of it.

For two decades, product management was a coordination job. You wrote PRDs, aligned partner teams, negotiated quarterly roadmaps, and shipped a feature every month or so. The work was slow because code was expensive. Teams needed four months to build a thing, so a PM spent four months making sure the thing was worth building.

That calculus has inverted. When a feature can be stood up in a day, the bottleneck is no longer engineering capacity. It is taste. It is knowing which of ten thousand GitHub issues is worth touching. It is knowing whether the current model can actually pull off the feature you are imagining, or whether you are shipping a broken promise.

Wu's own team operates on a rule worth stealing: ship almost everything as a research preview. Brand it clearly as an early idea. Tell users it might not survive. This one framing move reduces the commitment to a feature from "we shipped it, we own it forever" to "here is a draft, tell us what works." Commitment becomes cheap. Feedback becomes the roadmap.

If you are running an agency or a D2C brand or a tech platform, steal this verbatim. Half the reason your team ships slowly is because every release is treated as a marriage. It isn't. It is a first date.

The second thing worth sitting with: Wu openly says the PM role and the engineer role are merging, and Anthropic is hiring engineers with product taste over PMs who cannot ship. Designers on Claude Code write frontend code. Engineers take an idea from Twitter and turn it into a working feature by lunch. The PM job survives only as a multiplier role for people who can already build. The pure-coordinator PM is a dying species. Operators who cannot at least drive a coding agent are about to be priced out of their own product.

The third lesson is the one that hits the hardest, and it is buried under all the talk of velocity. Wu calls it the last-mile rule. Building 95% of a feature is the easy part. Pushing it from 95% to 100% — where it actually works for users every time, not just in the demo — is the entire job. Most teams ship half-baked features because the model fails five percent of the time, and now you have a broken process that you half-trust, which is worse than no process at all. Either put in the elbow grease to push it to 100%, or do not build it. The middle ground is the worst place to be.

Watch Amazon sellers and D2C operators doing this weekly. They build a half-working repricer, a half-working ad bidder, a half-working review responder, and then spend more time babysitting the automation than they saved. Wu's point is simple: the last mile is the entire job. Skip it and you have bought yourself technical debt dressed up as productivity.

There is a deeper layer under all of this, which is how Anthropic itself moves. Wu said that if Claude Code failed but Anthropic succeeded, she would be happy. Teams trade off against one another openly because the mission sits above any product line. That clarity is why the company ships a feature a day across a dozen surfaces without tripping over itself. It also explains some decisions that looked weird from outside — like sunsetting features built for old models because the new model makes them unnecessary. You don't carry around scaffolding that was put up to compensate for a previous model's weakness; you assume the next model will close that gap and you build with that future capability to catch up. Code review was exactly this — attempted for two years, only launched when Sonnet 4.6 could actually catch bugs.

If you are building for today's model only, you will be blindsided every quarter when a new model changes what is possible. Build for six months from now. The model will eat your harness for breakfast, and the things you scaffolded around to compensate for its weaknesses will quietly become unnecessary. That is the point. Remove the crutches. Keep the scaffolding honest.

The one-line takeaway: stop coordinating, start shipping. Stop prototyping, start using. Stop pretending 95% is done.

The bar moved. Your roadmap should too.

Source: Cat Wu on Lenny's Podcast

Create. Spread. Kill.

Every brand on Amazon moves through three phases. Most never get past the first.

1. Create space for yourself

You don't enter a category. You carve a hole in it.

One keyword. One use case. One price point. One thing you can own before anyone notices you exist.

This is not about being everywhere. It is about being undeniable somewhere.

Most brands skip this. They launch wide and show up as the fifth-best option on twenty keywords. Fifth-best is invisible. Fifth-best dies.

Create space first. One inch of territory you fully own.

2. Spread yourself

Once you own one thing, you expand from it.

More ASINs. More variants. More keywords. Every search a buyer might run should eventually surface you.

The customer who searched "study lamp" should also find you when they search "reading lamp," "bedside lamp," "LED desk lamp," "table lamp for office." Same brand. Different doors. Same shelf at the end.

You stop being a product. You start being a presence.

This is where the flywheel turns. Each ASIN feeds reviews into the brand. Each keyword feeds ranking into the others. Spread compounds in a way a single-product strategy never can.

3. Kill the category

Most brands don't believe this phase is real.

It is. We did it with table lamps. Nobody comes close. The category isn't competitive anymore. It is ours.

Killing the category means you hold the #1 BSR. You also hold #2. And #4. And #7. Half the search results page is you. Buyers stop comparing. They just buy.

Competitors can't catch up even when they try. Your review base is too deep. Your ranking is too entrenched. Your data on what sells, at what price, with which images, in which season — they don't have it. You do.

This is the endgame. Not market share. Market ownership.

The order is the strategy

Brands fail when they confuse the phases.

They try to spread before they create. They try to kill before they spread. They go wide and shallow and get drowned out.

There is no shortcut. There is only sequence.

Create first. Spread second. Kill third.

The Year You're Off By

Dario Amodei thinks there's a 90% chance we get a country of geniuses in a data center within ten years. He says it in public, with a straight face. He will still not buy a trillion dollars of compute.

The CEO who believes — really believes — that his own product is about to become the most valuable thing in history refuses to place the bet his conviction implies. Not because the compute isn't available. Not because he can't raise the money. Because if the revenue curve slips by one year, Anthropic dies.

This is the economics of certainty-of-utility in plain sight. Believing the payoff arrives is cheap. Believing when it arrives is expensive, and it's the only variable the check-writer is pricing.

Attach yourself to an exponential. But budget for the year you're off by.

Source: https://youtube.com/watch?v=n1E9IZfvGMA

Diffusion Is The Product

Diffusion is cope, Dwarkesh tells Dario. The word's become a buzzword — a way to wave off AI progress when the model can't do the thing yet. Dario, who you'd expect to agree, doesn't. His position is sharper.

The model being smart isn't the constraint anymore. Procurement is the constraint. Legal review is the constraint. The 3,000 developers a CIO has to roll it out to — that's the constraint. Claude Code is the easiest enterprise sale Anthropic has ever made. It's still slower than selling to a Series A.

The capability curve and the diffusion curve are two different exponentials, and the second one is the one your business actually lives inside. This is why implementation is the moat, not the model. Anyone with an API key has the same intelligence. What they don't have is the workflow, the buy-in, the change management, the person who can tell the model exactly what to do by Thursday.

If the model is the raw material, diffusion is the product. Sell that.

Source: https://youtube.com/watch?v=n1E9IZfvGMA

If She Likes You, There Are No Rules

---

The Two States

There are only two states a woman can be in with you.

She likes you. Or she doesn't.

There is no third option. There is no "working on it." There is no "she's coming around." There is no "give it time." Time is not a strategy. Time is what you spend while the answer is already decided.

---

State One — She Likes You

If she likes you, there are no rules.

• She'll make time when she has none.
• She'll cancel plans she shouldn't cancel.
• She'll reply at 2 AM.
• She'll drive across the city for you.
• She'll forgive the things she swore she'd never forgive.
• She'll bend in ways her own friends will tell her not to bend.

The same woman who is hard, busy, principled, unreachable to the rest of the world — soft, available, almost obedient with you.

Not because she's weak. Not because you tricked her. Not because of some "technique" you read on the internet.

Because she likes you. That's the only reason. That's the whole reason.

---

State Two — She Doesn't Like You

If she doesn't like you, there is no access.

• The texts go unread.
• The calls go unanswered.
• The plans never land.
• Every small ask becomes a negotiation.
• Every gesture is read in the worst possible light.
• Every effort you make is filed under "trying too hard."

She will be polite, maybe. She will be civil, maybe. But behind the civility, she will quietly make your life a living hell.

And the cruelest part — she won't even feel cruel doing it.

To her, it's just admin. To you, it's the whole year.

---

What It Is Not About

This is not about charm.
Not about looks.
Not about money, status, gym, gifts.
Not about a six-figure job, six-foot height, six-pack.

None of it.

Those are inputs. The output is binary.

She likes you, or she doesn't.

---

What Men Do When They've Already Lost

Stop trying to win the argument.
Stop trying to be reasonable.
Stop trying to "communicate better."

Reasonable doesn't unlock the door.

Reasonable is what men do when they've already lost.

---

The Whole Thing

Either she likes you —

— or you're managing a problem that has no solution.

That's it. That's the whole thing.

Claude Code Was An Accident

Claude Code is now the most-copied product in AI. Every frontier lab has built one. Every VC has funded three. Anthropic didn't set out to build it.

What happened, per Dario: early 2025, he told the team "models are good enough now — experiment with using them on your own work." Someone wired up a CLI. Internally, everyone started using it. The name was Claude CLI before it was Claude Code. At some point Dario looked around and said: this has product-market fit inside the building. Let's launch it.

The interesting thing isn't the origin story. It's the filter. Anthropic only ships products where they're the customer. "We didn't launch a pharma company because we don't have the resources to know what we'd need." That's the whole test.

Most product decks answer the wrong question. They ask: is there a market? The better question is: are you in it? Because if you're not, you're guessing at everything a real user would feel in five minutes.

Build what you use. Launch what you can't stop using yourself.

Source: https://youtube.com/watch?v=n1E9IZfvGMA

The Diffusion Gap: Why AI Won't Reach the Enterprise on Silicon Valley's Timeline

There's a gap opening up between what a San Francisco startup looks like in 2026 and what a JP Morgan looks like in 2026, and it's going to get worse before it gets better. Box CEO Aaron Levie had a conversation with Martin Casado and Steven Sinofsky on The a16z Show that named the three forces pulling the tech industry apart from the rest of the economy — and the biggest mistake most executives are making about the shape of the next five years.

The diffusion gap

Silicon Valley assumes that because startups can now automate a marketing team with one person and Claude Code, every enterprise is a year away from the same leverage. That's wrong, and it's wrong for a reason that doesn't get discussed often: algorithmic thinking is rare.

Sinofsky's framing: walk into a marketing team of 50 people at a global brand. Ask each one to draw a flowchart of their own job. Maybe one person can do it. The others know how to do the job — they don't know how to describe it as a system. That's the bottleneck for AI adoption inside large companies. It's not GPU access, it's not budget, it's not even resistance to change. It's that most people in most jobs were never trained to think in terms of process, branches, and feedback loops. The training they got was apprenticeship — watch someone, copy them, get good. That doesn't translate into directing an agent.

The viral Anthropic example (one growth marketer replacing five or ten people via Claude Code) works because that person was already a systems thinker. Put the same tool in front of most marketing teams and they freeze.

The optimistic version of this, which Levie believes: the abstraction layer just moves up. Sinofsky's cousin joined a bank right before spreadsheets arrived. She couldn't use Excel, so she supervised a room of interns who could. Two years later she was the spreadsheet person, and the interns were doing something higher. That's the pattern. Today's "rocket scientist coordinating 42 agents" is temporary. In a year or two there's just a skill-level domain agent — "marketing-ish" — and the average marketer can ask it for things.

Fine for the ten-year outcome. Ugly for the two-year transition. And the gap in capability between a startup using agents from day one and a 200,000-person bank trying to retrofit them is widening, not narrowing.

Build for agents, not for humans

But there's a subtle mistake in the discourse that Martin Casado called out and it's worth internalizing: you are not "marketing to agents." Agents don't care about your documentation, your positioning, your interface polish. The one thing agents are genuinely great at is finding the right backend for the job. They pick on cost, durability, semantics, the actual properties of the system.

This is a gift and a threat. The gift: merit actually wins. If your product is technically the best for the job, the agent will find it and use it, and you don't need to buy Gartner quadrants or run bigger trade-show booths. The threat: if your product is mediocre but has dominated because of brand or sales, the agent will skip you. "Which database should I use for this?" is a question the agent is going to answer from first principles now. Gartner is going to matter less.

(Casado's dry caveat: Silicon Valley will ruin the meritocracy quickly once the incumbents figure out how to pay-to-influence agent selection. Give it two years.)

The enterprise control problem is brutal

Every big tech company is confronting the same scenario right now: 5,000 employees, each one running Claude Code with access to the Box CLI or its internal equivalent. That's potentially 10,000 write operations per hour against the shared system of record — with agents creating nested directories without limit, conflicting with each other, racing each other on file moves, and accidentally leaking M&A data room contents because a prompt injection slipped in from a shared document.

The intuition that "treat the agent like a human" doesn't work cleanly. Humans have a right to privacy. Agents don't. You can log in as the agent and audit its entire output; you can't do that with an employee. But if you can log in as the agent, the agent can't really operate as a separate identity at all — any agent it talks to could be routed back to you. So the mental model collapses.

Sinofsky drew the parallel that fits best: the open source era. For years, engineers debated in conference rooms how much open source code could be pulled into Windows or Office, what the licensing constraints were, how to manage the security posture. None of that debate happened in public. It took a decade to build the norms. The same debate is happening now — except it's happening on podcasts and X in real time, and everyone expects the end state to arrive in six months.

It won't. The enterprise lockdown is coming first. Startups will pull further ahead in that window.

The engineering compute budget — the most consequential line item of the next two years

Levie's final warning deserves its own highlighted paragraph. R&D spend for a typical tech company is 14–30% of revenue. If tokens are 2× your engineering team cost, that's your entire EPS eaten. If they're 3%, you're fine. The delta between those two numbers is being debated today with effectively zero data.

CFOs are going to be forced to pick a number. Wall Street will hold them to it. Some will be spectacularly wrong. Some will get fired. Most of the economics people are using to model this right now are off by an order of magnitude — in the same way the PC market was underestimated (nobody predicted a thousandfold increase in MIPS-per-desk, or that software would sell separately from hardware), and the cloud was underestimated (nobody predicted that giving every engineer elastic compute would lead to a thousandfold increase in consumption, not a lateral migration of 60,000 servers).

The IBM analogy closes the loop. For years IBM was selling more MIPS for fewer dollars every year. They were pricing mainframes on MIPS anyway, and didn't notice they were on a decreasing curve — making MIPS faster than they could charge for them. Today's AI pricing is on the same trajectory. The companies pricing by token are going to be the ones pointing at their own decreasing curve in three years.

Three things to actually do about all this

1. If you run a SaaS business: stop treating your API like a compliance afterthought. The agent is your new main user. Your monetization model, your identity system, your rate limits — all of it gets redesigned around agent volume. The companies that get this right become infrastructure. The ones that don't become line items.

2. If you run an enterprise: resist the instinct to build a new governance layer for agents. Use the identity systems you already have — give the agent its own Gmail, its own phone number, its own RBAC role, its own payment method. Treat it like a separate identity with tight scopes. Adding a fresh policy plane on top of your existing mess just slows everything down.

3. If you're doing financial planning: assume your compute budget assumption is off by at least 10×. In both directions. Plan scenarios, not point estimates. CFOs who commit now to a precise number will be the ones getting fired later.

The line that closed the conversation: "They thought the Dakotas would be covered in vacuum-tube warehouses to fight World War II. Then someone invented the transistor." AI is in its vacuum-tube-warehouse phase. Act accordingly.

Source: Box CEO Aaron Levie on the AI Adoption Gap — The a16z Show

Token Maxing, Mech Suits, and Why Shopify Was Right About AI

A leaderboard went up inside Meta a few months ago. It measured, per engineer, the number of AI tokens consumed. It was supposedly "one data point among many" for performance reviews. Within weeks, Meta engineers were asking Claude to summarize docs they could read faster themselves. Salesforce set a minimum $175 monthly AI spend per engineer; people started racing to hit the floor. Microsoft engineers ran autonomous agents overnight to build junk so the number would climb. Meta eventually pulled the leaderboard — but people kept token maxing anyway, because in big tech, you don't forget that the metric ever existed.

Gergely Orosz (The Pragmatic Engineer) described all of this on the AI Engineer Summit stage with Swyx, and the historical rhyme is perfect. Ten years ago, early developer productivity tools measured lines of code and PR count. That was stupid, and everyone knew it was stupid, and people optimized for it anyway. The same thing is happening now — just dressed up as "AI adoption."

Why the push exists, though

The uncomfortable truth is that leadership didn't invent token maxing out of stupidity. Six months ago, CTOs were genuinely worried their engineers weren't using AI tools at all. One CTO at a Netherlands e-commerce company told a room of peers: "My engineers are skeptical. They're not using it." On existing codebases with older models, they had a point — the tool didn't find the bug, didn't refactor well, didn't earn its keep.

At the same time, Anthropic kept publicly saying a huge share of their own code was written with Claude Code — and their revenue line went vertical. So leadership, unable to tell correlation from causation, decided the safer bet was: force adoption. Coinbase's CEO Brian Armstrong literally emailed the company that anyone not using AI tools within a week would "have a conversation," then fired an engineer that Saturday. On $300–400K base salaries, the message lands.

Token maxing is the downstream result. It's leetcode reborn — an absurd ritual that selects for people willing to perform it to keep the job. The people who actually get value out of AI coding are the ones who ignore the metric entirely and just use the tools to ship.

The mech suit, not the manager

The other framing that's getting big tech wrong: "you're not an engineer anymore, you're an engineering manager." Gergely and DHH both think this is bullshit. The whole reason people resist becoming engineering managers is the stuff they'd have to give up: the product, the feedback loop, the hands-on craft. Agents don't give you any of that pain. You don't have to mediate conflict between agents. You don't do 1:1s with them.

DHH's metaphor: it's a mech suit. You're still the pilot. You're just doing seven things at once. The feedback loop is days, not quarters. The decisions you make compound in weeks instead of in six months. If anything, the role looks more like "tech lead" than "manager" — you're orchestrating without being removed from the work.

The role is compressing

Pre-AI, venture-funded startups were already running a compressed version of engineering. Dedicated QA teams disappeared into "every engineer writes tests." Dedicated devops teams disappeared into "every engineer owns their deploys." Product engineering emerged as a real title. AI is pushing the same compression one more notch. Junior engineers are now expected to reason about the business, plan at the architecture level, ship end-to-end.

One concrete signal: a VP at John Deere — a 200-year-old tractor company — told Gergely their "two-pizza teams" are now one-pizza teams. The smallest units in a company that has no reason to move fast are getting smaller. Everywhere else, it's already happened.

The real action is internal infra

The most underrated observation in the whole conversation: the biggest AI investment at large tech companies is not the product you see. Uber looks like it isn't shipping features. Inside, they are rebuilding the entire engineering stack — custom background coding agents integrated into their monorepo, an MCP gateway wired into service discovery, on-call tooling re-tooled around AI, code review systems that auto-categorize changes by risk. Airbnb, Intercom, Meta, Microsoft — every one of them is doing a version of this.

Three reasons it's rational:

1. It's the low-risk way to get hands-on with AI. You don't want your first AI feature to be customer-facing slop. Internal tooling is a safe training ground.<br>2. Their codebases will never fit in any context window. Off-the-shelf vendors (Cursor, Claude Code, Copilot) are built for typical codebases. The hyperscalers have code that is an order of magnitude larger and messier. Custom tooling + basic agents will beat the vendor stack on their own codebase.<br>3. Anything with "AI" in the name gets funded. Ask for two engineers for the platform team and get nowhere. Ask for two engineers for "agent experience" and it's done.

If you're at a large tech company and you're not building an internal MCP gateway, Gergely's line was: "what are you even doing?"

Why Shopify was right

The Shopify story is the one to remember. In 2021 — before Copilot was a product — Shopify's head of engineering heard it was being developed internally at GitHub. He DM'd Thomas Dohmke, the GitHub CEO, and said: "I'd like to get this rolled out to all of Shopify. In exchange you get feedback from 3,000 engineers, honestly, forever." It wasn't for sale. Shopify got it anyway, a full year before anyone else.

The tool wasn't great initially. Shopify burned real money and ate real engineering churn. They kept iterating. They became the first company onboarded to every major AI tool that followed, with unlimited budget.

Gergely's read: Shopify is trading churn + expense for being six months ahead. That trade is not rational for most companies — if your business is a physical product or a legacy vertical, wait it out, the tools will catch up. But if your company competes in technology, paying for the turn is worth it. Plus, at that point, AI adoption is a recruiting signal: "Come work here, you'll have every tool before your friends do."

The weird thing is that every tech company is doing this at the same time. So it looks performative. It isn't. It's rational individually. It just happens to be universal.

The takeaway

Three things to remember, regardless of whether you're writing code or running a company:

1. Don't measure token count. Measure output. Every time a company makes a metric the goal, smart people game it.
2. Treat AI tooling as a mech suit, not a manager. The value is in what you can now ship alone, not in "managing" anything.
3. If you're in tech, eat the churn to be six months ahead. Shopify's trade is available to most of us. The cost is real. The alternative is worse.

Source: How AI Is Changing Software Engineering — Gergely Orosz, The Pragmatic Engineer

Ship With Friction: Why The Slow Part Is The Only Part That's Still Yours

A security incident went up on a company's forum last week. The config change shipped by mistake. The auto-generated social preview rendered the company's tagline right next to it: Ship without friction. Armin Ronacher — the guy who wrote Flask — used that screenshot to open a conference talk, and the joke landed because everybody in the room had made the same mistake recently.

The uncomfortable argument Armin and his co-founder Christina Poncela Cubeiro made: the friction engineers have spent a decade trying to remove is the friction that was doing the thinking. Remove it and you don't get speed. You get a codebase nobody can steer.

The psychological trap

The first few months of coding with Claude Code or Cursor feel like cheating. You prompt, the machine writes, you ship. Then everyone on your team is using it. Then your team's baseline expectation resets. Then the ambient pressure becomes: more output, faster cycles, shorter PRs. The gift becomes the tax. You no longer have the quiet moments to stop and ask whether this is the best way to implement the thing — because you're one prompt away from shipping it.

Armin calls this the gambler's loop. You don't know if the next prompt is the one that makes the product work, or the one last drop of slop that tips the whole thing into an outage. You keep pulling the lever.

The more interesting part is the illusion underneath it. Because you're producing a lot of output very fast, you feel more efficient. You're not. You've just stopped doing the part of the work where you design.

The team composition shift nobody warns you about

Before agents, engineering teams were supply-constrained on the creation side. The balance between writing code and reviewing code was roughly okay. Now every engineer has 5–10× the production power, and nobody got 5–10× the review power.

Two downstream effects:

1. Pull requests pile up. The ones that aren't reviewed carefully get rubber-stamped.
2. The set of people shipping code expands. Marketing people ship code. Former-engineer CEOs ship code again. The number of entities — humans and machines — participating in code creation now vastly outnumbers the ones that can carry responsibility for it. And the machine can't carry responsibility.

The engineering team is still on the hook. But the production volume hitting them is no longer something they authored.

Why agents rot products faster than libraries

The single most useful technical observation in the talk: agents are excellent at libraries and mediocre at products.

Libraries have a tightly defined problem, a clear API surface, and a simple core. The agent can fit the whole thing in its context window, reason about it globally, and add features cleanly. That's why open-source maintainers are getting real leverage from these tools.

Products are the opposite. UI, API responses, permissions, feature flags, billing, background jobs — every change touches three other concerns. The agent cannot fit the global structure in its context. Locally it looks reasonable. Globally it's incoherent.

And the agent's failure mode is specific: it's been trained to write code that runs. That reward function is exactly what you don't want in a product. A human engineer writing a config loader feels bad when they write if config missing, silently load defaults. The agent feels nothing. So the agent ships it. Two hours later you have database records written against the default config, and you don't know it yet.

Humans build up revulsion toward bad code. Agents don't. The codebase accumulates entropy until the agent itself can no longer navigate it — it starts missing files, writing duplicates, forgetting what already exists. You've built a system neither you nor the agent can reason about.

The agent-legible codebase

Armin's prescription: your codebase is now infrastructure. Design it for the agent the way you'd design infrastructure for operators.

Concrete rules Earendil is enforcing through lint:

• Modularize the code flow, not just the components. The agent does its worst damage between the clearly defined steps — parsing types it shouldn't, stuffing things into state. Name the steps.
• Don't fight the RL. If there's a canonical way to do a thing in this language, use it. The agent is trained on the canonical version.
• No hidden magic. Raw SQL hides intent. An ORM shows it. If the agent can't see it, it can't respect it.
• No bare catch-alls. Silent failure is how products rot.
• One query interface for SQL. Don't make the agent grep the codebase to find where queries live.
• Unique function names. Not for readability. For token efficiency — when the agent greps, it wants one hit, not twelve.
• One UI primitives library, no raw inputs. Consistent styling, consistent behavior.
• No dynamic imports. Source of truth should be static.
• Erasable-syntax-only TypeScript. No transpile step. One source of truth between your code and the compiler.

Every one of these is friction. Every one of them is the point.

The part where your judgment gets woken up

The piece that made the whole talk click for me: Earendil built a PR extension that separates the review inputs. Mechanical bugs and style violations go straight back to the agent — those don't need a human. But a database migration, a permissioning change, a new dependency — those explicitly route to a human call-out that says "your brain should be on now."

Because if you miss them, you will regret them. And you will miss them. The machine's job, in this model, is to notice the moments your judgment is actually required, and to make sure you don't sleep through them.

Why "friction is bad" is the wrong slogan

Large engineering organizations have long used SLOs — service-level objectives — as deliberately inserted friction. The point of an SLO is to force the team to stop and ask: Do I actually need this reliability? Do I have the headcount to run this? Should I ship this service at all?

The AI-coding era has encouraged us to treat all friction as waste. In physical systems, friction is what lets you steer. Without it, you don't go faster. You just stop being the one driving.

The single line to take from Armin and Christina: the friction is where your judgment lives. The shift isn't to stop using agents — it's to stop pretending the remaining ten percent of the work, the slow part, is the disposable part. It's the only part that's still yours.

Source: The Friction is Your Judgment — Armin Ronacher & Cristina Poncela Cubeiro, Earendil

One-Chart Businesses: The Boring Way to Pick What to Build Next

Most people pick a business the wrong way. They start from what's trending on X, or what their friends are building, or what an AI demo made them feel. The better starting point is almost never that interesting: pull up a single chart, squint, and ask whether the line on it is going to bend in the next ten years. Sam Parr and Steph Smith on My First Million call these "one-chart businesses." The framing is simple — if a demographic, behavioral, or physical trend is already locked in and the chart makes it obvious, you've found a tailwind you don't have to fight.

Here's the chart that matters most right now: the global population curve split by age. The under-15 line is flat. The working-age line is flat. The 65-plus line goes from under 1 billion today to 2.5 billion. That's the tailwind. Everything that touches elder care rides it.

What the silver tsunami actually unlocks

The US Bureau of Labor Statistics already calls nursing the fastest-growing occupation between 2020 and 2030 — 275,000 new jobs. Assisted-living prices in the US have grown 31% faster than inflation and hit $54,000 a year on average. There are 31,000 facilities; four out of five are for-profit; half of the operators clear 20%+ annual returns on operating cost. That's not a tech margin, but on a real-estate-backed operating business, it's staggering.

Japan ran the experiment ten years earlier. Their silver tsunami produced akiya — over 8 million abandoned houses the government now hands out nearly free. It also produced nursing-home construction up 50% in a decade. Every country is running the same play on a delay.

The gap worth noticing: most assisted-living options are terrible. People already pay $20,000–$30,000 a month for the "good ones." Imagine the premium version — the place you'd actually feel good about sending your parent. That product doesn't really exist at scale. Build it and you own a category that's growing faster than anything AI is disrupting.

The physical-world businesses that don't fit in a pitch deck

A few more one-chart candidates from Steph Smith's database worth stealing:

Air quality. About half the world is exposed to roughly 5x the safe limit for PM2.5 particles. Delhi routinely hits an AQI of 450 — the equivalent of smoking 25 cigarettes a day. People notice water quality because someone showed them a glass of filtered-vs-unfiltered water. Nobody has done that for air yet. The company that turns "invisible threat" into "visible dashboard with a clear product answer" owns the category. Amazon data already shows AC furnace filters + air-quality monitors clearing $40M+ a month in revenue — and that's before anyone markets it seriously.

Sports that aren't pickleball. Pickleball is #1 on the fastest-growing-sports list. The more interesting names underneath are alpine touring, winter fat biking, off-course golf, and trail running. All of them have one thing in common: they bend a traditional sport toward something you can do socially, outdoors, in a smaller time window, without elite fitness. There's a whole "suburban triathlon" waiting to be branded — walk half a mile to a bar, drink two beers, play nine holes of golf. Out-of-shape middle-aged guys will buy anything with a finisher medal. The brand is already funny; the product design is the easy part.

Nerd neck. An entire generation is hunched over laptops and phones. Brian Johnson made a video about it, Tim Ferriss keeps talking about Egoscue, Roger Frampton's "why sitting destroys you" TED talk has millions of views. Right now the product landscape is a few dorky straps (BetterBack) and expensive sports bras (Form). There's a lot of room for a posture product that doesn't look like a medical device.

The less-obvious lens: Ask Nature

Sean Puri's favorite new rabbit hole from the episode is asknature.org — a database of how animals solve engineering problems. African darter feathers are radically water-resistant. Camel fur cools during the day and insulates at night. Otter fur is the blueprint half the wetsuit industry quietly stole. Biomimicry isn't a product category — it's a cheat code for brand stories. If you're building a clothing company and your marketing doesn't punch, the origin story is sitting on Ask Nature for free.

The breakup economy

A random stat from The Hustle: the average person spends $15,000 after a breakup. Divorce parties, breakup cakes, and "revenge body" kits are already getting organic search volume. If you already run a consumer meme account — F*Jerry, Lad Bible, anything with 5M+ followers — you have free distribution for a viral physical product. Breakup vodka. A "send us your ex's stuff in this box and we'll burn it on camera" service. Products like this usually top out at $2–10M a year, but they run themselves on the meme tailwind.

The rule the whole conversation rests on

Every idea in that episode sits on top of a chart that is already committed. Demographics don't reverse. Pollution doesn't un-compound. Posture doesn't fix itself while screens get more engaging. The only real question is whether a marketer shows up to translate the chart into a product the average person can buy.

If you're choosing what to build in 2026, don't start from the newest model or the sharpest framework. Start from the dullest possible chart. The more inevitable the line, the less competition you'll fight for the next ten years.

Source: 9 Killer Business Ideas the Internet Hasn't Caught Up To in 2026 — My First Million with Steph Smith

Purpose vs Task: The Lens That Tells You Which Jobs AI Actually Eats

Ten years ago, radiology was the consensus “first job to go.” Computer vision had just become superhuman, and the core task of a radiologist — looking at scans — was the most obvious target. A decade later, AI has completely permeated radiology. Every department uses it. Every scan gets processed faster. And the number of radiologists has gone up.

Jensen Huang offered this as a throwaway during a Davos conversation with BlackRock’s Larry Fink, but it is the single most useful frame I’ve heard for thinking about AI and labor. The lens is simple: distinguish the task of a job from the purpose of it.

A radiologist’s task is to study scans. Their purpose is to diagnose disease. When AI compresses the task from minutes to seconds, the purpose doesn’t vanish — it gets more of the person’s attention. More time with patients, more time with clinicians, more scans processed per day. The hospital sees more patients, earns more revenue, and hires more radiologists.

Same story with nurses. The US is short five million nurses. Nurses currently spend half their time charting and transcribing. Companies like Abridge are eating that task. The nurses don’t disappear — the bottleneck moves. More patients get seen, hospitals do better, more nurses get hired.

If all you can see is the task, every knowledge job looks extinct. If you look at the purpose, you notice that the purpose usually gets bigger, not smaller.

The industrial view of AI

Most people think AI is the model. Huang insists AI is actually a five-layer cake. Energy sits at the bottom. Chips and compute sit on top of energy. Cloud services sit on top of the chips. Models sit on top of the cloud. And applications — healthcare, manufacturing, financial services, the places where economic value actually shows up — sit on top of the models.

The reason this matters: every layer needs to be built before the one above it works. Last year, the models finally got good enough to support a real application layer. That’s why 2025 was the largest VC year in history, and why most of that money went to “AI native” companies in healthcare, manufacturing, robotics, and financial services. The model layer is subsidizing the application layer.

And the infrastructure beneath the models is enormous. A few hundred billion dollars in already. TSMC is building 20 new chip plants. Foxconn, Wistron and Quanta are building 30 new computer plants. Micron has committed $200 billion in the US. Trillions more to go. Huang calls it the single largest infrastructure buildout in human history. Not hyperbolically. Literally.

Why it isn’t a bubble

The word “bubble” gets used whenever a lot of capital moves at once. Huang’s test is simple: try to rent a GPU. Spot prices on Nvidia GPUs in every cloud are going up — not just the latest generation, but two-generations-old hardware. If the infrastructure were overbuilt relative to demand, spot prices would be collapsing. They aren’t.

The more interesting read: the bubble question is the wrong question. The right question is whether we’re investing enough to broaden the benefit. Right now AI usage is dominated by educated users in developed economies. That’s how every platform shift starts. The difference with AI is that it’s the easiest software to use in human history — a billion users in three years. If a country has electricity and roads, it can have AI. The open-model wave (DeepSeek, and everything that followed) means any country with local linguistic and cultural expertise can build AI that actually serves its own population.

For Europe specifically, Huang’s pitch was: your industrial base and your deep sciences are your moat. The US led the software era. AI is “software that doesn’t need to write software” — you teach it instead of coding it. That collapses the American advantage. Fuse Europe’s manufacturing strength with AI and the next layer — physical AI, robotics — plays to European strengths.

Three things to steal from this conversation

1. Audit your role by purpose, not task. If most of what you do is the purpose (diagnosis, judgment, client relationship), AI makes you faster. If most of what you do is the task (charting, retrieval, prediction), your seat gets compressed. Know which one you are.
2. Pick your layer. Energy, chips, cloud, models, applications — each has different economics, a different moat, a different timeline. Don’t build at the model layer unless you have a real reason to.
3. Infrastructure is the bet. The buildout is measured in trillions and in decades. Pension funds, sovereigns, and retail investors who sit it out will feel left out. The ones who fund the energy, chips, and factories will own the compounding.

The line that stuck: “You don’t write AI. You teach AI.” That sentence alone rewrites a lot of assumptions about who gets to build.

Source: Jensen Huang and Larry Fink at the World Economic Forum

Be Claude's PM, Not Its Proofreader

There's a strain of AI discourse that treats "vibe coding" as synonymous with letting a model write your code. It isn't. Eric, a researcher at Anthropic and co-author of Building Effective Agents, draws the line where Andrej Karpathy drew it: you're only vibe coding when you forget the code even exists. Cursor and Copilot don't qualify. Most of what senior engineers currently do with AI doesn't qualify. That's the whole problem.

The reason it's a problem is arithmetic. Task length that AI can complete end-to-end is doubling roughly every seven months. Today that's about an hour. Next year it's a workday. The year after, a workweek. If your workflow assumes you will personally review every line of code the model produces, you are building a career on the losing side of an exponential. Something will have to give, and it isn't the exponential.

So the question is not whether to vibe code in prod. The question is how to do it without shipping garbage.

Eric's answer borrows from every manager who has ever existed. A CTO green-lights code they can't read. A PM accepts features they couldn't have built. A CEO signs off on financial models they couldn't reconstruct. These people are not incompetent, they've just found abstraction layers they can verify without reading the implementation. Acceptance tests. User flows. Spot-checks on load-bearing numbers. Engineers are the last white-collar profession that still prides itself on understanding the full stack down to the metal. That pride is about to become expensive.

The compiler analogy is the one to sit with. In the early days of compilers, developers read the generated assembly to make sure it looked right. At some point the systems got big enough that nobody bothered. The code didn't become less important, the abstraction just became trustworthy enough that reading underneath it stopped being a good use of time. Application code is heading to the same place.

Three rules make the transition survivable.

Rule one: vibe code the leaves, not the trunk. Every codebase has leaf nodes, features nothing else depends on, bells and whistles that aren't going to be extended or composed. Tech debt in a leaf node is contained. Tech debt in your core architecture compounds forever. Human review stays mandatory on the trunk. Leaves can be trusted to Claude. The one class of problem today's models genuinely can't validate — is this extensible, is this clean — doesn't matter when nothing depends on the code.

Rule two: be Claude's PM. Ask not what Claude can do for you; ask what you can do for Claude. When Eric ships features with Claude he spends fifteen to twenty minutes collecting context into a single prompt, often through a separate planning conversation where Claude explores the codebase, surfaces the relevant files, and agrees on a plan. Only then does he hand the artifact to a fresh session and let it cook. The quick back-and-forth "fix this bug" loop is how you get mediocre code. A junior engineer on day one would fail the same prompt. Treat the model the way you'd treat that new hire: give it the tour, the constraints, the examples, the "here's how we do things."

Rule three: design for verifiability before you write the code. Anthropic recently merged a 22,000-line change to their production reinforcement learning codebase, written heavily by Claude. This was not a prompt-and-pray operation. Days of human work went into requirements and guidance. The change concentrated in leaf nodes. The extensible pieces got full human review. The team designed stress tests for stability and built the system with human-verifiable inputs and outputs, checkpoints that prove correctness without needing to read every line. That's the template. If you can't describe what "correct" looks like from the outside, you can't vibe code the inside.

The payoff isn't just saved hours. It's a lower marginal cost of software. When a feature costs one day instead of two weeks, you start shipping features you would never have started. You attempt system rewrites you would have dismissed as "not worth it." The cost curve reshapes what's worth doing at all. And that is where the real leverage lives.

Two caveats worth holding.

First, vibe coding in prod is not for the fully non-technical. Being Claude's PM means knowing enough about the system to ask the right questions and catch the wrong answer. The press coverage of leaked API keys and exposed databases describes a real failure mode — people who had no business running production systems were running production systems. The answer is not to ban vibe coding. The answer is to know what you're doing.

Second, today's caveat about tech debt will keep shrinking. Claude 4 models, even in their first weeks inside Anthropic, earned trust that 3.7 didn't. More of the stack will move inside the "safe to vibe code" bubble every quarter. The leaves will spread.

The uncomfortable framing: in a year or two, if your process still requires you to personally read every line of code, you are going to become the bottleneck on your own team. The models will happily produce a week's worth of work in an afternoon. The question is whether you've built the muscle — context, leaf-node discipline, verifiable design — to absorb that output, or whether you're still proofreading assembly while the rest of the industry ships.

Source: Master Coding Agents Like a Pro (Anthropic's Ultimate Playbook), Eric, Anthropic

 

Jensen Huang's Real Job Is Not Building Chips

AI Is Getting Cheaper — Fast. Here's the Data.

Every few months I get asked the same question: "Is AI actually getting cheaper, or is that just hype?" The answer is: yes, dramatically, and faster than almost any technology in modern history. Here is the data, plotted two ways.

Chart 1 — How many tokens you get for $1

In 2020, one US dollar bought you about 17,000 tokens (roughly 12,000 words) of the best AI model available (GPT-3). Today, one dollar buys you 800,000 tokens on GPT-5. That is ~48× more AI per dollar in six years.

In 2020, one dollar bought you about 17,000 tokens of the best AI (roughly 12,000 words). Today, one dollar buys 800,000 tokens — ~48× more AI per dollar in 6 years.

Green bars get taller each year because you are getting more output for the same money. Growth charts feel intuitive in a way that price-declining charts do not — so this is usually the version I lead with.

Chart 2 — How much 1 million tokens costs

The flip side of the same coin. A million tokens of the best AI cost $60 in 2020. Today the same workload costs $1.25 — roughly 50× cheaper.

Flip side of the same coin: a million tokens cost $60 in 2020, now costs $1.25 — ~50× cheaper. Faster price decline than computers, electricity, or solar ever managed.

For context, that rate of price decline is faster than:

• Computers (Moore's Law doubling cost-performance every ~2 years → ~8× per 6 years)
• Solar panels (~10× cheaper per decade)
• Electricity, cars, steel, aluminum — pick any major industrial technology, AI is beating it.

The data

Year	Best AI model	Price / 1M tokens	Tokens per $1	vs. 2020
2020	GPT-3	$60.00	~17,000	—
2023	GPT-4	$30.00	~33,000	2×
2024	GPT-4o	$5.00	200,000	12×
2025	GPT-5	$1.25	800,000	48×
2026 (today)	GPT-5 / Claude Opus 4.7	$1.25 – $15	67,000 – 800,000	4× – 48×

Why this matters for builders

The "cost per token" line does not feel revolutionary until you realise what it unlocks. At $60/1M you think twice about letting a user ask a question. At $1.25/1M you stop thinking about cost entirely and start asking "what if I ran 100 AI calls per user action?" — which is exactly how modern AI agents work.

The product patterns of 2026 (autonomous agents, document-heavy pipelines, real-time reasoning loops) were simply uneconomic in 2023. They are routine now because the floor fell out from under the price. And it is still falling.

The Cloud Ate the Robot

Physical Intelligence is two years old. It has not built a robot. It has built a model that controls other people's robots, hosted in the cloud, sending action commands over an API, with no model code running on the robot itself. Co-founder Quan Vang, on Y Combinator's Lightcone podcast last week, mentioned casually that "almost all of the robot evaluations we run at Pi today - including the complicated demos, making coffee, folding laundry, mobile robots navigating around - the model is actually hosted in the cloud. A real cloud. A data center somewhere." This single architectural choice has more implications for the next decade of robotics than any of the cooler demo videos they've shown.

Why this was supposed to be impossible. For twenty years, the first question any robotics customer asked was: what compute unit goes on the robot? It mattered because real-time control loops demand millisecond-level latency, the compute hardware you pick gets obsoleted every 18 months, and it bloats your BOM. The classical answer was "everything on-device," which meant robots were powerful, expensive, heavy computers with arms attached. Pi's answer is a systems-engineering trick called real-time chunking. The robot executes actions in chunks - say 100ms at a time. At the 50ms mark, before the current chunk is done, it requests the next one from the cloud with a continuity constraint so the transition is smooth. Inference happens in parallel with execution. Network latency is buried. The robot doesn't need onboard compute. Vang goes further: he has never seen the robots his model controls, and intentionally avoids knowing how they work internally. The layers are decoupled.

This is the unbundling of robotics. Here is what robotics used to require to build a company: your own customer relationships, your own hardware platform, your own autonomy stack, your own safety certification, your own data collection infrastructure, your own everything. Vertical integration wasn't a choice - it was table stakes, because the intelligence layer didn't exist as a component you could buy. Pi has explicitly externalized the intelligence. They open-sourced the Pi 0 and Pi 0.5 model weights - the same weights they use internally. The result is that a new founder can now walk into an industry with:

• Off-the-shelf robot hardware
• Pi's model handling perception, planning, and control as a cloud API
• A workflow they understand better than anyone else
• Scrappy data collection for their specific deployment

This is the playbook Vang actually walks through in the interview, and it's worth copying verbatim. Starting a vertical robotics company now looks like:

1. Understand an existing workflow deeply. Not conceptually - operationally. Where does labor bottleneck?
2. Identify the single insert point where a robot saves the most cost or unblocks the most capacity.
3. Use cheap hardware. The model is reactive; it compensates for hardware imprecision. You do not need a $100k precision arm.
4. Set up data collection and evaluation in the real deployment - not in a lab demo.
5. Get to mixed autonomy. Humans take over when the robot fails. This is okay. The point isn't perfect autonomy; it's economic break-even.
6. Once you're break-even per robot, scale the fleet. That's when the flywheel spins.

Two YC companies are already running this exact playbook. Weve folds diverse laundry in a real laundromat (not a demo) with clothes it's never seen, while people walk by outside. Ultra packs Amazon-style soft pouches in an actual e-commerce warehouse, running the full workday - same video starts bright outside and ends after sunset. Both built their autonomy on top of Pi's model. Weve reportedly got to a deployable laundry-folding system in two weeks.

What makes this the Cambrian explosion moment. Vang is careful academically but personally confident: he believes thousands of vertical robotics companies are about to exist, one for every workflow that currently has a labor shortage. The reason this is credible and not just vibes is that the startup recipe no longer requires a 20-year robotics PhD. It requires someone scrappy who can do system integration, understand a specific customer workflow, and collect data for that workflow. These are operator skills, not ML-researcher skills. Pi's role in this is not to win every vertical. It's to be the intelligence layer that lets a thousand other companies start. Their success is defined as their model performing useful work on somebody else's robot, in a warehouse they've never seen, for a customer they don't know.

The broader pattern. Every major technology wave gets unbundled at some point. Compute unbundled from hardware into the cloud. Payments unbundled from banks into Stripe. Distribution unbundled from publishers into the app stores. When the intelligence layer of robotics unbundles - and Pi has pretty much just made that happen - the sector moves from a capital-intensive, vertically-integrated, enterprise-only business into something that looks a lot more like the normal startup economy. If you've been waiting for the right moment to build something in the world of atoms, this is the setup Vang is handing you. The hard part is no longer the robotics. The hard part is the workflow, the customer, and the discipline to get to economic break-even before you scale.

Source: The GPT Moment for Robotics is Here - Lightcone, Y Combinator

Your Job Is Not Your Task

Jensen Huang told a story at Stanford last week that should be required listening for anyone planning their career or running a company through the AI transition. It's about radiologists, and it's the cleanest mental model I've heard for thinking about which jobs AI eliminates and which it doesn't.

Ten years ago, one of the most influential computer scientists of his generation - and one of the actual founders of modern AI - told the world that radiology was the worst career a young doctor could pick. AI was about to read scans better than humans within a decade. He was completely right. AI now permeates every aspect of radiology. Almost every scan is assisted by AI. The volume of scans being read has gone through the roof.

The number of radiologists also went up. Not down. Up.

Huang's framing for why is the line worth tattooing on the inside of every founder's eyelid: the purpose of your job and the tasks that you do in your job are related, but they are not the same thing.

The radiologist's task is to read scans. That got automated. The radiologist's purpose is to diagnose disease, work with patients, and partner with doctors. That demand only grew - more patients can be admitted, more conditions caught, more revenue per department, so hospitals hire more radiologists. The flywheel only collapses if the people who confused the task with the purpose start steering young doctors away from the field. Which is exactly what happened. There is now a shortage of radiologists in the United States, caused largely by the warning that the field would die.

This same trap is being set right now in software, design, marketing, sales, and law.

Huang volunteered the second example on himself. "What I do for a living is typing and talking. Both have been automated to superhuman level by AI. And I'm busier than ever." His engineers tell the same story. NVIDIA's coders all use agentic AI. The good ones - the ones being promoted and poached - are the ones who are best at working with the agents. The bottleneck used to be writing the code. Now the bottleneck is having the next idea, because the agents have already finished what you asked them to do and they're "perpetually harassing you in text" asking what's next.

Then Huang says something that explains why the productivity gain doesn't compress headcount the way most pundits assume. Pundits assume NVIDIA needs to ship a fixed amount of code per year - say a billion lines - and if AI lets a thousand engineers do what ten thousand used to, then nine thousand are out. But that's not how it works. A billion lines of code was the most they could do with that many people in that much time. The cap was always human bandwidth, not ambition. Huang wants to write a trillion lines of code. He'd hire more people to write a trillion lines, not fewer to write a billion.

This is the practical version of the same point: task automation doesn't shrink the org if the org's purpose is bottlenecked by ambition rather than by hours. The companies that contract are the ones whose purpose really was just to do the task at fixed throughput. The companies that grow are the ones whose ambition was always being constrained by the throughput, and now isn't.

The single quote founders should put above their desk:
"It is unlikely that most people will lose a job to AI. It is most likely that most people will lose their job to somebody who uses AI."

Two practical reads of that:

1. If you're hiring, the test isn't "have they used AI?" It's "are they faster than the humans who don't?" Treat AI fluency the way you treated Excel fluency in 2002 or English fluency in 1995 - non-negotiable for anyone in a role where the agents are now reachable.

2. If you're working, separate your task from your purpose. Then ruthlessly delegate the task to the agents and reinvest the saved hours into the purpose. The radiologist who learned to use AI now reads more scans, catches more disease, and is the most valuable hire in the department. The radiologist who refused is being told the job is being restructured.

Congressman Ro Khanna's contribution at the same panel sat alongside this and is worth taking seriously: the productivity gains will not be evenly distributed unless someone makes them so. Past industrial revolutions ended with more jobs but spent twenty miserable years getting there. Workers' bargaining position during the adoption phase determines whether the gains end up only with capital. That's a policy question, but it's also a culture-of-the-company question for any founder reading this.

The radiologist parable doesn't close the gap.

Source: U.S. Leadership in AI with Jensen Huang and Congressman Ro Khanna - Stanford GSB

When Latency Becomes Oxygen

Will Bodis runs Phoneley, a voice AI company that just raised a $16M Series A from Bessemer. The company handles millions of calls a month across hundreds of verticals, and 80% of the people on the other end don't know they're talking to a machine. By the end of this year, Bodis predicts that number will be close to 100%.

The interesting part isn't that voice AI works now. It's where Bodis says the bottleneck has moved.

For two years - back when "voice AI" wasn't even a phrase - latency was the thing everyone obsessed over. Phoneley was an early customer of Groq's fast-inference chips precisely because of it. Today Bodis calls latency "oxygen": you need it, but nobody talks about it anymore because everyone has enough. Companies that can't deliver low latency just aren't in the conversation.

The new game is statistical optimization of outcomes. That's a different sentence than "build a chatbot that talks to your customers." Phoneley's pitch is that they don't just answer your phone - they continuously surface what's working and what isn't. He gives one concrete example from earlier in the week: a customer changed one question in their voice AI's script and outcomes improved 5%. Phoneley told them which question to change, and could prove the lift statistically.

That's the position Bodis is staking out, and it's worth attention because it generalizes far beyond voice. In any AI-driven product, the layer above the model is usually where the durable business is built.

Bodis started with small businesses - the pest control company, the pizza shop. Not because the economics were great, but because they gave him constant, frequent, brutal product feedback he couldn't have gotten chasing one enterprise deal that took a year to close. Four or five months of that compressed iteration, and his first call center customer paid more than every small business combined. Then he moved upmarket.

Most founders flip this order - they chase the enterprise logo first because the deal size is bigger, and end up shipping based on their own assumptions because they can't get enough at-bats. Bodis's discipline: find the customer who will tell you what's broken every week, even if they can't pay much, and use them as the iteration substrate for the customer who eventually can.

The investor side of the same lesson

Bessemer didn't come from a deck or a banker. Caroline from Bessemer reached out after a LinkedIn post Bodis had written about doing 300-mile ultra-endurance bike races. The post was about commitment and being a founder. The conversation grew from there. A few months later, Bessemer preemptively offered the round - Bodis didn't shop it. He picked the investor the same way he picks employees: would I want to hire this person? If yes, take the offer.

Closing thought

There's a temptation in AI right now to think that the only game is to build the model. Bodis's career so far is an argument for the opposite: the model is becoming a commodity, and the durable position is the thing built on top of the model that knows how to measure, optimize, and improve a specific outcome. Voice AI is barely past the "books on the internet" stage. The companies that figure out the optimization layer for each vertical will own a lot more value than the ones competing on whose voice sounds most human.

Source: This Startup Built AI That 80% of Callers Think Is Human - Phoneley founder Will Bodis

Set Goals That Break Your Brain

Jon McNeill spent years running Tesla under Elon Musk. Five other startups bracketed it on either side. He's now telling the story in a book called The Algorithm, and the cleanest piece of it is also the one most founders get wrong: the goal you set determines how you think.

He puts it simply. Set a 5-7% improvement goal and you'll get 3-5%. Set a 100% goal and you have to reorganize how you think about the problem - because no amount of optimization within the current frame can get you there. Order-of-magnitude goals - 10x, 100x - force a different brain.

The example he gives is the moment Elon walked over and told him to 20x Tesla's digital sales. At the time Tesla had a 64-click checkout flow. McNeill's instinct, like most operators, was to start optimizing the 64. Elon pulled out a Domino's app and counted 10 thumb taps to buy a pizza. That's the new target.

Twenty-x meant the entire build-to-order religion at Tesla had to die. The company offered 360,000 possible car configurations. The data, when McNeill's team actually ran it, showed customers were buying two - call them Standard and Performance. So they killed the 360,000-option menu. Manufacturing simplified. Engineering simplified. The supply chain simplified. The clicks collapsed. None of that is reachable from a 7% goal. All of it is forced by a 20x goal.

This is the part founders flinch at. We pick incremental targets because they feel responsible. McNeill's argument is that incremental targets are the least responsible thing you can do - they lock you into the current architecture and waste a year tweaking it.

But the goal alone doesn't find the answer. Walking the floor does.

The second pillar of his algorithm is the part most founders skip entirely. Before McNeill formally joined Tesla, Elon asked him to look at the topline problem. Promised the street 12,000 cars; sold 3,000. McNeill didn't open dashboards. He went and mystery-shopped eight Tesla stores, used different email addresses for each test drive, and waited.

Zero callbacks. He called the head of sales ops and asked how many test drives in the past 30 days hadn't been called back. The answer was 9,000. That's the quarter. He shipped a fix in two hours - block all new leads to any salesperson who hadn't called their previous test drives back - and called Elon to confess he'd just made a CEO-level decision in a company he didn't yet work for. Elon paused for a long, uncomfortable minute, then said you'll fit in here just fine.

McNeill calls this the most powerful analytics tool a leader has: two eyes and two ears. Sit in the warehouse for eight hours. Stand on the factory line where the inventory is piling up. Watch a real customer try to buy something on your site and feel the friction yourself. He tells the Falcon Wing door story - Elon dragged him to the production line, they stood and watched workers thread bolts blind, and within ten minutes they could see the fix was a jig. No data could have told them that as fast as their eyes did.

The bank executives he met recently illustrated the inverse. He asked the room to raise their hand if they'd used their own bank's consumer app in the last week. No hands. He told them: I've used two of your apps; they're terrible; if you used them you wouldn't survive another day. The dashboards never told them. They never went and looked.

Combine the two.

The shape of McNeill's algorithm, stripped down, is two-step:

1. Set a goal so large that the existing frame can't reach it. The goal is the forcing function on your thinking.
2. Find the answer by going to where the work happens - store floor, warehouse, customer's screen - not by sitting in the dashboard.

Most founders do the opposite. They set incremental goals and analyze them from a distance. The result is a year of well-executed motion that doesn't move anything.

The other rule worth stealing from his career: hire salespeople from the company with the bad product, not the great one. Anyone closing inbound at Apple is an order taker. The salesperson at the Microsoft store two doors down - still beating quota with the worse offering - is the one who can actually sell. The same logic that finds 9,000 ignored test drives applies here: don't be impressed by the surface; find the friction that made the work real.

Source: Ex-Tesla President Reveals Everything Elon Does to Win - My First Million

The One Decision That Cost InVideo a Year

In January 2025, Sanket Shah and his co-founder were sitting in San Francisco, talking through a fork they both already knew the answer to. Their insight - the one that had taken InVideo from $10M to $70M in revenue - was expiring. The market was shifting under them. The honest move was to drop the existing strategy and bet the company on the next insight. They didn't take it.

Twelve months later, on the Z47 Moments podcast, Sanket called that single non-decision the most important thing that happened to InVideo all year. Not the shipping pace. Not the marketing spend. Not the AI roadmap. The decision they didn't make.

That story sits inside a worldview about how companies actually grow that's worth taking seriously - especially right now, when AI is collapsing and re-creating product-market fit on a six-month clock.

Insights, not optimizations.

Sanket's frame is simple: every business has a single load-bearing insight. The product, the architecture, the culture, the people you hire - all of it organizes around that insight. Without one, you don't have a company; you have a feature competing on price.

He distinguishes insight depth. L1 insights are surface-level - "creator economy" was his - and they get you to maybe $10M. To break through, you need an L3 insight that's actually hard to copy. For InVideo, the L3 insight that drove the $10M-to-$70M run was video editing, not just generation. Specific, not generic.

The corollary is the part most founders flinch from: optimization cannot break a ceiling. If your business has hit one, no amount of A/B testing the funnel or shaving CAC is going to move you. Only a drastic re-orientation around a new insight can. And drastic, by definition, means the existing status quo gets blown up.

Insights expire.

This is the part that should keep AI founders awake. Sanket's view of product-market fit is that it's a spectrum, not a binary, and the score moves on you. A 9-out-of-10 PMF today can be a 6-out-of-10 in six months because someone else found the next insight while you were still defending the current one.

In an AI market where new capabilities open up every quarter, a new entrant has a structural advantage: they're building from what's possible today, while incumbents are stuck inside an architecture and a worldview optimized for last year's possible. That's why the January meeting mattered. They could see the expiry coming. They chose to keep shipping inside the old frame instead.

How to read customers without being lied to.

Most of the conversation founders have with customers is wishful theater - leading questions, hypothetical futures, customers offering solutions back. Sanket's discipline is brutal:

• Only ask about the past. What do they actually do today? Never "would you" or "what if."
• Never accept their solution. The solution is the founder's job; the problem is the customer's.
• The framework is from The Mom Test - and he treats it less as advice and more as a hard rule.

This is how he separates signal from noise. Speculation, including the customer's own speculation, is noise. Behavior in the past is signal. Everything else gets filtered out.

When the bet isn't working, stop watching it.

This was the most counterintuitive operating principle in the conversation. When momentum dies, most founders stare harder at the dashboards - refreshing retention, revenue, signups, hoping for a turn. Sanket does the opposite. He stops looking entirely. Two to four people get assigned to keep the current business running. He goes all-in on the next bet.

He paired this with a cash discipline most founders don't have the stomach for: when his views-to-signup ratio drops below his bar, he kills marketing. Not throttles - kills. The cash he conserves becomes the runway for the next bet. "I have one more bet in me. If this one doesn't work, I have one more. I have to make one of them work."

The takeaway.

The pattern is a loop, not a ladder. Find an insight. Build the company around it. Ride it until it expires - and it will expire. Recognize the expiry early. Take the painful pivot before the ceiling becomes a floor. Conserve enough cash to survive the gap. Repeat.

The cost of getting this wrong is rarely a crash. It's a year of hard, well-executed, perfectly-shipped work that didn't matter. Which is exactly what Sanket says happened to InVideo last year - and why he's telling the story now.

Source: The Insight of Differentiation: Sanket Shah's InVideo Journey - Z47 Moments

The Information Mover Is Dead. The Builder Just Got the Keys.

There are more open product manager roles globally right now than there have been in three years. The last time the number was this high was peak COVID. So why is half of your LinkedIn feed full of laid-off PMs?

Because the job split in two and nobody told the loser.

Nikhyl Singhal — ex-Meta, ex-Google, ex-Credit Karma CPO, and the guy who runs the Skip community of 125 sitting heads of product — calls this a "complete renaissance for the product industry." But it's a renaissance with strings. The strings are: if you built your career as an information mover, you are the dinosaur. If you built it as a builder, you just got handed a vault.

Here is the bet he's making out loud: in the next twelve to twenty-four months, large companies will shed thirty thousand and rehire eight thousand. The eight thousand will be AI-first. The thirty thousand will be the people whose entire job was to take a deck from one boss, reframe it for the next boss, run the standup, write the status report, manage the backlog, and drive “alignment” through theatrics. That entire job description has been quietly automated. Nobody put up a sign.

The split. About half the product industry got into product because they liked moving information through organizations. The other half got into it because they liked making things. The first group is being shed. The second group is having the time of their lives — they have more offers than they've ever had, comp is at all-time highs, and the wall between PM, founder, CEO, and even non-product C-suite roles is dissolving. Singhal has fourteen sitting founders inside his community of 125 today. Twelve months ago there was one. He recently watched a senior member interview for a Chief HR Officer job because the company decided they wanted a product builder running HR.

That last detail is the real signal. Forward-leaning companies have started believing the obsolescence skill — the instinct to look at any manual workflow and write software around it — is more valuable than the function it's being applied to. The function is easier to learn than the skill.

The shadow superpower. Here is the cruel part. The people who are best at the old game are the slowest to adopt the new one. Their entire identity says what I do is working. Their employer agrees. Their bonus agrees. So they don't reinvent. Meanwhile the weaker performer — the one who was already struggling — has nothing to defend, opens Claude Code on a Saturday, ships something silly, catches the bug, and a year later is the most valuable person on the floor.

The block isn't intelligence. It isn't even taste. It's time. The mid-career person in their thirties — the one with the most leverage on paper — is in their power years for everyone else too. Aging parents. Small kids. A spouse. The first body aches. A career that demands constant relearning at exactly the moment when no one has a free hour. Singhal's framing for what your daily prioritization actually is: “I am going to equally disappoint everyone.” That is the honest math. And on top of that math, the industry is now asking you to spend your nights “feeding the LLM.” That is why the most predictable casualty of this era is going to be the diversity progress of the last five years. The Bay Area pace tax falls hardest on whoever already has the least slack.

What the new job actually looks like. Less moving information. More judgment. Judgment meaning: when ten ideas can be tested for the cost it used to take to test one, somebody has to decide which of them deserve to ship — what's good for the brand, the system, the long-run product. That somebody used to be in a meeting. They are now in their IDE.

The PMs Singhal sees thriving have one thing in common: they obsoleted a part of their own job. They built a chief-of-staff app. They wrote an agent that does the matching their community needs. They replaced their status reports with software. They got rid of the meetings they hated by automating the work the meetings were supposed to coordinate. That single moment — the first thing they ship that makes them go wait, this works — is the conversion event. Joy is the antidote to burnout, and most product work has been joyless for a decade. Building is joyful. Once a PM crosses that line, the energy comes back, the time appears, and the rest is mechanical.

Three things that are about to be true.

One: brand on your resume is depreciating fast. Six years at a name-brand company that builds the old way is now a liability in the room. Nobody asks “where did you ship?” They ask “what tools, what judgment, what would you build right now?” If your answer is a 2021 answer, you don't get the job.

Two: this is not a thirty-year treadmill. Singhal is firm on this. The next two years are chaos because every operating system of building software is being rewritten in real time. After that, things settle. There will be a new normal. There will be training programs and predictable tracks again. The activation energy is now. The merry-go-round does not spin forever.

Three: PMs are about to invade every other industry that runs on legacy software — which is most of them. The HVAC company a private-equity firm just bought. The school district. The mid-market manufacturer. They are all going to need someone who can walk in, look at how things are done, and obsolete the manual parts with software. The supply of those people right now is roughly equal to the population of the Skip community plus a few thousand others. Demand is the entire economy.

The one decision. If you love building, stay current — relentlessly, even at the cost of every other comfort, for two years. If you don't love building, be honest with yourself early enough to do something about it. The middle path — wait and see, hope it stabilizes, lean on the brand on your resume — is the path that gets shed in the round of thirty thousand.

Smiling exhaustion is the new floor. Exhausted-but-not-smiling is what comes next if you don't move.

Source: Nikhyl Singhal on Lenny’s Podcast — Why half of product managers are in trouble

Token Anxiety

Gym membership you never used. Buffet plate you couldn't finish. Data that rolled over and died.

Now add: tokens you didn't spend.

Token anxiety is subscription guilt's newest dialect — the nagging sense that every unused prompt is cognition you were entitled to and forfeited. You open Claude at 11pm not because you need anything, but because you haven't queried enough today.

The psychology is old. We've always confused access with use, and use with value. What's new is what's being metered. Not calories. Not bandwidth. Thinking itself. And once thinking is priced, not-thinking starts to feel wasteful.

The irony writes itself: the person who uses AI best is the one who doesn't feel compelled to use it at all. They pick their spots. They ask the one question only they need answered. They let the meter idle without flinching.

Token anxiety is the tell of someone who has mistaken the tool for the output.

The Only Game Worth Finding

Ask yourself two questions.

What kind of game do I love playing?

What kind of game can I play all my life?

Find where those two answers overlap. That's it. That's the whole thing.

Because here's what happens when you find it.

You show up every day. Not because you should. Because you want to. The work doesn't feel like work. The hours don't feel like hours. You're not waiting for the weekend or the exit or the retirement.

And while you're busy enjoying it, something quiet happens in the background. Time compounds. Skill compounds. Reputation compounds. Relationships compound.

Ten years in, the rewards aren't big. They're incalculable.

Most people miss this because they split the question in two. They pick a game that pays, and hope they'll learn to love it. Or they pick a game they love, and hope it'll pay. Both fail. One burns you out. The other starves you out.

The trick is refusing the split. Keep looking until you find the overlap.

And when you find it, the reward isn't what waits at the end.

The reward is every single moment of the path.

Two Kinds of Judgment. Most People Can't Tell Them Apart.

Every decision you make is either becoming a rule — or it needs you present every single time.

There is no middle ground.

---

Fossilized judgment is stable. You've made this call enough times that the answer is predictable. Encode it. Systematize it. Automate it. Let it run without you.

Live judgment is still moving. The context shifts. The stakes are high. New information changes the answer.

Encode this — and you don't get automation. You get a confident, consistent, wrong machine.

---

The Trap

Most people fossilize too early.

They take a judgment that was working because someone sharp was making it fresh each time — and they write the playbook. Build the process. Ship the agent.

For a while it looks like scale. What it actually is: yesterday's thinking, running at tomorrow's speed.

---

The Filter

Two questions. That's it.

1. Is the underlying truth still moving?
2. What happens when the answer is confidently wrong?

Stable truth + survivable error = fossilize it.
Everything else = stay live.

---

This Isn't New

Great managers already do this. They push routine calls down and hold the contextual ones close.

The law does it. Statutes are fossilized judgment. Judicial discretion is live.

AI just removed the friction that used to slow you down. Building an agent now takes an afternoon. That's extraordinary leverage — and leverage doesn't care whether you encoded something smart or something stupid.

---

The One Thing

Sort your judgments before you automate them.

Fossilize the stable ones. Revisit them on a schedule — the world moves, and yesterday's rule becomes tomorrow's liability.

Stay live on everything else.

The judgment you can never automate is the one about what to automate.

---

Get that one wrong and you don't scale your business. You scale your blind spots.

SOPs Are the Ceiling

If you can SOP it, you can automate it. If you can automate it, you can hand it to an agent. Spin up thirty specialized agents, run them in parallel — suddenly one person runs an organization.

True. Also incomplete.

The bottleneck migrates

With one human doing five things sequentially, the sequencing is implicit. They just know what's next. With five agents running in parallel, something has to decide what each one consumes, where outputs land, how conflicts resolve, and what gets escalated back to a human.

The work doesn't disappear. It moves. From doing to orchestrating.

That's where the real IP sits in an agent-heavy system. Anyone can stand up agents. Very few can orchestrate them well.

The SOP is the ceiling

A vague SOP makes a vague agent. A sharp SOP makes a sharp one.

The specialization isn't in the agent. It's in the crispness of the SOP it's running.

Most "our AI agent didn't work" stories — when you dig — aren't agent problems. They're SOP problems. The team never had a real SOP. They had a vibe. They handed the vibe to the agent. The agent returned a vibe. Everyone called it an AI failure.

Before you build an agent, write the SOP as if a new hire on their first day had to follow it. If you can't write that document, you don't have a process. You have a habit.

Not everything SOP-able should be agent-ified

Build cost + maintenance cost + debugging cost has to beat just doing it.

For high-volume repetitive work, this is obvious. For low-frequency judgment calls, the agent is a tax. You'll spend more time maintaining it than you'd have spent doing the task.

Two questions before you build anything:

• How often does this run?
• How stable is the underlying judgment?

Fossilized vs. live judgment

Every judgment in your business falls into one of two buckets.

Fossilized judgment is stable. The world has stopped moving around it. You've made this call a hundred times and the answer rarely surprises you. Safe to encode. This is what agents are for.

Live judgment is still moving. The inputs shift, context matters, the stakes of being wrong are high. Encoding this is dangerous — you freeze a decision that needed to stay dynamic, and the system quietly rots.

The mistake is treating these as the same. Founders either refuse to fossilize anything (stay trapped as the bottleneck) or fossilize everything (ship a system that's confidently wrong six months later).

The real unlock

The unlock isn't "build lots of agents."

It's figuring out which judgments have stabilized enough to fossilize, SOPing those ruthlessly, and keeping yourself in the live-judgment loop for everything else.

The meta-layer — orchestration above all the agents — is how you stay in that loop without touching every decision. It surfaces the live stuff to you. Handles the fossilized stuff without asking.

Automating judgment is the point. Automating the wrong judgment is how you scale your blind spots instead of your business.

Pick what you fossilize carefully. That choice is the one thing that can't be delegated.

 If you can SOP it, you can automate it. If you can automate it, you can hand it to an agent. Spin up thirty specialized agents, run them in parallel — suddenly one person runs an organization.

True. Also incomplete.

The bottleneck migrates

Now my job is to get things done .. i don't need to do it personally now

 Now my job is to get things done .. i don't need to do it personally now