At The AI Conference I attended last week in San Francisco, Timothy Cook from LaunchDarkly opened a presentation on “Controlling the AI Software Factory” with a joke that is not really a joke, but a serious commentary: We need to build software factories that work for humans, because past industrial revolutions didn’t get that right.
Let’s build software factories that work for humans!
Tim described this as his “mission statement” for all of us building software factories, and I think it’s a great value statement to start with. The software we build, and the processes we use to do that, should always keep in mind that what we’re doing should be for the benefit of humans.
I’ll admit that the term “Software Factory” already rubs me the wrong way, since it implies anonymity and it disregards the value of human creativity. But here we are, no one ever asks me what to name things. Just like the use of “resources” instead of “team members” when discussing our co-workers, and “sprints” instead of “iterations” when talking about agile work cycles, I’ll add “software factories” to the list of terms I don’t particularly like. I’ll bite my tongue and adopt the term anyway, since it’s already recognizable and widely used.
But nomenclature aside, the technological possibilities of software factories are still very interesting and worth studying.
Agents can write code, update documentation, and run tests in response to a single prompt. But human engineers are still involved in the definition and orchestration of that software factory, so the rest of this article will draw on observations from several talks I attended at The AI Conference.
What is an AI software factory?
For this, I turn to an episode of the Syntax podcast released on October 21, 2026, appropriately entitled “WTF is a Software Factory?”. Hosts Scott Tolinski and Wes Bos turned to Adam Jacob to answer that question. As the CEO and co-founder of Swamp Club, and earlier the co-founder of Chef, he described a software factory as covering pretty much everything in the traditional software development lifecycle. Humans put inputs into the system (requirements and prompts), and the software factory produces outputs (working code). Adam sees the vast majority of that SDLC being run by agents on your behalf, inside the software factory. Some teams call this an agentic software factory.
However, that doesn’t mean that software factories are “one size fits all” or a black box. Far from it, since each company’s unique situation and product may affect how they implement software factory best practices. Swamp Club is an open source AI platform that helps you do just that, to build repeatable behaviors, integrate with any model, and make your software factory available via command line, Slack, APIs, or other harnesses.
Because a factory is unique to each product being built, then you need people to design and run that factory. That job of “Factory Engineer” is what Adam sees software developers becoming. Call it a blend of DevOps and Developers, Builders, or Factory Engineers, I won’t get hung up on the nomenclature again. Let’s just all agree that this is not going to be an easy job, especially in a rapidly changing environment and when you’re working on products that must be scalable and reliable in production.
A software factory may be populated by agents, but you will need humans (emphasis on plural) to run it properly.
What an AI software factory looks like
Back to The AI Conference, another interesting presentation was on “Building a Self-Improving Software Factory”, by Zach Lloyd, founder and CEO of Warp. Warp is an open source tool for agentic software development, and Zach gave the most hands-on presentation of a software factory that I saw at the conference.
Zach Lloyd talks about a new role of Factory Engineer, to keep your Software Factory a well-oiled machine.
From a single prompt in Slack, he showed how his agents could:
- Implement a spec from Jira
- Write and test the code
- Update the documentation in GitHub
Warp orchestrates the whole flow, and he said nearly a million developers use the tool (including developers in our team). Warp also packages this approach as a product, Warp Factories, which entered closed beta in August 2026. It’s a good example of modern infrastructure as code, since how the factory works is itself defined as markdown prompt files stored in GitHub. To change the process, you change those files, review them, and version them like any other code.
Treating this agentic infrastructure as code shows how best practices in software architecture can be maintained in this new world. Just like continuous deployment practices of recent years prescribe, all production servers should be run with configuration management, monitoring, and someone responsible for keeping them healthy. The development pipeline is treated with the same discipline, even though agents do much of the work inside it.
Why the old SDLC strains under agent volume
Adopting software factories is not easy, and Jonathan Nolen and Timothy from LaunchDarkly were candid in suggesting that many early software factories are struggling, and we are all learning as we go.
The existing software development lifecycle was built for the pace of human developers. In an agentic SDLC, agents produce faster, but production still can’t be allowed to crash, and so we have to review code at a similar pace.
They talked about “keeping engineers in charge at agent speed”, even when they can no longer read every line of code the AI generates. How do you keep a human in the loop without burning out your team? It’s the same thing that continuous delivery experts and agile consultants have preached for years: Automation. The key is to provide granular visibility into each change, automated checks, and fast rollback procedures.
Factory engineering: the new job
Since AI coding agents make most of the code changes, Zach says that most developers become factory engineers. They spend their time inside the system, automating and improving how software gets built.
His recipe for getting started had three parts:
- Define the factory in code, so changes to your process are reviewed and versioned.
- Log every step of the process, so you can see where agents succeed and where they fail.
- Orchestrate it in a cloud sandbox, so agents can work freely without risk to production.
From there, the job of an engineer is to continuously improve the factory. They adjust prompts, rules, and checks to keep getting better at keeping the agents inside the guardrails and producing the type of quality output required by the organization. Making these changes at the factory level means that improvements learned from a single change or pull request are fed back into the whole system, creating longer term improvements.
Who thrives in an AI software factory
Between sessions, Lauren Sime and I were comparing notes on the various sessions we attended. One theme we kept discussing was what types of engineers adapt best to AI-driven development. We both agreed that the traits that have always made someone a strong Scrum team member are the same ones that help people thrive with AI.
- Strong communication. Agents need clear specs and clear prompts, and so does the rest of the team.
- A love of collaboration. Factory work is a team sport between people and agents.
- An appetite for customer input. When building gets cheap, getting feedback from real customers about what to build next matters even more. Flooding customers with cheaply developed features that don’t solve their problems will not make them loyal users.
In agile teams, it’s always been important for management to give teams autonomy and agency over their work. This is still true, since Factory Engineers need room to change the process. Improving the process is now a major part of their job, not just writing software.
After more than 15 years of Agile work at AgilityFeat, I find this encouraging. We’ve spent a lot of time learning how to build great teams, and that learning still applies, even as the nature of how those teams work is changing.
A faster factory does not replace good judgment
Wanyao Zhang, a former Product Manager from TikTok and Shopee, now at SeaMoney, gave a talk on validating demand for AI products that makes a useful counterweight. (Session recordings are posted on The AI Conference agenda.)
One of her key points was that although build costs have dropped, the cost of business judgment has stayed the same.
[Image: Author’s photo of a slide from Wanyao’s presentation. Alt text: Slide on build costs versus the cost of business judgment]
If it’s easier to build software, and you only apply that efficiency gain to building more features as fast as possible, then you will also have more false positives. Meaning that in the early feedback, an idea sounds good, but without deeper analysis with real users, that idea may not be enough to make a business or a software feature successful.
Someone saying they like an idea is still a much weaker signal than someone actually paying for it. Another lesson that has stood the test of time, but just becomes more painful to learn from if you can make the same mistake so much more rapidly than in the past. It’s also another good reason why you need humans in your team, because they are the best at obtaining and understanding user feedback.
As Wanyao said, if the evidence for an idea is weak, then you need to keep validating before you scale. That decision may fall outside of a Software Factory discussion, but it’s key to feeding the Software Factory with inputs that will create useful outputs.
What this means for project lifecycles
Putting these talks together, here are some ways that I think software factories will change the way projects are run:
- Requirement gathering is a bottleneck. When agents can implement quickly, the quality of the specs will decide the quality of the result. Working in small increments with frequent customer feedback is still the best antidote for this.
- The software process becomes a product in itself. Since the software factory definition lives in code, human teams will need to review and improve it the same way they have traditionally reviewed application code.
- Retrospectives are still important. Agile-style retrospectives ask how the humans are best working together. Now they also need to ask, “what should we change in the factory?”
- Validation moves earlier and happens more often. This is another classic best practice for agile teams, which becomes even more important in a fast-paced agentic world. Building software quickly only pays off when the tokens are spent working on problems that users actually value. The more you can build in some automation to validate user adoption of new features, the better.
- Engineering roles will continue to evolve. It’s more than just a title change from developer to builder. Some engineers are going to spend most of their time on the factory itself, and every engineer should have more DevOps and automation knowledge than they used to. Those who struggle the most will be those who don’t want to change anything about how they build code.
Where nearshore AI engineers fit
Factory engineering depends on fast review loops, clear written specs, and frequent retrospectives on the factory itself. Nearshore AI engineers in Latin America work within a few hours of US time zones, so code reviews, factory changes, and retrospectives happen during the same workday as the US team. The traits listed above, communication and collaboration, are also the traits we screen for when we build teams in Latin America.
Closing thoughts
The teams I’d bet on are the ones that treat their AI software factory as infrastructure, staff it with technical people who communicate and collaborate well, and keep the customer at the center of what they build.
If you’re building an AI software factory, you’ll need human talent that is experienced with orchestrating agent frameworks, and who excels at the “Builder” mentality of strong technical and communication skills. That’s not easy to find, especially when you are also exploring other countries in order to find that talent.
That’s where AgilityFeat comes in. We can build your prototypes using our highly efficient and cost effective Builder Pods, build ongoing nearshore teams using our staff augmentation services, or even build and deliver a fully functioning LatAm tech delivery center to you using our Build Operate Transfer model.
