How To Build A Company With AI From The Ground Up

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

it 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.

This framing misses the shift we're currently seeing

which is less about productivity boost 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 intelligent 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 control 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.

It continuously monitors its output

and adjust 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, 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 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 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.

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 an 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.

And then AI agents generate the implementation

and code and iterate until the test 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 the repos contain no

hand-written code,

just specs and test harnesses.

Strong DM's EI 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 a 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 1000 X engineer

that Steve Yegge talked 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 1000 or even 10,000 X 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 velocity 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'd miss the shift entirely.

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,

is 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 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.

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 and inflated 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.

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 skunkworks 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.