Welcome to AI Code, a course on building software with coding agents. This introduction explains what agents can do, how they work with a project, and why we still need to check their work. We'll also look at the risks of giving them access to our tools and files.
AI is changing how people work in computer science and in other fields.
Software development is one area where these changes are easy to see. Coding tools can write and change code, then run it to check parts of the result. During the course, we'll look at why these tools are useful for software development.
This course is a chance to start using coding agents on real projects and work through the questions they raise. We are learning these tools as they change under our feet. So some of what we learn here may change during the course itself. People are still working out how best to use AI, and many questions remain largely open. That makes this an exciting time to learn these skills and wrestle with questions on the cutting edge.
Over many decades, programming has added several layers of abstraction. An abstraction lets us use something without spelling out every detail of how it works. Start with machine code. These are the binary instructions that the processor executes. Working at this level means dealing directly with those instructions.
A programming language gives us variables, loops, and functions. A compiler or interpreter turns these into work the machine can carry out. We do not have to write each processor instruction.
Libraries and frameworks give us code that already handles common tasks. We can use that code without writing it again. We still need to know what it does and when it might not suit our needs.
With a coding agent, we can describe the behavior we want in ordinary language. The agent then tries to write the code. We let it make some decisions that we would otherwise make ourselves.
Each layer lets us say more about what we want and less about how to build it. But less detail in our instructions does not remove the need to check the result.
There are three kinds of AI based coding assistants that we've seen recently, that progressed in their abilities. Autocomplete suggests code as you type. You accept the suggestion, change it, or ignore it.
A chat assistant answers questions and writes examples. You copy the code into your project yourself.
A coding agent works inside the project more freely. It reads files, edits them, and runs commands, and it chooses each next step from what it sees. Some of those steps may be ones you did not ask for.
While with an agent, the latest in this line of development, your part changes. You set the task, and then review the changes it makes, while it gets much more freedom to work on its own.
An agent can work through several steps without a separate instruction for each one. You give it a goal and access to the relevant project. It then chooses actions that it expects will help complete the task.
The agent may produce code faster than you can review it. When a request leaves questions unanswered, the agent makes assumptions. It might change more of the project than you intended. The result can therefore differ from what you wanted, even if the code runs.
Start the review by finding out what changed. Read the changes and check what they do. You need to understand the current code before deciding what to keep. If the work does not match the task, explain what is wrong and what the agent should leave alone. When changes build up faster than you can understand them, a gap grows between the code you have and the code you understand.
This gap is sometimes called cognitive debt. Closing the gap takes time. You may need to read, test, or rewrite changes you accepted too quickly. Sometimes you will decide to undo them.
How much autonomy should you give the agent? That depends on the risk of the task and how easily you can check its work. Letting it work longer on its own means giving fewer, less precise instructions and steering it less often. But a wrong assumption by the agent can also affect more changes before you notice.
To decide how closely to check an agent, we need to know what it does well and where it makes mistakes. The uneven shape in this schematic diagram represents uneven ability across tasks. Surprisingly, an agent can often do one difficult task well and still make a very basic mistake on another.
For some tasks, an agent can quickly write a working program or explain unfamiliar code. These are useful abilities, but success in the very difficult domain of coding does not always translate even to domains that we consider simpler.
The same models that can write working code in seconds used to get much simpler questions wrong. Asked how many r's are in the word strawberry, they would answer two, very confidently. The answer is three. Current models have gotten better at this particular question. The general point still holds, because ability is uneven and the weak spots are not always where you would expect.
The model generates text from what it learned during training and from the information in the request. This does not guarantee that it rigorously checks each statement before answering. So how do we explain this mistake with the word "Strawberry"? Models work with pieces of text that do not always match individual letters. For a counting task, using a tool to count can be more reliable than relying on the generated answer alone.
The lesson we must draw is this: check the agent on the specific kinds of tasks you give it. Do not assume that its competence level is the same for all tasks. What matters is whether the result it produces works in the cases we need.
A coding agent has a language model and software that connects it to a project. The large language model, or L-L-M, shown here runs on remote servers. Your computer sends it requests over the network. The model generates a response from the information it receives. That response may contain an explanation or a request to take an action. The model's response does not change a file by itself. Software around the model must handle that action.
That software is called the harness. It runs on your computer.
The harness sends the model a prompt. This contains the task and other information the model can use to decide what to do.
The harness then receives the model's reply. The requests and replies form the conversation with the model. Claude Code and Codex provide software that manages this interaction. The harness also connects the model's requests to tools that can act in the project.
A request to use a tool is called a tool call. Tools can read files, edit code, and run commands. The harness handles the call according to the permissions in place.
Tools can also get information from outside the project, for example by searching the web.
The agent can repeat this process as it works. The harness sends a request to the model, receives a reply, and carries out an allowed tool call. It includes the tool result in the next request to the model. Each result helps the agent choose what to do next. This loop continues until the agent finishes, needs help, or is stopped.
The model generates responses, and the harness handles tools and actions. We'll study both parts to understand what an agent can do and where mistakes can happen.
In this course, we'll use agents on real programming tasks. We'll ask how to get useful work from them while keeping track of what the software does.
As a project grows, more pieces of code need to work together. We need to manage those connections and keep cognitive debt under control. That means keeping our understanding of the project up to date as the agent changes it.
We still need familiar software design principles and checks. Tests check selected behaviors. Types and other static tools can find certain mistakes in the code. Review asks whether the changes fit the project. Each kind of check helps in a different way. Together, they make mistakes easier to find and the agent's work easier to assess.
These checks help us keep a growing project working and understandable. They become more useful as the codebase gets larger and more parts depend on each other.
An agent's tools can affect the computer where they run. Access to files, commands, and the network lets the agent do useful work. It also determines what harm a wrong action could cause.
With the right access, an agent can build features, fix bugs, help maintain your computer, and automate repetitive work.
A mistake might delete needed files, expose a secret, or run a damaging command. If several actions run without review, the damage can grow before you notice.
Trouble can also come from material the agent reads. A web page, file, or dependency may contain instructions placed there by an attacker.
The attacker wants the agent to follow those instructions instead of the user's task. The instructions do not have to be hidden. The mistake is treating that content as something to obey.
This kind of attack is called prompt injection.
Give the agent only the access its task needs. Also consider which sources of instructions it should trust. We'll study ways to limit the harm from mistakes and attacks as part of learning to work with agents.
The course covers five related areas. The first is giving agents programming tasks and reviewing their work. We'll practice this in the labs.
The second is managing context: the information the agent has available for its task. Project memory files keep instructions available, skills store reusable procedures, and subagents can work with their own context. These tools help us give agents the information they need without putting every part of a large project into one conversation.
The third area is checking the software. Tests, types, linters, and continuous integration help us find different kinds of mistakes. We still need to review what these checks cover and what they miss.
The fourth area is security. We'll look at containers that limit access and at attacks such as prompt injection. An agent that can act in a project also needs limits on what it can affect.
The fifth area is coordinating several agents on one problem. Splitting the work is only part of the job. We also have to combine the results and check that they work together.
Throughout the course, we will measure whether the result is better and how much effort it took. Producing code faster is not enough by itself.
The next video explains how the course works, including the weekly schedule, grading, and what to set up before the first lab. For this introduction, remember that an agent can do a lot of the work, but it is our responsibility to define the task, check the result, and control its access. This itself is not easy in a growing complicated project.