Artie Shevchenko and Titus Winters on Code Health in the AI Era

Titus Winters welcomes Artie Shevchenko to the GOTO Book Club to discuss Code Health Guardian and the role of human programmers in an AI-assisted era. Winters asks what led Shevchenko to write it.

Shevchenko says he has long enjoyed sharing knowledge and preparing students for future challenges. At Google he developed internal code-review classes; more than 1,000 employees attended, and their response gave him confidence to continue teaching.

A presentation by John Ousterhout on A Philosophy of Software Design supplied another important influence. Shevchenko liked the way its complexity model gave theory to familiar engineering practices. Years of teaching university courses and revising the material then supplied further insights worth sharing.

Reading Software Engineering at Google, co-curated by Winters, made Shevchenko notice that some aspects of actual coding culture were only briefly covered. He sent Winters an early draft about design documents; Winters recalls being pleased to see that topic explored.

Winters asks about Ousterhout's complexity framework. Shevchenko explains three distinct problems: change amplification, where a seemingly small change spreads across many locations; cognitive load, the difficulty of understanding code; and unknown unknowns, where a developer lacks the information needed to see a problem.

Separating the problems helps prioritize them. Shevchenko generally regards unknown unknowns as more severe than cognitive load, and cognitive load as more severe than ordinary change amplification, while allowing that very large amplification can change the ranking.

Ousterhout links complexity to obscurity and dependencies. Shevchenko retained the three symptoms but reconsidered the causes while writing: dependencies can create problems, yet they are also fundamental building blocks of software. Winters agrees that a dependency provides a benefit as well as a maintenance liability.

Shevchenko replaces the broad dependency category with six more specific causes: misleading interfaces, complex interfaces, unfamiliarity, too many dependencies, duplication and unstable dependencies. Winters notes that every dependency has some cost and risk, but their quality varies considerably.

Turning to AI, Shevchenko argues that plausible generated code does not by itself demonstrate understanding. This is his view about current models. He worries that leaving a codebase entirely to generated output can erode a team's intellectual control, so people still need to validate important changes.

Winters says generated code often looks plausible at a glance but can have weak tests or questionable interfaces without sufficient instructions and supporting infrastructure. He asks whether the same six causes are useful as a review checklist for AI-assisted work. Shevchenko says they apply to human-written code too.

Shevchenko compares two students who produce similar exam answers: one understands the material and another has memorized it. The analogy illustrates his concern that surface-level plausibility is hard to distinguish from understanding, and that a useful answer in one case may not generalize to another.

Asked whether he reviews every line, Shevchenko admits that he now checks test scenarios more carefully than every line of test code, while still reviewing most production code. He is unsure whether that balance is right and says he is still learning how to prioritize review.

Winters says the industry is rebuilding its playbook as AI changes development, and that experienced engineers should be willing to acknowledge uncertainty. His own review priority is what is hardest to change later: dependencies and frameworks, state and storage, API design and database schemas.

Shevchenko puts interfaces near the top of the list. Reviewers should check whether an interface makes a clear promise and actually fulfills it. Poor interfaces can create both cognitive load and unknown unknowns that are expensive to uncover later.

Winters distinguishes intellectual control from statistical control. The former means understanding a system well enough to reason through a change; the latter uses tests, evidence and experiments to gain confidence in safety even when every causal detail is not understood. They see these as complementary tools.

Shevchenko says his book refers readers to Software Engineering at Google for a fuller treatment of testing. In his complexity model, tests help verify that interfaces keep their promises and reduce the chance that an unknown breakage goes unnoticed. Types and assertions also contribute.

Discussing reader reception, Shevchenko explains that he placed the most important ideas early because more readers reach the first chapters than the later ones. He highlights software engineering over time, the complexity model and design by contract as early topics.

Winters asks for the pitch for semi-functional programming. Shevchenko describes it as preferring immutability by default, an established practice rather than a claim of invention. Immutable values reduce the need to track who changed a variable and when, lowering obscurity.

He does not advocate making everything immutable regardless of cost. Taken to an extreme, the approach can hurt readability; there is still room for mutable state. His recommendation is a strong default with pragmatic exceptions.

Winters connects this to testing. Stateless code is easier to exercise; code that reads state needs representative state, while code that both reads and writes state requires careful setup and sequencing. Mutable state introduces a time dimension that software engineering has to manage.

The conversation ends with Shevchenko thanking Winters for encouragement and for writing the book's foreword. Both emphasize that the practices for AI-assisted development are still evolving.