The impact of AI on startups is no longer just about helping engineers write code faster, automating customer service workflows, or adding a Copilot to existing products. YC partner Diana recently pointed out that the real change is that AI is rewriting how “a company should be built from scratch.” For early founders, AI shouldn’t merely be an efficiency tool that a company uses occasionally; it should be designed from day one to be the operating system of the entire organization.
The productivity perspective is outdated—AI is rewriting a company’s starting point
Diana believes that when the market talks about AI today, it still too often stays within the framework of “increasing productivity,” such as engineers writing code faster, teams automating more processes, and companies launching more features. But this view actually underestimates the structural changes AI brings. She notes that with the right pairing of AI tools, it’s now possible to build functionality that used to require an entire team to accomplish—and even develop products that were previously impossible to deliver.
So the real question founders should ask isn’t “which company workflows can we add AI to,” but rather: “If we were building a company from zero today, which tasks should never have been handled through layers of human effort?”
This is the core of what’s known as an AI-native company. Diana says AI shouldn’t be placed outside company workflows like a plug-in to boost efficiency for certain departments; instead, every workflow, every decision, and every important action in the company should flow through an intelligent layer that continuously learns and improves.
In other words, future startups won’t be built by first creating org charts, departments, meeting processes, and management systems, and only then introducing AI. Instead, from the very first day of its founding, the company will be designed as a system that AI can understand, query, analyze, and improve itself.
Step one: Turn the entire company into an intelligent hub that AI can query
Within this framework, the first step in building a company is to make the whole organization “queryable.” In traditional companies, information is often scattered across meetings, DMs, emails, documents, CRM systems, GitHub, customer service systems, and managers’ heads.
That turns the company into an open-loop system: founders make decisions, teams execute tasks, but whether the outcomes are effective, where the problems are, and how to adjust next—usually relies on manual reporting and managerial interpretation. Diana believes this model naturally causes information to leak and also slows the company down.
An AI-native company must switch to a closed-loop system. Every meeting, every ticket, every customer feedback, every product decision, every sales call, and every round of engineering delivery should generate records that AI can read and feed back into the company’s intelligence layer.
Diana recommends that startups record important meetings, use AI note-taking tools, reduce information hidden in DMs and email, and embed Agents into Slack, Linear, GitHub, Notion, Google Docs, customer support tools, sales calls, and operational data. What the company truly needs to build isn’t a pile of disconnected tools, but an intelligent hub that can answer in real time, “What is actually happening in the company right now?”
A real-world example from engineering management: cut Sprint time in half, achieve nearly 10x output
She uses engineering management as an example. If an Agent can read Linear tickets, Slack engineering channels, GitHub, customer emails, customer service tools like Pylon, high-level plans in Notion or Google Docs, sales call records, and daily standup logs, then it’s not just summarizing meeting notes. It can analyze exactly what was delivered in the previous Sprint, whether the delivery outcomes truly met customer needs, and which features may have been completed but didn’t produce the expected effects.
Once this information can be connected together by AI, the Agent can further propose the next Sprint plan—making engineering planning more accurate, more predictable, and more aligned with market needs. This means that when a startup is built from scratch, it shouldn’t first copy the engineering management practices of big companies. In the past, engineering leaders had to spend a lot of time collecting status, organizing progress, and reporting upward—because internal information wasn’t transparent, so humans had to constantly move and interpret it.
But if a company designs all key workflows to be queryable from the beginning, many traditional middle-management tasks would lose their necessity. Diana points out that she has already seen similar approaches in multiple YC companies; some teams therefore cut Sprint time in half and, in the same time period, achieved nearly 10x output.
Step two: Redefine who writes code using an AI software factory
The second step is to rebuild the product development process with an AI software factory. Diana believes that an AI-native company shouldn’t just treat AI as a code assistant sitting next to engineers; it should redefine “who is responsible for writing code.”
In a new product development model, humans mainly write specifications and tests and define success criteria. AI Agents, meanwhile, are responsible for producing implementations, writing code, iterating through repeated testing and fixes until the result meets the specifications. The human role becomes defining the problem, judging outcomes, and calibrating direction—not personally completing every line of code.
This model can be understood as the next stage of test-driven development. In the past, TDD had humans write tests first, and then humans write code that passes the tests. In an AI software factory, humans write specifications and test frameworks, enabling the Agent to generate code and iterate on its own.
Diana mentions that some companies have already pushed this approach to the extreme—there is almost no manually handwritten code in their codebase. Instead, implementation is driven by specifications, tests, and scenario validation completed by AI. This is also the true meaning of “10x/1000x engineers”: it’s not that one engineer suddenly becomes 1,000 times more hardworking than others. Rather, it’s that an engineer has an entire Agent system behind them that enables them to accomplish work that previously required an entire team.
Step three: Redesign the first batch of employees—keep only three types of people
Therefore, if you want to build a company from scratch with AI, the founder must rethink the definition of the first batch of employees. Diana cites Block founder Jack Dorsey’s view, saying that if a company simply adds AI tools to its existing org chart while keeping the old management hierarchy and information flow paths, it will miss the real transformation.
In the future, companies shouldn’t build large amounts of “human intermediaries,” letting information be passed layer by layer among managers, coordinators, and project managers. Instead, the company should be designed as an intelligence layer where AI handles information integration and flow, while humans stand at the edge to make judgments, create, decide, and take responsibility for outcomes. In such a company, employee roles become fewer and clearer.
The first type is individual contributors—builder-operators. Not only engineers, but operations, customer support, and sales should also be able to use AI to prototype, build workflows, or create automation systems.
The second type is a DRI (directly responsible individual). This isn’t a traditional manager; it’s a person who is directly responsible for a specific result—one person corresponds to one outcome, and they can’t hide behind processes or departments.
The third type is the AI founder type, meaning the founder themselves must be on the front line using AI—demonstrating what it looks like when capability is amplified, rather than handing the AI strategy to some “AI owner” to manage.
Founders should maximize token usage, not headcount
This also points to the most counterintuitive aspect of AI-native companies: in the future, what founders may need to maximize is not employee count, but token usage. Diana believes startups should be willing to shoulder an API bill that’s uncomfortably high, because these expenses replace more costly, bloated labor costs in the past. A person skilled at using AI tools may be able to complete what used to require an entire engineering, design, or operations team in the pre-AI era.
Therefore, when building a company from zero, founders shouldn’t treat “rapid hiring for headcount expansion” as a growth symbol. Instead, they should ask: which jobs can be handled through Agents, closed-loop processes, and software factories rather than hiring another person?
This is especially critical for early-stage startups because small companies have no historical baggage. Big companies that need to transition to AI-native will have to maintain existing products while dismantling SOPs, management systems, internal politics, and old tech stacks accumulated over years. Every process change may break systems that were still working.
Early-stage startups have no such constraints. They can design meetings, engineering, customer support, sales, recruiting, operations, and product development to all be AI-readable, queryable, and capable of feedback from day one. Diana believes this is a major advantage startups have over large enterprises.
The future startup threshold: being able to reinvent a company with AI
Therefore, the answer to “how to build a company from scratch with AI” isn’t stuffing ChatGPT, Claude, Cursor, Devin, or various Agent tools into existing workflows. It’s the opposite: redesign the company itself.
Founders should first build a queryable organization, turning all important information into context that AI can read. Then build closed-loop workflows so decisions, execution, and outcomes continuously feed back. Next, use specification and test-driven product development so Agents handle large amounts of implementation. Finally, assemble the team using fewer but stronger builder-operators, DRIs, and AI founder types.
Diana’s view points to a more radical conclusion: an AI-era startup won’t be just “the same company, but more efficient.” A truly AI-native company will be different across everything—from organization, workflows, and product development to role division and cost structure.
It’s not about using AI to make the company run a bit faster; it’s about designing the company from the start as an intelligent system that learns, gives feedback, and improves itself. For founders, this may be the most important startup threshold in the coming years: not whether you can use AI, but whether you can use AI to reinvent the company itself.
This article, shared by a YC partner on how to build a company from scratch with AI, suggests startups should treat AI as an operating system rather than a tool. First appeared on Chain News ABMedia.
