Generated by Codex with GPT 5.6 Sol High

The Pragmatic Engineer surfaced this October 29 conversation with Titus Winters, a former Google engineering leader who helped run the company’s C++ infrastructure and language-readability programs before joining Adobe. The episode connects three questions that are often discussed separately: how to change enormous codebases safely, how to judge whether AI actually improves engineering, and what new programmers should learn when generating code is becoming cheap.

Winters’s central argument is that software productivity does not come from producing more code. It comes from making valuable changes without fear, preserving the evidence needed to trust those changes, and teaching engineers to reason about systems rather than merely emit plausible output.

How Google changed 250 million lines without stopping work

Soon after Winters joined Google in 2010, a team of roughly a dozen engineers began replacing foundational C++ APIs across a codebase of about 250 million lines maintained by 10,000 engineers. The challenge was not merely scale. The old and new systems had to coexist while development continued, and thousands of unrelated changes could reintroduce patterns the migration was trying to remove.

The team treated the job as a controlled program transformation. It used MapReduce to parse build targets into abstract syntax trees, matched exact call patterns, generated edits, and split the results into directory-sized batches. Old and new APIs worked side by side until the migration was complete. The build system then blocked new uses of the obsolete pattern, after which the old implementation could be deleted. The need for consistently formatted generated changes also helped produce the tooling that became clang-format.

This history is a useful corrective to the idea that large automated rewrites began with language models. Google already had machinery that could make millions of precise edits because its code was parseable, its dependencies were visible, and changes could be tested and reviewed. AI can widen the range of transformations that automation can attempt, but it does not remove the need for those foundations. A model that can propose a clever rewrite is much less valuable when the organization cannot tell what it touched or whether the result is safe.

Tests and review were organizational infrastructure

Winters traces Google’s testing culture to a concrete failure. Around 2007, changes throughout the company increasingly affected Search, and the flagship product slipped from monthly releases toward quarterly ones. Google responded by requiring every code change to include a test. That mandate was not simply a quality rule; it restored the organization’s ability to change a highly connected system at speed.

Google’s language-readability program addressed a different bottleneck. A change required approval from both a domain owner and an engineer certified in the relevant language’s style and practices. The program grew from hands-on mentoring into a company-wide teaching system, with more than 10,000 engineers enrolled when Winters left. Review therefore served two purposes: protecting the codebase and distributing engineering judgment.

Both practices support Winters’s claim that fear is a sign of an unsustainable codebase. Engineers should not need courage to make an ordinary valuable change. They need tests, ownership, review, and tooling that expose mistakes before production. Those controls are sometimes described as friction, but in a large system they are what make rapid change possible.

AI output is not the same as engineering progress

The episode is skeptical of simple productivity measurements. Winters says engineers he speaks with are reporting a familiar pattern: much more code is being produced, outages are up by about 30%, and the number of features shipped is roughly unchanged. This is an anecdotal cross-company observation, not a controlled measurement, but it captures the accounting error in treating generated code or pull-request volume as the product.

At the same time, Winters is not arguing that AI has failed. He thinks its greatest value may be enabling ambitious projects that were previously too expensive to attempt, rather than completing the same backlog faster. That distinction changes what teams should measure. A successful AI-assisted project might not reduce the hours spent on an existing task; it might make a migration, analysis, prototype, or cleanup feasible for the first time.

The Google refactor also suggests how to separate useful acceleration from churn. An AI-assisted change should enter a system with explicit invariants, automated checks, staged rollout, clear ownership, and a way to prevent regression. If code generation grows faster than these verification systems, the organization can appear more productive while its capacity to ship reliable improvements remains flat.

Computer-science education should grade reasoning

Winters helped shape the ACM, IEEE Computer Society, and AAAI undergraduate curriculum guidelines and argues that much of the standard curriculum still reflects the industry of roughly 2000. Testing and verification are central to modern engineering work, yet they receive far less emphasis than their practical importance warrants. AI makes that mismatch harder to ignore because students can now produce code without understanding the system that code is supposed to create.

Professors have described a troubling split to him. Strong students use AI as a patient tutor and become more capable. Weaker students can use it to reach superficially acceptable output. The middle group appears especially vulnerable: some students who would previously have struggled productively now submit working-looking code while understanding less of it. These reports are observations from instructors, not a longitudinal study, but they point toward a real assessment problem. Grading only the final program increasingly measures access to generation rather than engineering competence.

Winters proposes evaluating the work around the output: the prompts a student used, the tests they designed, the assumptions they made, and the evidence that the system behaves correctly. That does not mean prompt writing replaces programming. It means the scarce skill moves upward, from typing syntax toward specifying intent, recognizing failure modes, and constructing verification strong enough to make generated work trustworthy.

His metaphor is that an axe does not chop down a tree; the person wielding it does. Treating an AI system as an autonomous colleague can blur who is responsible for the goal and the result. The student or engineer remains accountable for deciding what should be built and for demonstrating that it works.

The durable advantage is judgment with evidence

The episode’s historical claims come primarily from Winters’s own experience, while its claims about current outages, student performance, and AI productivity are informed judgments rather than comprehensive datasets. The Google systems also benefited from unusual scale, centralized infrastructure, and authority that smaller or more fragmented organizations may not possess.

Still, the pieces reinforce one another. The giant C++ migration succeeded because automation operated inside a disciplined technical and social system. Mandatory tests improved release capacity because they turned confidence into repeatable evidence. Readability review made standards teachable instead of leaving them as private expertise. AI does not make those lessons obsolete. By lowering the cost of producing changes, it makes the ability to validate, govern, and learn from them more important.

The practical takeaway is not to slow generation for its own sake. It is to invest in the conditions under which faster generation becomes useful: code that can be transformed mechanically, tests that capture real behavior, reviewers who teach as well as approve, and education that rewards understanding. When output is abundant, trustworthy judgment becomes the constraint.