More generally, I and some other people, e.g. @helpful-quill-73496 @curved-angle-80449 are thinking about what the remaining bottlenecks are with a completely autonomous software factory: 1. finding which issues to prioritize: this is partly due through forward looking product priorities and vision, and partly through feedback from OSS users and enterprise customers. for the OSS users, @calm-artist-7206’s work here is excellent, and it’d be good to come up with a holistic solution that all three sources of info into account 2. making issues fully specified: I have been working on the

ready-for-dev

labeling, but it still needs a lot of work, probably including LLM-based processing judgement after all the automatic checks have passed. 3. auto-review: review is still not quite reliable enough for us to just trust it. we need to collect examples where the auto-reviewer was wrong, including gathering the examples from the slack thread in this slack where we discussed it, and also from github where the auto-reviewer approved, but the maintainer requested changes. 4. auto-testing: one of our review criteria we added in github.com/OpenHands/OpenHands/pull/17089/changes is that we need to have live before-after evidence, but we don’t currently have a An auxiliary concern in all of these is security. I think we can implement stronger guardrails through (1) better sandboxing on our automations server, (2) adding stronger guardrails to software-agent-sdk, e.g. by enabling the gray swan security analyzer, (3) different access controls for different automations through agent profiles. I’m thinking of turning the TODOs here into a software factory project that we can track and execute on so any feedback is welcome!

I personally believe that the reviewer agent depends heavily on LLM. Maybe one day LLMs will all “converge” as some people believe, but I don’t think we’re there. (I can even see some arguments why we might not get there.) I think one way to address this better includes: • always display the LLM Profile • maybe some easy way for humans to see what context it had, too, that lead to a particular review (e.g. links to skills at the correct commit hash) Simon was idly proposing somewhere that we could all have our reviewer agents with a skill/memory in context that channels the LLM towards the kind of thing that we want to see covered. I personally love that. I want to tweak my agent so that it does the things that I really want to see in a PR, and doesn’t care about the things that are in the default reviewer agent; which includes not repeating what that said, too, but it’s not limited to that. Also, not all PRs would need this customized-for-me agent. But some will. Distinguishing between them is also an LLM-shaped task I think. In the past, we had (still have?) some attempt in the default reviewer agent to assess risk. We are not making use of it, I think. That could be a way, though. Another way is what my agent was doing in the attempt you linked: it knows me, it has memory with a bunch of criteria and leanings, and it distinguishes the PRs I need to see in some way from those I don’t.

Yeah, these are good points! So I think the TL;DR is that overall the direction sounds good but we need to lean into customizability, and perhaps even configurability depending on the user who opened the issue/PR

Of course, overall the direction sounds good! To be honest, I felt you were heading in this direction for a long time. I kept asking myself what are the prerequisites, and how to fulfill them. Maybe it’s what we will all learn. It does feel like a bit of a wild experiment 😅, on these codebases, but it’s very reassuring if we focus this experiment on the open source repositories, and be ready to learn what we can we do at the current LLM capabilities. Some thoughts below… Software factory story Please let me take a step back. So we want to try to make the SWE work in the Open Source repos an autonomous factory. The five main, related, repos. People call something like this a “dark factory”. Why is it “dark”? Well, because there are no lights: I picture a long flat building, where there are only machines inside. No humans are operating them, so no need for lights. Machines can work in the dark. I think that LLM capabilities today are close, though not quite there - give or take that I haven’t really tried Fable and Astra. For the rest, we still need those pesky humans. 😅 But for what? Maybe in the hallways. I think we still need some lights in the hallways. The rooms are dark (or can become dark), but the hallways - what are the hallways? They’re the main way through the system, they and their walls separate components and sub-components. So humans can patrol around, and look at the shapes, and sometimes push a protrusion in the wall to make it clean and lean. The humans use flashlights sometimes. They enter a dark room and point the flashlight around a bit: see if the walls are still in place between rooms, or some machine took the wrong turn and made a hole in the wall… then they need to act and glue it back in place. Humans usually point their flashlight to the walls, not down to the floor where machines are working. There be dragons there! 😅 No, they just listen to the humming in the room - if it sounds right, and the walls are in place, it’s fine. Then they get out. Let it hum. Note that there are rooms, it’s not a single large room… that is, it has walls separating components, and it’s terribly necessary that walls exist (otherwise we’d go towards spaghetti - machines would get enmeshed into a mess of cables and stop working) The doors. The doors to the building are not fully in the dark. By definition, they’re half inside, half outside in the sunlight. Through doors, things enter the system, to be processed. Features, wishes, user feedback of course. In OpenHands’ case, it’s a dev tool, so we dogfood it, too, so the needs we discover through use, too. I think there may be some backdoors, on the other side of the building, in the shadow, where the system feeds itself… Bugs. Automations discover bugs themselves, reproduce bugs, fix bugs, review fixes. Or maybe those are just inner doors - where a drone patrols around, and finds a hole it can see, and feeds back into the system a fix. I think there are holes it can’t see yet. We need some hallways and flashlights for those. Why? Because LLMs love complexity. Oh, do they love complexity. If the system lets them have their way on that, they’ll entangle themselves into a knot. ——— Just the other day I was thinking about this factory, since of course it’s clear we’re moving towards it - and I was writing about this building. Please see the screenshot below. 😅 Yeah, LLMs are still perfectly able to tie themselves into a knot. Guardrails/constraints I think I would add to the list more guardrails or constraints. With any opportunity, we should add constraints for the next agent to do the right thing. You mentioned security guardrails, of course; and it’s not just security, we have a bunch of other guardrails in CI. I suggest these other kinds of guardrails are enforcing the shape of the system. Like this guardrail. And this - or maybe we could name this one self-healing automation. In essence, I think the better we make the code design, and pin it down with lints/workflows/precommit/whatever, the easier it becomes for the next agent passes. Easier to not make mistakes anymore. We could have a sub-goal to make sure it doesn’t make the same mistake twice. ——— Self-healing To put it differently: I agree auto-review is not perfect… I’ve been trying a lot and thinking a lot about this. I think a complement to auto-review is important: self-healing. I submit that the factory needs self-healing automations, running periodically, suggesting improvements in design at all levels of abstraction. In other words, if we accept that the agent’s review is enough when it’s not, and merge to main too soon, then the focus on doing things right moves: from before it’s in main, to after it’s in main. Redesigns, refactors, gain a new life. I mean, what is the main risk with insufficiently good review? Well, that bad code design slips into main, and, in time, makes the codebase unmaintainable. OK. So I ask myself, how can we address that? All the above: • guardrails/constraints • refactorings to fix code design (and put guardrails in place to pin it down) • (self-healing) automations to visit the codebase with the right prompts to focus the LLM on known design patterns and tell smells or improvement suggestions And one more: code review has been changing into code design review, for a long time now (several LLM generations, an eternity) Review: review the high-level behavior and design. • not exactly the code, most of the time (in the open source projects) • the code design - from “does this feature affect the right files or is there an unexpected file?” to a quick overview of the relations / data flow / changes involved Design docs Some of us have started to have the agent fill in design docs, with focus on high level view of the PRs, or of the entire feature/refactor. I suggest to make it standard, for PRs/redesigns that go deep enough. That will help the auto-review too (it’s context); but also: if the author feels it’s relevant and if other people should know about it, they can notify here, in Slack, and link that doc, so we can figure out what they propose, easier than by manually reviewing code. Reading at a glance is amazing, and we can just use the agents to give us the view we like. GitHub’s raw diffs are terribly time-consuming in comparison. ——— TL;DR: Yes, of course this is an exciting direction (and a bit scary, but I think with self-healing in place and use of these amazing tools for visualization and collaboration, we can have a lot of fun). I think there are others I missed above… such as e2e moved to test ALL behaviors of the system… 🤔 I'll stop here though, please do tell what you think. And where do you want to record the software factory project?

Wow, thanks for all the thoughts! I’ll read thoroughly and respond in earnest when I have a moment

I just want to add to the discussion quickly a thought… I see sometimes, around the OpenHands project, comments that assume that building a software factory, or letting agents do the SDLC stages… would mean only that; that, well, agents are doing triage, implementation, review etc. and everything else pursues as it did before. I doubt this assumption will prove correct. Once agents do more and more of these, I think more things change, than just triage, implementation, review. Much more. The old SDLC stages are melting, some stages split and/or change places[1], idk, new stages may emerge[2]. In other words, I feel quite strongly that the new SDLC is not quite like the old SDLC. In some projects, I see it melts processes, and morphs them into some other processes that weren’t possible or realistic before. That affects orgs, strongly, since human processes were built for humans, and assume that some things are hard when they are not with agents[3], and that some things are easy or enough, when they are not with agents[4]. I have many thoughts about this. For us to look at an idea on the difficulties here, I'd submit quickly a funny article, it’s not about SWE, but it’s at least food for thought. 😅 ——— [1] such as the pre-merge review and post-merge review; or the revival of thinking architectural trade-offs before rushing to implementation [2] self-healing is maybe an example of this. [3] “implementation stage” was time-consuming, hard, expensive; coordination tax was necessary. [4] e.g. can’t write contracts to cover you when your agents get affected by random prompts, as you could with humans.