This content demonstrates how to build the fundamental architecture of an AI coding agent, capable of interacting with code files, using only approximately 200 lines of code. It breaks down the core loop of such agents, showing how they leverage Large Language Models (LLMs) and a set of defined tools to perform development tasks.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
All
right. Hi everyone. Uh this is Mi Hy. I
wanted to put together this video
because just earlier this week, we had a
class for CS146S, the modern software
developer. It's a class uh the first of
its kind that we're teaching at Stanford
this fall. And the class is all about
modern software development practices.
Basically, how we can use AI coding for
every single part of the software
development life cycle. Now, in the
class this past Monday, we were we spent
the entire class basically going through
how we can implement the core of an of
an advanced coding agent like cloud code
or cursor or warp uh in just about 200
lines of code. So, we walked through uh
the entire source code, showed that it
really doesn't require anything more
sophisticated than than basic
algorithms. And what I want to do in
this video is actually go through that
same exercise, do a little bit of a
screen recording of myself uh coding up
such an agent uh and show that in about
200 lines of code, we have the core of
what powers most of these amazing coding
platforms that we've been using.
So here we are. Um that's what this
recording is going to be. Again, this is
for uh this is this was done this past
week for our new class. And if you're
curious in following along, the the
course materials are at this URL, the modernsoftware.dev.
modernsoftware.dev.
Uh we post all of the lectures, lecture
slides, uh assignments, and readings.
So, everyone is more than welcome to
follow along. But for the rest of this
this thing, let's let's actually dive
into some code and see how very quickly
we can build the core of of of a tool
like Cloud Code, which is which is just awesome.
awesome.
So, what I have here is the kind of the
starter code for what we're going to be
building. Um, I've already already put
together some scaffolding. It's about 60
or 70 or so lines. Uh, the way to think
about this is there's nothing super
crazy going on here. We're initializing
an an API client to some underlying
model provider. It could be OpenAI, it
could be Cloud, it could be literally
anything. But here, we're just using
OpenAI for for our purposes. Uh, we're
going to fill in a system prompt later.
So, this is just left blank.
There's some uh formatting uh strings
just to make it easier to to to color
the outputs of of our uh of our what we
print in the console. And so, you'll see
the differences in the colors. There's a
really simple utility that we put
together which is just a way to go from
the name of a file to the fully the
absolute path of the file. So, uh, we're
going to use this later and it's just
going to be helpful for the the agent to
actually open up files when we implement
those things.
The core of what powers this agent is
really going to rely on three tools,
right? So, three tools that we're going
to use to do so. Um, three tools that
we're going to have to implement are
read file, list files, and edit file.
Okay, so the way to think about any
coding agent today and what it really
does is it's actually quite simple. So,
it's a chat, right? Me interacting with
an LLM. And when I issue a request to
the LLM, maybe asking it to create a new
file or something like that, it will
return something to me which its
response may include lists of tools that
I should be using or issuing. So, I
might tell the LM, hey, make me a new
file. and the LM might issue a a tool
such as edit file with the arguments of
what I should be editing. Now I as the
recipient of the tool will receive that
you know in this case JSON we're going
to implement but you know you could
format it however you want and then I'm
actually going to execute that tool call
right so I myself the user I'm executing
this tool call um or I guess a lot of
cases the IDE or or cloud code is
executing the tool call and then we
return the response of the tool call uh
to the LM and so the LM then then we
just append this to a running
context like a conversational context
with what happened when we issued the
tool and the LM receives that uses that
context to then follow up. We might also
issue another query um with that context
like some some other user prompt and
then the loop just continues
indefinitely. So that's really the core
of the the loop, right? I issue prompt
or message to LM. LM responds and
detects whether or not I it needs a tool
to to do uh to kind of service the the
request. Um, and then based on that,
either we're going to issue the tool
call, execute it, you know, off the
offline, so not by the LM, uh, and we'll
return the response of the the output,
or we're just going to keep having
normal conversation because not every
time that we say something to the LM are
we going to have to actually, uh,
interact with tools. But anyway, so the
the crux of this is there are some tools
we're going to have to implement and
make available to the LLM, to the agent
to actually use. And so these are the
three tools that we're really going to
need. That's the core of what's going to
power this agent. And we're going to
have this uh kind of like tool registry
or tool uh just like a mapping from the
tool to its implementation. And then
there are these two other utilities. Get
toolster representation. As we'll see
later, this is just going to be a a way
to actually uh take any given tools
implementation, return a stringified representation
representation
uh which we're going to use to then feed
into a full system prompt because
remember we didn't actually uh we didn't
implement the system prompt yet or we
didn't write it, but eventually we will.
And we're going to need to have a sort
of collection of all the tools that we
have available to do that. And then
we're going to have a uh an extract tool
invocations which is going to be
responsible for receiving the output of
the LM that might tell us to actually
you know issue a tool execute a tool.
And so we have to parse that from from
the LM's output. We're going to have a
function to execute LM calls and this is
just going to be a really simple
function to interact with the the
clients that we've defined above. Then
we have the core of the agent loop, the
coding agent loop. And this is really
going to be the workhorse of kind of
running through that that sequence that
I've described. So that's the core of
it. Uh by the end of this video, we'll
have implemented about maybe 100 to
maybe 100 lit 150 lines of code um
powering all of these and and
implementing all these. So that sounds
good. Let's let's get get into it and
I'll be talking through this as I code.
Um and then and then hopefully that that
that's something you guys can can refer to.
to.
Okay. To start th this we're actually
going to implement the loop first,
right? The core loop of the agent. And
for our purposes, I'm going to really
just um start by printing out our FTON
prompt. This is just going to be useful
for debugging. Um, and then we're going
to use it as we build out the rest of
the components to iteratively
uh kind of see that we're that we're
changing that prompt.
So, we start by initializing this this
conversations object which will really
just keep track of all the messages that
we sent the LM. And anyone that is has
maybe issued API calls to GPT or Claude
or something like that is maybe familiar
with this format or O Lama. um this is
just the com kind of standard u message
format that that a lot of these LMS
currently use. So what's the role of the
of the message of this particular
message and what's the content of the
message? So we're starting with the
system prompt. So we're going to issue
the system prompt and then the core of
the loop starts by saying well while
true so you know loop this indefinitely
start by getting the user input. Okay so
we're going to get the user input. We're
going to use something pretty simple
here. Um, you can see now this is where
we we made use of those uh like antsy
code escape strings that I had at the
beginning. This is just going to color
the the U in this case a different
color. And we're just going to do that.
Nothing crazy there.
A little space. And then if it this
doesn't work,
we're just going to be defensive in our
programming and we're going to catch
keyboard interrupts and add a file
errors. Um, and that's just so we can uh
control C and control D if we want to
break for whatever reason, you know, as
we're debugging, we're going to break
out of the loop. Okay, cool. So, we have
the user input. We're going to start by
just appending that user input to the
conversational history. So, here in this
case, the role is user rather than
system. and content is uh just user
input that we strip out just to clean up
any trailing whites space characters. So
now we receive the user input and now we
have to go into the loop of what the
agent is doing or what the LM is doing.
So this is going to be one more nested
while true loop.
So let's actually issue um get a
response from the LLM. So, we're going
to execute the LM call with the
conversation history that we've been
built out, which in our first run of the
loop, we'll only have two messages. The
system prompt and then the user message.
And then we're going to once we issue
the the response from the LM, which may
or may not have tools mentioned in the
response as we as we described, we're
going to extract the invocations of the
tools. So, let's start by extracting the
tool invocations from the assistant response.
response.
um as we want to do
and we have two different cases. If
there are no invocations, if there's no
kind of tools explicitly mentioned in
the string, we're going to uh just
continue as we normally would. But let's
first print the assistance response
Again, we're using a different NC uh
escape string just because we're use a
different color. Okay.
And then we're going to uh just provide
the assistant response here, which is
And then we're going to append that to
the actual history of the conversation
that we're that we're running.
In this case though of course the role
is system
and the content is the ecosystem response
response
However, and then we want to break this.
We want to just break out of this. Um,
so we don't uh because if we're just
continuing, if the LM is responding and
we uh have no tools to call, then we
should just go back to the user and kind
of go back to the very top of the loop.
And then if that's not the case, let's
bit redundant here, but you know, not
saying this is the most clean and
perfect code, but it's it's it's
relatively condensed. Um, so there's a
bit of redundancy here, but let's just
do that
again. We're going to append this. So,
Okay, we're in the second case here
though where we have to iterate over uh
tools because the second case uh the
first case was we have no tools invoked.
The first case is no tools invoked. The
second case is we actually have tools
that the LM has said we should interact
with. So let's let's do that. So in
order to do that we you know this object
will presumably be not none and we're
going to iterate over the object. Now,
we'll show later what format the uh
function is expected to return when we
call extract tool invocations. But but
to give you kind of a a a look ahead or
or give you a little bit of taste of
what's to come, uh it'll be like a list
of of of objects tupils names where one
is the the first entry of the tupil is
the name of the tool to call and the
second was the arguments of the tool
that we should call. So that's what
that's going to look like. We're going
to print this just for debugging and so
we see what's going on. And we will
start by first getting the tool. So
we'll use the name of the tool that we
extract from the tool invocation to get
the tool. And then we have a few
different cases. Okay. If if the if the
name of the tool is read file, which you
know we had listed up here, this is the
this is the actual uh key to value
mapping. So if it's read file, we should
in theory call read file tool. But for
for our purposes, we're just going to
print um read file called because the
the existing read file implementation
doesn't do anything. But if it's list
files, then we'll
we'll print edit files.
Uh again, we're going to fill this in
later, but uh we're so we're just going
to leave stubs here for now. Uh and then
of course, we could have like an else
catch all. If an existing other tool is
called, we should, you know, either
throw an error or tell the user to you
try again. Uh we're not going to do that
for now. Just just to just in the
interest of time. Okay. And at the end,
we will append again the output of this
tool call.
This time it is because we are issuing
the tool not the LM we are receiving the
tool name issuing it and then returning
the response. The role in this case is
the user. So it's actually user message
and the content here will be a
particular format that we define uh but
let's just uh the the format is as
follows. when we return the output of
the LM uh of the tool call, we will say
we'll prefix it with tool result and
then we'll say just dump the actual
response of that
JSON.dumps response need to make this an
F string so it can do that. I should
probably initialize restp to something here.
here.
Um maybe like
rest. We'll just call it blank for now.
Actually, this is probably error. So,
We're going to fill in response when we
actually get the response the tool
calls. Okay, we're almost at something
that's useful. Okay, in order to make
this useful, because right now, if we
ran this loop, it really really wouldn't
do anything. To make this at least
mildly useful, we're going to start by
uh issuing or implementing the execute
LM call. So the way we do that is we're
going to start by uh again it's like a
pretty simple function because all we're
doing is interacting with the OpenAI
client which does the most bulk of like
the actual talking to the LM. And so the
way we're going to do that is we're
literally just going to say response equals
equals
OpenAI client.comp
completions.create create
um model equals GPT5
message equals messages equals
conversation as we would expect. And
then max completion tokens
max completion tokens equals let's just
say 2,00 to be really aggressive. This
is probably way more than we need but
you know just to be on the safe side.
Then what we return at the end is
response. Choices zero dot
Okay, so at this point we have
implemented the uh we've implemented
this uh function to interact with the
actual OpenAI client and that's just
going to issue a call to the LLM and
then return a response. Now, one thing
that we have to include is actually
we're going to just initialize rather
than a stub that says pass in the get
full system prompt, we're actually just
going to return an empty string. Uh just
because we're appending this to the
conversation and that's what we're
providing for the LM. So, we shouldn't
provide none messages to the LM. But at
this point, we actually have something
that we can at least talk to and not do
anything useful because we haven't
hooked in the integration with the tool calls.
calls.
So look at this. Hello there.
Yeah. So again, all this is doing the
loop without the tool calls is literally
just a conversational loop where we
issue something to the LM and the LM
returns with a message and then we just
keep going like that indefinitely. Um,
so there's nothing super crazy here.
It's not yet a coding agent. It's just a
chatbot really.
Okay. to get it to a point where it's
more interesting, we have to start
implementing uh the core crux of the
other aspects. So there's a few pieces
that we're going to implement and then
we're going to run this again. The first
piece that we're going to implement is a
kind of fleshed out system prompt here,
right? So that's what we're going to
implement is actually just put in some
of the meat of this system prompt into
which will describe the behavior of the
agent and then we're going to fill in
some of the implementations of the other
functions. So let's start with the the
the putting in the meat of the system
prompt. So we'll start by saying you are
a helpful coding assistant
whose goal is to help complete
complete
coding tasks. Okay, this is defining the role.
role.
You have access
to a series of tools. You can execute
even though it's not actually the one
executing. We're the ones executing, but
just tell it it knows what it can
execute. Here are the tools
And then the string, this is going to be
our tool list stir.
This is going to be something we fill in
with another function later that you
might remember we we stubbed out.
Okay. Now, really important part. We
describe what's the format of the output.
output.
that the should return if it wants to
use a tool. When you want to use a tool,
reply with exactly one line in in the format
So a string prefix and then specifically
the tool name
and nothing else.
Okay, so literally just a single line
when you want to return tool call.
Use compact single line
after receiving a tool result message.
You should continue with the task.
respond normally. Right? So
if you wanted to issue a tool lm output
this format with the tool name the
arguments make sure that it's singleline
compact JSON and then after we execute
the tool and return the tool response
using this tool result format which
you'll remember from down here
uh down here like this then proceed
forward. Okay, so that's the core of the
system prompt. That's all we need to
describe to it.
Okay, let's now start by putting in this
this these two bits. First is the kind
of tool representation that we want to
provide to the LM. So to get the full
tool representation string, we're going
to first start by uh getting you know in
this function we return we're pro being
provided the name of a tool. Let's
actually get the tool just a single tool
representation for this tool.
It's going to look something like this.
It's, you know, it's arbitrary how we
define this, but for our purposes, we'll
we'll we just have to be explicit about
what the name of the tool is, what it's
doing, and sort of like a signature
definition. That's that's the kind of
explicitness that the LM needs to know
in order to reason about that tool. So
we have the name, we got the description
and that'll be just from the doc string.
This is going to make it that we have to
be very explicit about our doc strings
when we define our tools as we'll see
signature.
So there's like a built-in a Python
builtin that allows us to actually get
this the signature from the defined
tool. So it's important that we have all
these like type definitions both in the
inputs and the outputs. Okay, now we get
the so that's getting one tools
represent string representation. But
when we want to inject that into the
system prompt and that that dynamic
variable that we have defined, we're
going to want to fill in the entire
We're going to some toolister.
tool list uh sorry toolster repper
equals plus equals we're just going to
append to it. And our format is a bit
arbitrary, but we're going to define it
of the tool name.
Okay, so tool,
tool,
you know, there'll be a new line there's
like triple equal signs add a single
toolister representation and then we're
going to
demarcate the end of that tool call. And
then if we have to go over multiple
tools um tool definitions, then we're
just going to make sure there's a line
Mhm.
Pretty arbitrary. Again, you can format
this how you want. just should be, you
know, reasonable in terms of uh
something that the LM can can uh parse
out and understand the semantics of what
a tool is doing and how that separates
from the semantics of other tools. And
at the end, sorry, we actually have to
do this. We're going to format the tool
stir or sorry tool list stir to be equal
to tool stir repper tool list rather
tool. So this should be tool stir repper.
Okay.
So this is now going to inject our
consolidated definition of all the tools
We have one more um one more thing to
implement that's pretty important sign
piece before we can start implementing
the actual tool calls. And this is like
the the the function that extracts the
tool invocations. So again, what this
does is it effectively receives the
response from the LM which may or may
not have one or more tool calls in the
response and we have to parse out those
tool calls and then use that to then uh
determine whether or not we need to
issue a tool call
with the name of the tool as well as the
arguments. So the way this function is
going to work is it's going to take the
typically what we'll provide to it which
is going to be like the assistant uh the
tool um the LM's response and it'll
return a list of tool names and
arguments as we mentioned before and
then again because the LM is going to be
outputting this format that we
explicitly ask across many maybe one or
multiple lines we're going to parse that
out. So let's let's do that. Let's see
what that looks like in practice. So,
we're going to keep a list of all the
tools that we parse out cuz there could
be multiple, one or more.
And it's going to be quite a bit of a
just raw string parsing. So, let's start
by getting the lines of the lm of the
response. So, we're going to
line strip
and if not line starts
with tool. So, this is not it doesn't
have the format that we expect. then continue
continue otherwise
otherwise sorry
we have to again this is
admittedly some somewhat slightly
brittle string parsing but um
yeah you can make it of course more
defensive and and be more careful about
this but the way we're going to do this
is we're literally going to um just kind
of lop off the prefix of the tool tool
call uh that the LM issues. So take away
the tool colon prefix and then we're
going to parse out what happens after
that which
for our purposes will be um
uh it'll be kind of like the tool name
and the arguments of the tool. So we
need to get the name and we need to get
the arguments. So we'll first start by
getting the name and the rest of that
string. Um,
so if not, if the rest of the string
doesn't end with the open colon, the
open uh parenthesis, then this is like
an ill- formatted tool call. And we
don't want to deal with that cuz who
knows what it is. So, we're just going
to be slightly defensive here and say if
it doesn't end with
this thingy, this close parenthesis,
then continue. Don't go forward.
Otherwise, it should be well formatted,
right? It should be something like this. Um,
Um,
take everything up to the end of that uh
closed parenthesis
and we're going to just load it because
we're expecting it to be JSON because
that's how we we provide uh we
explicitly ask the element to produce
JSON, you know, compact single line JSON.
JSON.
And then we're going to append both the
name and the arguments
to this this running list of invocations.
And then if there's some exception that
happens, uh, move forward. Again, we
could be more explicit about the
exceptions. This is obviously not the
best way to write this, but just for our
purposes, we want to kind of see see
what happens. Um, move forward and then
we're going to return the indications. Okay.
Okay.
We're at a point where we have the core
crux of uh the loop. Now, we're still
not able to do anything useful or
interesting yet because we don't have
any other tool uh implemented. So, if I
just ran this again, it would look very
similar to what we had at the beginning,
which was just talking to a chatbot. So,
let's implement one tool, the first
tool, and then hook that up to then see
what happens when we have this loop. So,
the first thing we're going to blend is
the simplest one, right? It's the read
file tool which as the name suggests
allows us to read files. So
there's a few things to to note here.
One is because when we get the tool
representation for the LM we extract the
dock string, we extract the signature,
we have to be very explicit about some
of these aspects. So in particular the
doc string should be like pretty
descriptive. You know this is something
you generally need to know is when
defining tools for LMS to use, be be
explicit. Be particular about what
they're doing. Don't just expect that,
oh, if I define the function, then the
LM knows what to do. No, it actually
it's it's using the dock string to
actually reason about what the tool is
doing and whether or not it should use
it, at what point in time it should use it.
it.
So, we're going to describe in fairly
explicit detail for something that seems
very simple, what it does. So, get the
full content of a file provided by the
user. Okay? And we define the parameters
which in this case is just file name.
The name of the file to read. Again
annoyingly maybe obvious but but again
we have to be explicit. The return
should also be clear. Full content of
the file. Uh it's pretty important to to
follow the to make it easy to parse this
right. So adding these colons ends up
being really helpful for parsing.
Now the actual implementation. So first
let's get the full path. So this is why
we had this this utility for resolving
the absolute path. Uh we're going to
provide that in there
and just for debugging we're going to
print the full path and then we're going
to get the actual content. So let's see that
read
All right let's wire it up. we have this implementation.
implementation.
So remember how we had stubs out here in
the actual loop. Let's actually make
tool calls, right? Uh which is what we
have to do as as the people that are
interacting with the LM. So
we got the name of the we have the tool
from our registry here.
We're going to get
and that's it. This should be enough to
actually interact the first tool.
So let's see what happens.
Okay. So as you can you you'll see here
uh now we have a the system prompt that
we printed at the beginning for
debugging. Right? this this um this
thing up here. Sorry. Up
very way up here. This is what it looks
like. Right. So, we have like the the
kind of first part of this. Oops.
Maybe I need to just Oops.
I just think I start a debugging
session. Sorry about that. Um
Um
So your helpful coding assistant as we
described in the assistant prompt you
know here are the tools you have access
to and then here are the the
representations of the tools.
Most of them like the edit file and list
files doesn't really have anything
interesting. Um, so all it has is the
name and the signature which is extracts
from the input and the types of the uh
output that I use type definitions for.
But the tool, the read file tool
actually has something more interesting.
It has the description which is which is
taking the dock string, right? And this
is what allows the element to reason and
to know when to use the read file tool.
Now let's give that a shot, right? So we
have something here. We have a um we
have like a few files in this um in this directory.
directory. So
So
this this file in particular will will
print and say uh okay what's in
Okay. You see the assistant issued a
read file command with our compact
singleline JSON as we would expect.
Awesome. It detected the name the file
name from my request, resolved the file
name to this path and then printed out
the contents of the file. Is this what's
inside the file? Let's see. Yes, it is.
It's literally just a very simple twoline
twoline
main function uh printing out this
works. Awesome. Right. So this is just
our first tool that we've actually
hooked hooked into the LM that it's able
to use uh to understand the semantics of
the tool and then know when it should
actually issue the tool based on the
user request which is great.
So this is the first step toward the agent.
agent.
We have two more tools to implement
before this becomes like really really
awesomely useful. So the the next one
that we're going to implement and we're
going to go through these
implementations a bit more quickly in
the interest of time is the list files
tool. So the list files tool is just so
we can like point to a directory say hey
what's in this directory and the element
becomes a little bit more autonomous and
in sort of reasoning through those
pieces. So let's start by implementing
this. Again, we're going to be very
explicit about the doc strings. This is
the files in a directory
provided by the user. The pram is the path
path
the path to the directory to a list of
full path equals resolve absolute path
as we did last time. We're going to you
know create a list of all the files that
file name.
So this gives us the name of the file
which if it's um
if it is a file then print file is a string
string else
else
and then we're going to return
again we need to we need to provide
return things because that's what we
provide in the tool result. So that's
why these are very explicit about um
being almost like JSON representations
because that's what we will provide and
add to the context of the LM. Okay,
you know let's see what uh now this
should be able to work. Actually, we
Okay, that's basically all we need.
So, now we should be able to we have a
second tool, our second tool wired into
the LM.
See, it issued the list files tool. And
so, it's going to issue that. And boom,
this is what is in list fi. This is
what's in week two, which is awesome.
And we could, you know, go one step
further, ask it to, uh, you know,
actually open up that file using our
read files tool. Uh, and then that would
be kind of twostep interaction with the
LM. But let's do one more thing to
really close the loop and then reach
Nirvana, which is to actually issue
implements the edit file
tool. So let's do that.
The edit file tool is the most the mo
probably the most complex of the three
tools. Uh but it's not it's not crazy. Basically,
Basically,
our edit file tool will
either create a new file depending on
what's provided as input parameters or
it'll replace existing files sort of
like replace them within an existing
string. So first we replace the first
occurrence of old stir which is the old
thing that maybe exists in a file or
something with the new thing we want to
replace it to. So either we're going to
replace oldster with newster in the file.
file.
Now if old stir stir is empty
uh then we're just going to
create create overwrite
file with new stir.
So this is just a a convention that
we're going to use. If if like old store
is just the empty string, then we're
going to create a new file.
the string to replace
return a dictionary
and the action taken. Again, this is
just to be explicit in the response so
equals resolve absolute path path. If
old stir is this thingy,
namely the empty string, then we're
going to uh write text. We're going to
write our string. We'll be explicit
about the encoding just to be on the
safe side. And in this situation, the
So this is if we're creating a file from
scratch. Otherwise, we could we're going
and then if we need to first find the
old stir that we want to replace. So
we'll find where that is. But if it's
you know if we can't find it which would
happen if we call find and it returns
negative one then you know we need to
know that we can't even replace this.
We can't replace the old store with a newster.
So, we'll just literally tell the LM, hey,
uh, old stir not found. You know, we
could do something more sophisticated if
we discover the old store is not found.
You know, we can reprompt the user to
tell us what they want to replace or or,
you know, do some sort of like um make
some implicit assumptions. That's
typically what ID's like these aides and
AI coding platforms do is depending on
tool results, they might bake in their
own fallback behavior. Uh but for our
purposes, we're just going to keep it
Okay. But if it if we do find it, then
we got to edit. So we're going to do is
we're going to replace
old stir new the first instance of
oldster with newster.
And then we are going to return that
again. What action did we just take? We
Cool. So this is the implemented edit
file tool. And then we need to actually
wire that into the the you know down in
So what we're going to do is we're going
to get we have three different arguments
we have to provide to the this
particular tool. One is the the path
right? So we're going to get the path.
which we can get. And finally the newster.
That should be it. Okay. So now that
we've implemented this, we can actually
put it to test. Let's see what happens.
So if I run this, I should now be able
to say
make me a new file
and implement
hello world
Hello. is the path. Oldster nothing.
Newster print hello world. Done.
Done.
hello.py
and add a function to it for multiplying
two arbitrary numbers.
So first we get hello.py.
We read it. Boom.
We saw what it was before. We edit it.
Right. So the old stir was this print
hello world. New stir is the
modification with the new function.
And then we return the response of this
edit. Said hey we just added a multiply
function. You good? We're good. Look at
it. We just produced code on top of
code. We edited the existing file.
That's crazy. This is the core of the
coding agent loop. At this point, we
could keep creating new files. We could
keep editing existing files. And that's
all there is to it. That's all like
things like cloud code are doing. That's
all you know, cursor and whatnot are
doing. I mean, of course, there's more
complexity, but it's all the it's all
the filler. It's all the fluff around
it, right? Bells and whistles that they
add on top of this just to make it more
streamlined of a UI. But if you look at
what we just did,
this is 27 28 lines of code and we have
a functional coding agent that we could
use to write code just by talking to it.
Absolutely crazy.
I hope you guys enjoyed this this video.
Again, this was for the, you know,
lecture that we did at the Stanford
course, the modern software developer,
where we're talking about all aspects of
the of the software development life
cycle and how it's changing because of
AI coding. So, please follow along. Uh
the URL uh is is up here. I'll be
sharing this code as well. Um just you
can see all of our lecture materials,
assignments, readings, etc. um at this
particular web page. Please follow along
the modern software dev. Thank you all
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
