For most of computing history, building a real application meant hiring people to do it: engineers who write the code, set up the infrastructure and look after the toolchain. In the last year or so that has stopped being the only way. A growing share of the internal software a company runs on is now built by the people who actually need it, a finance lead or an operations manager working alongside an AI agent that handles the engineering. What comes out is not a mockup or a clickable prototype. It is a working application on a live address, with a database and real logins.
That is a real shift in who counts as a builder, and it is worth looking at calmly, because the noise in both directions is loud.
What actually changed
Three things moved at roughly the same time.
The tools got good enough to ship, not just to demo. An earlier generation of AI builders would produce a tidy-looking screen filled with placeholder data and leave you to connect the database, the login and the hosting yourself. The current generation goes further down the stack and hands back something that is actually deployed.
The bottleneck moved. When building software required engineers, the binding constraint was engineering capacity: the long queue that every department learned to dread. When building requires a clear description of what the tool should do, the constraint becomes understanding the problem well enough to describe it. The finance lead who lives with the broken process usually understands it better than anyone in IT.
The economics changed. A custom internal tool used to mean a contractor quote in the tens of thousands, or a line on a roadmap that never quite came up for air. Vendors in this category now put the cost of a first build at a few tens of dollars of model usage and under an hour, though those are their own figures and worth treating with some caution. Even allowing for that, the order of magnitude is different enough to change who gets to decide a tool is worth making.
This is not a fringe trend. Gartner forecast in 2021 that by 2025, 70% of new applications would use low-code or no-code technologies, up from less than a quarter in 2020, and a year later predicted that by 2026 developers outside formal IT departments would make up at least 80% of the people using low-code tools, up from 60% in 2021. AI agents are the newest part of that same movement.
What people are building
Not consumer apps for millions of users. The centre of gravity is internal business software, the long tail of tools that every organisation needs and no engineering team ever has the spare capacity to build.
A finance team replaces a vendor-approval process stuck in email with a proper application that has roles, spending thresholds and an audit trail. An operations team turns the shared spreadsheet that breaks every quarter into an inventory tracker backed by a real database. HR swaps a manual onboarding checklist for a portal that new starters actually log into. A sales team that has been bending its CRM into a shape it was never meant to hold builds a lighter tool that fits the pipeline it really has.
The common thread is that the person closest to the problem builds the thing that solves it.
Is this just quick-and-dirty coding with extra steps?
It is a fair question, and the answer matters once a tool has to survive past its first week. Talking your way to an application through a chat window leaves the conversation as the only record of what you asked for. Reproduce the build, or hand it to a colleague, and you are re-prompting your way back to roughly the same place with no guarantee of getting there.
Spec-driven development takes a different route. You describe what the application should do, the agent drafts a plain-language plan, and that plan, rather than the chat history, becomes the thing of record. When you want a change, you edit the plan and rebuild from it. GitHub, which has published an open toolkit for the approach, describes the shift as moving from "code is the source of truth" to "intent is the source of truth". That is the difference between a department-built tool that can be maintained and one that quietly becomes nobody's to maintain.
The kind of tool that makes this work
It helps to separate two things that often get lumped together. A coding assistant edits code inside a project you already own and deploy; it is aimed at engineers working on an existing codebase. What is described here is different. It takes a plain-language specification and compiles it into a complete, deployed application, with the backend, the database, the authentication, the front end and the hosting all handled in one pass. The first kind speeds up people who already write software. The second lets people who do not write software ship it at all.
Both have their place. The point is not that one replaces the other, but that the second category is what puts a working app in the hands of someone who has never opened an editor.
The harder half comes after launch
Shipping the first version turns out to be the easy part. As an internal tool gets real use, it grows real needs. People forget passwords and need proper authentication and a way to reset it. Someone uploads a file. Legal asks for an audit trail. The dashboard slows down for one user and nobody can see why. None of these are failures. They are the ordinary milestones that every real product reaches.
What decides whether the tool keeps scaling is whether those needs are handled coherently in one place, or bolted on from a dozen separate services that nobody owns. This is also where the questions that used to sit with IT come back into view. An application with real logins and a real database raises real questions about access, data handling and security, and a tool built outside IT does not get to skip them. It just meets them later, often with less ceremony.
What this means for planning
For anyone running a technology function, the useful response is neither to wave this away nor to declare engineers obsolete. Engineers are still essential for large systems, hard performance work and anything that touches an existing codebase. What has changed is that the long tail of internal tools no longer has to wait in the same queue, and the people who own a process can increasingly build for it themselves.
That is worth planning for rather than discovering by accident. These tools will arrive in your organisation whether or not anyone signs them off, because they solve a problem people have lived with for years. The sensible move is to decide in advance how department-built applications get authenticated, where their data lives and who picks them up when they start to matter, before one of them quietly becomes load-bearing. The builder of your next internal app may well be whoever understands the problem best. Making sure they build on solid ground is still a shared job.