Building something new. Previously: CTO at Autonomy

San Francisco Bay Area
Joined November 2007
Pinned Tweet
Here’s a look inside my software factory. I’ve been using it to build itself and two other projects since May.
6
16
3
196
24,177
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.
7
5
457
> Cost: $2.40 per CVE found. That’s 27x cheaper than Opus 5 ($64.96) and 56x cheaper than Astra ($135.23) xitter.cf/pilvar222/status/21132…
Unsurprisingly, DeepSeek V4.1 Flash 1017 is mogging all other models on our cybersecurity benchmark - At pass@3, it rediscovered 87.5% of the benchmark CVEs (28/32). That ties DeepSeek V4 Pro 0813 for 2nd place, behind only GPT-6 Astra (90.6%) - Single-run recall is 70.8%, matching Opus 5 and Grok 4.7. The previous Flash was at 65.6% - Precision went from 78.9% to 86.4%, so most false positives are now gone Cost: $2.40 per CVE found. That’s 27x cheaper than Opus 5 ($64.96) and 56x cheaper than Astra ($135.23) @deepseek_ai keeps pushing the Pareto frontier 1/4 🧵
53
More on how to build a software factory: xitter.cf/mrinal/status/20818234…
Here’s a look inside my software factory. I’ve been using it to build itself and two other projects since May.
1
54
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.
Here's how my software factory gets better at building and managing a codebase over time:
1
2
179
The index is structured to help agents quickly find memories (learnings) that are relevant to whatever they are working on.
1
15
On the upside: The fact that old bugs are being discovered is a strong indicator for optimism: Old bugs are deep bugs that survived many years of code review. Finding a bunch of old bugs is the clearest indicator that technological progress in bug detecdtion is real.
2
24
1
150
8,858
Here's how my software factory gets better at building and managing a codebase over time:
2
1
16
928
mrinal retweeted
The biggest misread of anyone predicting the end of software engineering was imagining that the world only needed a certain amount of software, and bringing automation to the field would reduce the need for labor. Exactly the opposite is happening where essentially most things are actually turning into software. Because agents can use tools, work with computers, write software on the fly, and process data like humans (but far faster), we can now throw “software” at problems that never could reasonably be digitized before. What that leads to is the role of engineering taking on greater importance in the economy, because we can now engineer far more systems and processes than were possible before. If you’re a bank trying to do new forms of trading, engineers are often your first bet. If you are in life sciences, you expect more and more research and lab work to be engineering centric. If you’re in manufacturing, you’re trying to automate more of the supply chain, all that is engineering. More and more work is shaped like software problems. Yes we’re not going to be coding manually in the future. But almost everything will be code, which means those that understand it are in a fantastic position.
Some observations about the "total" automation of software engineering: 1. There are more software engineers now than in 2025, and demand is growing. 2. Software engineers have never worked harder than they do now. 3. They largely don't write code anymore, agents write ~100% of the code. 4. The bottom line of the companies that employs these engineers and agents (i.e. the terminal purpose of all this code) is typically not budging as a result of AI adoption. This is why you have to think in terms of systems. Automating one aspect of a system creates its own friction and moves the bottlenecks elsewhere.
158
130
35
1,125
126,277
Technical and Cost barriers to this were eliminated in the last couple months of open-weight model releasees. The only barriers that remain are Organizational.
It's really amazing to me when people think that fixing the vulnerability in the source code is the hard part. It's *by far* the quickest and easiest part of eradicating the risks from it. Fully automated, continuously deployed environments are the rare exceptions, not the norm.
2
229
I hope the OS level capabilities will be deeper than what @zeeg suggests below - closer to dots/muse etc with local models. My personal computer should be my personal agent and it must stay private.
if I were Microsoft I would build something akin to Wispr into the operating system. Its tablestakes going forward, and its insane that its not already done. If I were Apple I would make Siri actually good, because afaict it still can barely figure out what you're saying.
1
324
One viable defense against attacker agents might be to prompt-inject them back.
been talking about rogue agent swarms for months, now someone actually made first contact 🤯 @ethanelasky and team left a hidden note and a Tencent Cloud agent fleet hitting Alibaba's Amap 2,600+ times wrote back when they got blocked they just routed around it with someone else's leaked key... this is the attack surface now and growing faster than ever xitter.cf/ethanelasky/status/211…
139
In fact, I think, continuous agent-driven penn-test ... where white-hat agents are continuously attacking your own infra to find weaknesses before rogue-agents do will soon become a service all companies will run internally.
This is super cool! I think we should have communities of humans and swarms of agents continuously playing capture the flag on critical security infra. This is a great approach to incentivize that.
3
1
2
358
This is super cool! I think we should have communities of humans and swarms of agents continuously playing capture the flag on critical security infra. This is a great approach to incentivize that.
Amazing work hackers and especially @PaulosYibelo
1
1
2
483
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.
was at a community event and was asked a somewhat sad question: should developers be afraid of the labs eating the new possibilities jev opens up? with AI (system one) + software (system two): 1. there's no going back to a world without system one models 2. you control the software! 3. there's no way AI could beat the efficiency of this combo 4. you don't even send the model providers your whole program logic I think the days of "wrapper" apps will be seen as some of the darkest in software because people essentially did all of their programming in a system message and sent it over to a third party who was incentivized to bake that behavior into their 1st party product... keeping your logic in code and only asking AI for the minimum reverses that and keeps all of your logic yours. if you decompose enough, model providers can't even figure out what you're working on
2
229
27 to 31 billion parameter open-weight models currently perform better that Jev on some axes and close enough of other axes. Make an eval set of decisions that are relevant to your application. See how these off the shelf options perform. If they're weak on certain axes ask your favorite coding to help you fine tune a LoRA adapter. huggingface.co/spaces/multim…
61
Also true for VPs. For a few years, it became acceptable especially for VPs of Engineering to not be "hands-on". It was a mistake.
3
369
About these: "long running main conversations" in a software factory that @zeeg mentioned below. I've been thinking of them as "User Interface" agents. In Fluent each slice of specified functionality is built by many writers, testers, reviewers, learners etc. Anywhere between 6 to 100+ agents are run during the lifetime a work item. And each slice of functionality may get broken down into many work items. If you don't have an agent helping you keep track and interject .. the whole process starts to feel like a black box. What happened to the thing I asked you to do? Is it moving towards finishing or is it stuck? Have the agents made sensible calls so far? Fluent has a dashboard of sorts but its cumbersome to piece together the whole picture when so many things are happening across all the work you've delegated to the factory. And a dashboard definitely can't answer that last question in my examples above. I usually have several such "user interface" agents open depending on what ongoing work I'm paying attention to that day. Its not 1-to-1 with "project" if we define project as one codebase. In some conversations, some friends have referred to such agents as "orchestrators" ... they're not, because the factory is the actual orchestrator of work that is getting done, these agents are an interface to the factory.
building the pieces-that-can-actually-work of the software factory, and you can kind of see a convergence from folks who truly operate and ship these agents every day claude code's projects behavior is where my head is at today. we had a few discussions/tickets that all related to this kind of functionality: larger or longer running tasks, that need to be trackable with artifacts, broken down, etc. i havent had the opportunity to use it much yet, but it seems like a great addition to claude code the version we're building in Junior likely will be different (its multiplayer if nothing else), but i think its the right direction. i tried this approach (long running master conversation) that you're seeing now pop up (incl. in all these personal agents) early on with my own agent and it made the experience wayyyyy better. in my case it was naive and every single message was a new thread, and it'd simply have some context embedded to know recent threads/history. it wasnt efficient at all (everything is a new thread, so everything is uncached), but the reliability was so much higher and it retained context well enough that you didnt even realize this was happening
1
2
177
Here are 14 points about AI safety I made on the Ezra Klein show, and some impressions about the experience. ​​nytimes.com/2026/10/09/opini… 1. Intelligence isn’t power — An A.I. system being powerful is not a property of the model itself. It’s a property of what powers we choose to give it in the real world. 2. The capabilities and behaviors we saw in the HuggingFace and other hacks weren’t entirely emergent. The models were trained for persistence, cooperation, and cyber tasks. The RL environments in which they were trained had various issues that led to the unintended behavior. 3. I agree that controlling highly capable AI agents is different in some ways from controlling an airplane or a nuclear reactor. The agent’s intentionality does make a difference to our approach compared to traditional engineering problems and domains. But it is still an engineering problem. It is not a solved engineering problem, but it is a solvable one. 4. A lot of effort and money has been put toward alignment. That’s important and has proved useful, but if the same amount of effort and money had additionally been put toward control (sandboxes, monitoring, and other guardrails outside the model itself), we’d be seeing very different results. 5. Models getting smarter doesn’t necessarily mean safety gets harder, because capability gains improve defensive abilities too. In many ways it makes safety easier rather than harder. What matters is how the attacker-defender balance shifts, and we have agency to shift it back to defenders. 6. In cybersecurity, long before AI we reached a point where automated systems were superhuman at finding certain vulnerabilities. It helped defenders over attackers because the same tools are used by defenders to find and fix vulnerabilities in software before even shipping. There is a constantly shifting equilibrium, but it is not a new problem. 7. I pushed back on Dario Amodei’s term “operational excellence” to describe recent organizational failures. Excellence is still far out on the horizon. Ezra offered “operational adequacy”. I think that would be a good start — behaving like any mature company instead of a startup-like culture. 8. Defensive AI agents will have to be part of the solution, as uncomfortable as that seems. It’s a new paradigm. We won’t be able to figure it out right away. But the fact that both offensive and defensive technologies escalate in capabilities and complexity is a fact of technological civilization, whether in the digital or physical realm. 9. Ezra expressed some incredulity about my being okay with the ratcheting of complexity. I think it’s fair to be concerned. But safety technologies will never be fully legible to the public. People will have the same reaction if they see the immense complexity of safety in any other high-stakes domain such as nuclear or aerospace. We govern them pretty technocratically. 10. The weirdness of the current moment in cybersecurity absolutely does have historical precedents. There was a prolonged period of profound destabilization when worms and viruses started a new offensive paradigm. It took us well over a decade to develop effective defenses against it. This time we can hopefully get there in less than a decade. 11. I continue to be skeptical about the possibility of superhuman persuasion abilities from superintelligence. (Claims to the contrary tend to confuse two very different senses of the word persuasion.) 12. What worries me is not the capabilities of the technology itself or the possibility that we will get no warnings before catastrophic risks materialize. We are getting plenty of warnings! But our policy and organizational responses to the warnings remain inadequate. 13. Companies can and do make decisions that are against their own long-term interests because they are too focused on short-term metrics. This is how I interpret a lot of what happened with social media over the last decade. 14. AI companies are also acting irrationally against their own self-interest in some ways. The “we can’t slow down unless we’re forced to” view comes out of the mythical belief in superintelligence at OpenAI and Anthropic — that the race to RSI means everything for the company, for the country, and humanity. I think it’s actually in both companies’ self interest to slow down unilaterally. I would argue that the alarm coming from their employees is not evidence of beneficence so much as it is evidence of the underlying fallacy that’s causing the irresponsible behavior in the first place. (Beyond safety, we also talked about the economic impacts being gradual, the fact that intelligence is rarely the actual bottleneck, labor impacts being small and uneven, Jevons’ paradox, the changing nature of knowledge work, and more.) ==== A few impressions * Talking about a specialized topic on a podcast that has a big and broad audience is a balancing act. The producers stopped me many times during the interview to tell me I was being too technical (understandable!). I tried to be nuanced but this conversation is necessarily a distilled version of the arguments @sayashk and I have made in our essays (especially normaltech.ai/p/the-ai-as-no…) which are themselves written for a somewhat broad audience and hence distilled in complexity from our notes and 1-1 discussions with peers. * I knew Ezra had well-formed views on AI safety that were different from mine, so I was expecting a tough interview, but he also seemed like a fair interviewer. It went about as well as I expected and I feel like it was a good debate / conversation. I wasn’t necessarily expecting to change minds but I was glad to hear from people who found it thought provoking and looked up my essays and other work. * The interview was about two hours, edited down to an hour. I was a bit nervous waiting for it to land, because I knew the editing could make a big difference to how I came across. It turned out well. They even did things like find archival footage to illustrate my point that the early days of worms and viruses was a weird time in cybersecurity. * I use AI to prepare for interviews. I have an agent that has read all of my output (books, articles, essays, talks, podcast transcripts, tweets, internal notes — on the order of a million words) to pull out pithy explanations, examples, analogies, and other talking points that will probably work well in a spoken format. Reviewing this file before interviews is extremely helpful. It is of course not the only way I prepare but it’s the highest bang for buck. Maintaining this file would be a massive amount of grunt work and there’s no way I’d do it if it weren’t for AI. I mention this because there’s a very large space of beneficial AI uses in knowledge work that _don’t_ involve cognitive offloading. They don’t get much hype on social media so people might be unaware of how much mileage you can get out of them, with little downside.
50
94
29
451
56,733