“Sunlit Factory” by Ed Lyons via prompting Midjourney

This is the second of a two-part essay on the mysterious topic of software factories. Part one is a deep dive into what they are, how they work, and what providers are out there. It also explains how you can start using factory techniques in your own software development workflows.

This part explains how factories will significantly alter the software development methodologies so many organizations use, as the extraordinary momentum and cost savings of factory techniques will force changes.

Agents have been disrupting the way we build software for two years: who can build it, how fast code can be written, and how quickly it can be tested.

Software factories are a dramatic increase in the automation of product development. And once you churn out more than a dozen PRs in a day, you come to an inescapable conclusion: the processes we have used to build software for the past 25 years are going to change dramatically.

Naturally, the factory builders see this clearly. Blitzy promotes a new Agentic Product Development Lifecycle (PLDC) that makes requirements and design the focus; the implementation is a smaller, later phase in a project. (White paper can be requested here.) Ona says you should fully automate your SDLC with their factory. Factory is promoting a full automation of your SDLC, giving you a very cool dashboard:

The factory vendors are certainly not alone in realizing new processes are needed. Any product team where everyone (not just one person!) is pushing the agents hard sees that things need to change.

So yes, you can keep developing a software product gradually over a several months, with developers driving agents. Or, if you could gather all the requirements first, you could have it in days.

Now, you might say that the gradual process is superior. You can check in with users to validate features, and team collaboration should produce a better product. Perhaps! But there are weaknesses in how we develop software that we do not notice because everyone uses something like agile.

Despite agile techniques, many organizations implement all kinds of features without vetting them with users. On top of that, the coordination and handoffs between different people and systems are incredibly costly and prone to errors and misunderstandings.

Think how often one team member is waiting for another to get an answer to a question. Think about developers complaining that their build pipeline is having problems again and they are stuck waiting. Or a ticket is failing in QA because the developer didn’t understand the requirements properly. Or all the times someone created a bug ticket instead of just fixing it themselves.

If a factory can turn out dozens of features in hours, wouldn’t it be better to just spend a lot more time hashing out the requirements first? Or you could create incredibly sophisticated prototypes, and then when you were sure what you wanted, you could just generate the final version.

On top of that, if you generate everything in one long run, the raw token burn will be less than doing the tickets one at a time and the return on token investment will be easier to see.

Even individual developers who do not use factory automations can arrive at this process reckoning if they drive their agents hard enough.

You can try this yourself if you’re a skilled developer who is good with agents and have an environment where you can run your entire stack for end to end testing. Select a large group of well-defined tickets for upcoming work. You can use a factory or just drive a group of specialized agents using a mix of models and review the PRs yourself. Do this over a couple of days. Speed is the goal here. Don’t sweat the small stuff or spend too much time pondering ongoing clarification questions from the agents. Just record all your decisions for future reference. Then look at the resulting product.

I recently tried this on a large hobby application I’ve been thinking about for years. I had a lot of the requirements already and spent a few hours talking to an agent about them. Then I asked a group of Factory droids to get it all done overnight, using quite a bit of tokens. And they got it done.

Can I release the result to the public? Well… not yet. There are outstanding issues. Is this really the product the users want? How good is the user experience? Does the architecture support proper integration into other applications? How would I monitor and manage it?

But I couldn’t help but think: “This is pretty awesome and it’s close to completion. Would I really be better off dividing a project like this into four sprints just to have time to develop the best final product? Couldn’t I just spend more time up front nailing down requirements, user experience, and architecture and then just generate the right version in one day? Or maybe I could just show users a few different prototypes over two weeks.”

In fact, I know people at AI-driven small companies who do this for small-to-medium sized applications. They spend weeks in research and product development using prototypes to figure out what an application should be. Then they work through system architecture and deployment considerations.Then they use agents with lots of automations to do a series of builds and tests over a few weeks, which includes a lot of time for human reviews.

You may be wondering: could we really get all - or nearly all - of the requirements ahead of time?

We seasoned programmers remember that we once did start projects knowing all of the requirements. (Or… we believed we did.) Then there would be a “waterfall” process where we would then take months or even years implementing it all. But we abandoned that methodology to stop wasting time building features and applications people didn’t want.

Yet now, great code can be written impossibly fast. So does it matter if you wasted two hours generating three features that were unnecessary?

If you are worried about the risks of a big switch in processes, I don’t see this as a binary choice between traditional agile development and using a software factory.

Let’s take legacy modernization as an example.

Considering the cost and difficulty in maintaining and enhancing legacy applications, it’s tempting to think you should just rent a factory to create a modern clone of what you had, which is what you have dreamed of for years. But would that be the best outcome?

If understanding the codebase and generating all of the new code is no longer the scary part, what can you now spend time doing? Perhaps you can create an entirely different architecture, or substitute five new applications for the monolith you’ve been stuck with for years. You could tie that re-implementation to other organizational and process changes.

During that process, you might do rapid builds of pieces of that legacy application for prototyping purposes. Perhaps you’d even use a factory to do some of those builds. Or maybe there is one risky piece you’d rather handle by driving the agents yourself.

This reveals an important characteristic of software factories. Blitzy and Ona are not exactly like industrial factories. They are quite flexible and will adapt. Blitzy is already offering smaller services, including PR reviews, shipping a small set of features from their sandbox, and giving you 100,000 lines of generated and tested code for free.

Software factories do not have to follow one strict end-to-end process, even though they may advertise that. Even for a legacy modernization. They could take in all your requirements or legacy code, and then offer you lots of options about what gets built. In fact, many modernizations are better seen as a part of organizational transformation than a code translation.

Wharton Professor Ethan Mollick (who is quite good at using agents) wrote a nice description of two ways of using factories on his popular substack. He sees two software development models: “dark factories” for software that humans do not need to supervise and “twilight factories” where humans are involved for their judgment, ideas, and risk management.

l would add that a “twilight factory” does not have to finish all of its work overnight. You could use it over a few weeks.

I believe teams will choose from different processes according to the nature of the application, and then select factory options according to quality, cost, and speed.

How to move forward

In light of these ongoing disruptions and opportunities, how should organizations proceed?

I do not think all software will be built in factories, as the CEO of Warp recently said. But I do agree with him when he said that we will now see gradual change in that direction, starting with more automations.

Companies need to consider the coordination and delegation costs of their current agile methodologies. We all need to stop comparing how we do agile to prior waterfall processes nobody uses anymore. We should instead start comparing our activities in agile methodology to potential factory techniques.

If you want to keep an agile-style methodology, you should think about making it more efficient. I’ve seen people use agents to analyze tickets and figure out what product questions should be addressed before code is written. It’s a huge time-saver and the better-defined tickets can usually be generated correctly and without bugs.

It will take time to accept that the methods we use most often to build software might now be considered artisanal. But in light of what factories can do, that is the most useful framing.

This is where the comparison to real world factories becomes useful again. If you prefer artisan-made goods because they are more suited to your tastes and preferences, or you find them of higher quality, and you are willing to pay more for them, you can think of software the same way.

If you are going to spend six months creating a familiar business application with a web interface, ask yourself what you will get out of taking months to build it instead of weeks. Are there a lot of unknowns? Will it take time to figure out what users really want? Is the technology risky or unproven? If the final code could have been generated in a few days, why will it take six months to know what code should be?

Perhaps some applications your organization creates should be done in a slower, more deliberate way. But many should not.

The most important thing you can do now is to encourage your product and development teams to learn about these techniques, to increase their ambitions around how they can create software, and what great things that software could accomplish for your users.

Software Factories, Part Two: The SDLC Will Have To Change, By Ed Lyons

How to move forward