We are not buying anyone else’s factory. We are building our own verification system and wanted to give it a name and the term “factory” got stuck.
Anyway, I am on factory mode for the next two weeks with AI Heroes cohort.
Just wanted to defend the term "Software Factory" for a second.
First, the caveats:
It's bullshit. It sounds fancier than it really is.
It's a bandwagon. People are using it to get you and their VC's hyped.
But it's also referring to a real change.
Earlier this year, most SOTA teams were using agents to work on the product. Shipping features, fixing bugs.
But now, they're building automations to help agents work on the product for them. They've moved up a layer.
What do we call the thing they're building? Loops? Workflows? Some other generic label?
"Software Factory" is as good a term as any other.
- "We're not working on the product, we're working on the factory that builds the product."
- "We're not product engineers, we're factory engineers."
I like it. I'll continue using it.
@Metaliberal@mattpocockuk Thinking of adding a limit to the number of lines of code for a function, otherwise split it. seeing large chunks of code in one module.
@emilkowalski What’s your take on visual regression in CI after all these verifications? I find it less useful now that agents are the ones watching the progress.
Before adding another subagent ask what problem it's solving. A bloated system prompt is often the issue.
Skills and tool search can fix that without splitting context across agents. My rule of thumb is to keep a subagent when the work is parallel, needs fresh context or one agent really can't pick the right tools.
Otherwise, fold it into the main loop, turn its prompt into a skill, run your evals and keep whatever wins.
Good write-up:
https://t.co/1gcrNNpQru