Ask HN: What does your agentic software dark factory look like?
6 comments
I added a agentic QA (exploratory testing) at the end, after the reviews, with patterns about how to break the system
(it can works with web-based application, as well as APIs, CLIs, and even mobile apps inside an emulatore)
This agentic QA discovers defects that the "static" code reviews miss.
(it can works with web-based application, as well as APIs, CLIs, and even mobile apps inside an emulatore)
This agentic QA discovers defects that the "static" code reviews miss.
Hadn’t thought of that.
How does it work with web-based apps and simulators / emulators? MCPs + screenshots?
What is a dark factory?
A robotics factory that is fully automated. Hence "dark" because they can just turn the lights off and let the machines run 24/7 in the dark.
I guess in this instance it means some kind of harness and framework that lets models build without supervision.
I guess in this instance it means some kind of harness and framework that lets models build without supervision.
That’s pretty much it. I’d say minimal supervision, and I can’t say whether or not it is doable or desirable, but maybe I’m not bullish enough. Or too much.
There’s a joke about dark factories, by the way:
> The Factory of the Future Will Have Only Two Employees, a Man and a Dog.
> - The human feeds the dog.
>- The dog makes sure no one touches the equipment.
There’s a joke about dark factories, by the way:
> The Factory of the Future Will Have Only Two Employees, a Man and a Dog.
> - The human feeds the dog.
>- The dog makes sure no one touches the equipment.
We have OpenAI’s Symphony[1], StrongDM’s Factory[2], Yegge’s GasTown[3], and probably a few others I’ve missed.
So I’m curious. What have you been working on? What have learned? What has worked and what has failed? And what do you think comes after?
I’ll go first. The first thing I tried that yielded interesting results was, when possible, providing a ground truth or reference for the model to iterate against: screenshots or mockups for UI work, API contracts and unit / integration tests for logic. That’s the Ralph Loop we all know and love. A feedback loop.
The second (obvious, I know) was splitting planning and implementation.
Reviews by other models and iterative loops came next, with appreciable results. However the implementing agent would often wiggle out by deferring things into oblivion or saying things that were actually important feedback were out of scope. Another feedback loop. I’ve found turning those reviews into "hard gates" has its own set of issue, as reviewing agents will always find something to nitpick about, turning this iterative implementation approaches into near infinite loops.
Combining these reviews and committing plans alongside the code led to an interesting accident: reviewing agents spontaneously and unexpectedly picked up on those and drastically improved their feedbacks by comparing plan and implementation (should have been obvious, and you’ll imagine my surprise the first time GitHub Copilot actually provided useful feedbacks instead of the usual typo nitpicks).
Then a comment here led me to an adversarial green team / red team process.
A first agent creates a spec (based on StrongDM’s NLSpec) from my initial plan and gets it reviewed, including a detailed API.
A red team agent writes unit and integration test based on these specs, and gets them reviewed.
Then a green team agent is given those same specs and API, and implements the actual feature or fix, and iterates against the tests, without any access to the tests themselves, only which tests failed and what they were testing. This prevents it from gaming the tests.
Finally, once tests pass, a reviewing agent reviews the implementation against the specs.
This was nice. And it allows mixing and matching models, thinking levels, and providers. But both green and red team would sometimes diverge from the initial specs and API, sometimes with good reasons.
So another agent was brought in to evaluate those divergences when they occur and, if they are valid improvements, restart the process from the spec generation point, with the new insights. Yet another feedback loop.
And finally, integrating logs, OTel traces, and stack traces into the process. These agents seem remarkably capable at sifting through these, and end-to-end observability drastically improved results. Again, a feedback loop.
That’s all for me so far. Curious to see what other insights, findings, lessons or learnings everyone else has to share on this!
It’s a fun ride.