theCUBE + NYSE Wired: Physical AI & Robotics Leaders | Guy Gur-Ari, Augment Code

Clips
More from theCUBE + NYSE Wired: Physical AI & Robotics Leaders

Guy Gur-Ari

Co-Founder

Augment Code

play_circle_outline Enhancing Software Engineering: The Role of AI Coding Assistants in Boosting Developer Productivity Without Replacement

play_circle_outline Empowering Developers: The Evolving Role of Tech Leads in a Future Dominated by AI Integration

play_circle_outline Enhancing Code Quality: Bridging the Gap Between Agent-Generated Outputs and Junior Engineers Through Strong Architecture and Supervision

play_circle_outline Emerging use cases for AI in understanding and navigating complex codebases.

play_circle_outline The need for a balance between automation and responsibility in software quality assurance.

play_circle_outline Augment's integration with various platforms to streamline developer workflows.

Info
Transcript

Guy Gur-Ari, Augment Code

Guy Gur-Ari

Co-Founder Augment Code

Guy Gur-Ari, co-founder of Augment Code, joins theCUBE’s John Furrier and Howie Xu, chief AI and innovation officer at Gen, at theCUBE + NYSE Wired: Robotics & AI Infrastructure Leaders 2025 event. The conversation examines how AI coding agents are transforming the role of software engineers and accelerating the delivery of enterprise software.

Gur-Ari shares the origin story behind Augment Code and the company's mission to support developer productivity through intelligent code generation. He outlines the shift from traditional coding to supervisory... Read more

explore Keep Exploring

What is the intended role of the product in relation to software engineers? add

What changes are occurring in the role and mindset of software engineers regarding code reviews and their responsibilities with the use of agents? add

What is the relationship between the role of a developer and the use of AI agents in software development? add

What are some effective use cases for an AI agent that assists developers with code bases they are not familiar with? add

What are the advantages and challenges of using tools to automate code writing and testing? add

What capabilities do these agents have beyond coding, particularly in identifying issues in production? add

bolt Powered by CUBE AI

Guy Gur-Ari, Augment Code

search

Howie Xu

>> 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?

Guy Gur-Ari

>> 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.

Howie Xu

>> 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?

Guy Gur-Ari

>> 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?

Guy Gur-Ari

>> 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, 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.

Guy Gur-Ari

>> 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.

Howie Xu

>> 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?

Guy Gur-Ari

>> 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.

Howie Xu

>> 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...

Guy Gur-Ari

>> 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...

Howie Xu

>> Still not as mature yet.

Guy Gur-Ari

>> 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?

Guy Gur-Ari

>> 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?

Guy Gur-Ari

>> 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-

Guy Gur-Ari

>> Assembly, even better. Even better.

>> But this is a concern because COBOL is on mainframes and no one does that anymore.

Guy Gur-Ari

>> 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.

Guy Gur-Ari

>> Perform the task that they set out to. Yeah.

Howie Xu

>> 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?

Guy Gur-Ari

>> 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.

Howie Xu

>> 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.

Guy Gur-Ari

>> 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?

Guy Gur-Ari

>> 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?

Guy Gur-Ari

>> 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?

Guy Gur-Ari

>> 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-

Howie Xu

>> Important is the Zoom call transcript.

Guy Gur-Ari

>> Yes, Zoom call transcripts. Exactly. Slack.

Howie Xu

>> People already doing that with Augment?

Guy Gur-Ari

>> I don't know that people are doing Zoom call transcript with Augment.

Howie Xu

>> That will be a direction?

Guy Gur-Ari

>> That will be a direction. Yes. I think there's already a lot that's happening in Slack, even before we need to deal with Zoom calls. We're just kind of at the first-

>> In the moment about the code. Things are happening in Slack. I mean, there's real context.

Guy Gur-Ari

>> A lot is happening in Slack that doesn't get documented anywhere else. And so, just making correct use of all those context sources, I think is another big role for research.

Howie Xu

>> So from that point of view, when do you think 90% of the code out there by the enterprise software engineers are going to be done by agents rather than by software engineers? When that moment will come?

Guy Gur-Ari

>> Yeah, so I think this is, it's mostly a rate of adoption question rather than capabilities. My sense is that today, certainly most of the code and maybe 90% of the code can already be written by-

Howie Xu

>> Meaning that we are ready today. It's a matter of whether people have the faith and then practice and then do it.

Guy Gur-Ari

>> That's my belief. And then I speculate that within one to two years that will be true.

Howie Xu

>> So a week ago, know Matt Garman from AWS was in the occasion I was with, and I asked him this question. I said, "When is that moment going to be? Is that one or two years or five years or so?" He said one or two years. And then my next question was, how do you prepare your engineers towards that? There's a big, big implication for that.

>> Well, I asked Matt Garman the same thing last week and he said, "I think it's almost all of the code." Swami would say all the code is being done. But I think the question is, who touches it, right? This becomes, is it autonomous or semi-autonomous? So if I review the code and change something or just review it, some people consider that not generative, so semantic. Do you agree with that? Is that coming up in definitions that people are squinting through? What truly it means to do code by machine versus that percentage? I mean, I think you basically said all your code is coming out of there.

Guy Gur-Ari

>> Yes. For us internally at Augment, I would say certainly over 50% and maybe 80. I don't have the number, but I would guess 80 to 90%, just based on conversations and how often it comes up, "The agent did this for me." Yes, that would be my guess.

Howie Xu

>> In the previous conversation you and I had, you mentioned that there is also front ticket to PR directly. What percentage of the things are being done at Augment that's front ticket to PR already?

Guy Gur-Ari

>> So that I would say not a lot. So the end-to-end flow where you just one shot, give it a ticket and get a PR, I think that's certainly happening, but is more rare. I think the bulk of the work is people using the agent interactively. Again, this is a question of capabilities. Right now, ticket to PR in one shot works if you have a very small and simple task. For anything non-trivial, you kind of have to go in there and-

Howie Xu

>> You see that in a year or two it's going to be vast majority at that point for Augment internal?

Guy Gur-Ari

>> Oh, for Augment internal, would we do a ticket to PR in one to two years? Yes. That sounds feasible to me.

Howie Xu

>> The other thing is, if it's a front-end code or backend code or mission-critical code, I think for coding agents, they are going to have different level of challenges. I think you and I discussed before for front-end, do we have enough tools to test it? So as a result, it may be a little bit more challenging. So when do you think we don't need to worry about it? Okay, it doesn't really matter, mission-critical or the front-end, I'm going to be able to use Augment to program it all.

Guy Gur-Ari

>> Oh, for us, I think it's just a question of velocity. We use Augment for mission-critical code. There's no piece of the product where we say, "Oh, this is so important that it has to be done just by a person manually." There's nothing like that, that I know of in the product. Sometimes the code is very algorithmically complicated, and then maybe the agent doesn't do as good a job as a human. Those are the kinds of considerations that I think developers will usually make. It's not to us about whether it's mission-critical or not.

Howie Xu

>> What would be the future abstraction level for the software engineers? It was assembly language before, then Java, C, Python. What is the future in two years, three years? What's the abstraction level that software engineers will have to deal with?

Guy Gur-Ari

>> Yeah, that's a great question. It feels like there should be something between Python, JavaScript in English, because English is not a precise language, and yet this is the language that we use to steer these agents. It also means that we're losing a lot of artifacts. So the code we check in doesn't include all the context of how we arrived at that code from the agentic sessions, which then hurts us down the road when we go revisit it. So it feels like there is a place here for something in between, but I don't know what that is. That's a great question.

Howie Xu

>> Another question I have for you is the one-person Unicorn that Sam Altman kept talking about. What do you think? When is that going to be the case and how is Augment going to be relevant in this conversation?

Guy Gur-Ari

>> Yeah, so I think that's a very interesting angle of, can we take one person? Can one person really build a company and turn it into a unicorn with AI? And I think a few things need to happen for that, right? First, certainly we have to solve or automate engineering to a great degree. We also need to automate other business functions, like sales and marketing and so on. And these automations are all happening in parallel right now. I hear from friends who are entrepreneurs, how they're using AI to automate different parts of their businesses, just like we at Augment are automating our engineering and software development. So to me it seems completely feasible that we will see-

Howie Xu

>> People are using Augment or some other coding agents to program the MarTech, the new MarTech, sort of the SAS or whatnot, right?

Guy Gur-Ari

>> Yes. I think one advantage that you have when you're starting now with AI is probably the code that's going to get generated is going to be somewhat more AI-friendly because models have been trained to generate small files, to decouple things in a proper way. And so, if you can supervise the design, I think you'll end up with a code base that's potentially more AI-friendly. I'm not sure, but it is certainly true that with AI you can now... When you're doing zero to one development now, that's kind of where AI agents shine the most, because you don't have a lot of tech debt to deal with yet, so we can go really fast.

Howie Xu

>> So I don't want to finish the conversation without touching it upon the model. So Apple just recently published the paper, The Illusion of Thinking, right? Basically the idea is the reasoning capability is not as much as people touted. I wonder what's your comment? And also, is that relevant for the coding agent? Because one way to think about it is, for coding agents, we have enough of the rewarding functions. Maybe it's okay, the reasoning capability is limited, we still can go pretty far. Can you shed some light on this?

Guy Gur-Ari

>> Yeah, so that was a very interesting paper. I think what they ultimately showed is that when you take a problem and you dial up the level of complexity of that problem, all the models that currently exist will at some point fail to solve the problem, while a human would succeed because they kind of understand the algorithm for solving the problem and they can just crank through the algorithm. That's not a new phenomenon. I think they're shedding light on a known phenomenon, which I would put this under out of distribution generalization. We're training the models to do a large set of tasks, but when we try to push them far beyond what they were trained to do in a certain direction, they will always fail. This is-

Howie Xu

>> The model can generalize for things outside of...

Guy Gur-Ari

>> Outside of the training distribution. The model can generalize the unseen tasks as long as they are similar enough to tasks that it has seen before, but not the things that are completely novel. The thing we're learning about code is that there's a whole lot of value within the training distribution. Most of the things that developers do are not so novel that they stump the model. We just see it work in practice. And so, I don't think that this has practical implications for what we're seeing with coding.

Howie Xu

>> There is one conversation we're going to have with a startup, they claim they wanted to do Google L7 engineers. Do you think the model will allow us to do Google L7 engineer's job?

Guy Gur-Ari

>> So this to me is part of the one-person unicorn. I think if you want to get to a one-person unicorn, you're going to have to be able to some extent automate that, because otherwise you're going to end up with code with so much tech debt that nobody will be able to really maintain it. This is about making these correct architectural design decisions.

Howie Xu

>> So your view is, the answer is yes, you believe it will go towards that direction?

Guy Gur-Ari

>> I believe it will go towards that direction. I don't believe we're there today. We're not there today.

Howie Xu

>> How many years apart?

Guy Gur-Ari

>> Again, I would say my guess is one to two years.

Howie Xu

>> Oh, only one to two years. That's immediate.

>> All right, thanks for coming on.

Howie Xu

>> Thank you very much, Guy. This is a great session. This is one of the... Not one of, this is the revolution for software engineering. Thank you for coming to the show.

Guy Gur-Ari

>> Thank you so much.

>> Thanks so much.