How To Build A Company With AI From The Ground Up

1. 0:00 – 0:58

   Intro

   1. DHDiana Hu0:00

      [upbeat music] 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 copilots to existing workflows and ship more features. This framing misses the shift we're currently seeing, which is less about productivity

2. 0:58 – 1:57

   AI as your company’s operating system

   1. DHDiana Hu0:58

      boosts than entirely 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 in your company should be captured by an intelligent closed loop. A closed loop captures information, feeds it back into an intelligence systems, and improves the process over time. If you've ever studied control 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

3. 1:57 – 3:00

   Open vs closed loop companies

   1. DHDiana Hu1:57

      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. 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 a AI notetaker, 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, engineering, hiring, ops, everything.

4. 3:00 – 5:00

   Making your company fully queryable

   1. DHDiana Hu3:00

      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 linear tickets, all your Slack engineering channels, all customer feedback from emails or tools like Pylon and GitHub, high-level plans in a Notion or Google Doc, sales calls, and recordings from daily standups, 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. The days of eng manager status roll-ups 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 done 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 a open loop, where information is fragmented and manually interpreted. It becomes instead a closed loop system. 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,

5. 5:00 – 7:12

   The rise of the 1,000x engineer

   1. DHDiana Hu5:00

      and then AI agents generate the implementation and code and iterate until the tests pass. The human defines what to build and judges the output. The actual code is the agent's job. Some companies have already pushed this to the point where their repos contain no handwritten code, just specs and test harnesses. StrongDM'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 tests and iterate and code until it meets a probabilistic satisfaction threshold, and it works. This is how you achieve the 1,000x engineer that Steve Yegge talks about, by surrounding a single engineer 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. 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. The

6. 7:12 – 9:12

   Why middle management disappears

   1. DHDiana Hu7:12

      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, focused on strategy and customer outcomes. This is not a classic manager. It's the person with a clear responsibility for the result. 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 delegating 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 head count, 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. 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've taken a far more expensive and inflated head count. 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

7. 9:12 – 10:26

   Startups will win this shift

   1. DHDiana Hu9:12

      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. 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 skunkwork 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 risk 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. You can design your systems, workflows, and culture around AI from the start, and as a result, operate 1,000 times faster than the incumbents. [upbeat music]

Episode duration: 10:27