The Playbook For Building An AI Native Company

AI isn't just making teams more productive. It's changing how companies should be built. In this episode of Startup School, YC Partner Diana Hu explains what it means to build an AI-native company, where AI isn't just a tool but the operating system your company runs on. She breaks down how to make your company queryable so agents can improve across every function, why management hierarchies break down when an intelligence layer replaces human middleware, and why early-stage founders have a massive edge in building this way from day one.

• 0:09Speaker 00

  Hi, I'm Diana and I'm a partner at YC. Over the past few months, it's become clear to me that AI is not just going to change how quickly software gets built or what workflows get automated. It's going to fundamentally change the way startups should be run, from what roles will exist to what products are possible to build. In this episode, I'm going to discuss how founders should think about building an AI-native company, what roles their team should have, and what concrete internal practices they can adopt right now to move much faster. Currently, most people talk about AI in terms of productivity. They'll talk at length about how it can make engineers more productive, or say we need to add Copilot to existing workflows and ship more features.

• 0:52Speaker 00

  This framing misses the shift we're currently seeing, which is less about productivity boots than entirely in new capabilities. The right person with AI tools can now build features that used to require an entire team or were just impossible. Thinking about AI in terms of new capabilities has several implications for how founders should run their companies. At a high level, the way to think about AI is that it should not be a tool your company just uses. It should be the operating system your company runs on. Every workflow, every decision, and every process should flow through an intelligent layer that is constantly learning and improving. What this means concretely is every important process

• 1:37Speaker 00

  in your company should be captured by an intelligent closed loop. A closed loop captures information, feeds it back into an intelligent system, and improves the process over time. If you've ever studied controlled systems, you'll be familiar with the difference between an open loop and a closed-loop system. Open loops are controlled systems without feedback loops. In the old world, companies basically ran as open loops. You made a decision, executed it, and didn't always systematically measure the outcome and adjust the process. Open loops are inherently lossy. A closed loop, on the other hand, is self-regulating.

• 2:13Speaker 00

  It continuously monitors its output and adjusts its process to better meet the stated goal. Closed loops are extremely powerful for correctness and stability. With self-improving agents, your company should run as a closed loop. To build these closed loops, you will need to make your entire company queryable. In other words, the whole organization should be legible to AI. Every important action should produce an artifact that the intelligence at the center of the company can learn from and use to self-improve. This means recording your meetings with an AI note taker, minimizing DMs and emails, and embedding agents throughout communication of all channels. It also means building custom dashboards with everything in the company: revenue, sales,

• 2:57Speaker 00

  engineering, hiring, ops, everything. Here's a concrete example of how it could work. Take engineering, management, and sprint planning. If you have an agent that has access to your Lender tickets, all your Slack engineering channels, all customer feedback from emails or tools like Pylant and GitHub, high-level plans in a Notion or Google Doc, sales calls and recordings from daily stand-ups, then the agent can analyze what was actually shipped in your previous sprint and how well they met customers' needs for real. From there, you can go a step further. With full visibility into what shipped, what worked, and what didn't, agents can start looking ahead. They can propose sprint plans for engineers that are way more predictable and accurate and on track.

• 3:42Speaker 00

  The days of edge manager status rollups that are super lossy are gone. Having managed engineering teams myself, and now seeing this across multiple YC companies, this is a game changer. What used to require constant coordination becomes legible and queryable by default. I've seen teams that do this cut their engineering sprint time in half and get close to 10x. More than in that time. The overarching principle here is that to get their full capabilities, you need to provide models with as much context as you would provide an employee. When you do this, your company stops operating as an open loop, where information is fragmented and manually interpreted. It becomes instead a closed-loop system.

• 4:27Speaker 00

  Status, decisions, and outcomes are continuously captured and fed back into this intelligence layer. The result is a system that always has an up-to-date view of what's actually happening. There's also a new paradigm emerging for how the highest-velocity companies build product: AI software factories. If you're familiar with the Test-Driven Development, or TDD, this is the next evolution of that. With software factories, humans write a spec and a set of tests that define success. And then AI agents generate the implementation, encode, and iterate until the test passes. The human defines what to build and judges the output.

• 5:12Speaker 00

  The actual code is the agent's job. Some companies have already pushed this to the point where their replays contain no handwritten code, just specs and test harnesses. Strong DM's AI team is an example of how to do this. Their end goal was a system that essentially eliminated the need for a human to write or review code. And so, they built their own software factory where specs and scenario-based validations drive agents to write, test, and iterate on code until it meets a probabilistic satisfaction threshold. And it works. This is how you achieve the 1,000x engineer that Steve Yeegar talks about, by surrounding a single engineer

• 5:56Speaker 00

  with a system of agents that enable them to build things they would have never been able to build before. The era of the 1,000 or even 10,000x engineer is here. One implication of building your company this way, with AI loops everywhere, a queryable organization, and software factories, is that the classic management hierarchy no longer makes sense. In the old world, you needed middle managers and coordinators to route information inefficiently up and down an organization.

• 6:27Speaker 00

  In the new world, the intelligence layer serves that purpose. If your company is queryable, artifact-rich, and legible to an AI, you should have almost no human middleware. This matters because your company's velocities is only as fast as its information flow. Every layer of human routing you can remove is a direct speed gain. A great example is what Jack Dorsey is doing over at Block. After going deep on the tools, he's come to the same conclusion many have. This is about more than just incremental productivity gains. His view is that if you keep the same org chart and management structure, you've missed the shift entirely.

• 7:11Speaker 00

  The company itself has to be rebuilt as an intelligence layer, with humans at the edge guiding it rather than routing information through it. Going forward, Jack suggests every company will have three employee archetypes. The first is the individual contributor, or IC. Basically, the builder operator. This is someone who directly makes and runs things. In an AI-native company, this is not limited to engineers. Everyone builds: eng, ops, support, sales. Everyone comes to meetings with working prototypes, not pitch decks. Second is the DRI, the Directly Responsible Individual. Focus on strategy and customer outcomes. This is not a classic manager. It's the person with a clear responsibility for the result.

• 7:56Speaker 00

  One person, one outcome, no hiding. The third is the AI founder type. This person still builds, still coaches, and leads by example. If you're the founder, this needs to be you at the forefront, showing your team what massive capability gains look like, not allocating your AI strategy to someone else. With this structure, companies will be able to get outsized results with much smaller teams. Maximizing token usage, not headcount, will be the critical shift. The best companies will be the ones that are token-maxing. Think of the trade-off this way. One person with AI tools can be the equivalent of what used to take a large engineering team at a pre-AI company.

• 8:40Speaker 00

  That means dramatically leaner engineering, design, HR, and admin teams. And so you should be willing to run an uncomfortably high API bill because it's replacing what would have taken a far more expensive uninflated headcount. But... Don't just take my word for any of this. You cannot outsource your conviction on the power of these tools. You need to develop it yourself by actually sitting with coding agents and using them until you start to break your own priors about what is now possible to build. If you are an early-stage founder, you have a huge advantage in getting ahead on this. You don't have legacy systems, entrenched org charts, or thousands of people to retrain.

• 9:22Speaker 00

  You are small enough to build your company right from day one. The opposite is the case for existing companies. They have to maintain and grow a live product while unwinding years of standard operating procedures and core assumptions about how software gets built. Some companies can achieve this by spinning up small internal skunk work teams that can build AI-native systems from scratch, separate from the core business. Mutiny is a great example of this. But for most, every change to their core processes risks breaking something that already works. So by their nature, these large companies will have a much harder time going AI-native. Startups don't have that constraint, and that's a major edge to take advantage of.

• 10:07Speaker 00

  You can design your systems, workflows, and culture around AI from the start, and as a result, operate thousand times faster than the incumbents.