Tutorial2026-05-20

How to Build a Self-Evolving Company With AI: Lessons From Y Combinator's Latest Lectures

In two recent lectures, YC partners Tom Blomfield and Diana Hu laid out a provocative thesis: the real promise of AI isn't making existing companies faster — it's making them self-improving. Here's what every founder needs to understand about building an AI-native organization from the ground up.

1. Traditional Companies Are Roman Legions

Tom Blomfield opens with an analogy: companies are structured like Roman legions. When the empire needed to project power from Rome to distant territories, hierarchical organization was essential. Who reports to whom, how orders are transmitted, how information flows — each layer had a clearly defined scope of control.

At the center of this structure was not creativity. It was information routing.

Most companies today work the same way. Founders make decisions. Executives break those decisions into goals. Middle managers coordinate. Frontline teams execute. Information is aggregated from the bottom up; orders flow from the top down.

The role of many middle managers isn't to create something new — it's to serve as human routers. The phrasing sounds unflattering, but it's accurate. They collect, compress, translate, and relay information. Meetings, weekly reports, status syncs, OKR check-ins, project management — all of it exists to serve this routing function.

Before AI, this was rational. As a company grows, it becomes impossible for any founder to personally track every piece of customer feedback, every engineering update, every sales lead, and every operational anomaly. Hierarchy becomes necessary.

But Tom argues that AI is breaking this premise.

If the information inside a company can itself be read, understood, searched, summarized, and recalled by AI, then companies no longer need this many human nodes just to shuttle information around.

This isn't an efficiency problem.

It's an organizational design problem.

2. "Copilot" Is the Wrong Mental Model

Over the past year, most people have framed AI as a "Copilot." It's an easy-to-accept metaphor, but a potentially misleading one.

Give engineers an AI assistant that makes them 20% faster at writing code. Give customer support reps an AI assistant that speeds up response drafting. Give salespeople an AI assistant that auto-generates emails. This is all valuable, of course. But Diana and Tom argue that focusing only on this is like watching a steam engine make horse carriages go faster and missing the arrival of the railroad.

Diana puts it bluntly:

AI doesn't bring productivity improvements. It brings capability improvements.

Productivity improvement means doing old work faster. Capability improvement means one person can now do what previously required an entire team.

The YC slides contain a deliberately provocative statement:

1 person with AI tools = 1000x Google engineer

This isn't a strict mathematical equation. It's expressing the view that a person equipped with AI tools and surrounded by agent systems can produce output comparable not just to an individual's previous capacity, but to that of a large team.

So the real question isn't "Can an engineer write more code?"

The real question is:

If one person can invoke many agents, and the company's entire knowledge base is readable by those agents, and software can be generated and regenerated on demand — does the company need to be organized the old way at all?

YC's answer is clear: No.

3. First Step: Make Your Company Readable by AI

The first step to achieving this isn't buying more tools. It's restructuring your information architecture.

Diana Hu uses the phrase "queryable company." Tom Blomfield uses "legible to AI." Both mean essentially the same thing: a company must be queryable, understandable, and callable by AI.

These sound like elegant phrases, but they represent a brutal standard.

Company knowledge is typically scattered across:

Tacit know-how inside founders' and employees' heads
Slack messages, WeChat Work conversations
Emails and direct messages
Notion, Google Docs, Linear, GitHub
Customer phone calls, sales recordings, support tickets
Product telemetry, churn data, user behavior logs
Meeting notes, standups, weekly reports

Taken together, these define "how this company works."

If they exist only in people's heads, AI can't use them. If they're scattered across private chats, AI still can't use them. If they're unstructured, unsummarized, and unindexed, AI still can't use them.

Tom delivers a harsh line:

If it's not recorded, it didn't happen — as far as your company's intelligence is concerned.

In an AI-native company, an important meeting that wasn't recorded is the same as one that never entered the company's brain. A customer need that stays locked in one person's DMs simply doesn't exist in the system.

That's why YC records its office hours, saves partner communications, and funnels Slack conversations, DMs, and customer interactions into its systems wherever possible.

This isn't about surveillance.

It's about giving the company a brain that can learn. And the company's brain is not a metaphor — it's fundamentally an information engineering problem.

4. Open-Loop Companies Lose Information; Closed-Loop Companies Evolve

Here we need to introduce a concept from cybernetics: open-loop vs. closed-loop systems.

An open-loop system has no feedback. You make a decision, execute it, and regardless of the outcome, it's never systematically measured, summarized, or fed back into the next round of action.

Many traditional companies are open-loop systems. Everyone decides something in a meeting, the project ships, and nobody systematically reviews what happened. When a customer churns, sales knows a little, customer support knows a little, product knows a little — but there's no system that integrates those fragments to improve the next decision.

The fatal flaw of an open-loop system is that it continuously leaks information.

A closed-loop system is different. It continuously monitors outputs, feeds results back into the system, and automatically adjusts. It doesn't just execute — it learns.

Diana states that an AI-native company must be closed-loop. Tom goes further: a company should not just be one closed loop, but a series of recursive, self-improving AI loops.

A complete AI loop consists of roughly five layers:

Layer 1: Sensor Layer. This perceives the external world. Customer emails, support tickets, code changes, churn events, product telemetry — all of it is sensor data.

Layer 2: Policy / Decision Layer. This automatically determines what actions are possible, who needs to be consulted, what should be logged, and which actions carry risk.

Layer 3: Tool Layer. These are deterministic tools that AI can invoke — querying databases, reading calendars, running tests, calling internal APIs, committing code.

Layer 4: Quality Gate. This includes evals, tests, security filtering, and human review of high-risk items.

Layer 5: Learning Mechanism. After the system interacts with the real world, it detects what went wrong and feeds that information back to the top of the loop.

When these five layers are operational, AI stops being a "helpful assistant" that makes tasks easier.

It becomes a mechanism that detects problems, patches the system, and improves the next round of performance.

This is self-evolution. It's not just AI helping humans — it's the company itself becoming a system that learns.

5. YC's Aha Moment: AI Starts Fixing Itself

Tom shared an internal example from YC that I think represents the logical highlight of the entire talk — and something every founder should take seriously.

Initially, YC built an agent that could query their internal database. You could ask, "When was our last office hour with this company?" and it would find the answer.

Later, it got smarter. If a company needed introductions in the petrochemicals sector, the agent could search the YC database, use RAG to find relevant founders, and suggest connections.

This was already impressive, but Tom said it was still a sidekick — boosting engineer efficiency by 20–30%. Still Copilot mode.

The real aha moment came when they placed a monitoring agent on top of this system.

This monitoring agent observed every query that YC staff submitted. Which ones succeeded? Which ones failed? When something failed, the monitoring agent asked why:

Was something missing from the knowledge base?
Was a deterministic tool needed?
Did the skills file need updating?
Did the database need a new view or index?

And then the critical thing happened.

The system wrote code overnight, submitted a merge request, had another agent review it, merged it, and deployed it.

The next day, when a staffer asked the same question — it worked.

Tom called this his "holy shit moment." This is where the paradigm truly shifted.

Because at this point, AI wasn't just making humans more powerful.

AI was making the system itself more powerful.

That's what "the company gets better while you sleep" actually means.

6. Product, Support, and Sales Can All Become Self-Optimizing Systems

This thinking isn't limited to internal queries.

Tom offered a product optimization example. An agent could continuously monitor product analytics, identify the highest-friction point in the sales funnel, research current best practices, propose an A/B test, run it for a week, select the more effective variant, and deploy it — then repeat the cycle.

Customer support works the same way. Customer suggestions flow in continuously, and an agent performs initial triage. A judgment layer — think of it as a "virtual CPO + CTO" — decides which suggestions don't fit the roadmap and should be discarded, versus which ones align and are implementable.

Once the judgment is approved, the system can write code overnight, deploy it, and notify the customer: "This issue has been resolved."

The critical distinction here is that this is fundamentally different from ordinary automation. In ordinary automation, a human defines the rules and a machine executes them. In a self-evolving system, the machine executes the task and simultaneously discovers that the rules are insufficient, the tools are incomplete, or the knowledge is lacking — then improves the next execution.

This isn't just a pipeline.

It's a cycle that learns.

7. Three Roles: Builder, DRI, and AI Founder

When a company becomes a set of AI loops, the number of people inside the organization shrinks, but the weight of each person's responsibility increases.

Fewer people isn't because the company doesn't need humans — it's because it doesn't need this many "message routers."

Diana outlined three roles that she believes define the future organization:

Builder-Operator. Not just engineers — everyone must be capable of directly building things and running the business. Sales, support, ops, and HR can't just write docs, attend meetings, and raise requirements. In the future, you don't bring a PowerPoint to the meeting. You bring a working prototype.

DRI (Directly Responsible Individual). Every important initiative needs a clearly named owner. Not a committee. Not "our team." One person, one outcome, nowhere to hide. AI can help you coordinate, execute, and analyze — but responsibility cannot be diluted.

AI Founder. This one matters most. Founders must not outsource their AI strategy. The founder personally needs to use agents, shatter their own old assumptions about what's possible, and demonstrate the leap in capability that AI enables. Company culture is not built through slide decks — it's built through how the founder works every day. If the founder is still using old methods, the company will never become truly AI-native.

8. Burn Tokens, Not Headcount

Tom shared a phrase worth printing and hanging on the wall:

Burn tokens, not headcount.

The trend YC is seeing: when these companies arrive at Demo Day, revenue per employee is roughly 5× what it was 18 months ago. Companies are becoming less constrained by headcount and more constrained by how much intelligence they're willing to consume.

Diana echoes this: in the future, companies won't compete on headcount — they'll compete on token usage. The best companies will maximize their token utilization.

This sounds counterintuitive. In the past, rapid growth meant hiring more people — more engineers, more designers, more sales, more support, more managers.

But the logic of an AI-native company may be fundamentally different. With the right people who can use AI and agent systems, one person can complete what previously required an entire team. So yes, you should be willing to foot the API bill — because it's a substitute for a more expensive, slower, bulkier human structure.

Of course, Tom warns that naively tracking total token stats can be easily gamed and isn't suitable as a promotion-or-firing metric.

But the directional thesis is correct. Right now, the most important thing isn't conserving tokens — it's figuring out what the new intelligence can do. At this stage, if nobody in your company is using tokens, you're not saving money. You're just not entering the new paradigm yet.

9. Software Is Disposable; Context Is Valuable

This might be the most underappreciated idea in the entire talk.

Tom notes that in the past, every function needed its own dashboard built out. Now, he believes companies need on-demand software. Modern coding agents are already powerful enough to handle many internal software needs in a single shot. Operations, sales, and event teams can generate temporary dashboards, workflows, and lightweight tools based on their understanding of the business.

But don't treat the software itself as the treasure. What's truly valuable is:

Data
Business context
Company know-how
Skills and decision principles
Process understanding

Software is just a shell built on top of this context. Today, a company can build and regenerate software on demand. In the future, it will be the context that regenerates the software.

Tom's conclusion:

Business context and skills are valuable. Software is ephemeral.

This statement is important. In the past, when a company accumulated assets, it was accumulating a codebase, SOPs, documentation, and processes. In the future, the more critical asset may be the context living in the company's brain — how to judge customer needs, run events, handle sales, navigate layoffs, and choose products.

Software can be continuously regenerated. Context cannot be lost.

10. The YC User Manual: A Living Company Brain

Tom described the YC user manual as a case study.

Most of YC's original user manuals were written 5–10 years ago and were already outdated. Recently, YC recorded roughly 2,000 hours of office hours, organized them by topic — fundraising, hiring, co-founder disputes — synthesized the insights, and produced a new manual.

Over a single weekend, they produced a 150-page manual that was clearly superior to the old version. And they can update it every month.

Every time a new piece of advice emerges, it's compared against the existing manual. If it's helpful, it's included. If not, it's discarded.

The user manual thus stops being a document. It becomes a living, self-improving brain.

This is a prototype of the company's brain. And it can serve as context for AI agents. When a founder asks a question, the answer doesn't come from a generic model's training data — it comes from the accumulated wisdom of 16 YC partners who have advised founders over years, distilled and made queryable.

There's only one prerequisite: it must be recorded, summarized, and made legible to AI.

11. Humans Don't Disappear — They Change Location

If the company becomes the company's brain, where do humans go?

Tom's answer: humans move to the edge.

Humans are positioned where the company's brain meets the real world. They're needed in new scenarios, ethical judgment calls, high-stakes moments, and high-emotion-density situations — like when a founder is deciding whether to split from a co-founder. AI can handle massive information processing and coordination, but it can't replace everything overnight.

This actually places a high demand on people. In the past, much of human value lay in knowing where information was, routing it to the right people, and coordinating. These values will depreciate rapidly.

Human value will shift closer to judgment, responsibility, trust, taste, real-world contact, and high-risk decision-making.

Humans aren't being removed. They're being relocated — from the center of the company's information pipeline to the edge of its intelligent system.

12. Why Startups Have the Advantage

This matters especially for startups.

Large companies will use AI too, but they carry three burdens: legacy systems, legacy processes, and legacy organizations. They need to maintain existing products while dismantling years of accumulated SOPs and overturning fundamental assumptions about how software is built and how teams collaborate.

Every time they move a core process, they risk breaking something that already works. That's why it's genuinely difficult for mature companies to become AI-native.

Startups are the opposite. No legacy systems. No bloated org charts. No need to retrain thousands of people. A small company can design its workflows, culture, and organizational structure around AI from day one.

This is the opportunity. If you're starting a company today, you don't need to build a traditional company first and then bolt AI onto it.

The first question you should ask is:

If the company itself were a set of self-improving AI loops, how would I design it today?

Conclusion: Stop Treating AI as a Tool

Synthesizing both YC lectures, the core thesis is this:

An AI-native company isn't the one that uses AI tools best — it's the one that transforms the company itself into a system that AI can read, query, feedback on, and self-improve.

Several implications follow:

Don't fixate on 20% efficiency gains. That's the Copilot mental model. What truly matters is capability — a single person gaining the abilities that previously belonged to an entire team.
Make the company legible to AI. If it's not recorded, it didn't happen. Meetings, tickets, customer feedback, sales calls, product data — all of it should become part of the company's brain.
Convert open loops to closed loops. A company shouldn't just decide and execute once. It should continuously sense, judge, execute, check, and learn.
Organizations will thin out. Middle managers will lose their value as message routers. Builder-operators, DRIs, and AI founders will become more important.
Burn tokens, not headcount. A hefty API bill may be healthier than a more expensive, slower, bulkier human structure.
Context is more valuable than software. Software can be regenerated. Context cannot be lost.
Founders must be personally involved. Don't delegate your AI strategy. Use agents yourself. Shatter your own old assumptions about what's possible. Demonstrate the leap.