Aaron Bauer on Teaching Software Engineering in the Age of AI

Ron Minsky introduces Aaron Bauer, a Jane Street software engineer and developer educator. Bauer’s work combines programming with teaching other engineers, a combination he has pursued since his first experiences in computing.

Bauer says computers fascinated him as a child, but programming seemed intimidating. At a six-week summer science program in New Mexico, he used telescope observations and Python to calculate an asteroid’s orbit. He discovered that programming was the part he most enjoyed.

His small-town high school did not offer AP computer science, so he took an online North Carolina course taught by a retired teacher. Before graduate school he returned to the science program as a teaching assistant, wrote exercises and lectured on binary search trees. That experience got him hooked on teaching.

Minsky notes the long connection between scientific computing and computer science. Bauer recalls working on a Fortran simulation of asteroid or comet impacts derived from code for modeling atomic explosions. They discuss the mixture of sophisticated computing and practical, domain-driven programming in scientific work.

A computer graphics course inspired Bauer to apply to PhD programs, though he learned that much rendering research had moved to industry. His work eventually included game design and computer science education, ending in a dissertation on human-computer problem solving in the scientific game Foldit.

Bauer describes Foldit as combining players’ big-picture geometric insight with automated local optimization. Players, often without biochemistry backgrounds, helped resolve structures that had resisted laboratory work and later designed new proteins. He assumes such known structures would have been included in AlphaFold’s training, but does not claim direct knowledge of its dataset.

His graduate research also had a cognitive psychology element: how people learn, think and apply skills. Wanting teaching to be his primary work, he joined Carleton College in Minnesota. After two in-person quarters, the pandemic moved four quarters online.

Bauer initially used the text-only model of his own online AP course to accommodate students with limited internet access. Feedback quickly showed that what had worked for him did not work for everyone. He experimented with flipped classrooms, synchronous sessions and small working groups.

In a flipped classroom, students watch a prepared lecture before class, leaving shared time for exercises, discussion and individual tutoring. Bauer ultimately preferred mixing interactive activities with instruction during class rather than relying entirely on the flipped model.

Minsky argues that live lectures are often underrated: a lecture is also a compelling human performance. Bauer agrees that a live presenter can focus attention and encourage note-taking, while warning that an uninterrupted hour of talking can lose students. He favors active learning, pausing for questions, discussion or short problems.

They discuss note-taking as a way to process and distill material, even when notes are never reread. Both recall claims that handwriting helps more than typing but do not cite a particular study. Bauer adds that a screen between student and teacher also brings distractions.

Minsky describes teaching his children programming on paper. Without a computer to run the code, they had to reason about what an expression meant instead of simply trying changes until it worked. Bauer agrees that paper can push beginners to think about program behavior.

After returning to the classroom, Bauer kept recording lectures. At Carleton, students still attended and could use recordings after missing class or revisit a timestamped explanation. The experience may vary by institution or lecturer, they note.

He also retained automated quizzes and homework feedback. Feedback arriving a week or two later can be too late, after students have moved on. Automated checks allowed repeated attempts and a limited form of mastery learning: students could keep working until they demonstrated competence.

Minsky recalls that advanced mathematics sometimes only made sense months later. Bauer says mastery learning is often applied more fully with younger students; university courses need more targeted use and deadlines. His weekly quizzes permitted multiple attempts and kept the best result, with shuffled questions and answers to make understanding more practical than brute force.

Asked about LLM feedback, Bauer sees potential in bounded tasks such as code style alongside tests and linters. He also warns that model feedback can contain misleading false positives, so students need careful framing or a lower error rate.

Bauer moved to Brooklyn to be near family and found Jane Street hiring for an unusual educator-programmer role. Minsky explains that the firm already invested in teaching its distinctive trading domain, language and tools, but wanted people with sustained educational expertise who also practiced engineering in the same environment.

The intended split is roughly half programming and half education, including curricula, teaching and helping colleagues become better teachers. Minsky says hiring for this intersection has been harder than expected. Bauer notes that experienced educators often work in academia and may not want a substantial engineering role in industry.

Bauer says making education a first-class responsibility allows sustained attention. Needs continue to grow: new employees learn OCaml, experienced staff must learn changes to the language, and everyone needs to understand new AI tools. The firm is also interested in educators for programming languages and machine learning.

Minsky wants engineers to move among tools such as OCaml and Python rather than being confined to one language. Bauer suggests embedding educators in technical teams, including AI assistance, while Minsky notes that different technical placements would also broaden the educators’ collective experience.

Bauer works on the editors team in tools and compilers, supporting VS Code, Emacs, Neovim, code indexing and the OCaml language server. One project made it easier to split and arrange work for separate reviews in Iron, Jane Street’s feature-management tooling.

Minsky explains that a Jane Street “feature” is roughly analogous to a commit or pull request depending on context. Iron supports chains resembling stacked pull requests, but had awkward diff editing. Different tooling choices have produced a distinct development and review culture.

At Jane Street the editor is the engineer’s home base: code review, version control and other interactions are integrated there and navigable by keyboard. Reviews use comments in the editor, but a reviewer can also directly make a fix. Minsky notes that this collaborative style can feel strange to people used to separate pull-request interfaces.

Bauer describes problems of scale in general-purpose editors. Very large diffs can cause VS Code’s diff algorithm to hang and block other diff views. Integrations can violate assumptions about buffers and make search behave strangely, while richer OCaml indexing can consume so much memory that an index no longer fits on available machines.

Python notebooks are another difficult area. Different notebook tools have different limitations, and introducing a replacement that lacks a previous feature can leave multiple systems to maintain. Code written in notebooks may also be hard to share as a library; the team is exploring its own solution after performance and usability problems.

Minsky worries about overbuilding internally but values control when external notebooks do not fit the firm’s needs. Conversely, the team is replacing some custom Emacs functionality with upstream alternatives. Bauer says upstream code benefits from other users, maintainers and better compatibility with standard extensions.

The boundary between native editor languages and Jane Street’s OCaml extensions remains challenging, particularly for asynchronous work in Emacs. Bauer hopes to reduce awkward dependencies and potential deadlocks. Minsky notes that combining concurrency systems across languages is hard even when each has a reasonable model.

Agentic AI changes developer tools, but Bauer still sees the editor as a useful home base. Engineers may type less code while continuing to inspect diffs, review changes, navigate definitions and understand what has been produced.

Bauer is using editor and language-server telemetry to understand actual workflow changes instead of guessing. He expected per-user jumps to definition to decline if models wrote more code; the data appeared to show a slight increase instead, perhaps because people need to read more code. He treats this as an observation and possible explanation, not a settled conclusion.

Minsky says creating a plausible-looking change has become much cheaper, while verifying it remains difficult or may be harder: generated code can look polished and still be broken. He wants better tools for understanding, including LLM explanations and conventional evidence such as definitions, inferred types and test results.

Bauer tried Claude Code’s learning output style, which sometimes leaves a task for the human to complete. Stopping to read the generated code and implement a piece helped him build a mental model. He wants to explore workflows that cultivate understanding during generation, not just explanations after the fact.

Bauer compares reviewing generated code with reviewing another person’s finished change: unlike writing code incrementally, the reviewer must reconstruct a mental model from the result. Minsky sees an analogy with taking notes and suggests that active participation may improve understanding.

They consider new review aids. Minsky imagines custom visualizations generated for a particular change. Bauer suggests dividing code into logical sections with precomputed explanations available during review; these are ideas to explore, not deployed solutions.

Bauer describes a testing workshop on property-based testing and deterministic control of time. When an LLM can write an example using a new library, educators must decide what knowledge is essential and what is merely boilerplate. So far, he thinks implementing a technique oneself at least once helps build the understanding needed to assess later generated code.

They have not settled how to teach effective AI use while the tools change quickly. Minsky worries that learners need to struggle with material and can now ask a model to solve most exercises immediately. The range of tasks both manageable for a learner and hard for a model to solve in one shot may be very narrow.

Bauer has encountered the other side of this trade-off: tasks large enough to require real work on generated code can be too large to review and polish in the time available. He expects experimentation with a combination of activities done with and without models, each serving a defined learning purpose.

For OCaml Boot Camp, Bauer considers models that ask questions, provide a skeleton while leaving substantial implementation to the learner, or act as tutors giving hints. Minsky emphasizes preserving the learner’s opportunity to do difficult thinking. Bauer connects this to his earlier research on patient automated tutors available outside a teaching assistant’s office hours.

New engineers normally start with OCaml Boot Camp: a sequence of exercises building a client-server application, learning core libraries and receiving mentor code review. Production Boot Camp then introduces deployment, monitoring and configuration. Together they occupy roughly the first two weeks.

Bauer says the materials introduce concepts in the context of a specific feature or need, rather than introducing a tool and searching for a problem it solves. This gives learners a reason to use the tool and a hook for understanding it.

During the first year, engineers can take further teach-ins on testing, OCaml performance, debugging, advanced functional programming, Bonsai and market data. Bauer anticipates a course-catalog approach, with a manager or team selecting relevant material and self-study available when needed.

Minsky asks how to balance practical tools with conceptual lessons. Bauer says experienced colleagues already solve difficult problems in their daily work, so a canned puzzle can be less useful than guided practice with tools they can apply. Concepts still matter, but fuller understanding often develops when the tools are used on real desk problems.

Minsky recalls Bauer asking for the learning goals of a testing workshop. Bauer defines them as observable changes in what students can do after an activity. “Understand property-based testing” is vague; writing a property-based test for a specified kind of input is more concrete and measurable.

Specific goals determine both what to include and what to leave out. Educators can design exercises that practice the desired capabilities, then identify the lectures, code and background needed to support them. Minsky adds that checking whether students can do those things also evaluates the teaching program itself.

Bauer applies cognitive-load ideas to OCaml Boot Camp. An earlier version introduced OCaml, a new editor, version control and code review at once. The revised sequence begins with small OCaml exercises, then introduces the editor and version control separately before combining them.

Active learning is another principle. New intern materials use small-group discussion, design activities and practice talking with stakeholders, so students interact and work through material rather than simply hearing it.

The intern curriculum changed because AI tools could complete a former four-week introductory project with a prompt. Bauer says projects are becoming more open-ended and realistic, with design and requirements gathering; producing code alone is a less useful signal than before.

The new material also teaches effective use of LLM tools and their failure modes. Exercises need to be substantial enough that a model does not produce a complete solution immediately, but small enough for interns to inspect the output. Testing receives more attention, including writing a strong suite for a database-backed application.

Interns examine good and bad design documents and practice gathering requirements from full-time staff role-playing stakeholders. Code review, formerly uncommon for interns, becomes part of their work. Three days of mid-internship training use prepared changes, reference comments, group discussion and peer review before mentors send real features.

Asked how the redesign has gone, Bauer says the team is learning. If an exercise asks interns to generate more code than they can polish, it undermines the lesson that they own and must carefully review it. Oversized review examples with too many problems likewise make important issues hard to spot.

He values the new interactive structure: interns work in groups of four and regularly discuss their use of models and the problems they see in generated tests, often with mentors. He expects future revisions to adjust scope, pacing and expectations for people who progress at different rates.

An early version emphasized multitasking and vibe coding first; the team decided that set the wrong tone and moved high-quality testing to the start. Bauer expects more considered guidance on workflows as experience grows. Small-group discussions help participants exchange what works, while both speakers note that the tools change quickly and may behave differently for different users.