On September 17, Anton Osika posted a number about his own company that is worth more than most adoption surveys.
Osika
"Every department at Lovable now builds its own software. In April we had 11 internal apps our own teams had built on Lovable, by August it was more than 80. Lovable has a real internal software ecosystem now. The People team alone has built about 30 apps."
Eleven to eighty in four months is the headline. The last sentence is the part that should stop you, because it answers a question most AI plans never ask: who actually builds the software?
Why the department matters more than the number
Eighty internal apps is a growth number, and growth numbers are easy to wave away. The distribution is what changes how you plan.
The model most companies are running is hub and spoke. A central AI function builds things for other departments, demonstrates value, gets asked for more, and becomes the queue everything waits in. It works, and it has a hard ceiling: the central team's headcount. Every request is rationed against every other request, which means the work that gets done is the work with the loudest sponsor rather than the work with the best return.
Lovable's number describes what happens after that ceiling is removed. The function stopped being the builder and became the enabler. Rails, permissions, a platform, and the departments ship for themselves.
Ramp reached the same conclusion from a different direction. Cristina Cordova's description of how their agent work is governed: "a central team defines what agents can access and do, so functional teams can build their own automations safely on the same rails." Two companies, two stacks, one shape.
It is worth noticing what the central team's job becomes, because it is not smaller. Defining what agents can access, what they can change, who reviews what, and what happens when something breaks is harder than building the apps was. It is just leveraged differently. See Stop Hiring a Head of AI.
Why it was HR and not engineering
The counterintuitive part is the distribution, and the explanation is not that People teams are secretly technical.
It is that they had the longest untouched backlog. Engineering has always been able to build things for itself. Finance has a budget and buys software. The People function sits on a pile of processes that are too specific to buy, too small to justify a ticket, and too repetitive to keep doing by hand: onboarding checklists, interview scheduling, reference collection, policy lookups, equipment tracking, review cycles. Every one of those was a candidate for twenty years and none of them were ever worth a procurement cycle.
When the cost of an internal tool collapses to an afternoon, the department with the most unserved demand builds the most. That is the whole mechanism, and it predicts which team in your company will produce the number.
What actually gets replaced
Lovable's customer stories give the shape, and it is mostly not new software. It is software they were already renting.
eXp Realty reports saving over $2M a year by cancelling SaaS contracts, with 85% fewer support tickets. Scion Group retired more than $1M of contracts after building 100+ apps in under four months. Nursa retired 10 SaaS systems with 200+ employees building.
Those are the vendor's own customer stories and should be read as such. But the pattern is consistent and it is not "we built exciting new products." It is the long tail of departmental software that was never worth a procurement cycle and is now worth an afternoon, plus the seat licences that tail was being served by.
The surface question, answered by the person selling the surface
The obvious next thought is that if departments can generate apps, the app itself is on the way out and everything becomes a conversation with an agent. Osika, who has every commercial reason to say exactly that, says the opposite:
"For most actions, the app is the best interface because it's visual. For things like 'just do this,' tagging an agent is sometimes faster. I tag @Lovable in Slack to do things for me."
Two surfaces, split by verb. A visual app for work you look at and manipulate, an agent tag for imperative one-offs. That is the honest version of agent parity: the agent has to be able to do everything, but it should not be where you do everything. See What Is an Agent Operating System?
What to take, and what to leave
Take the shape. If your AI function is still the team that builds things for other teams, this is what the alternative looks like with dates attached: four months, one platform decision, and the department with the least technical staff as the heaviest user.
Take the diagnostic. Ask each function what they would automate this quarter if they did not have to file a ticket for it. The combined length of those lists is the size of the opportunity, and the People team usually has the longest one because nobody has ever built them anything.
Leave the target. Eighty is not a goal. This is the CEO of the tool reporting on his own staff's use of the tool, which is the most favourable environment that exists, and the metric is a count of apps built rather than apps used. Lovable's own north-star measure is daily active apps, and that number is not in this post. Eighty internal apps could as easily be eighty abandoned ones.
What survives the caveats is the direction, and the direction is the thing worth planning against. When the cost of internal software collapses, the builder is whoever has the problem.
