A Google Engineer of 12 Years: CS Curricula Should Be Burned Down—In the AI Era, Move Beyond Code

Someone Who Defined the Curriculum Says It Should Be Burned

How would you feel if you spent four years studying computer science, only to discover that what you learned was designed for building databases and operating systems in the 1990s?

Titus Winters's answer: Most CS curricula should be burned down and rebuilt.

This judgment comes from someone who is no outsider. Titus spent 12 years at Google, is the lead author of Software Engineering at Google, and once ran Google's readability program; in 2023, he was the only frontline engineer still writing code on the ACM/IEEE undergraduate CS curriculum steering committee. According to what he said on a podcast, the "average course" in the curriculum system is exactly what was needed to build databases and operating systems in the nineties—hardly a flattering statement for a field that prides itself on innovation.

His core argument can be summed up in one sentence: We need to move beyond code and raise the level of abstraction.

2.5 Million Lines of C++: The Largest Refactoring in Human History

To understand Titus's engineering philosophy, you cannot avoid the refactoring he led at Google.

At the time, Google's C++ codebase was about 200 to 250 million lines (first-party code only), and within a month about 10,000 engineers committed changes to this codebase. Titus's team's metaphor was: Google invented a new skyscraper foundation technology and had to replace the foundation without shutting down the Empire State Building or blocking traffic—and then discovered nuclear waste in the basement.

They did not use brute force, but instead built deterministic compiler-assisted tooling: Clang/LLVM-based AST (abstract syntax tree) transformations to do MapReduce over the codebase—the mapper parsed each compilation unit to generate a syntax tree, precisely matched function call contexts on the syntax tree, and then the tool generated rewrites. Interestingly, one of the biggest initial obstacles turned out to be "the generated edits couldn't place whitespace characters in the right positions," which directly led to clang-format.

Even Google, as powerful as it is, had things it couldn't do: editing tens of thousands of files at once inevitably produces merge conflicts. The solution was to let old and new APIs coexist, advance in parallel in batches by directory, and delete the old interfaces after cleanup.

AST (Abstract Syntax Tree) is a tree-like data structure generated by a compiler after parsing source code. It uses nodes to represent syntactic structure (such as function calls, variable declarations, expressions) while discarding information that does not affect semantics, such as whitespace and comments. Because the AST retains only the structural essence of the program, AST-based code transformations can precisely match patterns such as "a certain function is called in a specific context" without being disturbed by differences in code formatting. Google's refactoring tools traversed the AST to find target call sites, then generated rewrites at the tree level, and finally serialized back to source code. This "parse—match—rewrite" process is deterministic because the same input always produces the same output, and the transformation rules can be reviewed and reused, avoiding the random deviations that can occur when letting large language models directly edit code.

The Right Way to Do AI Refactoring: Let AI Write Rules, Not Do the Work

Titus's view forms a sharp contrast with the practices of many teams today. Using non-deterministic AI to directly reshape large-scale codebases is far inferior to having AI generate deterministic tools.

He mentioned OpenRewrite in the Java ecosystem: you declare "I want to find this pattern in the code and rewrite it this way," and the tool runs across all source files in an auditable and repeatable manner. AI is extremely good at generating OpenRewrite recipes—lower token consumption, higher accuracy, faster speed. He mentioned that some teams even have AI code review tools directly generate lint rules after finding problems: rules are cheap and repeatable, and there is no longer a need to spend half an hour running expensive and uncertain inference each time.

Behind this is a consensus: Inference is for one-off judgments; deterministic tools are for long-term execution. The so-called "zero-token architecture" idea is precisely to have AI generate tools and perform inference only in the gaps that tools cannot cover.

OpenRewrite is an open-source automated code refactoring framework in the Java ecosystem. Its core idea is "recipe-driven": developers describe a transformation rule declaratively—for example, "replace all calls to the old API with the new signature"—rather than hand-writing scripts to modify files one by one. OpenRewrite parses source code into a Lossless Semantic Tree (an AST that preserves formatting information), applies recipes on the tree structure, and writes back to source code, so transformations are auditable, repeatable, and rollback-capable. Because recipes are essentially structured rule descriptions, they are closer to code than natural language; AI needs fewer tokens and achieves higher accuracy when generating recipes, and the generated results can also be reviewed manually item by item. This forms a fundamental difference from letting non-deterministic models directly edit massive source files.

The Blind Spot of Productivity Measurement: AI's Value Is Not Where You Measure

Titus is responsible for developer experience at Adobe, and he says bluntly that "developer experience is ultimately a productivity business, except we are polite enough not to say we can measure productivity."

He cited the exact words of a senior engineer: code volume increased by 70%, online incidents also increased by 30%, while the number of features stayed flat. This exposes the impotence of traditional measurement—if AI merely lets you do the same things faster, the value is actually quite limited; the real value lies in doing harder and more valuable things you would not have thought of before.

He gave an example: an engineer at a mid-sized company used AI, with a large test suite as the specification, to rewrite a vendor's closed-source licensed component—faster and better—even though the team had no domain knowledge in that area. The vendor in turn paid them to not open-source it. This kind of "game-changing" benefit cannot be captured by any "counting parts" metric.

CS Education: From "Producing Code" to "Specifications, Testing, and Review"

Titus's criticism of education is extremely specific. He says most CS curricula have not substantively changed since 2000, and have been engaged in "incremental stacking"—constantly adding things while cutting the depth of existing content.

His alternative is:

• Stop making code artifacts the core of grading. Rather than writing yet another linked list or yet another book review of The Catcher in the Rye, grade the prompts you use, the tests you write, and how you verify that AI actually did it right.
• Teach interface design in the first course. He even imagines turning CS0 into a course on "input/output and interface structure"—the difference between checkboxes and radio buttons, when a button should be used, how to write command-line flags. Even if students take only this one course, what they assemble with AI will have a more coherent design language.
• Use projects to drive theory. You cannot offer a solution to someone who has not yet realized there is a problem; let students encounter the problem first, and theory will then turn from "isolated knowledge points" into answers.
• Grading includes peer review, and what is judged is "whether you can give feedback without malice"—this is directly tied to psychological safety.

He predicts: CS enrollment will decline sharply, while software engineering majors will rise—because in the AI era, what can still get you a job is teamwork, communication, designing specifications, testing, and verification, which happen to fall within the scope of software engineering.

He also mentioned the lesson from the University of Waterloo: through multiple paid internships, students accumulate close to a year of real work experience before graduation, which is extremely valuable from a hiring manager's perspective.

Teams Remain the Foundation, and Psychological Safety Remains the Strongest Predictor

Faced with the notion of the "100x engineer," Titus's judgment is: software engineering is a team sport, no exceptions. Even if AI agents are regarded as a team, engineers need to become the "managers" of the agent team, and the industry currently provides no relevant training for this.

He cited a data point from DORA research: culture questionnaire scores alone can explain about 30% of the variance in team goal attainment—he believes this is stronger than any technical signal. This also explains why the hidden damage of layoffs to productivity is severely underestimated: one-on-ones turn into emotional support, people start updating their resumes, and the link between "extra effort" and "extra sense of safety" is severed.

DORA (DevOps Research and Assessment) is a long-term empirical study that began in 2014, initially led by Nicole Forsgren, Jez Humble, and others, and later acquired by Google Cloud, which continues to publish annual reports. Through large-scale questionnaires and statistical modeling, it identifies key factors affecting software delivery performance and proposes two sets of metrics: "delivery throughput" and "stability" (such as deployment frequency, lead time for changes, change failure rate, and time to restore). An important finding of DORA research is that organizational culture factors such as psychological safety, learning culture, and cross-team dependency management have a significant and stable explanatory power for team performance, often stronger than technology stack or tool choices. The "culture questionnaire explains about 30% of the variance in goal attainment" cited by Titus is a continuation of this line of research, and it also explains why simply introducing AI tools without changing collaboration methods makes it difficult to bring about fundamental performance improvements.

Advice for Students: Take a Path No One Else Takes

Titus's closing advice carries some risk, but it is candid: most of his successes in life came from "not doing what everyone else is doing." Find a direction you are genuinely interested in—even if it is a bit eccentric—and invest time in it; you will have a unique story, and you will be worth a serious conversation in an interview.

He also flagged a concern: AI assistance has lowered the threshold for raw engineering ability, and what replaces it can only be a deeper understanding of the problem domain—which means industry mobility may decline. In the future, you will no longer be "a C++ engineer" or "a backend engineer," but "an embedded audio engineer."