Teaching Statement

Steven Atkinson, Ph.D.

I teach software engineering the way it is practised: with real tools, real constraints and, now, AI as an everyday collaborator. For nine years, from 2017 through 2025, I taught every spring, summer and fall semester in Virginia Tech’s graduate computer science programs while working as a senior engineer at Netflix. Across that time I taught Internet Software (web application development), Mobile Software Development, Software Engineering, and AI Tools for Software Engineering, a course I designed. Working in industry and the classroom at the same time shaped everything I do as a teacher. I bring students the problems engineers actually face, I hold them to the standards a production team would, and I keep the material current because I use it at work every week.

Teaching AI as an engineering discipline

In 2023 I designed AI Tools for Software Engineering. It began as a special-topics course (CS 5914) and became a permanent course (CS 5740) in 2025, the year it was also opened to undergraduates for the first time. Enrollment grew from 52 students in its first term to 98 in Fall 2025.

The course treats large language models as engineering components, not as magic. Over twelve weekly modules students move from the history and scope of AI, through classical machine learning, prompting, requirements, retrieval and testing, to autonomous agents and the risks AI poses. The spine of the course is a single application that every student builds incrementally: Ducky, an AI assistant for software developers. Each project adds one capability to it:

1. Machine learning with AI assistance. Students use the class chat assistant to write supervised and unsupervised models over a dataset of 25,000 source files, a domain most of them have never worked in.
2. Requirements engineering. Ducky generates vision statements, project plans and risk assessments, and students judge whether those documents are actually usable.
3. Coding with AI. Students use an agentic coding tool to build Ducky’s code-review, debugging and editing features, learning to use AI both to write an application and inside one.
4. Pragmatic semantic search. Students implement retrieval-augmented generation with embeddings, chunking and conversation pruning.
5. Agent personas. Students design system prompts, after studying the system prompt of an open-source coding agent taken directly from its source code.
6. Testing APIs and prompts. Students write deterministic pytest tests with mocked HTTP calls, then build an LLM “judge” that grades model output against their own rubric, and compare the two kinds of testing.
7. Agents and tools. Students add tool-using agents to Ducky through the Model Context Protocol (MCP), including a continuous-integration server that runs linting and type checking for the agent.
8. Evaluating extreme risks. The course closes with research on AI risk, security flaws in agent tool protocols, and a discussion of transparency when people use AI at work.

A question students bring to this course is how to get dependable results from a non-deterministic tool. By the end they can answer it: manage context, specify requirements precisely, test outputs, and know when not to trust the model. One student wrote, “Even though we used AI tools, which were a big part of the course, I still felt I was learning, thinking critically, and seeing how these tools really affect software development.” Another said the course “made it clear that AI was something that we should be using but not exploiting.” That balance is exactly what I aim for.

To make all of this work for a class of 100, I built the infrastructure myself: a reproducible Docker development environment that every project starts from, a shared class LLM served through a proxy I wrote so that no student needs a personal API key or pays for usage, a health checker so everyone can confirm access in week one, and AI-assisted tools that help my graders give consistent feedback on discussions. The course has no required textbook to buy; readings come from library-licensed books and current papers, so it stays free for students and current with the field.

Projects first, then concepts

Students learn software engineering by building software. In Internet Software (CS 5244), co-taught with Dr. Gregory Kulczycki, students build one online bookstore across the semester. They start from a visual design, then add a client-side framework, a REST back end, session state, a shopping cart, form validation and a checkout transaction, and finally deploy it to a server. Each project adds one real-world pattern to a system the students already understand, and I directed the curriculum and model projects for both web and Android versions of the course. Over five years enrollment doubled to more than 100 students per class.

I carry the same structure into every course. Each week has the same rhythm: short recorded lectures and demonstrations, readings with a quiz, a project that builds on the last one, and a live Q&A session. I make sure students see the whole system before they change part of it; one wrote that they “really love the walkthrough of directories and structures. It gives me a big-picture understanding of the project.” My grading rubrics are concrete and consistent. Students start with full marks and lose a specific amount for each style or functional problem, and I write the reasons out so that feedback teaches rather than just scores.

Clear communication

Explaining complex ideas clearly is the core of the job, and it is a skill I have practised for decades: in design reviews, incident reviews and architecture discussions at Netflix, in mentoring engineers, and in front of students. In Fall 2025, 95% of my CS 5740 students agreed or strongly agreed that I presented the subject matter clearly, a mean of 5.62 out of 6 against a department mean of 5.14. I use diagrams, live coding and worked examples, and I record short videos for the parts of a project students most often get stuck on. I also teach students to communicate: the final module of AI Tools covers presenting technical work, because an engineer’s ideas only matter if others understand them.

Feedback and continuous improvement

I read my evaluations closely and change the course every term. Across ten evaluated sections from 2023 to 2025, students rated my overall teaching effectiveness between 5.46 and 5.80 out of 6, above the department mean in every section, with response rates usually above 90%.

I am just as attentive to the criticism. Early students told me some project specifications were inconsistent, so I moved every project to a common structure; later students noted that “later projects seemed to follow a more consistent format, which helped.” In Fall 2025 students told me the Docker images and multi-repository setup cost them time that should have gone to learning. For my next offering I would ship lighter images, consolidate the starter repositories and state storage requirements in the syllabus. Students also asked for spec-driven development workflows and a project in which they build their own MCP server from scratch, and I plan to add both.

When things break, I treat it as a teaching moment and fix it quickly. Our class LLM failed in the middle of Fall 2025. I diagnosed the problem, restored service, and adjusted the deliverables and deadlines. A student mentioned it in the evaluations, and I think the episode taught the class more about operating real systems than a lecture could.

Inclusive, respectful classrooms

My students have been Master’s students in very different situations: in my early years most were working professionals studying online, often in different time zones, and in the AI course most are full-time students, with undergraduates joining from 2025. I design for all of them. Every lecture and Q&A session is recorded, live attendance is optional, readings use library resources so they cost nothing, and presentation recordings are captioned or have scripts available. All questions go through a shared forum, where students may help each other in public as long as they do not post solutions, so everyone benefits from every answer. In Fall 2025 students rated me 5.78 out of 6 for fostering an atmosphere of mutual respect. I want every student, whatever their background, to leave confident that they can learn a new technology on their own.

What I would bring to UT Austin

I can teach introductory programming and data structures, software engineering, web and mobile application development, and AI courses at both undergraduate and graduate level. I would especially like to develop and teach courses on AI-assisted software development, a subject where UT Austin students will benefit from instruction that is current and grounded in industry practice. I would also welcome mentoring students on capstone projects, and helping colleagues bring AI tools into their own courses responsibly, with the kind of shared infrastructure that makes that practical at scale.

Teaching portfolio

Supporting materials for the statement above.

A. Student evaluations (Virginia Tech, SPOT)

Scale: 1 (strongly disagree) to 6 (strongly agree). Item: “Overall, the instructor’s teaching was effective.”

Fall 2025, CS 5740 (89 to 91 responses): well prepared 5.59 (dept. 5.28); presented clearly 5.62 (dept. 5.14); feedback to improve performance 5.56 (dept. 5.06); mutual respect 5.78 (dept. 5.40).

What students said

• “In my opinion, Professor Atkinson is the standard by which all other instructors at VA Tech should be judged.” (CS 5740, Fall 2025)
• “This was one of the best classes I have taken so far in the M.Eng program. I liked the project based approach and how current/relevant the lessons were to the rapidly changing CS environment.” (CS 5740, Fall 2025)
• “Even though we used AI tools, which were a big part of the course, I still felt I was learning, thinking critically, and seeing how these tools really affect software development.” (CS 5740, Fall 2025)
• “We had a problem with the class LLM mid semester, and Dr. A was quick to diagnose and fix the problem and updated the course deliverables and deadlines effectively.” (CS 5740, Fall 2025)
• “The curriculum was reflective of the active development around AI for software engineering. We could tell Dr. Atkinson really worked hard to prepare starter code and the lecture videos.” (CS 5740, Spring 2025)
• “The instructor designed a very good project and split it into several weekly sub-projects throughout the whole semester.” (CS 5740, Spring 2025)
• “Dr. A was really helpful, his course made me learn a lot, doing MCP was so cool, it just got released and we are working on it.” (CS 5740, Spring 2025)
• “The instructors thorough understanding of the subject and his passion was contagious. He inspired me to dive deep into learning web development.” (CS 5244, Spring 2023)
• “The Q & A sessions each week were especially helpful, and I was grateful that the recordings were always posted as well because I usually couldn’t make it.” (CS 5244, Spring 2023)

B. Course design: AI Tools for Software Engineering (CS 5740), Fall 2025

Format: fully online; about 8 to 10 hours of student work per week. Each module has recorded lectures and slides, readings with a timed quiz, a project, optional “real world knowledge” extras, and a weekly live Q&A that is recorded for those who cannot attend. Questions go through a shared forum where students may help each other but may not post solutions.

Learning objectives: discuss the history of and differences between AI, machine learning and data science; identify key AI and ML techniques (supervised and unsupervised learning, generative large language models) and when to apply them; discuss the ethical and social issues of adopting AI tools in software development; and build an interactive AI development tool that engineers could use in their daily work.

Assessment: 10 reading quizzes (80 points); midterm and final exams (60 points each); about eight cumulative project assignments (180 points); graded discussions, peer reviews and small assignments (about 60 points).

C. Sample assignment: Testing APIs and Prompts (Project 8)

Students learn two complementary ideas and compare them:

1. Testing a REST API deterministically, using pytest with mocked HTTP calls so tests are fast, repeatable and independent of the network.
2. Evaluating LLM-generated responses, by writing their own prompt-based rubric and using a model as an automated judge.

The assignment asks students to explain where traditional software testing and AI-assisted evaluation overlap and where they differ: why a deterministic assertion is the right tool for an API contract, and why a rubric-driven judge is needed when correct answers can be phrased many ways. Like every project, it is delivered as a fork of a starter repository, developed inside the course’s Docker image, and submitted as a published container image so graders can run every submission in an identical environment.

D. Sample course structure: Internet Software (CS 5244)

Students build one online bookstore across the semester, adding one real-world pattern per project:

Rubric approach (all projects): each project starts at full marks; specific deductions are listed for each style or functional problem (for example, one point for a style problem, two for a functional problem or a repeated style problem), and each deduction is written out so the feedback explains exactly what to improve.

E. Course infrastructure I built

• Class LLM proxy: a reverse proxy for OpenAI-compatible APIs (prototyped in Node.js and Java/Netty, shipped in async Python) so a class of up to 100 students shares one model and one key, with no cost to students.
• Proxy health checker: lets every student confirm access to the class model in the first week.
• Reproducible Docker environment: a multi-architecture base image with every tool and library the projects need.
• Grading support tools: AI-assisted tools, integrated with Canvas, that help graders create and assess discussion questions consistently.
• Model projects and starter code: a reference solution for every project, and starter repositories that students fork.