Summary (TL;DR)

Why is changing existing code with AI so much harder than writing new code?

Vibe coding feels like using a new found super power—no prior experience needed, no constraints, pure speed, fast results. But changing existing code with AI is so much harder. Why?

My thesis: code is pure dependencies.

Every function call, every shared data structure is an edge in a dependency graph. And those edges exhibit path dependency: early decisions dig grooves the system can't escape—just like the QWERTY keyboard layout (designed in 1878 for mechanical typewriters) and US employer-sponsored healthcare (born from WWII wage controls). New code has no dependencies: that's why it's easy. Existing code by its very nature is a tangled dependency graph, and that's why it's so much harder to change, and AI agents can only help us so far.

The job of professional software developers has shifted. We no longer write code—we create guardrails (interfaces, contracts, tests, documentation) that keep AI agents on track and reduce path dependency so we don't get stuck. These guardrails must be validated by other mechanisms than AIs. LLMs, or AI agents, today, cannot be relied on to validate contracts. The antidotes to the tangled mess of dependencies are well-known software development concepts, and in this article we highlight how to adapt these into the age of AI coding:

• Modularity – clear boundaries with agent-readable, compiler-checkable contracts
• Exchangeable implementations – validate interfaces by building multiple implementations against them
• Planned interface evolution – extend without breaking (and let agents update required parameters across the changeable codebase)
• Testing – essential but double-edged; every test adds a dependency edge, so favor integration tests over fine-grained unit tests
• Documentation – LLMs are incredibly fast readers; the importance of good docs has skyrocketed
• Larger repositories – enable atomic cross-module changes
• External dependency tracking – the hardest problem, requiring deprecation protocols and clear timelines

These are some of the patterns that make AI coding work on large, real, existing codebases—not just greenfield toys. The individual developer is faster, but the organizational machinery around software development hasn't yet caught up.

To close this gap, we need to understand why existing code resists change so stubbornly, and what we can do about it. The answer starts with path dependency—a force that shapes everything from QWERTY keyboards to healthcare systems—and leads to a practical toolkit for software engineering in the age of AI.

Table of Contents

1. The Age of AI Coding
2. What is Path Dependency?
   • QWERTY: The Classic Example
   • US Healthcare: A Path-Dependent System
   • Systems Without Strong Path Dependency
3. Code Is Pure Dependencies
   • Vibe Coding the Inner Nodes
4. Guardrails for AI Coding
   • Antidotes to Path Dependency in Code
   • Modularity
   • Exchangeable Implementations
   • Planned Interface Evolution
   • Testing in the AI Age
   • Documentation Is More Important
   • Larger Repositories
   • Larger Deployment Packages
   • External Users: The Hardest Problem
5. Conclusion