Writing
AI Coding Part 3: What We Lose
On craft, memory, and the disciplines worth preserving in AI-assisted software work
AI has expanded what we can build. That is real. But expansion has a shadow: some forms of understanding, patience, and craft become easier to bypass. This final essay is about that tension, and about choosing a disciplined relationship to AI that preserves depth instead of replacing it with fluent output.
Part 1 was about guilt. Part 2 was about cost. Part 3 is about loss.
Craft here is not nostalgia. It is operational responsibility: explicit assumptions, readable decisions, and maintainable systems.
Not collapse or nostalgia. A more difficult question: what gets thinner when software becomes easier to produce?
One risk is that output grows while understanding shrinks. You can ship code that works while your relationship to the system weakens - you know less about why it works and where it will break.
Some friction is waste, but some friction is memory. The debugging trail, the rewrite, the slower boundary decision - these are often part of how judgment is formed.
The risk is not AI writes code. The risk is role drift: builders becoming editors of generated possibility rather than authors of coherent systems.
Craft here is not nostalgia. It is operational responsibility: explicit assumptions, readable decisions, meaningful boundaries, and maintainable systems.
This matters at product level too. If teams become fast but shallow, products become persuasive but brittle. Interpretation quality falls even while output volume rises.
That is why I care about structure and disciplined reasoning in SOPHIA, and interpretability/governance in Restormel. The aim is not anti-AI caution. It is anti-shallowness discipline.
The conclusion of this trilogy is simple: build with AI, but preserve the parts of practice that keep good work possible - attention, reasoning, structure, and responsibility.