AI Writes Code, But Can't Build the Engineer: Why Reading Source Code Still Matters

A Scary Realization

The author recently used an AI assistant (WorkBuddy) to adapt the Feat framework to a new MCP specification. The AI completed the task quickly, matching the project's coding style perfectly. However, the author felt a sudden panic: they had zero motivation to read the new specification themselves. Since the AI produced working, stylistically consistent code, why bother studying the dull spec document?

This revealed a dangerous gap: the code was in the project, but the understanding was not in the author's mind. They didn't know what changed, why it changed, or where the boundaries lay.

AI's Efficiency Is a Stock Dividend

AI's speed depends on the user's existing experience. The author could confidently delegate the MCP adaptation because they already knew the old spec and the codebase thoroughly — they could catch errors if something went wrong. But the new spec itself remained unlearned. AI amplifies your stock of knowledge; it does not automatically grow your increment . Human laziness means that when even incremental learning can be outsourced, we quietly stop growing. The convenience is real, but so is the stagnation.

Why a Half-Hour Fix Took Three Days

This stagnation sometimes surfaces as accidents. With AI becoming more capable, some developers fall into vibe coding : describe requirements, generate code, run it, ship it if it works — skipping review entirely. Normally this boosts efficiency. But when bugs appear, the situation flips: the developer never read the code, so they must ask AI to fix AI's own defects. One change breaks another; a problem solvable in half an hour drags on for hours or days.

The deadlock has two roots:

The developer never saw the code, so they lack a mental model to judge AI's suggestions.

They forget the context of their earlier prompts to AI, losing the thread needed to take over manually.

AI can generate answers, but it cannot give the "something smells wrong" intuition. Judgment comes from scars, not knowledge.

Same Tool, Different Stance

In a previous article, the author described using AI for a "health check" on Feat's internals, which uncovered nine issues. Crucially, every fix decision — whether to change something and how — was made by the author after reading the code themselves . AI did the inspection; the human made the judgment.

Contrast that with the MCP adaptation: same AI, same author, but this time the author nearly surrendered the right to learn as well. The tool didn't change; the author's position did — using AI as a lever in familiar territory versus letting AI replace them in unfamiliar territory. The former makes you stronger; the latter makes you idle, then weaker.

How Long Since You Read Source Code?

Every senior engineer is forged through countless projects, production incidents, and deep dives into underlying source code. The code is merely a byproduct; the real output is the tempered human being.

Today, AI can read source code for you, debug for you, even learn new specs for you. The programmer's role seems reduced to stating requirements. But results can be delivered; the process cannot be outsourced. It is precisely those seemingly "inefficient" grunt work — reading source, poring over specs, wrestling with incomprehensible problems — that shape the person. AI can hand you the code, but it cannot hand you the person forged by that process.

So, how long has it been since you last read source code? And if this continues, what will ultimately remain within us?

The author is the creator of Feat, a high-performance Java web framework featuring compile-time AOT, zero reflection, millisecond startup, and a memory footprint a fraction of traditional frameworks — especially suited for edge devices, long-lived connections, and private deployments. Interested readers can visit the project on GitHub or Gitee; a star is the best support.