This is my reading of Y Combinator's Spring 2026 Requests for Startups (RFS), first written in February 2026. The seven signals below are an interpretation of the directions discussed here, not a complete or current list of what YC funds.
For founders, the useful question is not just "Which idea should I build?" It is what these requests suggest about AI applications, selling outcomes, and the value of product judgment.
RFS is not a menu. It's a signal. Read the official RFS alongside this essay: YC explicitly says these requests cover only part of what it funds, and founders do not need to work on them to apply.
Signal 1: A Focused List Is a Signal, Not an Investment Boundary
The seven directions discussed in this essay give founders a focused set of problems to examine. But the length of an RFS list does not tell us how broadly YC invests.
My reading is that these requests draw attention to problems founders can work on now. That is an interpretation of the list, not evidence that YC has stopped backing other ideas or that a startup window is closing.
Signal 2: These Examples Point Toward Industry Applications
Look at the seven:
- Cursor for PM = AI + Product Management
- AI-Native Hedge Funds = AI + Finance
- AI-Native Agencies = AI + Services
- Stablecoin Financial Services = Crypto + Traditional Finance
- AI for Government = AI + Public Sector
- Modern Metal Mills = AI + Manufacturing
- AI Guidance for Physical Work = AI + Blue-Collar Labor
My reading of these examples is that founders should look closely at industry applications: take available models and solve a specific customer's problem. Stablecoin financial services also reminds us that the list is not uniformly about AI.
That is a reason to examine the application layer, not evidence that foundation models or infrastructure are finished. A useful analogy is the relationship between cloud services and applications built on them: new applications can grow while the infrastructure keeps developing.
Signal 3: "AI-Native Agency" Challenges SaaS-Only Thinking
This is the most interesting direction to me: what if a business used AI to deliver the finished outcome, rather than only selling software that helps the customer do the work?
My reading is that SaaS is not the only business model worth considering. At least not for every use case.
If AI materially lowers delivery costs while preserving quality, selling the outcome can become more attractive. Users may want the hole in the wall, not the hammer. The question is whether you can reliably deliver that hole at a price and cost that work.
An AI-Native Agency could give a service business more software-like economics. For a design firm, some work might shift from billable hours to API calls. Human review, revision, sales, and accountability still count in the margin calculation.
The implication for builders: stop thinking exclusively in SaaS subscriptions. Ask whether you can sell the outcome directly.
Signal 4: AI Guidance Brings Physical Work Into View
"AI Guidance for Physical Work" asks us to look beyond software and desk work.
For me, the interesting possibility is real-time assistance with physical tasks: cameras and voice interfaces could help a worker find the next step or recognize an exception.
Assistance is not the same as replacing an experienced tradesperson's judgment. Reliability, safety, and when a person must take over still have to be established in the actual job.
I read this as another direction founders can explore: augmenting physical work alongside knowledge work, rather than proof that the whole startup ecosystem has changed course.
Signal 5: "Cursor for PM" Raises the Value of Product Judgment
I read this direction as a question about what happens when tools such as Cursor, Claude Code, and Codex make implementation faster: deciding what code to write can become a more prominent bottleneck.
My inference is that, when AI helps a team implement faster, deciding what to build becomes more consequential. The bottleneck can move from execution toward judgment; it does not disappear from every team's engineering work.
The implication I take for builders is to invest in judgment alongside implementation: understand users, define problems, set priorities.
For product managers, this creates an opportunity to contribute more than forwarding requirements. It does not guarantee that every PM role becomes more valuable.
Signal 6: Hedge Funds Make Me Wonder About Exit Pressure
"AI-Native Hedge Funds" is a fascinating inclusion. It moves the question beyond selling a tool to what happens when AI helps do the underlying work.
My speculative reading is that interest in hedge funds might also reflect a search for larger financial outcomes when familiar startup exit paths feel harder. That is my hypothesis about possible exit pressure, not evidence of YC's targets or its investors' anxiety. The request does not tell us what returns a fund could earn.
For founders, the useful question is how value would be created and captured in this setting. The direction itself is not evidence that finance has no ceiling or that a trading strategy will work.
Signal 7: My Concern Is That Profitability Can Crowd Out Importance
The seven examples discussed here do not settle YC's climate priorities. Nor does "Modern Metal Mills" tell us, by its heading alone, whether a project has a climate benefit.
My critical reading is that attention to monetizable outcomes can crowd out attention to important problems whose payoff takes longer, including climate work. I worry that founders may read a prominent list as a preference for problems that are easier to validate, monetize, and exit.
That is a tentative interpretation and a criticism of the incentives such signals can create, not a finding that YC has abandoned climate work or adopted a "validate fast, exit fast" investment rule. Founders still have to judge the importance, economics, and time horizon of their own problem.
So What?
If you're a founder, here's how to actually read the RFS:
- Examine the application layer. Use available models to solve a specific customer's problem; do not infer that infrastructure opportunities have ended.
- SaaS is not the only answer. Consider the AI-Native Agency model — use AI for fulfillment, sell outcomes not tools.
- Watch where the bottleneck moves. Faster implementation can make requirements and judgment more consequential. Invest in your judgment.
- Explore assistance with physical work. Validate the workflow and the limits of the assistance before calling it a business.
- Treat the RFS as input to your judgment. It is neither a complete investment policy nor a substitute for customer evidence.
To me, the RFS reads as a set of hypotheses worth testing. Founders still have to do that testing themselves.
The RFS is not a map. It's YC's footprints on the riverbank. Following the footprints won't necessarily get you across. But you can read which direction the current flows.
Uncle J · 2026.02.03