Hello, everyone. This is Howie Xu, chief AI and innovation officer at Gen. Today I'm very much looking forward to the conversation with Guy Gur-Ari. He's the co-founder and chief scientist at Augment Code, and it was joined together. Guy, do you want to just give a quick intro of yourself before we kick off?
Yeah, for sure. Yeah, one of the founders at Augment Code. We work on developing an AI assistant for professional developers that works on large code bases, large teams for performing real software development tasks. Before that, I was at Google, I was a researcher there working on large language models. And so, to me everything that's happening now with large language models and code is just incredibly exciting. So happy to be here to talk about it.
So with theCUBE, NYSE, binding two futures, together we are doing a series. The series is about talking to the creators behind the AI coding agents, because I fundamentally believe it's a big revolution. What does that mean to the programmers? Let's cut to the chase of it, whether and how your product or this generation of the product will replace software engineer?
So the way we're thinking about it is we're not setting out to replace software engineers, we're setting out to augment them and help them be more productive. And that's certainly what we're seeing with the agent now. So things that used to take a developer hours, days, weeks to perform their tasks, now they can often be done in hours or less. But to us what that means is, that developers can ultimately then be more productive and produce more and build even more amazing products than they could before. Certainly as we automate more and more of the software development life cycle, I think we're going to see developers and also probably other people like designers and product managers just able to achieve more in terms of the products that they build.
And you were saying before we came on camera that you were in the back room coding or augmenting, what's the term and what were you doing?
Yeah, so the thing that I find mind-blowing about what's happening now is I've been developing software for decades, and in the last few months I've not actually had to write a line of code myself. I use the agent to do all of the software development and then I go and supervise what it did. And so, that's kind of my day to day right now. When I get a chance to code, I just ask the agent to do things and then I go and supervise its work. Sometimes people refer to working with agents as vibe coding, but we feel that term doesn't quite capture what you can do with Augment, because vibe coding has this negative connotation that you just tell an agent to go do things and you don't even look at the code, you just push it. And if it works, it works. And if it doesn't, you ask the agent to fix it. But what we're seeing when you use these things for real software development work, that's a very easy way to accrue a lot of tech debt quickly and to run into trouble. And so, for us, we're using the agent as a tool to still produce high quality, well-architected code.
You said you worked at Google. I was talking to a friend the other day and we're like, 'Vibe coding is I feel a lucky button.' Just random things happen, that Google was engineered, search, and I think that comes up a lot where vibe coding can be good for front-end work, very low end, very low QA requirements, but integrating it into production or making serious back-end reliable code still requires engineering, but the engineering is being done by the machines, AI. And the human, is it curating? Is it managing? Is the software engineer turning into the manager? So take us through the role of the software, because the folks out there watching might be sitting saying, 'Hey, I've just been doing SQL programming or Python and doing this or that, I'm writing some code. What do I do now?' And that's an open question that's a psychology of the mind. And then two, they want to see instant results. So does it change the role of, 'I just want to code, I don't want to be a manager.' But then again, you're just doing code reviews that you would normally do if you had banged out the code. Take us through the mindset of the software engineer out there today and how you guys change that and what it means to them as a developer and engineer.
Yeah, so the way we're thinking about it is that developers are now becoming tech leads of their agents. You can have a single agent, you can run multiple agents in parallel working on different tasks and then you no longer need to be concerned with the nitty-gritty details of every single line of code. I think a lot of it becomes supervising the high-level decisions that the agent made and making sure that they're correct. Are there any security implications? Is the system architected properly? Is it going to be maintainable? That still involves reading code and reviewing code and correcting the agent, but there's a lot... When you get into that mode, there's a lot less of worrying about, again, every single line or every character in the code. So in some sense you're just working with this thing at a higher level of abstraction than you did before and you can also run multiple of them in parallel now. Yeah.
So I use Augment, I like it a lot, but there are a lot of the people with the sort of, they are saying that, 'Hey, the Augment or Cursor of the world, they produce code, but that's from junior engineers production.' What's your comment to that?
Yes, so this is what I mean when I say that the role of a developer becomes sort of like a tech lead. It is true that the agent... So the good thing about the agent is it has a lot of breadth of knowledge. And especially with Augment, it understands your code base really well. And beyond that, it understands every library that's out there and so on and so forth. But the quality of the code that it generates can often be at the junior level, especially when it comes to design and architecture. It will often make really bad decisions, and so that's where the supervision still is very important. That's what I was referring to.
So do you anticipate a world where you not just supervise a number of agents, but also hierarchical agents? You are not just a software engineering manager, you're a software engineering director or maybe VP, VP managing director, the director's agent and the manager's agent. Do you foresee that world? Or...
I do. I think it's actually coming fast. You can see what's in the news out there. There are already blog posts from Anthropic and others about how to build and manage multi-agent systems. I think they have a few use cases. One is to be able to explore multiple solutions in parallel. You can launch a few agents to explore different approaches to a problem and pick the one you like best or have it pick the one it likes best. You can use it to paralyze work, because agents can often be slow, and so maybe some of the tasks can be worked on in parallel. I think right now with the models, they have basic capabilities for multi-agent systems. This is something...
Not as mature as the single, the flat agent session, which has ensured a lot. But if we just extrapolate from the rate of progress we've seen language models make and the amount of interest in multi-agent systems, I expect that will come very soon.
We're seeing a trend, we saw this in AWS where SageMaker was their thing and then Bedrock came out. They want to make SageMaker more of under the hood for the more people that want to turn the knobs, play with it, and then developers would just go to Bedrock, pick a model, be more lightweight. Is there a separation between consumerization coding, 'Hey, build me an app that takes my videos, puts them in this, that, and the other thing, or takes an app sheet that I have all this data in and tell me what sales are going to look like.'? I mean, I'm making that up, but just pretend those are more like, here's the input versus engineering a real app that's going to be pushed to AWS. So my mind just gets complicated. I'm like, 'Oh, I've got to get on Amazon. Do I provision the S3, EC2? I've got a log in route or user account for those steps versus the consumers, Hey, code me an app and then we're done.' What's the spectrum of usage and where should people know when to jump into what?
Yeah, that's a great question. I think there are already emerging different segments. And so, if you're just starting off on an app or maybe you don't have a lot of coding experience, there are great products out there. There's Lovable, Base44, there are others where you go to a web page, you type in your prompt and it will generate the whole app for you. It will deploy it. You don't even have to know what's the backend, where it's running, nothing like that. You just type the prompt and then you can edit the app and it will show you a new preview right in front of you. I think the place where this kind of stops working that well is when the app grows and becomes more complex and you have real users and maybe you're charging them, then your code base is large enough where these tools are often in their current stage not quite sufficient anymore. And I feel like that's a place where we, for example, will come in. We try to serve the professional developer. Typically, the folks who use Augment have existing code bases, they work on teams and they can benefit from agents that have a better understanding of their code.
So would the use case be like... Okay, I'll give two examples. The guy died who was running our COBOL mainframe code. And how he left, he was running the C++. We still have them both in production. Go figure out the code base or port it to Java. Is that a use case or is that fantasy?
Yes. So I would say asking it in one shot to migrate the whole thing to Java-
Probably the assembly maybe. Assembler. Maybe not C++, assembler, because-
Assembly, even better. Even better. Yeah, so one of the best use cases that we've seen to an agent that really understands your code base is to dive into a new code base or a part of the code base that the developer doesn't understand. That's where we see huge productivity gains. We have one customer that's a consulting company. And so, what they do all day is jump into new customer code bases and need to navigate what's going on there. And so, they use Augment exactly for this purpose, again, to quickly orient themselves to what's happening in the code base and become productive quickly.
And then provide value, whether it's rewrite or become a coder.
Perform the task that they set out to. Yeah.
So clearly I remember assembly language, but half of my career is doing VP of engineer job in my past life. So if a person out there as a VP of engineer, how should they think about with Augment, with coding agents coming? It's clearly a big revolution. I have engineers who know Java, who know Python, but a lot of the coding in Java, coding in Python is becoming free or becoming a different ball game. What should a VP of engineers managing 500, 1,000 people, 100 people, what should they think? What should they do today?
Yeah, so if I were a VP of engineering today, the number one thing I would pay attention to is adoption of these tools. So what we're seeing typically is that the capabilities of these tools are getting to be quite a bit beyond what people are adopting. So the rate of adoption is not quite keeping up with the capabilities, which I think is a normal thing that you do.
Meaning that even though you produce junior engineer code, but still that's very solid, the junior engineer code, people should be able to take full advantage of it and that people are not quite doing that today.
Yes, exactly. It takes time. It requires changing habits, it requires learning how to make the most of these tools and that takes time. One of the most effective ways that I've heard about to do that is to have... If you have someone in your organization who's already a power user of these tools, have other people look over their shoulder as they're using these tools. Typically, within 10 to 20 minutes of seeing that, people, it clicks for them and they understand, 'Oh, this is how you prompt, this is how you supervise.' And it makes their learning curve much less steep.
Guy, we hear this a lot in the robotics conversation around safety first, because robotics have physical impact. But also in the agent world it has been talked about. We don't want to let the agents wild. They have some agency to do things. Where does the code management come in terms of making sure that it's reliable and that it just doesn't run into production and breaks a bunch of stuff? I mean, what have you guys found in your experience and what are you guys doing with developers? Is there a pipeline? Is there a certain process? Or is that on the customer, your customer? What's the fear? Well, not fear, but I'm just saying, I would be worried. Okay, if code is out there, make sure it's QA, in this sense QA, just press a button, ship. What's your take on this whole trust equation?
Yeah, I think currently I would say we are still figuring it out. One advantage that these tools have is that don't just... They're not just able to write the code, they're also able to write tests. And so, you end up with... Typically, when you use these things, you end up with a lot more tests than you normally would. The tests need to be supervised as well. Because if you typically just ask it to write tests with no further guidance, you get low quality tests in many cases, but you are able to generate a lot more tests and quickly. And writing tests is something that developers especially don't like doing, so that's where automating them with an agent does help. But I think beyond that, the whole question of, how do we supervise and monitor and making sure everything works well? Still a bit of an open question. I think that's where moving from the inner loop of software development and letting agents be involved in the outer loop, triaging alerts that come in, addressing build failures, things like that will be a very interesting development.
Is there any data you can share or learnings or observations around what you've seen come through Augment Code where you start to see patterns and best practices? Is there a blueprint? Are there templates? I say templates, I don't mean like a template, template. I mean like a recipe for the future, how people can jump in. What's the learnings, I guess is the question?
I think it's a bit early for me to share high level learnings. What I can say is, what we've seen is that the agents are... So developers will often figure out how to use these agents to do coding, but they can actually do a lot more. So for example, one thing that these agents can do is, you can say, 'We have this alert in production, please look through all the pull requests from the last week and try to identify which one may have caused this,' for example. So that's something that if you're used to using agents just for coding, maybe it won't occur to you that they can actually do this. But because in Augment, in the product, we are integrated into GitHub, we're integrated into Linear, we're integrated into Notion and Confluence. It's integrated with all these systems as well, so you can ask it to actually go and investigate failures, for example. Yeah.
If you were a researcher now, I mean you had a research background, there's two questions to this. Research is key. Right now we're seeing some of the key AI native companies that's having influence in the product. So that's one question. The second one is if you were a researcher right now in college, how would you use Augment? So two questions. How is research impacting the product, AI research, I mean AI research in terms of algorithms, whatnot? And then if you were in college, what would you do? Would you just start building stuff or continue to do research and experiments?
So I think in terms of how research is influencing the product, I see two tracks along which things are improving. One is intelligence. The models are getting more and more intelligent over time, and that of course takes a lot of effort into training them and optimizing them. The second track that we're seeing is the track of context. The models, no matter how intelligent they are, they're only as good as the context we provide them. And so at Augment, we're very good at providing context from the code base, but they're a lot of other interesting sources of context that are interesting. One is code history, specs, tickets, all these other things that developers use to do their day-to-day work. And we're seeing a lot of promise in utilizing all of that context to make the agents better. So that's where-
Important is the Zoom call transcript.
Yes, Zoom call transcripts. Exactly. Slack.
People already doing that with Augment?
I don't know that people are doing Zoom call transcript with Augment.
