Is every AI Software Factory just a local script wrapped in 40 prompt files?
Or am I missing something?
Guys, let's talk honest about AI SDLC orchestration.
Has anyone here actually successfully moved AI-driven software development from "cool local demo on a senior engineer’s MacBook" into governed enterprise-grade SDLC system?
I've got a feeling that 90% of you are stuck the same as I am, and we all fighting the exact same wall. I'll start sharing my concerns. a) Work breaks (right after session ends, machine closes, different developer steps in to take over the ticket). b) Agent execution goes off-rail during long-running end-to-end tasks, c) engineers spend more and more time reviewing garbage code than if they’d written it from scratch.
We’ve already spent months building out our own internal AI software factory foundations — covering everything from structured product discovery down to evidence-captured draft PRs. Some parts work brilliantly. But turning this into multi agent system is proving to be a massive architectural challenge.
I’d love to hear your raw thoughts in the comments:
What is the single most broken part of your current AI dev setup? (Context loss? Flaky agents? PR review fatigue?)
Are you running agent orchestrators locally or pushing them off to cloud worker nodes?
How do you actually solve this agent orchestration in production?
Replies
i think cloud workers make more sense for longer workflows, but reliability becomes a much bigger requirement for me once agents are running without someone watching them.
@isabella_wandrei I’m curious whether teams are finding orchestration itself harder than the agents. For me, coordinating state, tools, handoffs, and failures seems like where most of the architecture starts getting painful.
@isabella_wandrei @elsie_ramsey The idea of a software factory sounds great until you have to govern what happens between each stage. I’d be intrested to hear what others consider the first thing that absolutely needs to be solved before scaling this.
Both kinds exist, and there is a cheap test that separates them. Count the places one fix has to land. That question is not a neutral one for me, since the customer sites I sell all come off a single shared image.
For the storefront code, that count is one. A site is a version rather than a folder, so changing the image moves every site together.
The strongest evidence for that shape is also the worst thing it ever did to us. When a container was recreated, two customer sites answered with the image's own default pages at the same moment. The fault appeared in two places at once because the image is shared, and it closed in one place for the same reason.
A wrapper around a local script gets fixed once per site instead, and the expensive part there is not the repeated work. It is never knowing how many sites still carry the old shape. So the number worth asking of any factory, mine included, is not how many prompt files it holds. It is what happens to every other customer the moment one of them gets a fix.