ExpertsFMThe Fastest Path To Super Intelligence
Y Combinator Startup Podcast · February 27, 2026
5 Selected Lessons:
heuristic · 2 framework · 1 reasoning_pattern · 1 priority · 1
Two distinct capability axes a harness can target: reasoning vs. knowledge extraction
Source
Y Combinator Startup Podcast — The Fastest Path To Super Intelligence (February 27, 2026) · at 13:19 ▸
When this applies
when a general-purpose capability-improving tool needs to demonstrate and prioritize which distinct sub-capabilities it improves
The takeaway
When positioning a general tool, choose benchmarks that each isolate a distinct capability, and show success on each separately to prove breadth rather than narrow optimization to one test.
Why it works
ARC-AGI primarily tests abstract reasoning while Humanities Last Exam tests deep domain knowledge recall/application; succeeding on both separately demonstrates the tool generalizes across different capability types rather than being narrowly specialized.
One level up
Credibility for a general-purpose claim requires demonstrating success across qualitatively different tasks, not just one.
Where it stops holding
This stops working when the two capabilities are not actually separable in practice, or when a benchmark doesn't cleanly isolate the capability it claims to test.
Detail
hierarchy:
- Improving reasoning (demonstrated via ARC-AGI)
- Improving deep knowledge extraction (demonstrated via Humanities Last Exam)
rationale: Showing strength on both benchmarks signals the system's optimization approach generalizes across reasoning-heavy and knowledge-heavy problem types, not just one niche.
In their words
And we view the Arc AGI results and the Humanities Last Exam results as showing kind of two different capabilities that we have. We can really improve your reasoning and we can really improve deep knowledge extraction from these models.
Stilts, not competition: building harnesses on top of frontier models instead of fine-tuning
Source
Y Combinator Startup Podcast — The Fastest Path To Super Intelligence (February 27, 2026) · at 0:00 ▸ · at 3:06 ▸ · at 13:19 ▸
When this applies
when a smaller player depends on a fast-improving upstream platform/input they can't control, and wants a durable edge rather than a one-time fine-tune
The takeaway
Build your differentiation as a layer that composes with your supplier's improvements, not as a fixed asset that depends on the supplier's current state.
Why it works
A harness (code, prompts, reasoning strategies) sits on top of whichever underlying model is available, so when the upstream model improves, the harness automatically inherits the gain instead of being made obsolete by it.
One level up
True defensibility comes from aligning your value-add with the direction your ecosystem is moving, not from freezing a snapshot of it.
Where it stops holding
This stops working when the underlying platform's interface/behavior changes in ways the harness can't adapt to automatically, or when the gap between harness and raw model closes because the base model itself solves the task well enough.
Detail
procedure:
- Treat the frontier model as a foundation layer you build 'stilts' on top of, not a competitor to be beaten at its own game.
- Build a harness (code + prompts + reasoning strategies) around the model rather than retraining/fine-tuning the model itself.
- When a new frontier model is released, the same harness becomes compatible with it, inheriting the improvement without additional engineering.
- Continue optimizing the harness for whichever model you choose, capturing further gains cheaply.
benchmarks: {"cost":"Poetic's optimization for Humanities Last Exam cost under six figures (~$100K) vs hundreds of millions for training a new frontier model from scratch."}
rationale: Fine-tuning on top of a specific model gets obsoleted the moment a better base model ships; a harness avoids this because it isn't tied to one model's weights.
In their words
With Poetic, what we end up giving you is a, you know, people are calling these things harnesses now, but, you know, or an agentic system or whatever you want to call it that sits on top of one or more language models. And it just performs better than them. And when the new model comes out, that same harness is perfectly compatible with it.
Automating emergent founder behavior (manual model-routing becomes systematic optimization)
Source
Y Combinator Startup Podcast — The Fastest Path To Super Intelligence (February 27, 2026) · at 7:55 ▸
When this applies
when skilled practitioners have developed ad hoc heuristics for allocating work across tools/people based on experience, and those heuristics could be formalized
The takeaway
When experts develop informal rules of thumb for routing work to the best-suited resource, there is an opportunity to formalize and automate that routing at a scale and precision humans can't sustain.
Why it works
Good founders already discover empirically which model/tool suits which subtask; systematizing this via automated search/optimization removes the need for a human to rediscover and manually maintain these rules, and can find better allocations than intuition alone.
One level up
The next leverage point after human expertise is often systematizing that expertise into an automated process.
Where it stops holding
This stops working when the routing decision requires judgment/context that isn't yet captured by any dataset or measurable signal the automated system can learn from.
Detail
approach: Identify the informal heuristic experts already use for allocating tasks across resources, then build a system that performs this allocation automatically and continuously, informed by actual performance data rather than intuition.
signals:
- Experts developing ad hoc rules ('hard bugs go to model X, architecture goes to model Y')
- Presence of a measurable task-to-resource performance gap
- A repeatable optimization loop available to search over the allocation space
rationale: Automated, data-driven allocation can be more precise and scalable than a human's intuitive routing, and frees the human from maintaining it manually.
In their words
I think a lot of founders that get very good results for agents, they treat the underlying model as a common layer that you can switch in between. And there's a certain task, for example, for GPT 5.2, like very hard to verify bugs get sent to that versus architecture that gets sent to clot 4.6, but you're kind of doing this automatically instead of having a human conducting is very impressive.
Just try things with AI, don't limit yourself
Source
Y Combinator Startup Podcast — The Fastest Path To Super Intelligence (February 27, 2026) · at 0:00 ▸
When this applies
when evaluating whether a new fast-moving technology could solve your problem, before assuming it can't
The takeaway
When a technology's capability is compounding rapidly, default to hands-on experimentation over a priori judgment of its limits.
Why it works
Because the capability frontier moves so fast, personal assumptions about what's possible become stale within months, so direct experimentation reveals capability faster than reasoning about it in the abstract.
One level up
In fast-moving domains, action generates better information than analysis.
Where it stops holding
This stops working when the technology's capability is stable or slow-moving, where upfront analysis is cheaper and more reliable than trial and error.
Detail
rule: Every day, try to do something with AI on whatever you're building, without limiting yourself based on past assumptions.
threshold: Re-test assumptions every few months since capability shifts meaningfully in that time (host cites 8 months as 'an age ago').
rationale: The frontier moves so fast that what was hard a year ago may now be trivial.
In their words
Last summer, I took a weekend and used GPT-5 to help me build an iPhone app. I hadn't done that in a decade. And yeah, it's so fast and so easy. And that was an age ago. That was like eight months ago.
Let the AI understand the data, don't manually curate it
Source
Y Combinator Startup Podcast — The Fastest Path To Super Intelligence (February 27, 2026) · at 10:27 ▸
When this applies
when deciding whether a human expert should manually inspect and correct the inputs to an automated system, versus letting the system learn to interpret its own inputs
The takeaway
When an automated system's job depends on understanding the data, resist the urge to manually override its data interpretation even when outputs look surprising or imperfect, because the system may be working for different, valid reasons.
Why it works
If the optimization system can itself discover failure modes and effective strategies from the data, human intervention to 'clean up' outputs may remove signal the system is using productively, even if a human wouldn't have produced that output themselves.
One level up
Trust process-level automation over spot manual correction when the automation's outputs are measurably effective, even if their form is unintuitive.
Where it stops holding
This stops working when the system's outputs are demonstrably wrong in ways that hurt measured performance, not just ones that merely look unusual to a human reviewer.
Detail
rule: If the automated meta-system produces something unexpected or even technically 'wrong' in the output, but the overall system performance is strong, leave it as-is rather than manually editing it.
threshold: Applies when the system's measured end performance validates the approach, even amid individually odd artifacts (e.g., one wrong example left unchanged).
rationale: Historically ML required deep human understanding of the dataset; the new approach outsources dataset understanding to the AI itself, including discovering failure modes and robust reasoning strategies.
In their words
And one of the examples is actually wrong. But we didn't change it. We're like, well, this is, you know, this is the thing that it output. We'll just leave it be. You know, we don't want to go in and monkey around with things.