Robert Brennan (2:49)

Yeah. So there's a huge variety of tooling out there right now for code generation. So it's a very hard space to navigate. There's two ways I like to bifurcate the space. One is, on the one hand, you have a lot of tools that are really meant for, like, rapid prototyping. There's some really cool stuff happening there. Stuff like lovable bolt.dev, v0.dev. They tend to be very visual. You're getting quick prototypes of games or websites, things like that. Some really fun stuff happening there. And it's stuff that's enabling a whole new set of people to experiment with software development. People who maybe like designers or product managers don't really have coding experience, maybe have very little coding experience. They can now build whole apps, which is super cool. And then on the other end of the spectrum you have stuff that is much more oriented towards senior developers who are shipping production code. They're working on a code base that's going to go and serve millions of users where you have to be a little bit more careful about what's going on. Also some really cool stuff happening on that end of the spectrum. And then the other way I like to bifurcate this space is that you have some tools that are very tactical. So stuff like GitHub Copilot, where it's inside your IDE, it's suggesting code like exactly where your cursor is inside the code base. You're zeroed in on a task and the AI is just helping you move faster through that task. And then on the other end you have these tools that are much more agendic, right? They're able to just take a quick human description of a problem and then go off and work for 5, 10, 15 minutes while you go get a cup of coffee or work on a different problem or catch up on email and then it comes back to you later with the solution. And open hand sits basically on the right end of both of those spectrums, right? We are really oriented towards senior engineers who are working on production grade code bases and we're really oriented towards those more agentic workflows where you are giving an agent something to work on and it can iterate forward on its own without you having to babysit it, without you having to be, you know, squinting at your computer screen trying to figure out where you should be editing.

Daniel Whitenack (4:50)

Yeah, that's super helpful. I'm wondering, this might be an interesting question, but I know Graham, we've run into each other in the past as related to human language related work in another context. I'm wondering from your perspective as kind of chief scientist, but also a researcher, as you've dug into this all hands project and work and product, what has been surprising in terms of challenges around this and maybe things that were surprising in terms of easier than what you might have thought. Any thoughts there?

Graham Neubig (5:32)

Yeah, it's a great question. Thinking back, in hindsight, it's kind of sometimes hard to come up with surprising things because the things that were formerly surprising now seem kind of obvious. But one of the things that I actually wrote a blog post about before was right when the Open Hands project started out, we were kind of on this bandwagon of trying to create a big agentic framework that you could use and define lots of different agents. Like you could have your debugging agent, you could have your software architect agent, you could have your browsing agent, and all of these things like this. And we actually implemented a framework where you could have one agent delegate to another agent, and then that agent would go off and do this task and things like this. One somewhat surprising thing is how ineffective this paradigm ended up being from two perspectives. So the first perspective is it didn't really. And this is specifically for the case of software engineering. There might be other cases where this would be useful, but the first is in terms of effectiveness. We found that having a single agent that just has all of the necessary context, it has the ability to write code, use a web browser to gather information and execute code, ends up being able to do a pretty large swath of tasks without a lot of specific tooling and structuring around the problems. And then the other thing is, building many, many different agents is kind of a relatively large maintenance burden if they're not very easy to define. So we've basically gone kind of full in on having like a single agent that can do many, many different things. But in order to do that, it has to have the ability to pull in, you know, whatever information it needs. So we have a framework called microagents, where basically you can pull in a new prompt or a new tool or something like that for a particular task, but the underlying overall agent is a single agent that can do many different things.

Chris Benson (7:38)

Quick follow up on that. Just for listeners who aren't really familiar with agentic workflows and stuff, could you talk just a moment about what that means if you've been developing for a number of years in the more traditional workflows that we've all started out at, and now we're hitting this world of agentic possibilities, could you talk a little bit about what's different for the user from where they came from in traditional development environments to what gentic development workflows are like?

Robert Brennan (8:11)

Yeah. So, you know, I think the sort of like step one of integrating AI into your development process was like copilot, right? Where it's really just plugging into Autocomplete, right? We're all familiar with Autocomplete, we've been using it for decades, and it just got a thousand times better. All of a sudden, instead of just completing a class name, now it's writing like, you know, several lines of code. So that was like a huge boost to my productivity. When I adopted Copilot, I was like, yeah, this is amazing. And then I was still for bigger chunks of code. I was going to ChatGPT and I was like, hey, can you write a SQL statement that'll do X, Y and Z? Things like that. And often I found myself doing this workflow where I would ask ChatGPT or Claude to generate some code. I'd paste that into my ide, run it, get an error message back, paste the error message back into Claude or ChatGPT, and I just do this loop. And at some point I was like, well, this is dumb. I'm just shuffling text between one app and another. And that was actually when I built my first agent, basically where I built a little CLI that would just do that loop with Anthropic in the background. And that's kind of like the core of what an agent is. It's doing a full loop where you basically, you give a problem to the agent and say, okay, I want to write a SQL statement that does X, or I want to modify my app to add this new feature. The agent writes some code, it runs the code, it sees what happens, it gets some kind of output from the real world, whether that's like the output of a command or maybe the contents of a webpage or the contents of a file, puts that back into the LLM's context, and then it can take one step forward, closer to its goal. And then, you know, you can as, as you get kind of better and better and more accurate at taking one step closer to your goal, you can take on longer and longer range tasks. So I would say in the beginning, agents were really good for things that would take like 10 steps. You know, something really simple like implement a new test and then make sure it passes. And now they can implement things that take hundreds of steps, which is really cool. I mean, that's the change that we've seen over the last six to 12 months, is that they're able to take on these huge tasks. So I can say implement feature X front end, back end, and add testing. And today's agents are able to just continue executing, stepping forward into that until it comes to a full pr where all the tests are passing and it's just kind of packaged up and ready to go.

Daniel Whitenack (10:29)

Selfishly, maybe I'll pass on a question. I was sitting around with a number of people at the conference I'm at last night, and there were some opinions. This gets to some of what you were just talking about. I mean, some of what you talked about at the beginning about this being geared towards more senior, maybe more senior developers working in existing code bases or something like that, but also what you were just talking about, about that kind of workflow. It was kind of the opinion around the group that I was with last night that, hey, a lot of. A lot of these tools might be well suited to senior engineers because you can iterate like that and actually have a sort of smell test for what's going right and what's going wrong, but not really for, you know, less experienced developers or new developers who really don't have that ability. I'm curious to understand, like, your. Your perspective on that and maybe who's sort of using this and who's using it successfully, I guess is the question. And what does that person to look like?

Robert Brennan (11:30)

Yeah, I think it's important to realize that you still need to keep all the same code quality controls in place that you did before the age of AI, if not more code quality controls. Right. Everything needs to go through code review. You need somebody who's familiar with the code base to look at the changes that are happening. I would say one of the kind of failure patterns I see with the technology is a lot of times a junior engineer or someone who doesn't really know how to code, you know, vibe codes their way to like a pretty good mvp. Because these agents are especially good at like, Greenfield stuff, right? They can build a, you know, a to do list app all day, and then as you layer on more features over the course of like, weeks or months, the code base just starts to rot a bit. Like, the agent adds a bunch of. Maybe it like duplicates a whole function because it couldn't find the original function, or it just keeps expanding the single function so that it's like thousands of lines of code and has all these forking paths. If you don't have somebody looking at the changes that are being proposed and critiquing them and like telling the agent, hey, you know, you added this new function, but we have an existing function that does that, or, you know, this function is getting too big, please refactor it. If you're not looking over its shoulder and critiquing its work, the code base will just grow into this monster and you'll have to throw it all away because it's just, it's, it's beyond repair.

Daniel Whitenack (12:47)

Well, I do want to get into some of the kind of unique elements of all hands and the perspectives that you all are taking. One of the things, of course, that strikes me right away as I. It's even top of the webpage when you go there is your approach to do this kind of open source, so open source approach to this kind of tool for developers. I'm wondering both of you could speak to this, but maybe Graham, you, you could start in terms of like, obviously you've built various projects over time and done research and been plugged into the research community. Why from your perspective, was it important that at least some portions of, some key portions of what you're building here are open source and you know what you think that might mean for these kind of tools, including all hands moving forward?

Graham Neubig (13:43)

Yeah. So there are a number of reasons why we decided to do this open source. The first reason is I think everybody in our community believes that this is going to be very transformative technology and it may drastically change the way we do software development going forward. And we have two options. We have an option where software development is drastically changed for us by other people, or there's the option where we do it ourselves together. And we believe in the latter approach. Basically we believe that if this is going to have a big effect on software development, software developers should be able to be able to participate in that. That's kind of the ideological point of view. The other point of view is we also believe that from a research perspective, open source, especially from the point of view of agent frameworks, not necessarily the underlying foundation models, but from the point of view of agent frameworks, open source is not ever really going to be behind the closed options. And the reason why is because academia and all these people really love this topic. They really love working on it. If we have an open framework and we can provide a platform both from the point of view of having a good code base that's easy to experiment with and providing resources to people who want to do experimentation on these topics, then the open source community together will be just as good as any company that is working on this in a closed manner. Instead of reinventing the wheel, we can all invent it together and come up with something really good that's good for developers, developers, interesting for the academic community and other stuff like that.

Chris Benson (15:37)

Could you talk a little bit about how you bring developers into this process, you know, since that's kind of foundational to how you're operating. Could you talk a little bit about what you're looking for, how you bring people into your community and kind of ramp them up on that?

Graham Neubig (15:51)

Yeah. So it's kind of interesting. Our software is a little bit complex because there's necessary complexity in order to do things like make a very strong agent, give it all the tools it needs, allow it to run in a safe manner and things like this. So if people. One thing that we try to do is we try to, if people are interested, point them in the direction of issues they could start working on. We have a unique problem which is a lot of the easy issues that would be good for developers to learn more about the code base are just solved by the agent. So we're still working through the best way to fix that, but especially front end stuff. We have a new front end capability that we'd like to have. We've had a lot of people join successfully through that. And then we've had longer term research projects where we collaborate together with people in universities and we've been pretty successful at doing some interesting things there, I think.

Daniel Whitenack (16:49)

Cool. Yeah. I'm wondering, Robert, from the perspective of obviously sometimes this is hard to do on an audio podcast, but if you could just give a sense. I just logged into All Hands not that long ago online, so I see some visuals, but if you could maybe paint the picture. So there's like the open source side of things, which I'm assuming means people could maybe host All Hands themselves, which might be interesting for some, but you also have kind of a hosted version of that. Could you just talk us through those options? How kind of people can access this and what they'll see, how they integrate or how they connect their code into. Into All Hands to get started, that kind of getting started picture.

Robert Brennan (17:39)

Cool. Yeah, yeah. So for the open source, everything runs inside of Docker, so that includes the application itself. You just run Docker run and you'll see, you know, a web Interface running at localhost3000 and you can just drop in a prompt to the agent. You can also connect it to GitHub by generating a token inside of your GitHub settings, plugging that into the UI and then you can start to pull and push to your repositories. It's a little bit tricky running things locally because not only do we run the application in Docker, but when you start a new conversation with the agent, we want to make sure the agent's Work is done in a nice sandbox way. So the agent gets its own Docker container to work inside of. So there's a little bit of trickiness. We have to deal with a lot of like troubleshooting, you know, why isn't Docker behaving properly kind of stuff. So it's a little bit of a difficult application to run locally. So we actually created app.AllHands.dev where you can use Open Hands in the cloud. This is a really just like, it's pretty much, you know, one for one in terms of the functionality with the open source, but there's a bunch of convenience features because, you know, A, we have this persistent server in the cloud and B, we can take care of all the infrastructure for running these sandboxes for the agent. So like, you know, for instance, when you start up a conversation in the cloud, sandbox comes up within like one or two seconds rather than having to wait like 30 seconds or so for it to start up on your local machine. And we also can like connect into GitHub a little bit more seamlessly because we can have an OAuth application where you just like one click login and you know, we can access everything. And then the cloud feature that I love more than anything is that if you can, if you leave a comment in like a pull request, like say the tests are failing, you can just say open Hands, please fix the tests. And because we have this long lived server in the cloud that can just kick off a conversation automatically and Open Hands will just commit back to your pull request. Those are actually the interactions I love the most where I don't have to go into the openhands UI and like fiddle around. I just inside of GitHub or soon inside of Slack, I just, you know, summon the agent and it just does the work for me and I get to, you know, reap the fruits at the, at the end there.

Graham Neubig (19:46)

My favorite is programming from my phone. So you log into the app and then just tell it what to do. I do that while I'm walking to work and by the time I get to work I have a pull request to review. It opens up a lot of possibilities if you don't have to run it locally.

Daniel Whitenack (19:59)

Yeah, I could imagine also just in the spur of the moment thinking of some great feature to add and a lot of those things are lost. So if you have the ability to just. I know some people are, it's when they're running on a treadmill or they're coming out of the shower or Something they can just like pop in and give a prompt and like, have, have some work be done and, and then finish getting ready and get into work. I love that idea.

Robert Brennan (20:24)

Yeah. It's funny, I feel like I'm still getting a lot of coding done despite being the CEO of the company and being in meetings all the time. Because as I'm going into a meeting, I'll just like quickly be like, hey, do X, Y, Z go into the meeting? And then once I'm done, it's just the codes there waiting for me.

Chris Benson (20:39)

It's funny, you guys are actually already leaping ahead and answering the question I was about to ask as I was thinking, Robert, on your first answer a moment ago, and that's really. It's dramatically changing the workflow and not only the workflow, but how and where you're coding and stuff like that. I'm kind of curious if you've been developing for a long time, this feels a little bit magical. And as you've had users come into this new workflow, what are the kind of the mindset shifts that are either challenges or maybe most welcome on the. Conversely that, you know, that get people productive and useful and recognizing the utility of this and benefiting from it because there's a little bit of a leap from kind of, you know, where they, where they grew up into the bold new world of. Of this. What's that mind shift like? And how do you get people through that?

Robert Brennan (21:36)

Yeah, it's a great question. It's actually very similar to when I started managing folks for one. Like, you just have to get good at thinking, like, oh no, I should delegate this. You have to kind of have that switch flip and your instinct is fire up VS Code and just start working. And you have to have that moment of like, oh, no, this is actually a good thing for the agent to work on or for my employee to work on. There's also like a little bit of a trust thing, right? Like, when I first started managing folks, I wanted to micromanage them. I wanted to like, tell them exactly how to do everything. And it ended up being just more work for both of us and frustrating for them. Once I learned to like, trust my employees and know that like, they might not do it exactly. Like, like I would do it, but, like, they're going to do a good job. They might need some coaching and some direction. But building, building that trust over time is really important. And it's the same thing with the agent. You know, the agent isn't always right. You do need to, you know, I like to say trust but verify. Right? You need to read its code and like understand what it's trying to do and where it might have misunderstood something and maybe iterate a few times through either like a code review in GitHub or by just like chatting with it inside of the application itself. But yeah, very, very similar to that management experience of like learning to kind of take your hands off the keyboard and be really clear with somebody else about communicating. These are the requirements and here's how you can improve and things like that.

Daniel Whitenack (22:54)

Yeah, Graham, I have maybe a question that I also get a lot of times one is actually related to. Chris just asked one question that I get a lot, which is the workflow related stuff. But the other question that I get a lot related to these types of tools is, hey, I've seen people create a lot of cool demos with these sorts of tools. Small projects that you can kind of like sort of regenerate if it doesn't work. But if I'm working in a large existing code base to the points that were brought up earlier, that's where most development happens. What are the technical pieces that have to be in place for you to have an agent work in a kind of larger code base or an existing project and actually have the context that's needed to, you know, needed to do things that fit, you know, have the context of other things that exist in the code base but also the potentially the context of, you know, maybe it's a company style or other things like that.

Graham Neubig (23:56)

Yeah, it's a good question. For reference, the Open Hands agent is the largest committer to our code base. So we're definitely. And our code base is rather large and complex. So I just checked now and it had 209 commits over the past three months and the next closest contributor had 142. So it's doing pretty well. But there's a bunch of technical pieces that need to go together to make that work. The underlying language model is really important and fortunately a lot of the kind of core language model providers are focusing on this. We're also training language models ourselves. But the underlying language model needs to have a lot of abilities. One kind of boring but extremely important one is the ability to edit files. So about six months ago this was a major problem for most language models. They were not able to successfully generate a diff between what the file used to, what a portion of the file used to look like and what the new portion of the file would look like or they would like add an extra line or duplicate Things or stuff like this. So this, this was a major problem. Claude is very good at this right now. A lot of the other language models are kind of catching up to be good at doing this. Another thing that's kind of more on the like especially a big problem for large code bases is identifying which files to be modifying. And this is somewhat less of a big problem than I originally thought it would be. Like, I was kind of imagining that this would be a really huge problem. But actually language models are pretty good. Even if you give them no tools to specifically like search a code base or something like that. They use find and grep and like all the other tools that a normal programmer might use and are able to kind of navigate their way around a code base. But I do think that like code search and other things like this can help this. And we have some preliminary results that demonstrate that it doesn't necessarily improve your resolution accuracy, but it definitely improves your speed of resolution. And so that's another thing. Being able to run tests and iterate on tests, being able to write appropriate tests that test whether a new piece of functionality or adding is actually working as expected or not being able to try on the language model side, being able to try lots of different possibilities. So for example, one big failure case of a lot of language models is they try the same thing over and over and over again and get in loops and never get out of that. And models like Claude are good at not doing this, whereas a lot of other models fall into this failure mode and don't do as well. So the list kind of goes on. I could talk about this for much longer, but those are some of the kind of most important parts, I think.

Daniel Whitenack (26:54)

Well, Graham, you're already getting into this, which is another thing that I wanted to ask about. Maybe you could comment from your angle of the technical and research side. And Robert, I'd be curious on the kind of business product side about generally like why you got into also building models and you know, for, for those that want to kind of take a look, there's some really great models that, that all Hands has released. It's just all dash, hands on, on hugging face. And you can read a little bit more and we can talk about the details here. But yeah, maybe first, just like, why was that a step that you all felt was important and, or kind of wanted to be part of your contribution to the space?

Graham Neubig (27:42)

Yeah, so there's two reasons. The first reason is we are an open source company and we kind of philosophically believe in open source and openness and if you're relying on a closed API based model entirely, then you can never fully achieve that goal. Another thing is practically there are issues with customizability and cost for closed models. And the best closed models are somewhat expensive. There's a non trivial cost involved with using them to do agentic tasks, especially because you need to query them over and over and over again. Having another option that's more cost effective that we can either just use as is or possibly switch over to that for easier portions of a task, but use a more expensive model for the less easy portions of the task is something that would be useful. And then customizability. We have a lot of our enterprise customers or design partners asking for some variety of customizability, be it to their code base or to a programming language that they're interested in working with and, and other things like this. And if we don't have a model that we can fine tune, we are limited in our scope of things that we can customize. So looking forward, that's something that we would like to do and we're not done yet. We just released v01, so we'll definitely continue being interested in this in the future.

Daniel Whitenack (29:24)

Awesome. Yeah. I guess from the product perspective, Robert, in terms also of the hosted version that, that you're running, the one that people can log into, are the models that you've built, are those integrated to one degree or another in that kind of live product or what's the kind of roadmap there?

Robert Brennan (29:47)

So yeah, so right now it's all Claude 3.7 under the hood. There are some really cool ways where we can build our models into the process. One is if we can route certain parts of the agentic loop or certain queries to a cheaper model rather than putting everything through the most expensive model out there without sacrificing accuracy. That's really great for our users because we can pass those savings onto them. So that's one really interesting path. Another path that we have where we have a model that is specifically trained basically to recognize whether Open Hands is on the right track to solving a problem or if it's like going off the rails. Right? So we built this model specifically based on the data set that we've gathered. And that's a really cool product feature because on the one hand like you can just recognize like, did we achieve, did we, did we solve the task or did we not and like report back to the user appropriately? We can stop the agent if it's like going off the rails and we can say hey, this is what's going wrong. Please reroute. You know, using this new strategy, we can also like launch several different trajectories towards solving a problem and then, you know, maybe pick one out of the, out of the three that we launched and say, okay, this one looks like it's going in the best direction. Keep following this one and kill the other two. So lots of really cool stuff we can do there by having a model that specifically knows kind of the inputs and outputs of what Open Hands is doing.

Chris Benson (31:12)

Well, while you're talking about that, I'm wondering, could you talk a little bit, you know, with whether the models we've kind of talked about the, you know, the frameworks and stuff being open. Are you looking at models that you're creating being open or does that say as part of a proprietary offering? How, how are you envisioning that from, you know, in terms of the, what the models are, what they're addressing, whether they're larger or smaller models, what licenses apply, that kind of thing. Could you, could you speak a little bit about your, your philosophy and strategy toward that?

Robert Brennan (31:41)

Yeah, I mean, so far it's, it's, we're, we're opening everything up, right? We've taken the position that we basically want Open Hands to be as useful as possible to an individual developer running it on their workstation. Right. We are a company, we do want to make money and so we are building some closed source features specifically for large teams who are using Open Hands together. But so far we've taken the position that basically all the research we do and all the know how for how the agents do as good a job as possible at solving software tasks that should be open source, that should be available to every developer. And it's stuff like collaboration features, things like multi tenant things like auditing compliance, stuff that like big enterprises need that your average developer working on an open source project doesn't need. That's what we're going to hold back and say, okay, this is closed source and we're going to enable big enterprises to do this stuff, you know, the way the big enterprises like to do things.

Chris Benson (32:35)

And one other follow up, just because I happen to work in an industry where security and privacy are, are really paramount. How are you thinking about like with, you know, with going instead of going off to one of the large foundation models via cloud. Often that runs into challenges for enterprises that have security concerns in particular. Any thoughts on, or something that you can offer for when it needs to be, you know, all held close, closely held data cannot Go out onto a cloud connection, that kind of thing. What you're thinking about that, either for present or for the future.

Robert Brennan (33:10)

Yeah. So we basically have three offerings. We've got the open source, which anybody can run and use for free. A lot of security conscious companies do start with the open source because everything they can hook it up to Bedrock or a local model, or basically they can plug into the existing models that the company has approved. We have the cloud offering which all runs through Anthropic, all runs through our servers, which is a great convenience for a lot of people, but kind of scares off some companies that are very security conscious. But then we can also take basically all the infrastructure we've built for our cloud offering and ship it into somebody else's cloud. So you can run it all inside your AWS environment, you can connect it to Bedrock, so it's basically all configured to stay within your walls.

Daniel Whitenack (33:52)

I'm wondering, kind of just thinking about current functionality and what Graham, you mentioned all of these commits from all hands in your own repo and some of those kind of easy, maybe first issues the developers could solve, maybe those are taken care of. How do you see kind of the level of performance now? How are you all measuring that and kind of red teaming that, testing that over time and thinking about improving that over time? How do you even kind of consider something like that given that there's so many different types of projects out there? Obviously there's academic benchmarks, I think you have the SWE bench and those sorts of things. But as a product, as an offering, how do you think and measure kind of that performance over time and what right now is performing very well and maybe where are those areas of improvement?

Graham Neubig (34:54)

Yeah, it's a great question. There's a lot to that question. But just about how we are doing benchmarking. Up until recently we were doing a lot on Swebench, but we have a very large evaluation harness that actually already has 20 benchmarks incorporated into it by our academic partners. And one thing that we're thinking about doing going forward and are actually kind of in the process of doing is we have identified the common use cases, the ways that people typically use open hands, and tried to identify benchmarks that reflect these use cases and then do a more balanced benchmarking strategy across these. So we have some pretty exciting results about things like web navigation and web information gathering, which is really, really important for like if you want to function in an environment where you have lots of docs, or learn about a new library or do data processing Data science related tasks. And then we're also doing things like making sure that you can fix broken commits. So you have like a pull request that has failing tests and merge conflicts and can you merge that in? And this is something developers hate to do, but like need to do all the time. So this is something we're putting a lot of effort into making sure we're good at and we have some good results about that that we hope to release soon. And then other things like test generation, version updates, things like this. The academic world is large, so it turns out there are benchmarks for almost all of these that have already been created by some institution somewhere in the world. And so very often we talk to these institutions and say, hey, do you want to contribute this into our evaluation harness? And often the answer is yes, because they did their work for a reason. They want it to be used. So we're using that as a way to expand our vision of benchmarking to cover the actual use cases that the users are most interested in.

Chris Benson (36:52)

Well, as we start to wrap up here, one of the things that we really like to do is to get a sense of the future going forward. And with both of you here, I'd like to ask the same question of each of you and get each of your takes for a little bit of diversity on, on how you're seeing the thing. But as, as you, you've kind of introduced us into this kind of new way of thinking about development going forward and what's possible for old guys like me. It takes, it's, it's definitely changing how I think about development and this is moving really, really fast right now and, you know, it's accelerating. I'd love to understand how each of you sees the future both in the space itself, in terms of changing the world, in terms of developer workflows and your role in that process as an organization and as an open source community, how you see those going forward. I'll let you guys decide who wants to go at it first, but would love to hear each of your perspectives.

Robert Brennan (37:59)

Yeah, I think the thing that's really exciting for me is the idea of bringing the next, you know, billion developers into the fold. You know, when I, when I first started learning to code, I felt like a wizard. Like I could just all of a sudden make my computer do anything and I could build all sorts of different applications and I was, you know, a baby engineer, I was building all sorts of nonsense and. But I just, I felt so powerful and so excited and then that like, that fades over time. And, you know, it becomes a job. And then I would say over the last year or two, I've got that excitement again. I feel. I feel like a wizard again. I can get so much done using large language models and using agents. And so I'm really excited to bring that feeling to a whole new tranche of people who have maybe had ideas for software that they want for workflows that they want, for applications that they'd like to have and just haven't been able to bring them to life. And I think it's really exciting that they'll be able to do that. I think there's a lot of questions as to how we enable them. Like, you know, my mom definitely has some really cool ideas, but she has no business like monitoring a production database. And so I think we're going to need to rethink like how infrastructure works and how we ship applications and things like that. I think there's a lot of thought that is going to need to go into that and I'm really excited to see kind of what shakes out.

Graham Neubig (39:20)

Yeah, I love Robert's answer, but from a completely different angle. One of the things I have in my introductory slides to a presentation I give about coding agents is looking at the Nobel Prize winners from last year in physics and chemistry. The Nobel Prize winners in physics were people like Geoff Hinton and the ones in chemistry were people like Demis Husibus. And these are obviously the top awards in areas other than computing. And I'm building agents to create software, but the reason why I'm building agents to create software is not because software is the end, it's because software is like a means to an end. And I think AI has a huge possibility to increase the impact and the human condition and things like this. But I think the way it's going to do that is through software, basically. And so if we can make it very easy to effectively create software and make it very accessible to the people who want to use it, we'll be able to make great strides forward. And so that's what I'm most excited about.

Daniel Whitenack (40:44)

Awesome. Well, we're definitely excited to see what you all are doing. It's amazing work and really just encouraged to hear also your perspective on the project and the way in which you're building. I encourage all of our listeners to go and check out all-hands.dev. check it out, try it out and yeah, thank you both for joining and taking time. It's been great.

Robert Brennan (41:07)

Thanks for having us.

Graham Neubig (41:08)

Thanks so much.

Podcast Host (41:16)

Alright, that is our show for this week. If you haven't checked out our Changelog newsletter, head to changelog.com news. There you'll find 29 reasons. Yes, 29 reasons why you should subscribe. I'll tell you reason number 17. You might actually start looking forward to Mondays.

Graham Neubig (41:37)

Sounds like somebody's got a case of the Mondays.

Podcast Host (41:40)

28 more reasons are waiting for you@changelog.com news. Thanks again to our partners at Fly IO to break master Cylinder for the beats, and to you for listening. That is all for now, but we'll talk to you again next time.