# The Loop Closes > Source: > Published: 2026-09-07 20:10:34+00:00 [Andrej Karpathy gave a great talk about LLMs](https://www.youtube.com/watch?v=LCEmiRjPEtQ) in 2025. He talks about three generations of software: code written manually by people (1.0), narrow machine learning (2.0), and code written by LLMs (3.0). He gives the example of working on Tesla autopilot. Initially the whole stack was software 1.0, written by humans. Then, machine learning was used to replace chunks of it – which looks like 2.0 eating its way into part of the old 1.0 code: And so LLMs come along. Increasingly they write better and more performant code than humans do, and 1.0 codebases around the world are being eaten away by this new generation of software: We can also think of ‘companies 1.0’. Organisational processes that are human-designed and run are increasingly being eaten up by agents which can perform faster and better than us, can be infinitely parallelised, and never need sleep. Take the software engineer on call: it used to be that an engineer would hold the pager (or an app on their phone) to be alerted about outages, service degradations, increased error rates, etc. At my organisation, errors get posted to Slack by Sentry, our error-monitoring tool. Claude then immediately picks them up, requesting information from Sentry, reading logs, running diagnostics, checking the health of our site. If it needs to, it’ll write a change request to fix the errant code. The only part of this that needs a human is clicking ‘merge’ – then our automated deployment pipelines kick in, the code goes live, and the error’s fixed. Or take a product request. Previously these were added to our ticketing system, manually triaged once a week, and then moved into the backlog of work for the week. Hopefully an engineer gets to it; if so, they implement it, deploy it, and let the requester know (often long after the initial request came in). Now, someone can request a product change in Slack. Claude picks it up, helps spec the change with the user, writes the code, and adds a ticket to the backlog. Again, the only job an engineer has is to click ‘merge’. The code gets deployed, Claude marks the ticket done, and lets the requester know. When code gets deployed to our staging site, an engineer would typically QA it, running the new code through its paces, making sure it works as intended, looks visually acceptable, etc. Now Claude can open a browser and click through a set of QA steps, adding a comment to the ticket indicating what QA it did. Because the models can see, it can check for visual regressions. [Because it has](https://henryaj.substack.com/p/ai-has-taste-now-too) *[taste](https://henryaj.substack.com/p/ai-has-taste-now-too)*, it can see if the design looks good. All the human does is hit deploy. These are still open loops. The tech team hasn’t yet made itself redundant. But our role is shrinking – the red in the diagram above is being eaten by the yellow, as more and more processes can be done by LLMs, with humans in the loop only as a final gate. Increasingly it looks like that can be removed as well. Our product deals with money, so I’m reluctant to outsource literally everything to agents. But given LLMs can now take a feature request, spec it, code it, test it, merge it, QA it, and deploy it, it’s not clear there’s really much left for a human to do. Sure, I keep myself busy by asking Claude to do stuff and then rubber-stamping its work. Occasionally you spot a bug that would’ve crept in without your oversight. But as the models get more powerful, they’re better at writing error-free code and reviewing their own work. This works upsettingly well; just by running LLM code reviewers with higher ‘effort’ (a parameter which tells the model to think longer in its responses) we’ve seen the number of defects and comments on change requests dropping to nearly zero. The last bug we introduced was a configuration error caused by me fat-fingering a form on a settings page. Perhaps the final frontier is product strategy, and running an organisation more broadly. LLMs are still not great at looking at a product and *telling you what’s missing*. What features *should* we have that we don’t? Claude can give you some good suggestions but lacks the context that a good product manager has developed from years interacting with their stakeholders and the wider market, knowing how their product fits into it. I suspect as we can funnel more and more context in – from documents, the company wiki, meeting minutes, old Jira tickets, a decade of email – the better it’ll be able to position itself in the same place as an expert manager and make calls as good as any human. A friend of mine says that his team mostly just has meetings now. It’s the final thing that humans are still good at – absorbing, parsing and sharing context with each other. Those meeting notes then get passed to an LLM and all of the usual outputs which we consider organisational intermediate goods – emails, tickets, product requirement docs, implementation plans, code – drop out of its thinking. And once *that* can be automated… we’ll have finally closed the loop. [Then what’s left to do but keep paying the bill?](https://henryaj.substack.com/p/living-at-the-hinge-of-history)