AI Engineer World's Fair 2025
To the moon! Navigating deep context in legacy code with Augment Agent
Read the talk
Navigating Apollo’s Legacy Code with Augment Agent
An Apollo guidance demo moves from explaining descent alarms to generating Python guidance code, showing how repository context and fixed tests support legacy modernization.
From a talk by Forrest Brazeal and Matt Ball
Before you start: Basic familiarity with Python modules, automated tests, and command-line errors is helpful; no assembly experience is required.
How do you understand code you cannot comfortably read?
How do you get useful work done in a legacy codebase when its language, conventions, and design are unfamiliar? Before changing anything, you need to recover the reasoning embedded in it. Forrest Brazeal and Matt Ball approach that problem with an unusually demanding example: the Apollo 11 guidance computer. Their demonstration moves from understanding assembly code to implementing part of its behavior in Python with Augment Code.
Brazeal introduces himself as an Augment friend and partner, not an employee; Ball describes his role as an Augment solutions architect. The exercise is to investigate the historical code, then use an agent to complete a simulated lunar landing. The session also offers a free trial, though the interface and access terms shown belong to the recording.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Retrieve code knowledge, then choose how to act
Ball starts with the input to the model: useful answers require relevant code context. A repository is not simply a collection of prose documents. Understanding a routine can require locating its callers, data structures, conventions, and related behavior. He describes Augment’s proprietary context engine as a system for retrieving the right repository knowledge and passing it to models, attributing better understanding and output quality to that retrieval. Those are product claims, not comparative measurements from this demonstration.
The surrounding product choices address enterprise adoption. Plugins let developers remain in existing IDEs—for example, IntelliJ for an older Java project. Ball also highlights customer-managed encryption keys and ISO/IEC 42001. The latter concerns an AI management system; it does not certify the correctness of generated code.
The execution mode determines what happens after the system retrieves context:
| Mode | Best fit | Execution pattern |
|---|---|---|
| Chat | Explore code and ask technical questions | One turn at a time, with user control |
| Agent | Complete larger tasks using tools | Read files, issue commands, and act on results |
| Remote agent | Continue work away from the laptop | Run in the cloud, including parallel tasks |
Remote execution matters when a task should keep running after the developer closes the laptop. It also makes independent tasks candidates for concurrent work.
Brazeal connects that possibility to an earlier workshop contest: someone wondered how the winners submitted solutions so quickly across several problems. He suggests that remote agents might have helped them work in parallel, but does not establish that this is what happened.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
An unfamiliar language with consequential behavior
Apollo 11 carried Neil Armstrong, Buzz Aldrin, and Michael Collins to the Moon in 1969. Its figurative fourth astronaut was the Apollo Guidance Computer, or AGC. Brazeal connects that computer to MIT’s development work and the familiar photograph of Margaret Hamilton beside a towering source listing. The code is assembly, a language few people in the room claim to have used professionally.
Brazeal characterizes the software as one giant monolithic source file. The preserved Apollo 11 source repository actually separates command-module and lunar-module programs into multiple assembly files. Either way, the practical difficulty is familiar: looking at the instructions does not immediately reveal the system’s behavior. The goal is to understand enough of that behavior to investigate its alarms and then simulate a landing.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From an alarm number to a recovery mechanism
The first task is to recover an explanation, not change code. During Apollo 11’s final descent, the crew reported program alarms that raised the possibility of aborting the landing. Brazeal recounts five overload alarms before Houston cleared the crew to continue. Given only the source, could you explain why continuing was reasonable?
In VS Code, Brazeal opens a slightly modified Apollo checkout. Searching for 1201 or 1202 can locate a constant, but finding the number does not explain the condition that produces it or the recovery path that follows. He asks: “What does the 1202 program alarm do?”
The response combines repository inspection with web context. Brazeal compares this to calling Mission Control: the developer asks a focused question and receives an explanation backed by a wider body of information. He suggests MCP servers as a way to expand those information sources, but does not demonstrate an MCP integration.
The code investigation identifies two related resource-exhaustion conditions:
| Alarm | Exhausted resource |
|---|---|
1202 | Executive scheduler core sets |
1201 | VAC areas |
The response points to the octal 1202 value in source and connects it to the executive scheduler’s inability to allocate another core set. That turns a number into a statement about the computer’s capacity to track concurrent work.
The web-derived explanation then connects resource exhaustion to the descent. Brazeal summarizes the cause as an external radar being left on; the historical account is more specific, involving rendezvous-radar configuration and false tracking-angle signals. Recovery restarted selected programs so mission-critical work could continue, rather than simply treating every queued task as equally necessary. The useful answer explains both the failure condition and why recovery preserved essential behavior.
Brazeal contrasts the brief interaction with the time he would need to understand the assembly unaided. That is an informal observation during the demo, not a measured productivity benchmark.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the agent a missing module and a fixed evaluator
The next task moves from explanation to modernization. The lunar landing guidance source contains the adjacent P65 and P66 routines. After initially reversing them, Brazeal corrects the distinction: Armstrong used P66, while this demonstration targets fully automatic P65. Armstrong’s control through P66 still involved computer-assisted guidance; it did not remove the computer from the descent.
Brazeal now points out that the previous interaction was actually in agent mode, despite his initial chat framing. In the auto mode shown here, the agent can write code and run commands without waiting for a permission click at each step. That permits a continuous loop of investigation, implementation, and execution.
The task has an explicit boundary. Brazeal has already written simulator.py, which expects a module named descent containing a class named LunarDescentGuidance. That class must implement the P65 algorithm. The simulator exists; the guidance module does not. The agent’s job is to create the missing implementation and make the simulation succeed.
His instruction is deliberately short:
Run simulator.py until it succeeds.
Then he adds the constraint that makes the task meaningful:
Do not change simulator.py.
The evaluator stays fixed while the implementation changes. Without that boundary, an agent could make the task appear successful by weakening the simulator instead of satisfying it. The autonomous landing here is a software simulation, not operation of a spacecraft.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Let execution expose what is missing
The agent begins by running the simulator and investigating the resulting problems. Ball describes repository knowledge as the starting point for choosing commands and tools. Reading individual files then refines the plan: what does the task require, and what is absent? Here, execution exposes the missing descent module, and the agent searches the repository for the assembly and tests needed to implement it.
Terminal commands continue without presenter intervention. The existing tests help the agent infer the expected LunarDescentGuidance interface, and it creates descent.py. Brazeal finds that the agent has completed this step before he finishes narrating its investigation.
The generated Python is easier for Brazeal to inspect than assembly. It exposes position, velocity, desired velocity, gravity, and a P65 guidance routine. The agent has also located the corresponding routine in the indexed historical source. One calculation in that source—velocity difference divided by TAUVERT—can be expressed directly in Python:
python
def velocity_error_acceleration(velocity, desired_velocity, tauvert):
return tuple(
(desired - current) / tauvert
for current, desired in zip(velocity, desired_velocity, strict=True)
)
This expresses the velocity-error component, not the complete guidance implementation. It makes the relationship inspectable: with the same velocity error, a larger time constant produces a smaller acceleration correction.
The agent then runs the simulator. Brazeal reports that the final landing position falls within the simulator’s expected zero-to-one-meter range. He also points to final vertical and horizontal velocities without reading their exact values aloud. The demonstrated result is successful execution against this simulator’s checks; it does not establish flight-ready equivalence with the original guidance software.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Understand, test, then modernize
The reusable workflow begins before code generation:
- Understand the existing system. Index the repository and ask what the application does, what individual files contribute, and which styles or conventions matter.
- Specify expected behavior. Use a conversational exchange to predict what should happen for concrete inputs, then have the agent write tests that check those predictions.
For the lunar descent example, that means predicting the behavior of P65 for given input parameters before asking an agent to encode the expectation in a test. A test is useful only to the extent that its expected result captures the intended behavior.
Brazeal gives a specific reason not to accept every prediction: in another scheduler investigation, the agent could be persuaded that priority zero was either the highest or the lowest priority. It could produce a plausible explanation in either direction. The response is to have the agent surface the relevant source, then inspect the ordering logic yourself. Otherwise, the same misunderstanding can enter both the implementation and its tests.
- Modernize small portions. Convert a bounded part of the code to the desired language or style, then apply the same tests to check that its functionality remains intact.
This keeps the unit of change small enough to understand and review. The agent assists with navigation and translation; the tests preserve a behavioral target across the conversion.
The enterprise counterpart need not involve assembly or spacecraft. The closing discussion proposes moving a Java 8 project to Java 17: tedious modernization work in a repository potentially much larger than the Apollo example. Brazeal is unsure of the Apollo repository’s line count, so its size is not offered as a scaling benchmark. Greenfield projects are also possible, but the demonstration’s distinctive value lies in working through inherited behavior. No enterprise migration or deployment is shown.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Tests give an agent a way to check its work
The first audience question asks about checking dependencies across a large codebase. The presenters answer affirmatively, then point back to concrete recovery in the demonstration: discovering missing files and switching from an unavailable python command to python3. Those examples show the agent responding to local execution failures; they do not demonstrate exhaustive dependency analysis across an enterprise repository.
The final question identifies the exercise as effectively test-driven development. The answer emphasizes the feedback loop: agents reason and iterate, and tests let them check their own results. A fixed simulator gives the agent something more useful than an instruction to keep trying—it gives each attempt an observable outcome that can guide the next change.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The product's public site, with current offerings and getting-started links.
Browse the preserved assembly source for Apollo 11's command and lunar modules.
Luminary 099 assembly listing containing the P65 guidance equation and adjacent P66 routines.
Further reading
- Introducing Remote AgentArticle
Augment's launch announcement describes cloud execution and practices for assigning, validating, and reviewing parallel tasks.
The vendor describes certification of its AI management system and the governance processes covered.
Read the complete timestamped transcript
- 0:00
[upbeat music] Welcome, everyone.
- 0:16
Thank you so much for coming. My name is Forrest, this is Matt, uh, and we're gonna be talking to you today about Augment Agent and specifically legacy code, how we get the most out of gnarly legacy code bases using an AI agent.
- 0:30
Uh, so I do not work for Augment Code. Um, I am a friend and partner of Augment Code, uh, so I helped to put this talk together. Matt is from Augment Code, so he's gonna be your best person to come to with your most detailed technical questions after the session.
- 0:42
Matt, anything you wanna, uh, say about yourself?
- 0:45
Yeah. Uh, I was once a software engineer and then got into the developer tool space. Um, I was at Postman for a number of years and then got really excited by the, the AI boom.
- 0:55
So I've been at Augment for the last two years or so. Um, I'm a solutions architect.
- 1:00
Fantastic. All right, so just a quick roadmap of where we're going. We're gonna talk a little bit about Augment Agent. Uh-oh. Do we not have, um...
- 1:08
I see someone pointing. We good now? Okay, fantastic. So we've got, uh, Augment Agent. We're gonna talk a little bit about the Apollo 11 guidance computer, and then we're gonna show you some really interesting things you can do with that code base, uh, and Augment Agent.
- 1:21
So Augment is the, uh, it's the product we're gonna be using today. Um, you do not need your laptop out to follow along with this session. We will do it all in front of your eyes.
- 1:29
But if you want, you can sign up. There's a free trial at augmentcode.com, and, uh, Matt will tell you a little bit about the most important features of Augment Code.
- 1:37
Yeah. Uh, number one is our context engine. So we really identified early on that in order to get high-quality outputs from any of the models, they require high-quality input.
- 1:49
Uh, doing that for, for code bases is not necessarily straightforward. It's not just like text. Um, so, uh, this is something that we've seen in the, in the market.
- 2:00
Uh, a lot of folks think that there's a, a way to do this. We spent two years building a proprietary system that can lift the right knowledge from a code base and pass it over to the models, and we think that results in higher quality outputs and more accurate understanding.
- 2:14
Uh, we're a plugin to existing IDEs. We see in a lot of enterprise that if you've got a ten-year-old Java code base, you're using IntelliJ, you don't wanna have to switch.
- 2:23
Um, and then from day zero, because we were targeting enterprise, we've focused a lot of security capabilities. So we have things that are unique to us versus any other vendor, like customer-managed encryption keys.
- 2:34
We have ISO 42001, which is a new AI ISO standard. Uh, so we really wanted to, to laser in on providing security over what is very important, uh, a very important asset in your code base.
- 2:49
Awesome. And then we've got a couple of tools we'll be referring to today, mainly the chat and agent modes of Augment Code, and when would you use each of those, Matt?
- 2:56
Yeah. Chat is great for kind of simple back-and-forth question and answer, uh, or when you want to leverage a little bit more control over the, the models and you just want to go one turn at a time.
- 3:07
Uh, obviously we see that agents can integrate into other tools, are much more capable of larger, more complex tasks. Um, and then remote agents are great when you actually wanna close the lid on your machine and allow them to continue, continue to run in the background and in parallel.
- 3:22
Yes. We did a workshop on Tuesday that involved a contest component, and I had someone come up to me afterwards, afterwards saying, "I don't understand how the winners were so fast at submitting their solutions," 'cause we had eight or nine problems we were doing.
- 3:33
Oh, okay.
- 3:34
And it's possible some of them were using a remote agent to do some of those tasks in parallel, so it can come in handy for that as well. All right.
- 3:40
So we're gonna be talking today about the Apollo 11, uh, mission in 1969. I think most of us are familiar with this, the first time humans landed on the Moon.
- 3:48
There were three astronauts in that capsule, Neil Armstrong, Buzz Aldrin, and Michael Collins. But sometimes people say there was a fourth astronaut on the Apollo 11 mission. Does anyone know what that astronaut was?
- 3:59
Computer.
- 4:00
Yeah, the, uh, the Apollo Guidance Computer, or the AGC. Uh, and the main things to know about the AGC, so this was used to land the lunar module. If you've ever seen that picture of Margaret Hamilton with, like, that giant stack of papers, uh, with the code on it, that was the source code for the Apollo Guidance
- 4:14
Computer. It was one giant monolithic source file developed over a period of several years at MIT in the 1960s. It was written in Assembly language. Who here has written Assembly at some point in their lives?
- 4:25
Who... Put your hand down if it was in college.
- 4:28
Me.
- 4:28
All right. So keep your hand up if it was in production in some capa-- Yeah, exactly. That's what I thought. Uh, so not a lot of us are gonna be able to look at Assembly code and be able to tell you confidently what it does on first glance.
- 4:38
I certainly can't. I haven't written much Assembly since I was in Computer Systems 201. All right. So in some ways, this is the ultimate legacy code base. It is on GitHub.
- 4:47
You can check it out yourself if you want. It's easy to find. We're gonna try to navigate it well enough to see if we can understand it and land the lunar module ourselves, and Augment Agent is going to help us do that.
- 4:57
So the first thing you wanna do anytime you pop open a large legacy code base is you wanna see if you can get your head around it, right? Someone put a lot of their time and mental energy into putting this code base together, and you've got to catch up with them.
- 5:08
That historically has been a long process. It's been a fraught process. It's been an imprecise process. And AI agents such as Augment Code can help a lot with that.
- 5:16
So let's look at, uh, a specific example, and I'm choosing the 1201 and 1202 program alarms. If you're an Apollo 11 history buff, you know about these because during the final descent onto the surface of the Moon, the astronauts called to Houston and said, "Hey, we're getting this alarm.
- 5:31
It's a 1202." Uh, the, uh, "Give us a reading on the 1202 program alarm." This alarm went off five times, uh, as the lunar module, the Eagle, was making its descent onto the lunar surface, and there was a question for a moment about whether the landing would need to be aborted.
- 5:45
And finally Houston said, "No, you're okay. You can continue." So our question is, could we determine that for ourselves, right? If you were given the Apollo Guidance Computer source code, would you be as confident as Houston was to say, "No, this is not a problem that's going to affect the success or stability of the mission"?
- 6:00
So the way I would do this is I'm gonna pop open... I've got VS Code up here, and I've got, uh, a slightly modified version of the Apollo 11 code base.
- 6:08
Just to orient you, it looks like this. All right, this is, uh, this is their version of Assembly code. It's truly just a bunch of two-word commands saying, "Move this piece of data into this register somewhere."
- 6:18
So it's, it's not fantastically readable. Uh, and even if you did a, like, a grep and looked for 1201 or 1202, it's not gonna tell you what the value of those alarms actually is.
- 6:28
So I can go to Augment Chat, and I can say, um, [keyboard clicking] "What does the 1202 program alarm do?"
- 6:37
And let's see what it tells me. It's generating our response. All right, and so it's gonna take a minute to churn on that. Uh, and it's gonna come back to me with a number of, uh, pieces of information, both from the code base itself, and it will also be able to call out to the web, and it'll
- 6:52
be able to look there. One of the things I think is interesting about using a chat mode like this is, uh, it's kind of similar to calling back to Mission Control in Houston.
- 7:00
Um, and if you were to plug in, like, you know, some MCP servers to this, right, there's a... It gives you an even, uh, an even larger Mission Control element to work with.
- 7:08
Okay, so, uh, it's, it's actually reading this file for us. Uh, uh, so the ACG executive scheduler system runs out of available core sets. All right? And it shows us where that happens.
- 7:18
Look, there's, uh, octal value 1202 right there. It explains the number of registers there are. Uh, it explains the, um, yeah, along with 1201, no vac area, so it pulled both of these.
- 7:28
And, look, it went out to the web, and it's giving us the context of what actually caused the error. It was an external radar system being left on, and the Apollo 11 computer was smart enough then to offload some low-priority tasks so that it could continue executing mission contr- mission-critical components inside the computer.
- 7:44
That's why they were able to land. Uh, so, yeah, and then there's your little TLDR. 1202 means the computer's trying to do too many things at once and has run out of memory to track all the concurrent jobs.
- 7:54
How long would it have taken you to figure that out on your own reading through that code base, right? I can tell you it would've taken me more than the 30 seconds we've been talking here.
- 8:01
So that's pretty cool to see. All right. The second thing I wanna do is do a little bit of code modernization here. Now, when the lunar module actually landed on the surface, uh, Neil Armstrong used a routine in the lunar landing guidance equations file called P65, and that was kind of like a manual override mode.
- 8:20
They didn't really trust the computer enough to let it land the Eagle all by itself. Neil Armstrong kind of had a thumb on the controls throughout that process. There is also a routine in that file, as I discovered, called P66.
- 8:34
Uh, sorry, he used P66. We're gonna use P65. P65 is full automatic. That's where you just let the lunar module land by itself. It turns out that Augment Agent has a thing called auto mode.
- 8:43
Yes?
- 8:44
Yes.
- 8:44
Uh, I'm gonna show you what that looks like. Uh, so you see down in my chat here, um, I actually was on Augment, uh, on agent mode before. So we could have been in chat mode, but I can also be in agent mode, and this is going to...
- 8:56
If I ask it to write some code for me or to run some code, it's not gonna ask me for permission. It's not gonna wait and have me click on something.
- 9:02
It's just gonna go do it. I could go get a, you know, a cup of coffee, and I could let Augment Agent land on the Moon for me. So what I'm going to do, I've added a couple of files to this code base.
- 9:12
Uh, one is called simulator.py. I wrote a little simulator that expects a file to exist called descent, and it expects a class to exist in that file called lunar descent guidance that implements the P65 algorithm.
- 9:24
That file is not written. I'm going to see if Augment Agent can write that file, run the simulator, and land on the Moon without any human assistance whatsoever, just like the actual P65 would've run.
- 9:36
Should we give it a try?
- 9:37
Whoo. Yes.
- 9:37
All right. So this is my favorite prompt to do this. It's just, "Run simulator.py until it succeeds."
- 9:46
Nice.
- 9:47
"Do not change simulator.py." All right. See, that's, that's where it would try to get me, right? Okay, let's see what happens. All right. So what's Augment Agent doing here?
- 10:00
All right, it's gonna run the simulator.py file and work through any issues. So, uh, Matt, any comments you wanna make about, like, how Augment builds its plan for what it wants to run here?
- 10:08
Yeah, so it's gonna use code-based knowledge as a starting point to figure out-
- 10:13
Mm-hmm
- 10:13
... you know, how it should... what tools it should run, what commands might be important. Um, and so from there, it can start to understand what might be missing.
- 10:22
Mm-hmm.
- 10:23
Um, and then typically, you'll see the agent start to put together the framework of a plan as to how to solve this. So it might go and read individual files and just start to gather a better sense of what it's gonna take to complete the, the task.
- 10:36
So here, it's realizing at this point that the file's missing, and then it's gonna start exploring the code base more generally with our context engine, so it can kind of grok some of that assembly code and start to think about what an implementation would look like.
- 10:49
That's right, and it's actually... Like, it's running little terminal commands for us, right? And it's not waiting for us to intervene here. It's just doing it. All right. So let's map things out.
- 10:58
Uh... Yes. All right. So look, based on... So there's a little test file in here. Oh, it already succeeded. Okay. It, it got ahead of me. So based on the test files, it can understand what the lunar descent guidance class should look like, so it created the missing descent.py file.
- 11:12
Let's take a look at that and see. So there you go. So it wrote descent.py. It's a, uh, implementation of the P65 vertical descent guidance. So Augment has indexed this entire code base.
- 11:21
It's able to go look at it. So it found, you know, where it is in the original source code. Uh, and then I gotta tell you, it's easier for me to read Python than it is to read Assembly code, right?
- 11:31
But it's actually laying this out for us. So here's where the position and velocity are. Uh, it's got the desired velocity. It's got the gravity fields. Uh, and then it pulls the routine together, and it, it should actually have a, yeah, an algorithm in here called P65 guidance, uh, that implements this in Python.
- 11:46
And so our final position as it ran this here... Let me go, let me catch up with my, uh, with my chat.
- 11:55
Yeah, and it ran the simulator. Final position, this number of meters, final vertical and horizontal velocity, uh, and you can see that it landed, you know, within our, uh, zero to one meters that we would expect for our final simulation values.
- 12:08
So yay, Augment Agent. [clapping] Good job. [laughs] It landed on the Moon for us. Okay, most of us are not landing on the Moon as part of our day job. So is this a parlor trick?
- 12:17
Is there something we can actually learn here? So this is what I would take back to a legacy code base of mine based on what we've seen today. There's three basic steps.
- 12:25
Number one, anytime you pull this open, you're gonna try to use the agent to help you understand on your own what's going on in that code base. So Augment Agent will index it for you.
- 12:33
You can ask questions in chat. You're gonna be asking questions like, "What does this code base actually do?" Right? "What does this piece of the code, what does file XYZ do for me?
- 12:41
Are there style or convention things going on here that I should be aware of?" Uh, and then you can start writing some tests. So sometimes people ask, like, you know, "If I am not sure I fully understand this code, am I gonna know if the new code that I create is actually correct?"
- 12:55
So I think a blend of agent and chat mode are gonna help you out a lot here. Use chat mode to predict what you think the code should do.
- 13:00
So in the case of the P65 algorithm, you know, tell me what I think should happen when I run this lunar descent given these input parameters, and then have the agent mode write some tests to check that behavior.
- 13:10
It's not always gonna get it right. I had a case where it was working with the scheduler, and it couldn't decide for itself whether priority level zero was the highest level or lowest level in the system, and you could convince it either way.
- 13:21
Like, it's a classic thing an agent would struggle with. So take the time to go, you know, read yourself, right? Have it surface those pieces of the code for you, and then, you know, you're an engineer.
- 13:30
You can in- apply your human ingenuity to it. And then modernize. Start converting small portions of the code in modular fashion to the desired language or, you know, style that you want and apply those same tests to make sure that you're not getting far afield from what the actual functionality of the code should be.
- 13:46
And that is not just a strategy for success landing the Apollo 11 guidance computer on the Moon, but for working with your code as well. All right. Once again, you can try Augment Agent yourself, uh, for free at augmentcode.com.
- 13:59
Uh, bring your gnarliest legacy code bases and refactoring projects. I forget how many lines of code are in the Apollo guidance computer repo. It's thousands. Um, I mean, that's reasonable for this, right?
- 14:10
Yeah. That's pretty small fry-
- 14:11
Yeah
- 14:11
... when it comes to, like, enterprise projects these days. So, you know, the real world equivalent of this kind of thing might be, like, I've got a Java eight project.
- 14:18
I wanna go to Java 17. Uh, it's really tedious, toilsome. How do I pass some of that over to, to AI?
- 14:25
Yep.
- 14:25
That's the, that's the, like, real world equivalent, yeah.
- 14:27
That's right. And as you can see, it's pretty fast too. Um, and you can bring your greenfield projects. There's no shame in that, but, uh, the legacy ones I think are a little bit more fun.
- 14:35
That's all we've got. Yes, sir. What about things like, uh, checking for dependencies across, like, a large code base? It loves to do that. Yeah. And it can actually go back in and- Yes, it can.
- 14:48
And you actually s- in 20 seconds, you actually saw a little bit of that here, right? Where it went through and, like, there were some missing files. It tried to run Python and said, "Oops, it's not installed.
- 14:56
I'm gonna use Python 3 instead," right? There's... It's happy to do that. In 12 seconds, go ahead, Drew. What you showed was test-driven development effectively. Yes. Like, did this move, move the needle on whether that's a recommended practice or...?
- 15:08
Yeah. Agents love to reason and iterate, so any way they, they can check their own result is very helpful. So tests are good for that.
- 15:15
That's a great question. We are out of time. Thanks, everyone. We appreciate you. [upbeat music]