Teaching in the Age of AI: Learning Goals and the Goals of Learning

Main ideas, concepts, and lessons

1) Erin Bauerer’s background: how software, science, and teaching converged

• She became interested in computers/programming early, sparked by a childhood fascination with computers.
• A formative experience was a summer research program in New Mexico involving:
  • Mathematics, astronomy, physics, and Python
  • Telescope observations (asteroids), then coding in Python to calculate asteroid orbits
• Her path into teaching began after returning as an assistant for the summer program, where she worked on writing exercises and giving small lectures (e.g., binary search trees).
• She later pursued graduate school influenced by excitement about computer graphics/rendering, though the industry focus changed by the time she arrived.
• Her dissertation/work included:
  • Human–computer interaction and game-like approaches to scientific problems
  • A discussion of protein folding as a “game with purpose” (Foldit-style) where non-experts helped solve structure problems by manipulating geometries while computers optimized local energy.

2) Gamification and education research themes

• She connects early technical roots (e.g., simulation/physics traditions in computing) with education research interests, including cognitive psychology:
  • How people study, think, and learn
  • How learning strategies can be designed to match human cognition

3) Teaching experience: online pivot, active learning, and feedback

• She taught at Carleton College:
  • In-person quarters, then a heavy online shift during Spring 2020
• She tried to make online learning accessible starting from a text-first model (mirroring a prior high school AP Computer Science course).
• She experimented with “flipped classroom” approaches:
  • Flipped learning definition
    • Instructor records lecture/video in advance
    • Students watch before class
    • In-class time is used for interactive exercises/discussion rather than passive lecture
• Key belief: lectures aren’t “wrong,” but passive listening misses something in human psychology:
  • Live presence can increase attention/focus
  • Videos can be less effective than in-person for sustaining attention
• She emphasizes active learning during lecture time:
  • Pause to ask questions
  • Students talk to neighbors / check understanding
  • Solve small problems to test comprehension
• Evidence-based teaching method referenced:
  • Note-taking can “fix” memory even if notes aren’t later reviewed (the act of recording and distilling is the learning mechanism).
• She also contrasts learning with vs. without distractions:
  • Screens in computer labs can reduce concentration for many learners.
• She teaches programming cognition by reducing “escape routes”:
  • Encourage thinking on paper instead of relying on execution on a computer immediately.
  • This forces students to reason about what code does.

4) Pandemic-era lessons: lecture recording and rapid feedback loops

• She found lecture recordings useful (with an important caveat: outcomes vary by institution and student behavior).
• She explicitly added a webcam/tripod setup to produce recordings herself when institutional video gear was missing.
• She expanded emphasis on immediate feedback:
  • Weekly quizzes with self-assessment
  • “Fill in the blanks” style checks
  • Software that provides immediate pass/fail feedback on home tasks
• She prefers feedback sooner rather than delayed grading after learners move on.
• Skill-based/competency learning was discussed:
  • Repeating attempts until a skill is demonstrated
  • But deadlines are still necessary to prevent students from deferring everything to the end
• She designs low-temptation practice mechanisms in quizzes:
  • Encourage brute-force attempts only after understanding
  • Shuffle question order and answer positions to reduce copying

5) LLM-assisted feedback: opportunities and risks

• She sees significant potential for LLMs to help feedback, especially for:
  • Narrowly structured tasks (e.g., code problems rather than free-form essays)
  • Suggestions of style guidance and linting-like feedback
• But she warns about “false positives” and misleading feedback:
  • LLM feedback must be carefully constrained and validated
  • Feedback quality and accuracy can’t be assumed

6) Jane Street’s “teacher-developer” role: why it exists and how it’s structured

• She explains that Jane Street invests heavily in education and tries to formalize this via hiring:
  • People who combine practical industry experience with deliberate teaching work
• The role is designed with a 50/50 split:
  • Half the time programming (practical, current engineering)
  • Half the time teaching and educational program development
• The “source” of successful teaching is both:
  • Pedagogically serious teachers
  • Practitioners who can be credible and effective in their specific technical ecosystem
• They highlight hiring reality:
  • Posting an unusual role doesn’t automatically attract perfect candidates
  • Finding candidates is still hard because the skill intersection is rare
• They tie the need to evolve with changing technology:
  • New AI tooling and languages (e.g., “Ocamel” and Python) require ongoing internal education
  • They aim to prevent “tool capture,” where developers become narrowly focused on one language/tool
  • They also teach internal languages and systems

7) How their engineering culture is built around tools—especially editors

• Erin (as a Jane Street software engineer) works in tools/compilers/editor-support infrastructure.
• She describes Jane Street engineering groups/tools and their central idea:
  • The text editor is the home base for working with code, review, and version control
  • Most workflows occur inside the editor, not by switching to external web tools
• Distinctive elements in Jane Street workflows:
  • Review comments and code-change interactions happen in-editor
  • The editor becomes central for code understanding and communication
• Why this is difficult:
  • External tools (e.g., VS Code) aren’t designed around their internal scale and workflows
  • Performance problems occur when files/diffs become extremely large
  • Integrations can violate assumptions in the editor (buffers, URIs, search behavior)
  • Indexing/search infrastructure may require more RAM than they can afford
  • Notebook support for Python is hard; Jane Street ends up supporting multiple notebook solutions and building their own to regain control

8) AI for programming affects development—and learning—via changed mental models

• She expects AI changes coding processes, including:
  • More code generation at lower cost
  • Less obvious “roughness” in generated code, potentially making bugs easier to miss
  • More need for comprehension: AI can produce code that looks correct but isn’t
• Editors will be impacted:
  • New questions arise about what workflows remain valuable when AI edits/code generation is available
• She describes telemetry/observation as a way to decide what to build:
  • For example, tracking whether people still navigate to definitions as often
  • Their hypothesis: if LLM handles some tasks, people might not need to use language-server features as much—but data can show the opposite (people may still need to read more to understand).

9) How AI changes education: “LLM can do it” vs “you must still learn”

• Example: teaching software testing methodology to beginners
  • Even if an LLM can generate test code, students must understand what they’re testing and why
  • Understanding requires independent implementation at least once
• She highlights a major education-system risk:
  • If students always outsource problem-solving to LLMs, they may lose essential learning opportunities
• This leads to a core instructional design problem:
  • Find tasks that are:
    • Small enough to be approachable for students
    • Large/complex enough that LLMs can’t trivially solve everything
• Proposed educational direction (implied as likely):
  • A blended workflow where students do some steps independently and use LLM as assistance/hints rather than full replacement
  • Design “scaffolds” (skeletons, partial solutions) and require students to fill in larger parts
• She references older tutoring concepts:
  • An infinitely patient tutor/assistant that guides through examples can still be valuable, especially if it prompts reasoning instead of doing the work.

10) Internship redesign: integrating LLMs with code review, feedback, and structured interaction

• Motivations:
  • Traditional intern projects risk becoming less meaningful if interns only “produce code” that LLMs could generate automatically
  • The project nature needed to shift toward design, requirements, and evaluation
• New internship structure elements:
  • Students still do real projects, but curriculum increases education time
  • Emphasis on testing: because LLMs rely on feedback mechanisms to correct outputs
  • Balanced challenge:
    • Tasks must be complex enough that LLM doesn’t give perfect code instantly
    • But not so huge that students cannot learn within the internship time
• Concrete changes described:
  • Increased focus on design documentation/planning and stakeholder-like roles
  • Interns work in small groups (about four people) with frequent group discussions
  • Interns participate in code review more directly than before:
    • A “mid-internship” code check period
    • Interns comment on code review-ready changes and see model feedback/examples
    • Then they implement their own functions and perform reviews
• Challenges identified:
  • Generated code volume can exceed time for careful review
  • Students may not polish or validate sufficiently
  • Cognitive load/volume and pace issues arise across groups
• Adjustments planned:
  • Reduce volume and tune pacing
  • Improve the balance of focus and multitasking early on
  • Expect that advice will evolve due to fast-changing LLM behavior and diverse student use patterns

11) “Goals of learning” as a framework for course design

The video’s title emphasizes “learning goals” and “goals of learning.” The guest explains how this methodology works.

Methodology: writing learning goals and using them to design curricula

• Step-by-step approach described
  • Start any big project (including course/program design)
  • Write learning objectives as:
    • Specific statements describing what will change in students as a result of teaching
    • Best written in post-condition form, e.g.:
      • “After completion, students will be able to ____”
  • Use active verbs to make goals measurable/observable:
    • Example given: not just “understand property-based testing,” but:
      • “Students can write tests based on properties”
    • Include concrete details like data generation/input structure and complexity/structure expectations
  • Clarify what the course is not trying to achieve:
    • Prevents vague scope creep
    • Ensures time is spent on relevant practice rather than irrelevant content
  • Once goals are written:
    • Decide what student tasks/exercises/actions are required to demonstrate those goals
    • Decide what training/materials/lectures are needed to prepare students to succeed
  • Use the goals to evaluate the program:
    • The most direct evaluation is whether students can do what the goals claimed they would do
• Conceptual distinction offered:
  • “Goals of learning” = the intended outcomes (what students will be able to do)
  • “Learning goals” structure evaluation, practice selection, and material design

12) Teaching design principles: cognitive load + active learning + context

• Cognitive load / working memory:
  • Break down learning into stages to avoid overwhelming students.
  • Example strategy for a new-complexity environment (Ocamel + tools):
    • Start with syntax in a simple environment (command line / small fragments)
    • Then introduce editor workflows
    • Then version control/code check tools
    • Finally integrate all pieces together
• Active learning:
  • Prefer interactive study methods over passive information transfer
  • Include small-group discussion and “stakeholder” simulation exercises
• Motivation design:
  • Tie new concepts to a specific motivating application or feature being built
  • Teach “why this tool/concept matters” by embedding it in a project narrative

13) Jane Street-specific teaching philosophy: tools and practical competence

• Compared to university-style courses:
  • Jane Street education focuses more on tool-based competence and practical application
  • University settings require more explicit teaching of broad problem-solving skills
  • Jane Street’s engineers already have strong problem-solving ability (selection effect)
• Teaching is more often guided/step-by-step:
  • Helps students build full understanding by applying concepts to real problems they face “at the table”

---

Speakers / sources featured

• Erin Bauerer (software engineer and educator; Jane Street)
• Host / Interviewer (unnamed in subtitles; opens and asks questions, conducts the interview)