Agentic Software Factories: The Future Of Programming?

What if anyone in a company could build the exact software they need, without writing a single line of code? Agentic software factories, powered by GenAI, are making this possible. They’re also redefining what it means to be a software engineer.

Software That Builds Software

A new type of application is emerging: software that builds software. Let’s call them Agentic Software Factories, because factories are machines building machines, and because AI agents are the core of these factories.

You could argue that software factories have existed for a long time: Retool and Excel are good examples of applications allowing non-programmers to build new software. But the new generation of software factories, led by products like Claude Code or Lovable, differ in one key point: they understand natural language. This means their users don’t need to learn how to use the software factory (the way you would need to learn functions and macros to get the most out of Excel). The entry barrier is much lower (you just need to be able to afford their hefty subscription).

These factories differ from car factories and the factories of most industries because they can build a different piece of software for each user. Standardization in the industry resulted from the cost of changing the factory parameters. There is no such cost in software factories. In the past, it was too expensive to ask the IT department to build software for a single employee. Instead, companies bought software from specialized vendors, adapted their workflows and taught their employees to use them. Now, software factories act like 3D printers that let anyone build the exact object they need.

Under The Hood Of Software Factories

These modern software factories are incredible pieces of engineering, whose core technical asset is Generative AI (via models like Claude or GPT5). But GenAI alone isn’t enough to get a working factory. To produce software that is robust, usable, performant and maintainable, a factory must bake in the tools, skills and rules that real software developers use every day. This is called the harness: a system that gives special skills and tools to an AI assistant.

The harness of the current software factories incorporates the best practices of modern software engineering: automated tests, observability, separation of concerns, etc. They are also very general-purpose: they can replicate the technical part of a software engineer’s job, regardless of the programming language. But this strength is also a weakness. Because the factories are not specialized, they need supervision as soon as they’re used for anything a bit specific. That’s why you still need a software engineer to operate these factories today. A software engineer isn’t just a person who produces code. They’re also someone who identifies problems, explores the context, imagines solutions, uses their domain expertise to rank them, and puts themselves in the shoes of a user to criticize the result. Software factories can’t (yet) do that, so when they fail, and they do fail quite a lot, a software engineer is absolutely necessary.

Specialized Software Factories

One way around this particular requirement is specialization. A specialized software factory (say, a software factory that can only build calculator apps) has a narrower scope that can be completely addressed by a custom harness, effectively reducing the failure rate to zero. We will still need software engineers to build these specialized software factories, but their users will become completely autonomous and gain the ability to build the software that perfectly suits their needs. That was the promise of no-code tools like Retool, but they failed as soon as the expected result crossed a certain complexity threshold.

There are two main ways to specialize a software factory: by job, or by domain.

Let’s look at what a job-centric software factory can look like. A factory designed for the HR job, for instance, would contain the knowledge of the various regulations and best practices for recruitment, onboarding, career management, OKRs and offboarding. It would also have special abilities like checking a resume, searching job boards, connecting to payroll software or producing reports. Using this factory, an HR employee could build exactly the tools they need to automate the parts of their job they want. No need to learn a complex piece of software when they would only use 10% of its features.

However, designing factories based on roles in a company reproduces the boundaries of the organization. These boundaries create friction in all cross-job workflows. Instead of specializing by job, we could imagine a domain-centric software factory. For instance, a factory designed for bike rental companies would contain the knowledge of a rental business and the peculiarities of running a bike shop, as well as all related skills required to run the business (legal, accounting, recruitment, management, etc). It would enable everyone at the company to produce exactly the tools they need while staying in line with the company’s strategy.

These factories don’t replace human workers. They are tools letting human workers automate the tasks they want, without the cost or delay usually incurred by delegating the task to an IT team. In essence, software factories are the ultimate no-code platform.

Atomic CRM, An Example CRM Factory

To make things a bit more concrete, let’s look at such a specialized software factory. We’ve built a CRM Factory called Atomic CRM Builder. It’s not spectacular: at first sight, it’s just a normal CRM. Except it’s a CRM that can modify itself. We don’t want users to learn how to use the software. We want the software to adapt to the user workflow.

Authorized users (let’s call them builders) can ask a specialized agent to add features to the software. The initial CRM is just a template that the factory uses as a base to avoid reinventing the wheel for every new user. A builder doesn’t need any specific skill to describe their need. A plain text description like the following does the trick:

I want a CRM for my recruitment agency. My contacts are either prospects, clients, or candidates for a recruitment campaign assigned by a client. Candidates go through a multi-step process (first contact or spontaneous application, screening against the role, background checks, first meeting, selection or rejection for the campaign, proposal to the client, then acceptance or rejection by the client, and finally successful hire after the trial period for billing).

Candidates I’ve met for one role can be reused for another, so I need the history of roles I’ve proposed each candidate for. My company has 2 recruiters who share the candidate database. We mostly recruit technical profiles (developer, machine learning engineer, CTO, infra lead, lead developer, etc.) but occasionally we recruit Product Owners or team managers.

With its knowledge of what a CRM is and of the corner cases that need to be addressed, the software factory will ask some questions to pinpoint the exact requirements. Questions like:

Client companies (beyond name, website, address, sector): do you need a status field (prospect vs. active client)? A contract start date? Anything else?

Candidates (beyond name, email, phone, LinkedIn): I’d suggest adding current job title, years of experience, area of expertise (developer, ML engineer, CTO, etc.), availability date, and salary expectations. Does that cover it?

Campaigns: title, opening date, deadline, and status (open / on hold / closed) — anything else, like a fee or billing terms agreed with the client?

Roles (positions within a campaign): job title, seniority level, contract type (permanent or fixed-term), location, salary range — what else?

Applications (a candidate on a role): mostly driven by the process steps, but do you need free-text notes per step? A rejection reason? A billing date once someone is successfully hired?

Then the factory will proceed to modify the template to fit the builder’s requirements. This takes some time - the factory is actually a team of specialized agents led by an orchestrator agent that splits the work into small tasks. But after a few minutes, or a few hours if the requirements differ significantly from the template, the builder gets a modified CRM that they can test, and if it fits their needs, deploy to production.

Using this CRM factory, internal builders with no programming knowledge managed to build CRMs for various use cases:

• A CRM for a clinic, tracking entries and exits of patients, linked to physicians and pathologies
• A CRM for a hotel, managing loyalty programs, reservations, guest preferences, and performance monitoring
• A CRM for a preschool, managing students, parents, teachers, classes, schedules and applications for enrollment

Atomic CRM Builder is open-source. You can check out the code on GitHub:
marmelab/crm-builder

As a side note, the harness we built for Atomic CRM can in theory be used with any open-source software as its template. You’re welcome to use it to build your own custom CMS (based on Wordpress), office suite (based on LibreOffice) or password manager (from Bitwarden).

The Next Frontier Of Software Engineering

Because they remove the need for developers, software factories make custom software incredibly cheap. Small and medium enterprises, who could never dream of tailor-made solutions, can now get one for less than 10k€ thanks to these new platforms. The main consequence should be the same as what happened with cars when Ford started selling incredibly cheap ones: virtually every company will want a software factory adapted to its business. That’s why I believe the demand for software will not decrease, but increase dramatically.

Building the harness for software factories like Atomic CRM requires classical software engineering skills, because you must make sure the factory produces good software before shipping it to a customer. It also requires a new set of skills that relate to management, because organizing and monitoring a team of agents is a bit like managing a team of developers. Finally, it requires a testing discipline that comes from data analysis, because agentic workflows are inherently probabilistic, and a feature can only be considered “done” when the factory produces the right result on a large number of tries.

As a consequence, the demand for software engineers will probably increase, too. As a matter of fact, the role of software engineers is shifting from building software to building software factories. And even though we use powerful tools like Claude Code to manage the technical part of the job (including writing most of the code), our problem-solving and domain modeling skills are key to enabling this future.

That’s a challenge for every IT team: we must learn a new craft without abandoning what we already know. But by doing so, we’ll empower companies around the globe to get more value from their computer tools, and unlock their business from legacy software.

Tip: We’re already building specialized software factories for our customers. If you’re interested in having one for your business, get in touch!