Most companies are introducing AI into software development without reconsidering how software work is organised. Developers get coding assistants, analysts generate requirements faster, testers produce more test cases and product managers summarise more meetings. The existing factory remains intact; every role simply receives a more efficient tool. That makes teams more productive, but it leaves most of the opportunity untouched.
AI can do more than speed up the existing process. It can let the person who understands a problem build, deploy, use and improve the solution directly. Once that becomes possible, many of the handoffs between domain experts, analysts, product managers, designers, developers, testers and project managers stop being technical necessities. They become organisational choices, and expensive ones.
I have spent much of 2026 putting that idea into practice inside an approximately 800-person fintech company. We built an internal platform that lets employees create and deploy applications with AI, connect them to the systems they already use and share them with colleagues. By August 2026, over 300 employees had created more than 1,900 applications. More than 200 people were using one on a typical day, and over 80% of the company had used one during the previous 30 days.
The lesson here is not that everybody has suddenly become a developer. It is that coding ability is no longer a reliable boundary between people who identify problems and people who are allowed to solve them.
The short loop
Traditional software development separated knowledge from implementation for a good reason. A corporate actions specialist might understand every exception in a process but could not turn that knowledge into production software. The specialist explained the process to an analyst, who translated it into requirements. A product manager prioritised the work, and a team of designers, developers and testers turned it into software. That was the essence of the software factory: knowledge moved through a long chain of specialists before it became working software.
The problem is that every permanent participant adds another handoff, another meeting and another chance for context to be lost. Responsibility becomes harder to locate as the group grows.
Another issue is that no analyst can capture every detail of work they have never performed, and no user can fully specify a product they have never touched. People often discover what a product really needs only after they start using it. In the traditional model, every discovery had to travel back a long way through the delivery chain before the user could see the change.
AI changes the economics of implementation. The specialist can now describe the need, inspect a working application, test it against real cases and correct it while the context is still fresh. Product discovery and delivery collapse into one continuous loop: build, use, notice, fix and use again.
The goal is not to make the chain of specialists faster. It is to shorten the loop until one accountable person owns both the problem and the result.
What employees build
Our platform is easiest to explain as Google Drive for applications. Nobody writes a business case before creating a spreadsheet. People make documents because they need them, share the useful ones and organise the resulting environment afterwards. Application creation can work the same way. That freedom does not mean a lack of control: identity, access and baseline safeguards come from the platform rather than from assembling a project organisation before an idea can be tested.
The ~1,900 applications created on the platform should not be mistaken for 1,900 production systems. They include experiments, duplicates and abandoned ideas. But the same environment has also produced operational systems that a central software organisation would never have prioritised.
Among many other examples, one application cut a month-end close from 17.7 hours to 7.3 by handling vendor matching and accounting rules before human approval. Another turns trading tickets into settlement files. A third reshapes Jira data around the bookings and controls its team actually manages.
These applications reveal a recurring pattern. Generic enterprise platforms store the underlying data, but they rarely represent how a particular team actually operates. Employees bridge the gap with spreadsheets, copy and paste, recurring tickets and tacit knowledge. Once they can build directly, that missing operational layer becomes software.
I built most of the platform myself, and I am not a developer — a colleague built the integrations, and a teammate has since taken on much of the feature work. More importantly, the products on top of it are being built by hundreds of people who know their domains better than a central development team ever could. The application count does not prove that every product is valuable or every builder exceptional. It does show that software can be created across the organisation rather than supplied exclusively by one department.
The full-stack operator
Inside my own small team, one person shows how far this can go.
For roughly four months, one team member — a product designer rather than a conventional developer — has shipped most of the platform's new features. She designs the work, implements it with AI, tests it and fixes what is wrong herself.
She owns the product rather than one function within it. Support, documentation, communication, discovery and operations stay in the same loop, and when part of that work becomes repetitive, she builds a tool for it on the platform. A conventional organisation could split the same loop across product, engineering, QA, operations, support, content and community roles.
That does not mean she has replaced a matching number of full-time employees. It shows that boundaries which once seemed natural can collapse when one person with taste, sound judgment and agency owns the product loop and AI supplies the implementation capacity.
One person is not a pattern
One unusually capable operator shows what is possible, but not how often it can be repeated. If this approach depends on finding an imaginary superhuman for every product, it will never replace the conventional team.
We already see many people who take an ambiguous problem and turn it into a working system among the creators on our platform. They are often hidden inside narrow roles, where that range is neither visible nor rewarded. Not everyone will become a strong builder, and AI does not manufacture judgment. The task is to find those who already combine judgment with agency, then give them a larger loop to own.
Existing employees with these qualities stand out through what they build. Finding them outside is harder because conventional interviews reward candidates for describing past work and fitting an existing role. We are experimenting with a different process: candidates receive temporary access to our application platform and a realistic fictional problem. We assess what they build and the AI conversation behind it: how they framed the problem, challenged the AI, tested their assumptions and recovered from failure. We do not yet know how well this predicts performance, but it lets us observe the capability directly.
The foundry replaces the factory
Finding capable builders is only part of the answer. They need a shared environment that gives them infrastructure, access and controls without rebuilding the software factory around every product. We already have such an environment for internal applications: the platform described above is their foundry. The next step is to extend it to established production systems, including client-facing software.
The team that builds the foundry should remain genuinely small. Its members need agency, judgment and systems thinking too, but their product is the capability layer: identity, permissions, reusable data access, deployment, observability, rollback and interfaces that domain builders can compose. The much larger value layer consists of people building the software that runs their own domains.
Specialists remain essential, but they create more value by turning their expertise into reusable leverage than by joining every product permanently. One security engineer can create a control used across hundreds of products. Infrastructure, design, compliance and quality experts can do the same through safe defaults, test harnesses, design systems, adversarial agents and deployment mechanisms.
The foundry needs those specialists, not permanent translators, coordinators or gatekeepers. When problem owners can build solutions themselves, much of the permanent coordination structure around each product becomes unnecessary.
Extending the foundry beyond internal applications requires stronger production controls. Higher-risk software needs stronger safeguards for deployment and recovery, better auditability and genuinely independent review — not more permanent teams around each product.
Supporting the builders
The hardest part of extending the foundry is what happens when an application built outside conventional delivery becomes important enough to need production support. We faced that question with our own platform. Bringing it into the standard production-support structure would have required formal ownership roles, independent QA, monitoring, several technology teams and a multi-person support rotation — a transition requiring dedicated people and months of work.
Yet that structure would still route every serious issue back to the person who understood the product. A monitoring team would alert production support, which would call the developer. A client report would pass through client support writing a ticket to production support before reaching a developer who could neither speak directly to the client nor release the fix. The chain would distribute responsibility without distributing the ability to solve the problem.
The alternative is to keep support and product ownership in the same loop. This already works well for us: with AI, I can keep dozens of support conversations moving at once, draw on live information from the relevant systems and turn what comes back into fixes to the platform itself. Support becomes more personal and more technically informed, not less.
The owner does not have to stay on call, and the product no longer depends on one person being available forever. Someone else can step in for a night, cover a holiday or take over permanently. Agents can inspect the repository, reconstruct its history, read live telemetry and use deployment tools. With that help, the person taking over can get sufficiently oriented in an unfamiliar codebase to diagnose an incident, fix it and release the change. The same mechanism provides both on-call coverage and continuity: ownership can change hands without making the product dependent on one person.
From assistance to ownership
Giving every existing role an AI assistant is the easy part. It produces more code, requirements, tests, summaries and presentations, but leaves ownership fragmented.
We can already see many employees taking ownership of the whole loop: building, using and improving solutions to problems they understand firsthand. The harder question is whether organisations are willing to remove the handoffs that no longer need to exist and organise software work around that ownership.
The strongest case against this
What is the strongest case where you believe a traditional software team is still necessary? I would rather have that argument than agreement.