L01 Deep Dive (full): Course intro + the AI coding landscape EECS AASE Podcast, season 1, episode 5 Transcript of the published audio. The episode is AI-generated from course materials; this transcript is produced locally from the audio. Two synthetic hosts in conversation. Turns are separated by blank lines and are not attributed, because the local transcription does not label speakers and guessing at labels would be worse than none. Imagine walking into a really high level university computer science class, right? Yeah. The kind you've fought tooth and nail to get into. Exactly. You've spent, you know, countless nights debugging segmentation faults in C plus plus plus. Oh, the absolute worst. Right. So you finally secure a seat in one of the most cutting edge courses on the schedule. You sit down, you crack open your laptop, fully expecting the professor to, I don't know, immediately dive into neural network architectures or advanced state machines. You're bracing for impact. Totally bracing for it. Expecting to write some incredibly complex algorithms, but instead the professor looks at the room and says, um, look at the person next to you and just smile. Just smile. No code. No compilers. Nothing. Just forced, awkward smiling. I mean, welcome to the new era of coding where your biggest obstacle isn't syntax, it's your own psychology. It is incredibly disorienting. I mean, if you've been trained for three or four years, that your primary value as an engineer is, you know, your ability to manually type perfectly formatted logic. Being told to stop typing and start feeling is going to trigger some immediate resistance. Oh, for sure. And that is exactly the resistance we are tackling today. Welcome to this comprehensive deep dive. For those of you joining us, our mission today is to completely impact the very first day of AASE. Which, if you're following along in the catalog, is EECS 498, applied agentic software engineering. Specifically looking at the fall 2026 iteration. And our goal here isn't just to give you like a bulleted summary of lecture one. We are going to extract the core philosophy, the mental models, and really the practical survival guide you need to actually make it through this semester. Because it is a relentlessly demanding course, we're synthesizing a massive stack of materials today to give you the complete picture. Right. We've got the de-identified live lecture transcript. The actual slide deck presented in the room. And the official course overview documents. Okay, let's unpack this. Because the sheer ambition of a course that treats AI not as a gimmick and, you know, not as a shortcut for cheating on homework. Yeah, it's not just a fancy calculator here. Exactly. It treats it as a first-class load-bearing engineering practice. It's absolutely staggering. We're talking about a fundamental rewiring of how a human brain approaches building software. And what is so striking to me is that the instructor intentionally starts this massive technical journey with a YouTube video. Yes, specifically a channel called Sitting and Smiling. By a creator named Ben, right? Yeah, by Ben. And it is exactly what it sounds like. It's wild. The instructor references this guy who has over 300 videos, some of them stretching for like four hours long, where he just sits in a room, stares directly into the camera lens, and smiles. No talking, no movement. Just smiling. And the instructor uses this incredibly bizarre internet artifact to force an entire lecture hall of serious engineering students to physically smile for five seconds. Which, you know, feels deeply uncomfortable. I mean, you can almost hear the collective groans reading the transcript. Oh, I would have been groaning. Right. But there is a profound pedagogical reason for it, and it's grounded in embodied cognition. Okay, break that down for us. So the physical act of contracting the zygomatic major muscles in your face. The smile muscles. Exactly. Doing that actually changes your body chemistry. It actively lowers cortisol, releases endorphins, and forcefully alters your physiological state. Which begs the question, why does an engineering course need to start with emotional regulation? Because to survive this course, you are required to give up a massive amount of control to an AI agent. Hold on, though. Giving up control sounds great in, like, a corporate management seminar, but in software engineering, a single misplaced comma brings down an entire production database. Oh, absolutely. Are they really telling students to just blindly trust the black box? Because that goes against every survival instinct a programmer has. Well, they aren't saying blindly trust it, but they are saying you can no longer micromanage it. And giving up that micro-level control requires immense psychological safety. I see. Because if you are operating from a place of fear, specifically the imposter syndrome that just runs rampant and high-level computer science programs. Oh, yeah. Everyone thinks they're the one mistake in the admissions process. Exactly. If you have that fear, you will inevitably fight the tool. You'll try to manually rewrite the code the AI generates because you don't trust it. And then what happens? You fail the course. Yeah. Because you simply cannot type fast enough to keep up with the curriculum. It's like handing the keys to a student driver for the first time. If you're terrified they're going to crash, you're going to grab the wheel and mess them both up, you have to sit back with confidence. You know, using these new agentic tools is less like driving a car and more like being an air traffic controller. That is a great way to put it. You aren't flying the planes anymore. You are managing airspace, monitoring telemetry, and deciding when to wave off a bad landing. If you try to jump at the cockpit and grab the yoke of every single plane because you're terrified. You cause a massive pilot. Right. You have to sit back in the tower with absolute confidence. But confidence is fragile. What makes the lecture so effective is that the instructor explicitly normalizes the anxiety. They admit, on day one, to experiencing imposter syndrome themselves. Even as an MIT grad, an award-winning professor. Exactly. Hearing that from someone so highly credentialed fundamentally shifts the energy in the room. I mean, the tech industry has a terrible habit of completely ignoring the psychological friction of adopting new paradigms. We really do. We just throw powerful disruptive tools at engineers and expect them to adapt seamlessly overnight. And if they don't adapt, they get labeled as dinosaurs. Right. But if an engineer feels threatened by an LELM, if they feel it undermines their core identity as the person who, quote unquote, writes the code, they will actively sabotage their own workflow to prove the AI is bad. Acknowledging that fear is the literal first step to mastering the tool. Spot on. And the instructor doesn't let them passively absorb this lesson, either. They implement a mandatory exercise right there in the room, the neighbor affirmations. Oh, this part was fascinating. Yeah. The instructor states, I belong here and demands the room repeat it. Then they're instructed to turn to the student sitting next to them, look them in the eye and say, you belong here. It is a structural mandate, right? We must build a psychological foundation of mutual support before we even consider touching a keyboard. Because that foundation is about to be put under immense structural load. The structure of this course is not a gentle on ramp. Not at all. The instructor distills the entire 15 week semester into one single object and three distinct verbs. The object is constant. It's a coding agent. Everything you do, every single lab, every assignment, revolves around manipulating, extending, or evaluating this one entity. Okay. And what are the three verbs? Apply, analyze, and create. They dictate the entire rhythm of the semester. Let's break these down, because if you're taking this class, this is the map of the territory you're going to be navigating. Phase one is apply. This covers weeks one through three. What is the actual mechanism of work here? So in the apply phase, you are actively driving a coding agent, specifically a command line tool called AIDR. AIDR, yeah. To act as your pair programmer. You are learning the syntax of collaboration. How do you feed a directory of files into a context window without overflowing its memory? How do you instruct a language model to refactor a function? You're basically using an AI agent to build the foundational scaffolding of a larger application. So you're learning how to talk to the machine, so it types for you. But then we hit phase two, analyze. This runs from weeks four through seven. And the transcript outlines a shift here that sounds, frankly, terrifying. Taking yourself out of the loop. Yes. You take yourself completely out of the loop. It is the ultimate pressure test of what you built in phase one. You take that pair programmer you've been nursing along, and you give it execution tools. Okay. You give it an execution loop. You define hard stop conditions. You essentially turn it from a reactive tool that waits for your pump into an autonomous agent that acts on its own. And then what? Then you step back, let it run, and meticulously measure every single thing that breaks. Wait, wait, wait. You want it to break? Oh, yes. Because a lot of AI workflows only appear to function because a human is sitting there acting as the connective tissue. Just constantly catching minor hallucinations. Exactly. Or fixing bad syntax on the fly. By taking the human out of the loop, you expose the brittleness of the system. That makes total sense. You learn the profound difference between a tool that can write a Python script and an agent that can independently navigate a complex file system, run tests, and debug its own errors without hallucinating itself into an infinite loop. It's forced failure. You have to let it crash the plane to understand the aerodynamics. And once you understand exactly where and why it fails, you enter phase three, weeks eight through 15. Right. This is where you synthesize everything. You take that brittle agent and you grow it into a robust, full-fledged assistant. So adding real features to it. Exactly. You engineer long-term memory for it so it doesn't forget past conversations. You implement a structured design method so it plans before it actually codes. And finally, you build a non-terminal interface for it, moving beyond just the command line. You are recursively using AI agents to build the exact infrastructure that AI agents require to function at an enterprise level. It's so meta. But here is the architectural detail that completely blew my mind reading through the syllabus. The code you commit in week two and the massive complex demo you present in week 15 occur in the exact same Git repository. What's fascinating here is the pedagogical brilliance of that specific constraint. Think about a traditional EECS course. Oh, I know exactly what you're going to say. You build a linked list for assignment one, you turn it in, you get your grade, and you literally never look at that code again. Right. It's a totally disposable code. You never have to live with the consequences of your own bad late-night hacks. But in the real world of software engineering, code is a liability, not an asset. This course forces you to experience the compounding gravity of legacy code. That sloppy, poorly documented output you allow a small LM to generate in week two. You're going to have to write a parser that interfaces with that exact sloppy output in week four. And if it's undocumented, the AI in week four isn't going to understand it. Wait, if everything is one repo, what happens if you completely botched the architecture in week three? Doesn't this create a terrifying snowball effect of technical debt? Like, if you realize in week eight that your database schema is fundamentally incompatible with the memory module you need to build, are you just doomed to fail the semester? Well, what's fascinating here is that that anxiety is exactly what the course is trying to evoke. Managing that exact compounding technical debt is the real lesson. Really? So the struggle is the point. Absolutely. If you allow an agent to generate bloated, overly complex code early on because you didn't properly constrain its prompt, you will pay an exorbitant tax when you try to extend that code base two months later. The course forces accountability. It makes me wonder about the mechanics of agentic memory, though. When an LMM is asked in week 10 to modify a class it wrote in week two, does it have any inherent understanding of its own past design choices? None whatsoever. Really? None. And that is a crucial mechanism for listeners to grasp. And LMM doesn't possess a continuous, persistent internal state between isolated sessions. When you fire up Ader on a Tuesday, it has no metaphysical memory of what it wrote on Monday. So it's starting fresh every single time. Exactly. Reading three-month-old code is mathematically identical to reading code written by a complete stranger. It relies entirely on the explicit context you provide it in the current prompt window. So things like the clarity of the variable names, the architecture of the modules, the doctrine. That's all it has. Wow. So we've traditionally been taught that you write clean code so that the human developer who takes over your job in five years can understand it. But now you are writing or other curating clean code so that an AI agent accessing the file five minutes from now can parse its intent. The audience for code readability has shifted from humanize to machine context windows. Precisely. It is a completely different optimization target. You are designing code for token efficiency and semantic clarity for a machine. If that's true, if the AI is essentially writing the code and everything lives in one massive evolving repository, now on earth is the university possibly going to grade this? It's a huge challenge. Right. Because what's stopping a student from just setting up an auto- loop script, going to sleep, and turning in whatever Frankenstein code base the AI spits out? How do you attach a fair letter grade to that process? It requires a radical departure from traditional academic assessment. First and foremost, the syllabus makes it explicitly clear. There are no exams. Zero. I can literally feel the collective blood pressure of the listener dropping right now. But they shouldn't relax just yet. Oh, right. The assessment model is rigorous. It's just different. The grade split works like this. 10% is strictly administrative, largely driven by attendance verified through poll everywhere. Okay. Standard stuff. And they've built in a massive margin for the realities of student life. You only need to hit a 70% attendance threshold across lectures and labs to secure full credit. Which is incredibly generous. And actually, they had a live demonstration of why that flexibility matters on day one. Oh, yeah. The glitch. Yeah. The transcript notes that the poll everywhere system entirely glitched out in the room during the lecture. It cut the poll off after just two minutes instead of staying open. And the instructor didn't panic. They used it as an immediate real world lesson in system resilience. Systems break, APIs fail, stress less. Everyone just got the attendance points for the day. It was a perfect microcosm of the course's underlying ethos, gracefully handling failure. Now, the remaining 90% of the grade is heavily weighted toward the back end of the semester. It's split roughly 20% for the apply phase, 25% for analyze, and a massive 55% for create. But how do they physically assess the code? If there are no exams, how do I actually prove I did the work? Through an automated system they call gates. Gates. Okay. A gate is a fixed scored programmatic task. You run this task against your own locally configured AI endpoint. The university's test suite evaluates your application, reports back exactly what fraction of the required features your work successfully completed, and that raw fraction is your score. Then here's the absolute kicker that fundamentally changes the psychology of the homework. You can rerun the gate infinitely before the deadline. It's brilliant. It entirely removes the high stakes, heart palpitating anxiety of hitting submit and wondering, did I pass? Right. The test suite just tells you you're great in real time. If you have a 60%, you know you have a 60% and you keep engineering until it hits 100%. Yeah. It shifts the student's focus away from performing for a grade and toward an iterative, real world engineering process. Alongside these gates, they've scheduled three evening hackathons. Oh, this sounds intense. Yeah. The first one is locked in for Thursday, September 24th, located over at the ETF, the Electronic Testing Festival. They are corralling the entire cohort into one massive room from 7 to 9 pm, and the instructor makes it very clear, stop what you are doing and put this in your calendar right now. And listeners should know, these are not your typical, you know, energy drink fueled 48 hour weekend hackathons where you just build a fun startup idea. Not at all. These are intense, tightly scoped tasks operating within a fixed two hour window. The university will likely provision stronger, centralized frontier models for these events. The goal here isn't just to see if your final output passes a test. They want to observe how you engineer under pressure. They want to see your prompt logs, your context management and your strategic process. And remarkably, the financial cost of this course is zero. There's no required budget for LM API calls. You are going to be using local models running on your own hardware, or if your laptop doesn't have the compute power, you will SSH into the cane labs and utilize the university's graphical processing units. The instructor is incredibly adamant on this point too. Your choice of language models should be a single line of configuration in an environment file, not a vendor dependency that completely dictates your architecture. Which is a crucial engineering principle, but we need to address the most significant policy shift introduced in the syllabus. It's the cornerstone of the entire course, the integrity rule. Right, because if an AI is writing the code, the entire concept of cheating becomes incredibly murky. The instructor distills the new policy into a single unyielding sentence. If you can explain it, it is yours. If you cannot explain it, it is not yours. And that is an honor code manner. It entirely redefines what it means to possess academic integrity in the modern era. I mean, the traditional definition of plagiarism asking, did my physical fingers type these specific characters is utterly obsolete in an agentic workflow. Completely obsolete. The university is explicitly shifting the burden of integrity away from the mechanic to production and placing it entirely on the depth of human comprehension. The only question that matters now is, does my brain understand exactly how and why this system works? The instructor shares a deeply personal anecdote in the lecture that perfectly crystallizes why universities are being forced to adopt this stance. He talks about his daughter attending a highly rigorous summer camp over at Oxford. Oh, the Gemini notebook story. Yes. So before the camp even begins, they send out this massive 135 page PDF document containing all the required reading, syllabi, and schedules. The instructor, acting like any curious technologist, decides to play around with Google's Gemini notebook, which used to go notebook LM. Right. He feeds his entire 135 page PDF into the system and prompts it to generate a podcast overview of the material. The meta irony of us sitting here discussing this specific anecdote on a deep dive is certainly not lost on me. We are quite literally living the anecdote right now. But the result he gets back from the AI isn't just a dry, bulleted summary of the PDF. The AI generates a synthetic two-person audio conversation, and it begins to actively analyze the subtext of the document. Then what does it find? It accurately predicts that his daughter is going to be calling home late at night, crying in frustration, not because of typical teenager dorm drama, but because it identified a specific requirement buried in the syllabus for a 1000-word paper that, given the timeline and the density of the reading, was going to be deeply overwhelming for a student. And the instructor confirms to the lecture hall that this is exactly what transpired, four consecutive nights of tears over that exact paper. The AI didn't just read the text. It inferred the human emotional toll of an academic assignment based purely on analyzing the density and structure of a syllabus. The instructor was absolutely floored by it. He noted that the machine wasn't regurgitating facts, it was synthesizing complex implications. And if an accessible AI tool can synthesize implications at that level of emotional and logical depth, how can a university possibly continue to test students simply on their ability to produce a block of text or a genetic sorting algorithm? They simply can't. The value of the human in the loop is no longer the generation of raw material, it is the curation, the verification, and the deep comprehension of that material. Think of a modern computer-fying student as a general contractor building a house. As the contractor, you didn't physically swing the hammer. You didn't manually mix and pour the concrete for the foundation. The power tools your AI agents did, the physical heavy lifting. But if you try to build a three-story house on a foundation meant for a shed, and that house collapses... The city inspector doesn't issue a citation to the nail gun. Exactly. They hold you, the contractor, accountable. You own the liability of the outcome. That is the perfect mental model. You are solely responsible for the structural integrity of the final product, regardless of who or what framed the walls. If you don't understand load-bearing principles, if you can't explain to a professor exactly why a specific database query is structured the way it is, or why a memory module uses a certain caching strategy, you are committing professional malpractice. That is precisely what the integrity rule is enforcing. You can use the power tools, but you must own the architecture. To really grasp why we desperately need this new rule, and why the fundamental definition of a programmer is changing so violently, we have to look at how quickly the tools themselves have evolved. The instructor walks the class through the four distinct waves of the AI coding landscape, tracing how we arrived at Fall 2026. Let's dig into this evolution, starting with Wave 1. This spans 2021 to roughly 2022, the autocomplete era. This era was defined by the mass arrival of GitHub Copilot. To be historically accurate, it wasn't the absolute first tools like Kite and Tab9 existed prior, but Copilot, backed by OpenAI's PODEX model, is where the technology became load-bearing for everyday developers. It crossed the threshold from neat toy to actually saving me time, but it was entirely reactive. The mechanism was simple. You type a function definition, and it suggests the rest of the line or the block in gray text. You hit Tab to accept. Very simple. But its vision was incredibly narrow. It was scoped almost exclusively to the single file you currently had open in your editor. You were very much still in the driver's seat. The AI was just a really fast, occasionally helpful passenger. Then the paradigm shifts with Wave 2, hitting in late 2022 and dominating 2023. The chat era. This is catalyzed by the release of chat GPT, and subsequently, Copilot chat integrating directly into the IDE. This was a massive leap because the interaction became bi-directional. You were no longer just accepting code suggestions. You could interrogate the machine. You could paste in an error message and ask why it was happening. You could describe a complex problem in natural English prose and get a functional block of Python back. But, and this is a critical limitation, you still had to act as the manual copy and paste glue. Oh right, the endless copying and pasting. The AI wrote the code in a chat window, but you had to figure out where it belonged in your project and manually integrate it. Which brings us to the Pivotal Wave 3, spanning 2023 to 2025. Theogenic Tools. This is where tools like Cursor and Ader step onto the stage, followed shortly by ClodCode. This is where things get spooky. Yeah, totally. The tool stops being a passive chat box and becomes an active participant in your file system. It reads multiple files simultaneously, it edits across the entire project structure, it executes terminal commands, and it runs your test suite. It operates in a loop, fixing its own errors until the task is complete or it hits a conceptual wall. And it is crucial to note that Wave 3 is the environment most students entering this course are already accustomed to. They've used Cursor, they know how to prompt an agent. But the course explicitly does not stop there. It is aiming to prepare students for Wave 4, which is the bleeding edge reality of late 2025 and present day 2026. Orchestration. Orchestration. Not just a single AI helping you write code, but an AI running an entire software lifecycle process. We are talking about multiple long-running specialized agents supervising other agents. Okay. Tools dynamically utilizing other tools. To understand the implications of orchestration, it's vital to dissect the hype versus the reality that played out across these waves. Go back to 2023. Oh, the hype was out of control. The hype cycle, driven by venture capital and tech media, loudly proclaimed that AI would replace programmers outright within a year. They said the computer science degree was dead, but it wasn't. Software engineers are still getting hired. Exactly. The mass extinction event didn't happen. What actually occurred was a severe bifurcation of the workforce. Developers who embraced these tools and learned how to direct them became hyper-productive. Right. The mythical 10x engineer suddenly became a tangible reality through the leverage of AI. But the developers who expected the AI to work by magic, who just pasted in vague requirements and expected production-ready enterprise systems, they got burned badly. Because they completely misunderstood the mechanical limitations of language models. The lecture does a fantastic job explicitly pointing out what elements excel at and where they catastrophically fail. Mechanically, they are incredible at boilerplate generation. They are phenomenal at translating human intent into specific syntax. The localized refactoring. Yes. But they are genuinely terrible at understanding highly specific quirky business logic. They cannot handle ambiguous contradictory human requirements. And they fundamentally struggle with maintaining long-term system coherence across a massive multi-file project. We have to explain why they struggle with that. An LM, at its core, is a massive statistical pattern matcher trained on terabytes of open source code from GitHub. It knows how a generic web server is built because it has seen 10 million of them. Sure. But it does not know the unique, bizarre, undocumented business rules of your specific startup. It doesn't know that your legacy payment processor requires a 500 millisecond delay between API calls because a server in a basement in 2014 was slow. Right. It doesn't have the lore. It lacks that deep localized historical context that a human engineer builds up through sheer experience. Here's where it gets really interesting. If we are currently trying to master Wave 4 orchestration, where does Wave 5 go? If we have agents managing agents, does Wave 5 involve AI systems writing their own proprietary orchestration platforms? Are we entering the true autopilot era of programming where human intervention is strictly limited to takeoffs, like defining the initial product and landings, deploying the final build, while the agents fly the plane entirely on their own in the middle? That analogy highlights the exact tension in the industry right now. I wouldn't classify it as purely autopilot just yet. Okay, why not? The reality is that software engineering isn't like flying a commercial jet along a known fixed GPS route. Building software is more like trying to build the plane while you are already falling out of the sky and the passengers keep changing their minds about where they want to land. That sounds incredibly stressful. It is. The ambiguity of human needs is the ultimate bottleneck. Until an AI can perfectly deduce the unstated, contradictory, often irrational desires of a human client which is currently impossible, the human remains absolutely essential at the requirement's definition and final evaluation stages. Which means this massive shift in the tooling landscape dictates an equally massive shift in how the human brain must approach the job. We can no longer act as typists. We must become curators. This is the defining central philosophy of the entire EECS-498 course, the transition from typist to code curator. Let's deeply unpack this typist versus curator mental model because it fundamentally alters how you spend your eight-hour workday. A typist focuses heavily on the mechanics, syntax, formatting, remembering the exact order of arguments in a library function, and writing boilerplate. They spend their cognitive energy on the how. Exactly. Their internal metric for a successful day is, I took the logic correctly and the compiler didn't yell at me. Conversely, a curator operates at a higher abstraction layer. They focus on intent, architectural evaluation, and refinement. They spend their cognitive energy on the what and the why. So the AI acts as the incredibly fast, infinitely patient typist that drafts the code. Right. And the curator reviews the diffs, redirects the model when it hallucimates, and assembles the pieces. Their metric for a successful day is, the system works, it scales, and I can technically defend every architectural choice the AI made. It is a profound shift from implementation mechanics to architectural judgment. And to help students navigate this, the instructor introduces a very specific, modernized version of the KISS principle tailored for prompt engineering. Keep it simple, software engineers. Keep your prompts laser focused. Keep your intentions completely unambiguous. And above all, resist the human urge to over-explain yourself. This is perhaps the most counterintuitive lesson for beginners. When an LMM fails to produce the desired code, the immediate human instinct is to apologize and add more context. I do this all the time. We all do. We start writing paragraphs of caveats, trying to explain our thought process to the machine. But mathematically, adding caveats compounds the ambiguity in the model's latent space. It almost never resolves it. The lecture provided a side-by-side comparison that perfectly illustrates this trap. They contracted two prompts, the bad prompt read like a nervous scream of consciousness. Please, could you help me write a Python function that iterates through a list of integers, checks if each one is even. Actually, I think a list comprehension is cleaner, but I'm not certain. Also, you probably need to handle the empty input case just in case. It's filled with conversational filler. It contains human hesitation. I think. I'm not certain. Just in case. Exactly. And the AI gets confused because it's trying to mathematically wait your hesitation. Contrast that with the good prompt the instructor showed. Write a function that extracts the even numbers from a list. That's it. One sentence. Ten words. The underlying mechanism here is that the language model infers the correct implementation far better from tight, rigid constraints than it does from wishy-washy human uncertainty. If you are ambiguous about what you want, you cannot expect the machine to read your mind. You must resolve the architectural ambiguity in your own head before your fingers touch the pumped bar. That makes total sense. The language model is not your therapist. It is a literal execution engine. I get that, but I have a serious concern here. Doesn't completely removing the physical act of typing make us fundamentally worse at the mechanics of coding over time? If we stop doing the daily reps, if we stop wrestling with obscure syntax errors, misplaced brackets, and fighting the compiler, do we eventually lose our foundational coding muscle memory? If we connect this to the bigger picture, you have to realize that the software industry is permanently moving up an abstraction layer, and this isn't the first time it's happened. Think back to the transition from assembly language to C. I guarantee you that veteran assembly programmers in the 1970s asked the exact same existential question when compilers were invented. If I'm not manually managing the CPU memory registers and shifting bits, will I lose my edge as a real programmer? And historically, the answer was, yes, you did lose the assembly muscle memory. You forgot how to manually shift bits. But in exchange for losing that micro-level skill, you gained the macro-level ability to build entire operating systems, graphical user interfaces, and the modern internet. You traded micro-level syntax for macro-level architecture. Precisely. You are trading syntax repetitions for architectural repetitions. The skill of engineering isn't disappearing. It is elevating. You are no longer managing memory registers. You are managing intelligent agents. So if the AI is handling the vast majority of the actual syntax typing, what exact levers does the human need to pull to control this process? The instructor introduces a framework they call the Big Three. The Big Three levers of control are context, model, and prompt. These are the three core variables you must explicitly manipulate to generate reliable output from an agentic system. Let's define this mechanically. Sure. Context is the information the AI has access to when it begins evaluating your request. What specific files are loaded into its memory? What API documentation is available? Right. And model refers to the actual neural network you are utilizing. Are you querying a massive, generalized frontier model in the cloud? Or a highly quantized, smaller, local model on your laptop? And finally, prompt is the specific, unambiguous English instruction you use to dictate your intent. And to pressure test whether the students truly understand why they are sitting in that room, the instructor poses two fascinating existential questions before anyone even touches a piece of software. The first question cuts right to the core of the computer science curriculum. If AI can write all the code, why do you still need to take EECS 281? EECS 281 being the infamous data structures and algorithms class at UMich, it is the grueling gatekeeper course. Very grueling. If the AI has memorized every sorting algorithm and graph traversal method ever invented, why do I need to spend a semester suffering through learning how to implement a red-black tree from scratch? The answer the instructor provides comes down to one single powerful concept, taste. AI entirely lacks engineering judgment. It has no taste. Taste is such an evocative word to use in the context of computer engineering. We usually associate it with fashion or culinary arts or music. In software engineering, taste is the hard-won intuition of knowing why an elegant, minimalist solution is infinitely better than a complex brute force one. Ah, nice. An LM has absolutely no taste. It operates purely on statistical probability based on its training data. It will happily and rapidly generate code that looks syntactically flawless, passes your basic local unit test, but harbors a catastrophic architectural flaw. The lecture gives a terrifyingly realistic example of this. You prompt the AI to write a user lookup function. The AI confidently generates a function with an n-squared time complexity. Now, mathematically, when you test this locally with 10 dummy users, 10 squared is 100 operations. It runs in milliseconds. It looks perfect. Right. But the moment you deploy that code to production and a million users hit the site, a million squared is a trillion operations. That n-squared complexity literally starves your server of memory, melts your CPU, and takes down your entire company. And the AI will not warn you about that n-squared trap, unless you explicitly instruct it in the prompt to heavily optimize for massive scale. You absolutely need the theoretical foundation built in EECS 281 to look at that AI generated diff and instantly recognize this nested loop is an n-squared nightmare. We need to refactor this into an O of one hash map lookup. You must know what excellent code looks like in order to recognize when an AI has produced terrible code. Like the instructor said in lecture, you don't give a toddler a pneumatic nail gun. You give them a hollow plastic hammer. They bang on blocks. They learn the basic physics of swinging an object. They build the foundational understanding only when they grow up, respect the tool, and know exactly where the nail is supposed to go. Do you hand them the power tools? That's a great analogy. AI is a pneumatic nail gun. You need to know exactly where the architectural nail belongs before you pull the trigger, or you're going to put a nail through your own hand. Which leads perfectly into the second pressure test question the instructor asks the room. When would you actively choose not to use AI? Which is a wildly surprising question to ask on day one of a class entirely dedicated to applied AI. It is, but the boundary conditions are critical. You do not use AI when you are in the initial stages of learning a fundamental concept, because the cognitive struggle of wrestling with the logic is the entire point of the exercise. That makes sense. And you definitely don't use it for highly secure mission critical code, where a subtle hallucinated dependency could introduce a zero day vulnerability. You also strategically avoid it for deep complex maintenance tasks on legacy systems, where the cost of tracking down a subtle bug introduced by an AI misunderstanding the architecture far outweighs the few minutes saved by having the AI draft the patch. AI is a tool, and like a table saw or a scalpel, all tools have highly inappropriate use cases. Exactly. It does make me wonder though, how long until the models themselves develop a synthetic version of taste? Is architectural intuition strictly an organic human trait? Or will an orchestration layer eventually be trained to evaluate its own generated code, calculate the big O complexity, test for edge cases, and select the most elegant solution automatically? That is precisely the frontier of current AI research. We are beginning to see agentic architectures that can generate multiple parallel solution paths, score them against a heuristic, and select the most efficient one. However, true architectural intuition, the ability to balance technical debt against upcoming business requirements, while factoring in the skill level of the junior developers who have to maintain the code. Right, the human elements. Exactly. That remains a deeply contextual, uniquely human judgment that is incredibly difficult to encode into a statistical model. So, to practice this uniquely human judgment, you need a very specific type of digital workshop. You need a tool that forces you to exercise those muscles. Which brings us to the software choice for the early weeks of the course. They mandate the use of ADER. Yes, they explicitly bypass the popular commercial options, not cursor, not GitHub co-pilot, not Claude code. They use ADER, specifically for the apply phase of the first three weeks. And the reasoning for this choice is deeply rooted in the concept of pedagogical friction. I want to really dig into this idea of pedagogical friction. Why would a university intentionally force its students to use a command line tool that is arguably much less slick and less intuitive than the commercial alternatives that exist right now? Because the slick commercial tools are actively designed to hide the underlying mechanics from the user, a tool like cursor has a beautiful graphical interface that automatically manages your context window behind the scenes. It seamlessly abstracts away the complex interactions with the model API. It is designed to cover up your bad habits. If your prompt is vague and sloppy, cursor will send it to a massive multi-trillion parameter frontier model that will often successfully guess what you actually meant and fix it for you. You don't learn anything from that interaction. You just got statistically lucky. It's like putting a student pilot in a fully automated commercial jet and telling them they flew it because they pushed the start button. They didn't learn about wind resistance or stall speeds. Exactly. ADER operates entirely via the command line interface. It is raw. It forces you to explicitly manage the big three levers. You cannot hide behind a GUI. When you run ADER, you must explicitly declare exactly which files to drop into the context window. You must explicitly type out a slash command to define which model to query. You must write meticulously clear prompts because the smaller local models you are forced to use will immediately and spectacularly fail if you are vague. I absolutely love this methodology. It's like a baseball player swinging a bat with heavy iron weights attached during the on deck circle. It is grueling and awkward. But when they finally step up to the plate and take the weights off, when the students finally get access to the massive frontier models later in the semester, it's going to feel like absolute magic. Their fundamental understanding of context and prompting will be bulletproof. And there are two other incredibly pragmatic reasons for the instructor choosing ADER. First, it communicates using the OpenAI compatible API format, making it completely model agnostic. This raises an important question about the current state of the industry and vendor lock-in. The instructor is aggressively adamant on this point, repeating it in the lecture. Your language model is a line of configuration. It is not a dependency baked into your code base. Yes. They want students running their own local endpoints. Why is avoiding vendor API lock-in such a massive priority? Because the AI landscape is intensely volatile. If you tightly couple your entire enterprise workflow around a proprietary API from a single company, and that company suddenly doubles its pricing or deprecates the specific model you rely on, your entire system is paralyzed. That makes whole sense. By configuring ADER to point to a local endpoint on your own machine, you own the infrastructure. You swap the brain just by changing a text file. Furthermore, running local models ensures the course costs the students absolutely nothing in API fees, which is a massive win for educational accessibility. And the final, most audacious reason for choosing ADER. It is a small enough code base that it can be completely reverse engineered. And the students are literally going to rebuild its core functionality starting in week three. It entirely demystifies the magic of AI. You spend two weeks driving the tool from the outside, experiencing its quirks, and then the instructor forces you to open the hood and build the engine yourself. That's so cool. You write the code that parses a conversation history. You breathe the rejects that extracts edit blocks from an elements text output. You write the script that applies those get diffs to a file. That is how you transition from being a user of a tool to a master of the architecture. To vividly demonstrate what driving this tool actually looks and feels like, the instructor performs a live five minute pair coding demo on stage. It's fascinating because he explicitly warns the students, do not worry about memorizing the specific keystrokes I'm typing. You will learn those in lab. I want you to watch the rhythm of the loop. I want you to observe the shape of the collaboration. The live demo is a masterclass in the curator workflow. He uses three sequential tightly constrained prompts. Right. For the first prompt he types, refactor this parse erbs function to handle the case where the user passes no arguments, print the usage string and exit cleanly. Ader reads the abstract syntax tree of the file, sends the context to the model and produces a get diff. The instructor visually reviews the diff, confirms it handles the logic correctly and accepts the change. Then immediately to the second prompt, add a unit test that explicitly exercises the no arguments path. The AI generates the test file, Ader automatically runs the PyTIS suite and the new tests pass green. And finally the third prompt, replace the long if chain in the dispatch function with a clean dictionary lookup. The AI heavily refactors the core logic, Ader runs the test suite again and the tests still pass green proving the refactor didn't break existing functionality. Five minutes, three coordinated logical changes across multiple files, one continuously passing test suite and zero physical lines of Python code typed by the human. The human provided the intent, the human performed the evaluation and the human exercised the judgment. The machine did all the typing. And the raw transparency of the command line tool exposes the underlying mechanics in real time. The instructor specifically points to the token usage statistics printing on the screen. He shows the class that this interaction cost fractions of a penny. He demonstrates exactly how adding a dense file like notes.pyy into the context window instantly inflates that token count, increasing the latency of the response and the cost of the API call. It takes the abstract mystical concept of an AI context window and makes it visceral. You see the literal mathematical price of throwing too much irrelevant information at the model. It forces you to be surgically precise about what the AI actually needs to see. Which brings us directly to the immediate practical reality for the listener. What do you need to do right now to survive the first week of EECS 498? Yes, let's lay out the exact game plan. First off, lab zero, which was the grueling environment setup lab getting all these tools installed is already in the rear view mirror. Take note, there is no official lab session on Monday or Tuesday of the coming week. Your immediate primary mission centers entirely on cloning the AIDR practice repository and using it to build a command line application called Tasker. The Tasker assignment is strategically split into two distinct parts. Part one covers lessons one through 10 and this is your workload for the current week. The strict non-negotiable requirement here is that you must use the incredibly small 4 billion parameter model, specifically QUEN 3.5 4B running locally. QUEN 3.5 4B, the small model. This is putting the heavy iron weights on the bat. Exactly. Then part two covers lessons 11 through 16 intended for the following week where you take that command line logic and build a web front end for it. For part two, the instructions recommend upgrading to a slightly more capable 9 billion parameter model. The complete setup gate along with all 16 passing lessons are hard due on Friday, September 11. So what does this all mean for your actual minute to minute workflow when you sit down at your laptop? How do you physically complete these lessons? The methodology is brilliant. Every single lesson in the repo is structured as a failing test case. It is extreme test driven AI development. You are provided with a specification, but it is written entirely as code as a failing PyTest function. Your sole job is to drive AIDR, manipulating the context model and prompt levers until the AI writes the code that makes that specific test turn green. The psychological relief of this structure is immense. As a student, you never have to guess if you were finished. You don't have to stare at a block of code and wonder is this good enough for an A. The automated test tells you precisely when you were done. When the test passes, you commit the code and move to the next lesson. But here's the critical warning. Getting that test to pass using a severely constrained 4 billion parameter model is going to be incredibly frustrating. Oh, absolutely. And that frustration is entirely by design. To understand why, you have to look at the mechanism of a 4B model. It simply does not have the dimensional latent space to hold complex instructions and complex file context simultaneously. If your prompt is vague or if your context window includes irrelevant files, it will fail immediately. It forces you to perfect your habits under immense pressure. The lecture explicitly warns the students about the specific pain points they will encounter with the 4B model. It warns that the model might stubbornly ignore a very specific line level correction you ask for. Or worse, when you ask it to add a small feature, it might decide to rewrite the entire file and silently drop an existing feature in the process. And those pain points are the true curriculum of the assignment. Experiencing a model silently delete a working feature forces you to adopt the habit of meticulously reviewing every single Git diff before you accept it. It builds the exact paranoia, resilience, and skepticism you need to survive the rest of the semester. The course restricts you to the 4B model first so you feel the sharp edges, and it only permits you to move to the 9B model after you've mastered mitigating those limitations. It's all about aggressively building that code curator muscle memory. So taking a step back, look at the massive conceptual territory we've covered today just from unpacking lecture one. We started with the physiological necessity of forcing a smile to combat the paralyzing effects of imposter syndrome. We mapped out a grueling 15-week architectural arc that culminates in managing the massive technical debt of a single, continuous Git repository. We examined the radical shift in academic integrity, moving away from tracking keystrokes, and instead demanding absolute architectural comprehension. We traced the historical evolution of AI coding waves, fully adopted the code curator philosophy over the typist mindset, defined the mechanical levers of context, model, and prompt, and previewed the test-driven gauntlet of the week ahead using highly constrained local models. The ultimate goal of eX498 isn't to train you to be a fast typist anymore. The goal is to forge you into an architect of outcomes. The machine writes the syntax, you own the outcome, the liability, and the architecture. It represents a profound, permanent shift in the identity of a software engineer. Which leaves me with a final lingering thought to mull over as you start your assignments. If our primary engineering skill is violently shifting away from producing human-readable syntax and shifting toward exercising high-level architectural judgment to direct machines, how will that alter the fundamental design of programming languages in the future? Right now, we build systems in Python and C++ specifically because they are somewhat readable by the human eye. But if humans entirely stop writing the code, will we eventually architect new programming languages meant only to be read and written by other AI agents, leaving human readability behind entirely? A truly fascinating possibility. If the compiler is an artificial neural network communicating with another neural network, the syntax could become infinitely dense, highly compressed, and optimize purely for machine execution speed, completely bypassing the bottleneck of human cognition. And suddenly, that deterministic, neatly typed, human-controlled machine we talked about at the very beginning of the deep dive is truly gone. The architectural murkiness takes over completely, and all we have left to rely on is our judgment, our taste, and our ability to steer the agent. Thank you for joining us on this deep dive into AASE. Make sure you check your local endpoints, embrace the friction of those small 4B models, and get your environment ready for the next lecture. We'll see you then.