ExpertsFMHow To Build The Future: Paul Graham & Amjad Masad
Y Combinator Startup Podcast · November 7, 2026
5 Selected Lessons:
case · 3 reasoning_pattern · 1 heuristic · 1
Grief cycle before acceptance of disruptive technology
Source
Y Combinator Startup Podcast — How To Build The Future: Paul Graham & Amjad Masad (November 7, 2026) · at 5:16 ▸ · at 7:59 ▸ · at 10:02 ▸
When this applies
when any practitioner confronts a technology that threatens to obsolete their core craft
The takeaway
Expect and plan for an emotional adjustment period (denial, depression, acceptance) when a technology threatens a deeply held professional identity, rather than assuming people will rationally adopt it immediately.
Why it works
Identity attachment to a craft creates emotional resistance (denial, depression) before someone can rationally re-orient toward the new reality (acceptance).
One level up
Technological disruption is processed emotionally before it's processed rationally; those who've already grieved move faster.
Where it stops holding
This stops working when the practitioner has little identity investment in the old craft, in which case adoption can be immediate without an emotional cycle.
Detail
approach: Recognize the grief cycle (denial, depression, acceptance) in yourself and others when disruptive tech threatens identity; having already gone through it earlier gives an adoption-speed advantage.
signals:
- visceral discomfort or offense at the new method
- statements like 'this isn't really programming'
- later resignation followed by active adoption
rationale: Masad says he grieved the loss of 'the craft' years earlier (circa 2020) which let him move to acceptance and build the tool, while Graham was still in the emotional reaction when shown the 2024 demo.
In their words
I think with AI, everyone will have to go through this period of, you know, denial and then, and then sort of later on, you know, depression and then, you know, eventually acceptance.
Infrastructure depth as a moat enterprises will pay for
Source
Y Combinator Startup Podcast — How To Build The Future: Paul Graham & Amjad Masad (November 7, 2026) · at 14:59 ▸
When this applies
when competing with lighter-weight entrants who replicate only your product's surface layer
The takeaway
When a market commoditizes the visible surface of your product, the deep, invisible infrastructure underneath it becomes your defensible moat — especially with buyers (like enterprises) that value reliability over speed/cost.
Why it works
Enterprises weight reliability/security heavily, and deep infrastructure (transactional file systems, sandboxing, systems-level engineering) is costly and slow to replicate, so it becomes a durable differentiator even if it makes the product slower or pricier.
One level up
Durable competitive advantage often lives in unglamorous, hard-to-copy depth rather than in the visible feature that attracted the market.
Where it stops holding
This stops working when your buyer segment doesn't value reliability/security enough to pay for the depth (e.g., pure consumer hobbyist market), in which case the lighter competitor wins on speed/cost/simplicity.
Detail
rule: Build the invisible infrastructure (custom file systems, provisioning, sandboxing) even when it makes the product slower/pricier, because enterprise buyers reward reliability.
threshold: n/a
rationale: Masad states this is literally why Replit wins enterprise deals versus newer competitors who only replicate the thin 'tell it in English' surface layer.
In their words
Yeah, so that is helping us win enterprise in our category because they are a lot more sensitive to reliability, security, all of that stuff. It's really hard to get consumers to care about security, for example.
Prior infrastructure investment becomes 'surreally' plug-and-play for a new product direction
Source
Y Combinator Startup Podcast — How To Build The Future: Paul Graham & Amjad Masad (November 7, 2026) · at 14:59 ▸ · at 18:01 ▸
When this applies
when evaluating whether past, seemingly unrelated infrastructure investments could unexpectedly enable a new strategic direction
The takeaway
Investments in general-purpose architecture (e.g., modeling flexible actors/users) can become unexpected unlocks for future pivots, because the new use case fits the existing abstraction rather than requiring new primitives.
Why it works
Because the collaborative system already modeled 'another user' joining a session, an AI agent could be inserted into that same abstraction with minimal new engineering, and the team's existing functional divisions (infra, deployment, IDE) mapped directly onto new agent-support roles.
One level up
Deep, general infrastructure built for one purpose often creates optionality for unforeseen future products — invest in good abstractions, not just the immediate feature.
Where it stops holding
This stops working when past infrastructure was built too narrowly/specifically for its original use case, in which case it won't generalize to the new direction without rework.
Detail
situation: Replit had built collaborative editing where multiple humans could work on the same project, plus a team structure split into infra, deployment, and IDE.
decision: When adding AI agents, they treated the agent as just another user in the existing collaborative system rather than building new primitives.
outcome: It was 'surreal how plug and play' it was — the agent slotted directly into existing collaborative infrastructure and team structure (later formalized with a dedicated agent team in the middle).
lesson: General-purpose abstractions (multi-user collaboration) built years earlier can directly enable a much later strategic pivot (AI agents) without redesign.
In their words
So when you put an agent into a REPL, as we call it. It's like you're collaborating with the agent. Yes. So the agent is another user.
Building robust custom tools to compensate for weak early-model capability
Source
Y Combinator Startup Podcast — How To Build The Future: Paul Graham & Amjad Masad (November 7, 2026) · at 18:01 ▸
When this applies
when a platform you build on top of has systematic weaknesses that undermine your product's core workflow
The takeaway
When your core dependency has a known, specific weakness, build dedicated tooling to detect and route around that exact failure mode rather than waiting for the dependency to improve.
Why it works
Building custom robust tooling (a dedicated edit tool, detection/looping for lazy outputs) compensated for specific, identifiable failure modes in the underlying models, which let the product work despite an immature base layer.
One level up
Early-mover advantage in an immature-technology market often comes from absorbing the technology's weaknesses with bespoke engineering, which becomes commoditized/unnecessary once the base technology matures.
Where it stops holding
This stops working once the underlying technology matures and natively solves the problem, making the custom tooling investment obsolete (as happened once native edit tools and shells sufficed).
Detail
situation: In 2024, editing code via LLMs was unreliable: models hallucinated line numbers and got 'lazy,' leaving placeholder comments instead of finishing functions.
decision: Replit built its own robust edit tool and detection/looping logic to catch and fix these specific failure modes rather than waiting for foundation models to fix them.
outcome: This let Replit ship a working (if imperfect, ~30-50% failure rate) agent product in beta in 2024, ahead of when native edit tools eventually appeared in the models themselves.
lesson: Bespoke engineering around a known immature-technology failure mode can enable an early product launch, even if that engineering later becomes unnecessary.
In their words
There's all of these different things that you had to make it ridiculously robust in the early days because the LLMs were so bad
One-hour product exposure flipped majority sentiment on AI job anxiety
Source
Y Combinator Startup Podcast — How To Build The Future: Paul Graham & Amjad Masad (November 7, 2026) · at 35:57 ▸
When this applies
when any population is anxious about a disruptive technology based on abstraction rather than direct hands-on experience
The takeaway
To change widespread anxiety about a disruptive technology, give people direct, short, hands-on experience of actively using it themselves rather than relying on messaging or reassurance.
Why it works
Direct hands-on experience with a tool that lets someone personally wield the disruptive technology converts fear (of being replaced by it) into optimism (of being empowered by it), because it shifts their mental model from 'victim of' to 'user of' the technology.
One level up
Abstract fear dissolves fastest through direct, embodied experience, not argument.
Where it stops holding
This stops working when the hands-on experience itself is poor/frustrating, which could reinforce rather than dissolve the anxiety, or when job displacement fears are concretely justified rather than merely perceptual.
Detail
situation: A large telecom company's employees were surveyed on AI anxiety before a Replit hackathon: 80% were anxious/worried about their jobs.
decision: Employees spent about one hour actually using Replit.
outcome: Post-survey flipped: roughly 80% became optimistic and 20% remained worried.
lesson: A short, direct hands-on experience with an empowering AI tool can rapidly reverse majority sentiment from anxiety to optimism.
In their words
And so pre-using Replit, just for like an hour, like 80% were anxious and were worried about their jobs or whatever. And after they used Replit, it flipped. Like 80% were optimistic and 20% were for one hour.