Why companies are becoming a series of loops | Anish Acharya (a16z)

Lenny opens with the meme he wants tested: that anyone who fails to stay on top of the latest AI tools will be sorted into a permanent underclass. He notes that some people treat it as a joke, that many take it seriously enough to be stressed by it, and asks how real the concern is.

Not very seriously, and it's a funny dark fantasy that we seem to have as Silicon Valley collectively.

Anish does not treat the fear as fringe. He says it runs from researchers at foundation-model labs to the Silicon Valley layman, and that it is framed as being pushed outside the light cone. His counter-claim is that things have never been better by almost every measure: how distributed the opportunities are, the technology available, the ambition people are permitted, and the number of companies independently working on things that are winning.

His empirical case has three parts. First, the previous era of tech was more centralized: network effects were the gold standard of the mobile era and are definitionally N-of-1 networks, whereas now each layer of the stack has something closer to twenty relevant players than two, and the coding-agent market that looked winner-take-all has Claude Code, Codex, Lovable, Replit and Wabi all working. Second, radiologists have been predicted to be displaced for roughly twenty years while job postings, programmers included, are higher than ever. Third, the technical story is not recursive self-improvement producing a runaway winner, but autocatalytic effects: using the technology to improve your own process, which is not truly recursive.

Lenny reframes the dispute as fast versus slow takeoff, observing that each milestone so far has been noticed, caught, observed and iterated on rather than arriving unannounced. Anish agrees, describing the fast-takeoff argument as everything up to now followed by an event nobody can quite articulate. He adds two brakes: the slow rate of economic diffusion, evidenced by his small hometown looking much the same when he returned, and the likelihood that most problems are not intelligence-bound at all — a data center of PhDs at FedEx or Domino's would not exponentially dominate supply chains or pizzas.

On ambition, he says the filter has inverted. Three years ago a firm would decline a company whose plan was too ambitious; today an idea that is too small is the thing not worth engaging with. He frames the technology as amplifying agency and separating skill from desire, so that it can drive both productivity and ambition.

Lenny asks whether a divide is opening between employees who embrace the tools and those who resent them. Anish rejects the abstractions underneath the question: the Dilbert-esque manager shuffling paper, consumers as low-agency NPCs, and the assumption that everyone else's job is automatable while ours is not. In his experience, once you get into the details, many people are eager for more leverage.

His evidence runs from sophisticated companies such as Google to Kavak, a used-car seller in Mexico, which runs a six-week academy teaching the whole company, mechanics included, to use the new tools, with each cohort shipping a cutting-edge agent into production by the end.

using AI versus reorganizing your entire company around AI

He argues that distinction is the big change, and reaches for the diffusion of electricity: forty years passed between its inception and the reorganization of factories, because that meant burning buildings down and starting over rather than swapping coal for electricity. The most ambitious companies are therefore rethinking everything around the models, while earlier or less ambitious ones focus on giving existing roles access to the technology.

Asked whether this should lower anxiety about careers, Anish reasons from executive incentives: Sundar running Google would rather build a forty-trillion-dollar company than run a more efficient four-trillion-dollar one, so a more productive unit is worth keeping. He offers an anecdote from an executive friend at Google who reported no layoffs; instead the team ripped through a two-year roadmap in three months, and the hardest problem became knowing what to add to it — which he calls every product manager's fantasy.

His prescription is a posture rather than a tool: ship things. He points to Claire Vo as the example — constantly shipping, trying things, unafraid of mild embarrassment, and seeming like the best version of herself. Lenny reads the thread as a reason to be less stressed about jobs and careers.

Anish concedes that the loops concept gets teased on X as over-intellectualized, and that graphs are the current meme for its next stage, then builds the steel man: prompts came first, then agents, which are models in a loop with tools, memory and skill files, then loops, which are sets of agents doing tasks.

Coding is his proof case because the best models meet the most technically adept customers and a set of established loops. A bug report arrives, a reproduction is generated, a fix is written and reviewed; high-risk changes get human confirmation before shipping, low-risk ones ship automatically, and the customer may be emailed within five minutes. Engineering contains many such loops, from bug fixes and customer feedback to sales demos and new feature development.

The question he wants answered is what the business loop is. A general manager oversees loops in coding, marketing, sales, support and legal, and the combined output of those loops is itself something to optimize. In its strong form the loop escalates a message to the CEO that a physical aspect of the business, the business model or the strategy has to change, producing a cascade from a loop per person to a loop per function, across business units, to loops running large parts of the company.

Growth is the worked example, drawing on Lenny's time on Airbnb's supply-growth team. That team brainstormed, prioritized, built, shipped and measured experiments; the loop version generates every variant, measures each one, converges and ships at statistical significance with a high enough p-value, keeps a long-term holdout, and moves to the next experiment.

Go-to-market shows the same shape. Lenny mentions a tweet claiming OpenAI's go-to-market team now uses Codex more than its engineering team. Anish's caricature — salespeople want the gym, steak dinners and the trophy for salesperson of the quarter — supports his claim that the loop distills the job down to the part people are best at and most interested in, with the surrounding administration handled for them.

A product-manager inversion follows: say yes to everything, build it, and simulate user reaction with tools such as Simile. Anish's less obvious reading is that many PMs who believe they are zero-to-one thinkers will discover they are not, and that working on someone else's good idea is more fulfilling than their own bad one. A second effect is that the winning idea no longer has to be the one that sells best to an executive, because ideas get tried and the best one wins.

The loop will help you climb to the local maxima, but then it plateaus

The consequence is structural, not cosmetic: reaching the next hill requires out-of-distribution thinking and human intuition, someone who can land the organization at the base of a different hill. Lenny restates this as an agent-to-human handoff on a chart, where agents climb and humans reframe, repeatedly.