The software factory pattern lets agents run projects, not just tasks
Trying the Software Factory Pattern
Will Larson describes adopting the software factory pattern at Imprint: an agent skill reads a Linear project's goals, audits missing RFCs and metrics, then works through non-blocked tasks. It catches post-release issues like passkey adoption spikes or error rate changes. The pattern depends on Datadog MCP, Snowflake, Linear as the single source of state, and an orchestrated harness. Larson notes it forced him to stop hoarding project state and reflects on the compounding migrations.
What I particularly like about the factory pattern is that it parallels very closely how I've been working locally, while forcing me to recognize the places where I was accidentally hording parts of the state for myself regarding the goals of the project.
- hibikir
Will has trouble with this in a relatively nimble org, where he has good control of what is adopted. Imagine how much fun this is in more ossified enterprise environments, where getting work done efficiently means bypassing process with dev lead and line management blessings. The differences in performance among individuals has never been wider, and not just gains in productivity, but performance losses as some people who have iffy judgement cause trouble a lot faster.
Maintaining quality when an organization just lacks the muscle to make changes and nobody has the mandate to try to make sure uptime is in good shape is a challenge. A lot of things break, precisely because there's just as much change as Will sees, but it's very unevenly distriuted.
- alexpotato
So I ended up doing something similar:
- Create a Git Hub project board for issues
- Connect Grok to the above
- Use Grok voice mode to take ideas, have Grok refine them with me and then save them as issues
- Created slash commands in OpenCode like /ni (new issue), /do (do an issue), /curr (what is the current issue), /done (self explanatory)
- I generally tell the OpenCode instance to /do <number> and then off it goes
This give me several benefits:
- I can use Grok Voice while walking or driving to develop and test ideas
- I can lose my entire local OpenCode setup but still have relevant data in the issues
- multiple machines can read from GitHub
- I could go even further and have separate user accounts for each of my bots.
Having been both a PM, dev, SRE and manager, this really does feel like managing a team of devs.
- richardbarosky
Writing about these things in public and putting yourself out there is greatly appreciated. Hats off for that!
However, as far as what's being pursued, it seems more like wantonly trying to ride a hype cycle without strongly questioning the end-to-end value of new software development approaches or vetting their immediate suitability.
Personally, I think it would be more sensible to take a few individuals or a smaller team(s) and do more isolated/skunkworks experimentation and adopt as justified based on what those people report/experience. The smaller group can adjust faster and iterate/advise the larger dev org about the good approaches/techniques/strategies, and avoid more broad damage/chaos for things that aren't that well thought out.
For more conservative AI use cases like adding to code review, writing low stakes PR summaries, or beefing up security checking, a more global, but still not off-the-rails, approach would be the kinds of things that would make more sense to push more broadly.
- bsilvereagle
Has anyone demonstrably gained market share over a competitor who is vocally _not_ adopting agentic software development flows? This article outlines a lot of process churn without a clear through line to how it is impacting feature development or revenue.
- bicx
My team is in the agentic orchestrator phase. I like this software factory pattern in concept, but our biggest challenges in development are acceptance testing of anything UI-related. Mobile app testing in particular is still a huge bottleneck that requires a human. AI models really suck at identifying poor usability and jank, particularly because they only typically process snapshots of the app from an instance in time.
I know there are traditional testing frameworks that can detect jitter and frame drop to a certain level. We could potentially start having agents build that in.
If we had concrete designs and specs on every project, that would also be helpful, but in a fast-moving startup, that gets delegated to the builders. That puts a human back in the loop every time.
Curious to hear what anyone else does to fully adopt a software factory pattern.