Software engineering has been one of the most impacted fields by generative AI. We have seen coding agents literally disrupt the entire industry, and the job of a software engineer has transformed in the last 18 months or so.

More recently, over the last few months, there is this new concept of AI software factory. In this blog post, I want to go deeper into the concept and try to understand what it is and how it works. Let’s go.

What is a Software Factory? Link to heading

Anatomy of an AI Software Factory

First of all, let’s try to understand what a software factory is. There are several of them out there, but in my understanding, if I could abstract away a high-level definition, a software factory is a set of AI agents and integrations to make humans and agents work together on the entire software development lifecycle. We are going to break it down component by component.

Coding Agent Vs. Software Factory Link to heading

There is an important aspect here with respect to comparing a software factory with a coding agent. With a coding agent, you are the one moving the work forward as the user. You prompt it, read what it produced, and decide if it is good, and then prompt it again for the next step.

In a software factory, the output of each phase becomes the input of the next one. The output of planning would become the input of design, and the output of design would become the input of coding.

One more thing: for each phase in a software factory, you can have verification and validation checks. This could be with automated and integration tests, a human in the loop, through an LLM as a judge, or a combination of all.

These are the main differences between a software factory and a coding agent.

SDLC Link to heading

Before we go into the anatomy of a software factory, let’s first do a little bit of a primer on the software development lifecycle. Whenever we are building any kind of software (whether it is a product built by a team of engineers, a project or solution developed by a team of customer-facing consultants, or anything in between), at a high level, the software development lifecycle is divided into the following phases:

  1. Requirements gathering and planning: Before you build any software, you want to understand:

    • what exactly you are going to build
    • how you are going to build it
    • what kind of resources (with respect to time, money, and engineers) you have available
    • how you are going to distribute some of that work

  2. The next stage is the design and architecture phase, where, once you decide what you are going to build, you have to understand how exactly you are going to build it:

    • what components come into the picture
    • how the data is going to flow
    • how the user is going to interact

    This is basically the design part. Then comes the technical architecture, where you would then fit these components together and create a blueprint of the software:

    • how all these components interact with each other
    • what the data model should be
    • where the data should be stored
    • what scale will be supported by the system
    • a bunch of other things

  3. The next phase of software development is the coding itself. There are other things also, like how to break things down into smaller tasks and how much time you want to take for each task. Then you actually do those tasks to implement the code.

  4. Once the coding is done, you are going to do testing. Sometimes this is machine-supported testing, like integration tests, and sometimes this is manual testing done by humans by clicking on the software.

  5. Finally, you go with deployment and release of the product or project. That’s, on a very high level, how a software development life cycle looks.

GenAI, Coding Agents, SDLC Link to heading

If you look at it from a high level, you would see that the software development lifecycle has a lot of generation happening.

  • When it comes to requirement gathering and planning, we are generating requirements and planning documents.

  • When it comes to design and architecture, we are again creating a bunch of technical documents, specifications, and architecture documents out of it.

  • In the code generation parts, we are generating code.

  • On the testing front, we are generating unit tests and integration tests, again generating code.

  • For deployment, we create infrastructure using automation scripts.

If you look at all of these processes and their outputs, we generate a lot of text, whether it is a non-technical document, a technical document, code, or infrastructure script.

And guess what’s really good at producing text? Generative AI models.

Anatomy of an AI Software Factory

This is exactly why the software industry is one of the fields most impacted by generative AI, because the majority of the output is text or code, and generative AI models can do that fairly easily and much faster than humans (at least the models of today, since Opus 4.5 came out in November 2025). If you look at the combination of the software development lifecycle, generative AI, and coding agents, you would see there is a very interesting complementary relationship between them:

  • When you do requirements gathering, in most cases you are trying to come up with a set of features or functionalities that the user would want to have in the software that you are building. This could be very efficiently brainstormed with a decently intelligent AI model of today, because these models have already looked through a bunch of source code and have understood what kind of applications have what features that are popular among the users.

  • When you create an architecture document or a specification, the same intelligent AI models can help you do that as well, because of the same reasons: being trained on a vast variety of architecture documents and code.

  • When you code features and write unit or integration tests, or even infrastructure scripts, the coding agents can do that as well. That, we already know.

When this AI native software development workflow comes together, that’s your software factory.

Components of Software Factory Link to heading

Now that we have a high-level understanding of what a software factory is and how it corresponds to the software development life cycle, let’s do a breakdown of the components of a software factory and how they all come together. This is based on my understanding of some of the products (8090, Factory, Augment) out there in the market, looking at their documentation and demo videos. Most of them have some version of the following:

Anatomy of an AI Software Factory
  1. A project level overview module that takes care of the initial set of high-level requirements or goals for a project. This is where humans, along with AI agents, describe a project and its functionalities.
  2. A requirements module to define concrete features of a project. The human would briefly prompt the agent to come up with a set of requirements and feature descriptions. The agent comes up with the initial draft, the human reviews it, provides clarity or comments on it, the agent fixes them, and then they are frozen as feature descriptions.
  3. A design module for creating a spec or an implementation plan from these feature descriptions, and the same process is generally applied - human prompt + previous output, agent creating the artifacts.
  4. A tasks module for breaking down these implementation plans into smaller tasks. Again, this is where human in the loop is extremely important to prioritize and make sure the tasks are independent enough so the agents can code them without too many complexities.
  5. The coding module for executing these tasks and converting those task descriptions into code and committing them to the codebase.
  6. A review module for doing the initial set of reviews for all new pull requests, whether created by humans or agents, and flagging common issues.
  7. Testing and verification module to run tests. Some advanced software factories also have a computer-use agent that can run the software and test it.
  8. The loop for feeding feedback and bugs as new requirements. This is one of the USPs of software factories: to keep the software continuously improving.

Each of these modules or components produces output that becomes the input for the next module or component in the software development process using the software factory. Generally, the user prompts, along with the context from the previous module’s output, and the agent processes them together to create the new output.

When I’m talking about human and agent, these could be multiple humans and multiple agents working together on many sets of features and their implementation plans in parallel. These software factories are generally sophisticated enough to have a whole team of humans and agents working together on the same project. If you want to envision it, think of a GitHub project view with Markdown files as requirements documents, features, and implementation plans, but with an added window for a human prompting an agent and that agent creating these files. That’s what most of these software factories look like.

Integrations Link to heading

One of the most important aspects of a software factory is integrations. Think of it this way:

  • If there is a human team or agents working together on a project and discussing these features and iterations in Slack, you want to bring that conversation into the mix.
  • When there is a pull request and people are providing reviews on those using comments on GitHub, you want to bring that conversation in as well.
  • If people are having their requirements and descriptions on external tools like Linear or Jira, you want to bring that in as well.

A software factory is mostly useless if you do not have these kinds of integrations. You want to have:

  • An integration with the communication channel of the team, whether it is Slack or something else.
  • An integration where the teams are collaborating with the codebase, whether it is GitHub or GitLab or something private.
  • At least one integration with wherever the customer conversations are happening. Sometimes they happen in the shared Slack channels, or elsewhere.

There are several other integrations that multiple software factories offer, but these are the main ones. You want to bring in all the communication happening across the teams and the customers regarding the project.

Once you have all of this context from these conversations, the task to improve the product or build on top of the product becomes much easier, as described in the previous components.

The majority of these integrations are generally supported using tool use, MCP, or directly calling an API through the Software Factory interface.

Software Maintenance Link to heading

So far, I’ve only mentioned new software development and the entire lifecycle for that, but what if there is an already existing project?

Most software factories also provide importing of existing projects, their codebases, and their reviews and pull requests. In such cases, they import a codebase and create an entire local index for that: for agents to know where the code files are, where the documentation is, and how to make sense of it. Of course, all of this indexing is also done through agents.

I built something similar as a standalone project called Sonar, where a local AI agent went through a codebase on GitHub, used a LLM to index that codebase, and then answer questions. That is what a lot of software factories also do.

Once all of this codebase is indexed, the associated context from Slack and other places, GitHub pull requests, and the documentation come in, and then it becomes like any other project. The software factories can build on top of that using the components described before.

Open Questions Link to heading

While going through several of these software factories, some questions came to my mind that I also wanted to list down here:

  • What happens when the text created by the phases of software factories becomes too big for the context window of the model?
  • What happens when the requirements change or a bug fix makes the upstream spec irrelevant? Are the agents looking at it? Some vendors say yes, but I wonder: does it hold at scale?
  • What is the cognitive load on the human in the loop? Even if I look at the demo videos of these things, there is so much text created. Sometimes it feels unnecessary.
  • Are the humans going to read everything later on? If not, what could be a better and more efficient way of describing software in the future?

Conclusion Link to heading

This was a high-level overview of what a software factory is, how it works, what the components are, and how they all come together. At the end of the day, it’s basically an automation of an entire software development lifecycle, where the majority of the work is done by AI agents while keeping humans in the loop (because you still want to have a sense of prioritization and quality checks).

I think there are a few things to keep in mind here because a lot of software factories that I have seen so far create too much text for each of these stages’ outputs. Although it’s the agents maintaining them, in the future, it could still become a burden on the project if any of the artefacts become stale and the agents don’t fix it.