This repository contains all the materials used in the spring 2026 Software Engineering course at the University of Austin.
Software Engineering is positioned as the third course in the intro sequence at UATX. Students had already taken Programming I and II that looked spiritually similar to what you would see at other top computer science departments - weekly assignments in Python and then Java that covered the building blocks of coding from variables and functions to objects, classes, data structures, and so forth. Programming I and II at most universities, including UATX, aren't intended to cater exclusively to people who will write code professionally, and have as their implicit primary objective teaching students a particular way of thinking and breaking down problems. Coding agents would undermine this, and therefore, like at most universities, were not permitted.
The third course in the intro sequence is different. At many schools this is the first CS course that would primarily be taken by future majors of computer science, data science, or electrical engineering. I loved my time at Stanford, but when I looked at the syllabus for CS107, it read as basically identical to the syllabus when I took it a quarter century ago. When I looked at the syllabi for other schools like Berkeley or Carnegie Mellon it felt similarly dated. Computer science has been one of the fastest moving fields of study over the past few decades. It seems inappropriate for those courses to be taught as they were when I was in school, and that's before taking into account how coding agents have upended the field.
UATX gives us a rare opportunity to reimagine how computer science education should look in the current era. After much discussion, we settled on the following assumptions, which drove what we ended up teaching.
-
We expect most students to go into industry, not academia. Obviously we want to support all passions, but a non-negotiable baseline is that we should be giving people the tools they need to write code professionally.
-
Coding agents are fair game. Our students will be entering the workforce in 2028 or 2029. It's simple reality that their primary coding language will be English, and if we're not helping them build their skills with coding agents in their coursework we're doing them a disservice. It's clear that they must eventually switch from no coding agents in the intro courses, to using coding agents for all assignments, with the only decision being at what point of the major.
-
We should talk to folks in industry to understand where new college graduates tend to be lacking, and make tradeoffs to cover the most important gaps. This is obviously related to the first bullet, but I see it as subtly different. The first bullet is more oriented towards "what are your classes", whereas this bullet is more about techniques/ideas to emphasize within a class.
To illustrate this last point, look at Stanford's CS108. This class ends with a group final project. This was true back when I took the class - the project, called BunnyWorld, was an open-ended assignment where you create a video game. I really liked this idea (I think everyone should experience sharing codebases with colleagues early and often), and while I didn't have the catchy name or video game focus, I incorporated something similar into Software Engineering. But as a longtime engineering director, one of my frustrations with new graduates is that, even in their project classes, they were never taught testing in its various flavors, and had limited practical experiences with deploying code reliably and responsibly. And so in setting up a capstone project for Software Engineering, it was a requirement that the code be well tested, with proper continuous integration and continuous deployment, to a real webserver with a public-facing url, with proper auth such that anyone could sign up.
With all the above bullets in mind, we decided to make the third course of the intro sequence Software Engineering. The course would focus on all the components of the modern web stack, teaching students to build a deployable web app from back to front. Very few universities would put this course at this stage of a student's education, and we took a very ambitious scope to it. You can see the full syllabus here. Obviously we made the, perhaps controversial, decision that given the scope of the course, the subject matter, and the direction the world is going, this would be the course where we would introduce coding agents, and thanks to generous financial support we were able to cover the $100/mo cost of a Claude Max plan for every student. Coding agents were fair game for every assignment and the final project, and the assignments were scoped such that without coding agents it would've been very difficult to complete in the timelines provided.
A few words on the folders you'll find in this repo:
I'm very happy with the syllabus/content of the individual lectures. Having gone through it once, I think this was the right material at the right point of the major presented in a cohesive order that tells a story, where each class sensibly builds on the material that precedes it. If you're visiting from another university thinking about how to revamp your curriculum to include a course like this, I'm very proud of the structure of this class and the way we taught it.
I'm less concerned with the exact text of the lecture slides themselves (I'm not trying to hide it - I absolutely used Claude to help draft/iterate on lecture slides, and I definitely wasn't perfect about scrubbing out all the Claudevoice). As is evident from the recorded lectures that were posted online, I aggressively avoid just reading the content on the slides in class. They mainly exist to maintain pacing and make sure I don't forget important discussion points over a 75-minute period. Read them with an eye towards what's being taught, not so much whether they are A+ PowerPoint content.
This is the shakiest part of the course. The final project I feel good about because it's open-ended and ultimately the grades are curved, but it's hard to design assignments where it's possible for a student to understand what their agents are doing (their design decisions, implementation and testing strategies, and code) and yet not have the assignment be so easy that the agents one-shot it. One of the strategies I used to mitigate getting it wrong was to provide bronze, silver, and gold success criteria for each assignment (thanks to my colleague Clint Staley for letting me steal this idea), without providing in advance what percentage grade each level corresponded to. As it turned out, agents chewed through the bronze and silver levels of most of the assignments more easily than I would have liked. This only gets harder as agents get more capable. There was also an unsurprising tension between the specificity provided in the assignment PDF (to make correctness grading easier) and how easily an agent could complete the task.
A note on languages: I decided that we would use Python for the server, and Typescript/React for the client. Obviously full-stack Javascript applications are all the rage and Python is not the world's most popular language for webservers. This isn't an endorsement of Python as the ideal production webserver language. It was a pedagogical decision - students had already seen Python in Programming I, so I could introduce webserver concepts without concerns about teaching syntax or confusion about what was part of the language vs what was a library. I also really liked having a different language for the client and the server to make it easier to understand, when a student is iterating on a piece of code, where it is running and what assumptions they can make about it, and where are the boundaries/handoffs between the server and the client. I understand a 20-year industry veteran might find this silly, but it makes for clearer education.
To restate one of our assumptions, if you produce code professionally in 2028 or 2029, your primary coding language will be English. We encouraged coding agents in this class, and therefore our students got fewer reps for the (less necessary) syntax mastery of SQL, Javascript, and Python. In-person, closed-laptop exams are a critical part of evaluation in a coding agent world to verify that you actually learned something. In most CS classes, in-person exams of a coding-focused course involve writing code. For Software Engineering, since the primary coding language is English, the exams involved writing prose.
Rather than forcing students to write functions they didn't spend the quarter writing and won't spend their careers writing, the exams forced the students to design apis, think about testing strategies, discuss deployment procedures, and look for issues in code provided to them. I feel very strongly that this is the right way forward in any course that leans into coding agents. It tests the skills we need students to actually learn. While I was not prepared for the trainwreck that is the average 20-year-old engineering student's handwriting, it was an obstacle that was necessary to endure.
This is the most experimental section of course material. There was no TA to do the grading, so I leaned on Claude to build grading harnesses for each assignment. Each grading harness contains a script that will test a student's submission against the constraints in the assignment PDF, which could be testing api endpoints, whether data made it into a database, or whether bugs were found (for the assignment focused around testing). If tests fail, it's instructed to figure out why - whether that's a shortcoming of the student's work, or whether the harness was set up to be overly prescriptive and the student's work was actually sound. It then does a design/code cleanliness review and presents its findings as part of its final report. Student submissions are done as pull requests against the class's GitHub repo, which makes this easy for the agent, and also makes it easy for the agent to provide one-liners for me to launch any individual student's server/program to manually test features in the UI or any gold/extra credit level work that isn't harnessable. The grading folder contains a parameterized, student-data-free version of that harness.
The harnesses do a good job of finding bugs and verifying correctness against the assignment specifications. This came at the cost, as I suggested above, of perhaps overspecifying in the PDF and making the assignments more one-shottable by the student's agent. If I were to do this again, I would reduce the specificity of the assignments (and probably up their difficulty) and count on the ever-improving generations of agents to make the grading harness work against a less uniform set of student submissions. As of spring 2026, an agent's design and cleanliness review was definitely not something you could just accept - all of its findings would be verified by me before I entered any student grades. Like everything else, this may not be true next year in our fast-changing world. Its suggested dockings for this or that failing were only moderately consistent from assignment to assignment, and if I wanted to fully automate the grading process I would have to not only fix this, but also have a long session where I taught it my specific opinions of how harshly to treat particular failings.
I wove some of this discussion into prior paragraphs, but it feels appropriate to add a concluding section. The course was very well received, both by students and the administration that I worked with. The students produced a cool variety of final projects, such as a health tracking site, an RPG intended for teachers, a student marketplace, a Bible study aid, a career planner, and an educational casino. Obviously this is in part by wielding one of the most transformative technologies our industry has ever seen, but it's clear from the in-person discussions and exams that they learned a lot, and specifically learned skills that are largely neglected in traditional programs that are nevertheless essential whether one goes on to work at a software startup, in data science, or even in academia.
Looking ahead, I think the difficulty of the exams is basically exactly right (the aim was for them to be challenging, with means that you often see in physics classes and then curved along according to UATX's standards). The assignments leading up to the final project were probably too easy, specifically with too much clarity in the PDF that simplified it for the LLMs. The open ended nature of the final project allowed it to avoid that pitfall. I was very happy with the syllabus. As for the individual lectures, I think they got stronger as the quarter progressed, which was unsurprising given that I'd last taught at a university in 2006. I will probably iterate more on the earlier ones in prep for teaching this class next year. The grading harness will also be a major target of iteration, not least because agents may look very different by this point in 2027.
As always, any successful course operates on the work of many people. I'd like to thank my colleagues Professor Ricardo Vilalta, University President Carlos Carvalho and Provost David Ruth for their support, advice, and guidance (and thanks to Carlos for giving me his blessing to put these materials online). Thanks to the production crew, Audrey Unverfeth, Clara Haberly, and Dane Williams for their great work on the videos. Thanks to Phil Greenwald and Shez Shafiq for their administrative support. Thanks to my friend Joe Lonsdale, and his 8VC colleague, Bela Becerra, for pushing me to get involved and their support getting UATX's nascent STEM program off the ground. Thanks to the students who brought such enthusiasm and joy to every class - they're making UATX a very special place. And finally, thanks to Professor Clint Staley for his advice, ideas, and wealth of wisdom. Clint is a madman who could probably teach 50 different computer science courses, blindfolded, with ten minutes of advance warning. UATX is lucky to have him.
If you want to see a sampling of some of this course's lectures, one of our two sections was partially videotaped, and is available on UATX's YouTube page. I offer all materials here freely to anyone, especially those considering how their university's coursework should change in the face of technology that has overturned an industry. The University of Austin is a startup, and has the distinct advantage of building what we think is right from a blank slate, but there's an entire generation of students that require the best foundation we can give them.