Yeah, so I think the engineering world is kind of waking up to this idea of background agents, cloud agents, uh, whatever you'd like to call it. And I think we saw a shift around the December time frame of 2025 where the models Opus 4.5 and GPT 5.2 reached a capability where we moved away from kind of handholding the model and being able to actually more or less autonomously drive the model. And what I mean by that is that we could pretty much go from a specification to a completed pull request assuming the spec was good enough uh with very little friction.

In retrospect you know we always thought it was ramping up but then even now over the last 3 4 months from today it's been ramping up even faster. Honestly a lot of it was stripping out parts of Devin that were no longer needed with that jump in intelligence. ... there's this funny graph where our usage of PRs or our merged PRs has grown 7x since ... Devon commit percentages on all Devon repos was 16% in January and now 80% in March.

Yeah, open inspect came about through primarily my clients observing how they were using tools like cloud web, openai's codex at the time and seeing some of the friction that they were having with it. Primarily the claw web was being used through Slack and a big issue they ran into was that these sessions that were launched were specific to whoever called it via Slack and so if a PM was the one who invoked the session and they would then go to pass context to engineering, engineering can't see the session and that in itself was kind of a dealbreaker.

I thought that having a background agent system is going to become a critical infrastructure within their company. And so because of that, I think that I wanted to open source it so that they could fork it and put in whatever customization they wanted. ... you kind of sit in this weird in between gray area where what are you actually selling? You're selling I guess the infrastructure. You're selling the integrations maybe.

Yeah in a background agent systems you have a decision to make of where the agent is actually going to run this is typically described as the harness in the box or out of the box. ... The negative trade-off you're making is primarily security because the agent is running in that box. Unless you otherwise design it, all of your secrets need to go into that box as well. And given the nature of AI, it can be unpredictable and you could very easily end up accidentally x-filling your secrets.

Now the out of-the-box is the idea that we are going to have the actual agent running not directly in the sandbox and we'll have quote unquote the brain of the agent running in some type of worker uh control plane. That sandbox then is going to serve as the hands where the brain is basically operating and making tool calls into that environment to manipulate it. ... we actually from the start build Devon to what we called separate the brain from the machine.

The hardest part of it's been a perennial problem since the start of the company of how do we help people get the set up because not everyone just has working cloud environments working out of the box. ... a lot of the times it's go talk to Bob and get the secrets and that obviously doesn't work when the agent needs to actually set this up.

... our info people realized that actually the root cause of this problem is that a lot of these virtual machines actually underlying them don't use real file systems. They use these network file systems where things are actually cached over the network actually in S3. So when you're grepping, you're actually making network calls. ... we had to eventually go swap out that network file system.

The block diff file storage format which is a file system format that we built so that the VMs could be spun up and down very quickly. Every time you save and bring the machine back up, you're only doing work that's proportional to effectively the diff in the file system.

When people think about the ability of an AI to run your app and test it, I think they actually overindex on the computer use part of it because computer use in my mind is the literal okay you want you know a button you want to click can you emit the right coordinates to go click that button. I think testing is actually a really interesting problem solving challenge for these AIs because if you wanted to do arbitrary testing ... you have to reason through what how do you first run these applications to orchestrate with each other with the right version of the code.

That is where we spend most of our time when we think about this testing problem. Not so much the computer use part. ... one experience that we spent a lot of time tuning early on was what is the right experience on GitHub for these tools. ... what I really like is that it labels what it's testing. Um and then it and then you actually see the the cursor and everything.

I think memory as a whole is a pretty unsolved problem and it is why I've been kind of hesitant to add it. ... we wanted it to pick up things over time and not need the user to be proactive about teaching Devon things. So, anytime you remind Devon, "wait, no, that's not quite the way you're supposed to use git," we actually want Devon to say, "hey, do you want me to actually just remember this for the future?"

Generation like you don't want it to remember something like if you asked one time to like oh please open as a draft PR. You don't want everyone forever now should get their PRs as draft PRs. ... should we rebuild memories to feel more like a file system that we let the agent navigate on its own? ... Maybe it's just Devon creating tickets, which then maybe some humans do, but then maybe other Devons do.

The meme that I have is that your codebase regresses to your worst engineer because that engineer who is very gung-ho about AI and is not auditing their code, their pattern starts cementing into the code and now the AI is referencing their patterns. ... The AI is seeing that as the pattern of how things are done and starts to then exponentially grow this slop.

One thing I'm very bullish on this year is agents calling other agents or spawning sub agents ... But I guess it somehow creates like a really chaotic world. ... I think that demonstrates a level of maturity and communication today that makes a multi-agent world possible. like when can two agents who have seen different information come back to each other and actually figure out who is right.

The easiest and most common use case I see across everyone is SRE use cases. ... we want the agent to be the first responder on that. ... collect that context ahead of time is huge because again that agent is integrated into the production logs, the database, it has full visibility. ...

I'm seeing a lot of teams where the idea of who's actually contributing code is starting to change. ... the PM is not creating an issue anymore. The PM is just prompting through Slack and the pull request is then being created. ... Common numbers that I hear are anywhere from 1,000 an engineer up to 5,000 an engineer.