Now that you built your first app using an AI collaborative agent, let us go back in time and look at the history of these tools and how we got here, and separate some of the hype from the reality. Let's dive in. Let us start by understanding the AI code assistance landscape, and think about mental models of how to think about these different types of code assistance, and where the lines between hype and reality lie. To set this up, we'll start from the very beginning. Before AI altogether, when it was just humans, we could represent the actions that a human would take, as they were developing code as a timeline of various actions such as navigating through code, making edits, doing research. When ChatGPT and other tools like GitHub Copilot, Codium and Cursor started coming out, we started entering what I like to call the age of copilot-like assistance, where instead of humans having to complete every single task, individual small pieces of the overall problem, such as making an edit or doing some research could be replaced by getting an autocomplete suggestion or asking a chat-like experience a question. This was clearly value additive and has propelled the industry forward. Over time, these have gotten better and better by increasing access to private knowledge sources. In the code world, this could be something as a private code base. The large language models themselves, we're not trained on these private code bases, but by giving access through methods of retrieval, these AI assistants could give more grounded answers and responses and suggestions to the developer. And this has made things even better. Combination knowledge, improved UX, over time, these tools have added more and more value. The best way to think about these copilot like tools is like a person just starting to learn how to code. You can't really ask it to do a very long running task, because it can only has a single call to an LLM. But by reviewing it constantly, you can definitely get value and speed yourself through. But this idea that a single call to an LLM was the limits of these copilot-like tools, it posed a limitation to the overall amount of work that the copilot-like system could do. And that is why we started talking a lot about agents. The first iteration of agents that were being discussed is this idea of an autonomous agent. Tools such as Devin from Cognition fit into this mold. And the idea is relatively simple. Instead of every single call to an LLM being an individual invocation that has to be reviewed by a developer, we would have the AI system be able to chain multiple calls to LLMs and integrate access to tools that would change the state, or give new inputs and information to the AI system. And this, in theory, would be able to allow the AI system to complete larger and more complex tasks. They still have access to knowledge sources, just like it was for the copilot-like systems. The best way to think about these autonomous agents is like an intern or a junior engineer, where you need to still scope out the task very clearly for them, and after they complete their work, you have to actually go in and review all of the work that it completes. And so that is just part of the reality and one way of framing the idea of autonomous agents. The other reality is that a lot of these autonomous agentic systems, especially in software engineering, do take a lot of time. And so anyone who has worked with another intern or junior developer knows that there could be some parallel development work going on between you as a developer and the AI agent. And so after this idea of autonomous agents, really the next kind of generation of tools is this idea of collaborative agents, which I might refer to as flows throughout this lecture and others. The basic idea behind flows is to treat the AI instead of an intern or a junior engineer that you delegate work to, treat it more like a peer programmer. And the beauty of treating it like a peer programmer is, instead of having to perfectly scope out work and review a bunch of work from an agent, it is kind of this back-and-forth mind meld like experience, where any actions that the human takes in, for example, in the IDE can be reasoned about by the agent. And any of the work that the agent does can be reasoned about by the human. Of course, still have access to knowledge sources. But this combination of knowledge sources, tools, and the understanding of what each other is doing creates this kind of new experience that tools such as Windsurf and our agent called Cascade really kind of build upon in terms of paradigms. But that being said, it's important to still keep a reality of what these tools are capable of doing. While there might be a lot of hype about the capabilities of AI systems and AI agents for software engineering, the reality is these flows have some of the same kinds of issues and downsides as any of the other kind of agentic or non-agentic systems that came before it. These are all using large language models under the hood that have data distribution issues. Not every single language or framework is equally represented in the public corpus of data that these models are trained upon. There might be imperfect tool calling. There might be limited tool sets that don't fully match all the different things that a human could do or a developer could do. And the reality is, there's always going to be some incomplete intent that these agents won't have. The conversation that you have at the watercooler with the coworker is never going to be something that the agent will be fully aware of, so you can't expect the agent to know absolutely everything. And so therefore, guiding it to the ability that you can doesn't improve the performance. So this all leads to the question of why should we talk about AI code assistant today? It really is two halves. The first is these are available for use right now. There's a lot of theory about agentic systems, but not too many applications that any individual are able to freely use on their own time. And so we can use this time to understand really what goes into building an agentic product that is generally accessible. And some mental models of how to think about these products underneath the hood. And of course, the other half is that this is a tool for software engineers. So you as a developer can understand how to best leverage them, which will give you an edge in your development.