ExpertsFMThe State of Startups in 2026
Y Combinator Startup Podcast · September 18, 2026
5 Selected Lessons:
reasoning_pattern · 3 heuristic · 1 framework · 1
Vertical fine-tuning of foundation robotics models for real-time reliability
Source
Y Combinator Startup Podcast — The State of Startups in 2026 (September 18, 2026) · at 26:17 ▸
When this applies
when adapting a general-purpose foundation model to a high-stakes, real-time, narrow-domain task
The takeaway
The more an application domain diverges from a foundation model's training distribution in dimensionality and latency requirements, the more essential custom fine-tuning becomes before deployment.
Why it works
Physical robotics tasks require real-time, low-latency responses to stimuli (unlike LLMs which can 'go and come back'), and operate in high-dimensional 3D space rather than language space, so general foundation models must be fine-tuned on custom, task-specific data to be reliable enough for deployment.
One level up
General-purpose intelligence provides a starting point, but domain-specific reliability requires domain-specific adaptation, especially where failure has real-world physical consequences.
Where it stops holding
This stops working when the task is low-stakes or tolerant of latency/errors, in which case the general foundation model may suffice out of the box.
Detail
procedure:
- Start with a general robotics foundation model (e.g., Pi) as a baseline.
- Collect thousands of hours of task-specific footage/data (e.g., putting things in boxes, data center cabling).
- Fine-tune the foundation model on that custom data for the specific vertical task.
- Validate real-time responsiveness given the task's physical risk tolerance.
benchmarks: {"example":"Ultra: thousands of hours of box-packing footage fine-tuned from the Pi model"}
rationale: Out-of-the-box general models aren't reliable enough for real-time, physically consequential vertical tasks without fine-tuning.
In their words
all the YC companies that are using physical intelligence as models to deploy robotics, They're all fine-tuning the Pi models. I don't think any of them are able to use the Pi models out of the box.
Design software for agent-customers, not just human customers
Source
Y Combinator Startup Podcast — The State of Startups in 2026 (September 18, 2026) · at 14:33 ▸
When this applies
when a new class of 'customer' (automated agents) starts consuming your product alongside or instead of humans
The takeaway
When a new type of user/consumer emerges for your category, re-optimize the product around what that new user needs, not just legacy human users.
Why it works
As agents increasingly use software more than humans do, products that agents can effectively use and that remain the required system continue to generate value, even if human usage patterns change.
One level up
Anticipate shifts in who/what actually 'uses' your product category and build for the emerging dominant user before it becomes obvious.
Where it stops holding
This stops working when agents don't actually end up operating independently at scale, or when human oversight requirements prevent agent-first design from mattering.
Detail
approach: Ask whether agents will be significant consumers of your software; if so, design the product so agents can use it effectively, since agent usage volume may exceed human usage.
signals:
- SaaS stocks recovering despite agent disruption narrative
- agents increasingly doing tasks inside existing software systems
rationale: If agents use software more than humans will, building for agent usability sustains and even grows demand.
In their words
if you think of agents as your customers and you make things that agents want, and your software is something that agents want to use, then that seems like the right type of software.
Proprietary interaction data as a model-improvement flywheel
Source
Y Combinator Startup Podcast — The State of Startups in 2026 (September 18, 2026) · at 26:17 ▸
When this applies
when a company has exclusive access to rich behavioral data about what 'works' and must decide whether to turn that data into a model-training advantage
The takeaway
Owning unique behavioral/outcome data creates a compounding advantage when that data is fed back into model training, widening the gap versus competitors without such access.
Why it works
Platforms with exclusive visibility into real usage/outcomes (who codes best, what content is engaging) can use that proprietary signal to train models that outperform generic competitors lacking that data.
One level up
Data exhaust from a product's usage is itself a strategic asset separate from the product's direct revenue — treat it as a second product line.
Where it stops holding
This stops working when the data isn't actually predictive of quality/outcomes, or when competitors can access equivalent signal through other means.
Detail
approach: Identify proprietary usage data that reveals ground-truth quality signals (e.g., who are the best coders, what content people actually watch); feed this data back into training the next-generation model to outperform competitors.
signals:
- platform has exclusive access to outcome/engagement data
- that data correlates with quality or success
- feasible pipeline to retrain models on it
rationale: This data-flywheel effect compounds a platform's advantage beyond its product usage alone.
In their words
If you happen to own TikTok, you happen to have all of the data on what people watch and click on and what's compelling. And you can use that to make much more compelling videos in Seed Dance.
Venture drifted from hard tech to SaaS for profitability, now swinging back
Source
Y Combinator Startup Podcast — The State of Startups in 2026 (September 18, 2026) · at 12:32 ▸ · at 14:33 ▸
When this applies
when an investment community abandons a historically core category because an easier, more profitable alternative emerged, then returns to it once conditions change
The takeaway
An industry's stated core competency can be temporarily abandoned for an easier adjacent opportunity, and will snap back quickly once the relative economics shift again.
Why it works
Venture was originally structured to fund capital-intensive hard tech, but drifted toward SaaS for a decade or two because SaaS was more profitable and easier to fund; a shift in relative attractiveness (SaaS stock dips, AI coding breakthroughs) rapidly reversed that drift.
One level up
Don't mistake a multi-decade drift away from an original competency as permanent — track the relative-profitability conditions that caused the drift, since reversing them can reverse the drift just as fast.
Where it stops holding
This stops working when the drift was caused by a structural rather than cyclical factor (e.g., permanent regulatory change), in which case reversal won't be as fast or complete.
Detail
approach: Notice the speed of the VC shift toward hard tech coinciding with SaaS stock dips and AI coding breakthroughs; conclude that this is a return to venture's historical roots rather than a brand-new phenomenon.
signals:
- VC enthusiasm pivot happening within a single batch cycle
- historical precedent of the industry's original focus
- coincidence with a triggering market event (SaaS stock dip, coding agent surge)
rationale: Rapid reversals suggest the prior drift was driven by relative profitability rather than permanent incapacity to fund hard tech.
In their words
venture was set up to fund hard tech, but it like drifted away from it for a decade or two because it was so profitable to just fund SaaS companies. And so it's cool to have it coming back to its roots.
Full end-to-end automation drives outsized revenue vs point solutions
Source
Y Combinator Startup Podcast — The State of Startups in 2026 (September 18, 2026) · at 0:00 ▸ · at 18:02 ▸
When this applies
when choosing between selling a tool that assists a task versus a product that fully completes the task/job
The takeaway
The more completely a product substitutes for the full outcome a customer wants (versus merely assisting), the higher the price and adoption speed it commands.
Why it works
Products that fully complete a job (not just assist) are perceived as more valuable because they replace labor cost entirely, so buyers pay significantly more and adopt faster than for tools requiring a human operator.
One level up
Value capture scales with how close a product gets to delivering the complete desired outcome rather than a partial input to it.
Where it stops holding
This stops working when full automation isn't yet reliable enough for the task's risk tolerance, or when customers specifically want to retain control/oversight of the process.
Detail
rule: Favor building products that complete the entire job/workflow end-to-end rather than point solutions that still require a human operator.
threshold: Batch share of full end-to-end companies went 10%→25%+; median batch MRR went $8K→$20K in the same shift.
rationale: Full automation is valued much higher than partial tools because it eliminates the need for the human labor the tool used to merely support.
In their words
The percentage of companies we accepted that do sort of full stack end-to-end work or a task has gone from just 10% to over 25% of the batch.