AI-native companies are built from loops, not prompts

The September 6 episode of Lenny's Podcast asks what an AI-native company looks like when models can run repeatable work. Anish Acharya, a General Partner at Andreessen Horowitz who focuses on consumer investing, joins Lenny Rachitsky after working as a founder and product operator at companies including SocialDeck, Google, Snowball, and Credit Karma. 1

Acharya's answer is a company made from nested feedback loops. An agent handles a bounded task, a function combines many such tasks, and the output of one function becomes an input to the next loop. The model can improve work that has a clear finish line. Humans still choose the finish lines that matter, handle exceptions, and decide when the company should pursue a different opportunity.

The conversation begins with a familiar software loop because software already has a series of observable checkpoints. A bug report arrives. A reproduction is generated. An agent proposes a fix. The fix is reviewed. A human confirms high-risk changes before production, while a low-risk change can move through the release process more quickly. A customer can then receive a message that the bug has been fixed. 1

The value of this arrangement comes from the feedback, rather than from the word "agent." Each stage supplies a check for the next stage. The team can ask whether the reproduction matches the report, whether the patch passes tests, and whether the change is safe to ship. A model has a useful role when the work produces evidence that another step can inspect.

Acharya extends the same pattern beyond engineering. Marketing, sales, support, and legal can each build loops that turn an input into an observable result. At the company level, the output of those functional loops becomes another loop for a business leader to optimize. The shift changes the question from "Where can we add a chatbot?" to "Which part of this function can move from an input to a measured impact?" 1

The growth example makes the measurement requirement more precise. A team can generate several variants, measure each one, converge on a winner after reaching statistical significance, keep a long-term holdout, and begin the next experiment. The loop can improve conversion inside the current experiment. The team still has to decide which customer problem deserves the next experiment. 1

The episode's most important boundary appears when the speakers discuss local maxima. A measurable loop can climb toward the best result available inside the assumptions built into the loop. After the loop reaches a plateau, more iterations produce a better version of the same idea. A person has to recognize that the current hill is no longer the right hill and point the team toward a new one. 1

Acharya connects that boundary to strategy and exceptions. He expects humans to remain especially important in sales, support, strategy, and cases that fall outside the data or rules available to an agent. The model can respond to a known pattern. A human has to notice when the situation calls for a new pattern, a new product, or a change to the business model. 1

A used-car marketplace example gives the division of labor a practical shape. Acharya describes Kavak using an agent for each customer. When an agent gets stuck, it calls a human. The human coaches the agent through the missing knowledge or data, and the interaction becomes a trace that can improve later work. The human intervention therefore serves two purposes: it resolves the current exception and adds material for the next version of the loop. 1

That model changes how a team should inspect failure. When an agent makes a mistake, the useful question is what the human knew that the agent lacked. The answer may be a missing document, an unstated rule, a customer preference, or a judgment about which outcome matters. The team can then decide whether to add context, improve the evaluation, or keep the decision with a person.

Acharya's model-selection argument follows the same logic. Work with a bounded outcome and a reliable check can use an efficient model when the cheaper model reaches the required quality. Work with large upside or difficult judgment may justify a frontier model because a small improvement can create much more value. The right comparison is the extra model cost against the value of the result, rather than a permanent preference for the most powerful model. 1

The distinction also explains why model access alone may produce weak defenses. Many companies can call similar models. A company gains more from knowing which work to automate, which work to measure, and which work needs a person to select the next direction. A product that turns those judgments into a fast learning loop can create an advantage even when its underlying model is widely available.

The speakers return several times to product judgment. Acharya argues that people still need to say, "Here is the thing we should make," and be right about it. He also suggests that product managers should ship something every week because direct contact with the result builds intuition. A small personal example makes the point: he used Codex to assemble a Mother's Day slide deck from messages and photographs, treating the model as a way to turn a clear intention into a finished artifact. 1

The operational lesson is simple. Start with work that has a visible input, a measurable output, and a clear approval boundary. Build the loop around that work. Record where people intervene. Use those interventions to improve context and evaluation. Then ask whether the loop has reached a local maximum and whether a human should choose the next hill.

That sequence captures the episode's central claim. AI-native companies will contain more automated loops, yet the people who define the objective, recognize the exception, and choose the next product direction remain part of the operating system. The advantage comes from connecting those human decisions to fast, observable feedback rather than removing them from the process.