Software defense factories. CVEs like PHP2Shell need a swift response. Your team has to understand the newly published vulnerability and how it can be exploited. They then have to assess whether it affects software and infrastructure within your company. Once they identify affected systems, they might prototype a simple exploit to demonstrate to themselves and the rest of your team that the CVE is a problem you have to address. Then they build a fix, test that their prototype can no longer exploit the vulnerability, and create a pull request. Others on your team have to carefully review the fix to make sure all security gaps are closed and nothing was missed. Finally, you deploy the fix and release a new version. Depending on how sophisticated your software team is and how well your version of this process runs, it can take anywhere from a few hours to a few days to orchestrate this response. In the last 48 hours, multiple critical vulnerabilities have been disclosed, and it’s a glimpse into our near-term future. AI has made it easy to find security problems, and we’re about to see a flood of reports and attacks over the coming months. A manual defensive response process simply won’t hold. Over the last few months: 1. Open-weight models have caused the cost of intelligence to fall sharply. The cost of operating highly capable coding agents has dropped two to three orders of magnitude in the last 6 months. 2. Software factories that autonomously build and deploy code have become viable. I’ve been operating a personal software factory since May that produces 3,000 high-quality pull requests a month using hardware with a one-time cost of about $10,000 and no recurring costs other than a little electricity. I can also run it on elastic, on-demand hardware with the click of a button. Small, fast, inexpensive open models like Qwen3.8-27B and GLM-5.3-Flash are highly capable at prototyping proof-of-concept exploits for vulnerable scenarios and autonomously iterating on the code until it’s no longer vulnerable, without breaking desired product functionality. Fast and open decision models, combined with deterministic machinery, can orchestrate a rapid autonomous response where your security and software teams are presented with an automatically created, well-researched, evidence-backed fix. These developments make continuously running software defense factories practical, and the need for them is urgent. To be effective, AI factories have to be tailored to and evaluated against how your team ships software. You can’t buy this capability off the shelf; you have to build it. You won’t be able to do that in the middle of a firefight, so start now. The code for Fluent, my factory, is open source on GitHub: mrinalwadhwa/fluent - fork it or use it as a reference. I also have a Discord group with a few friends who are all building software factories. If you’d like an invite, let me know.

More on how to build a software factory: xitter.cf/mrinal/status/20818234…

This works like a very simple memory system that stores memories about your code and past agent runs in your git repo right next to your code.

This is spot on! And there is one last piece - system one models don't need to be very big. Its easy to specialize them to what your software does and run them where your software runs.