The framing for this piece comes from a recent interview with Barbara Liskov on data abstraction, distributed systems, and the design problems she has spent her career on. A widely-shared “Downsides of Python” clip pulled from that conversation surfaces a long-standing argument: Python allows you to express architectural boundaries, but it does not strongly enforce them. That argument is not new. It is significantly more important now than when she first made it.
Barbara Liskov’s 2008 ACM A.M. Turing Award Lecture, “The Power of Abstraction” — watch on YouTube
What Liskov actually meant
The critique is precise. Liskov is not saying Python is unusable — she is distinguishing between convention and enforcement. Python has the vocabulary to express modularity: modules, classes, the _private single-underscore prefix, name mangling, packages. What it does not have is a runtime that prevents external code from reaching past those boundaries.
Specifically:
_privateis advisory. Nothing in the runtime stops a caller from using it.- Reflection and introspection routinely bypass the abstractions a module declares.
- Modules expose internals freely; the boundary is social, not enforced.
- Runtime flexibility — monkey-patching, attribute access,
__dict__— weakens strict abstraction guarantees in ways languages with stricter encapsulation do not allow.
Encapsulation matters because it protects modularity from implementation leakage. In a Python codebase maintained by careful humans, conventions can hold the line. The team agrees not to reach into _internal; they don’t. The encapsulation works because the people work.
Why this matters more with AI coding
Human teams could partially compensate for advisory boundaries with code review, tribal knowledge, senior engineers, and architecture oversight. That is exactly the system Liskov’s critique relied on to be merely a quibble.
AI changes the scaling dynamic. An AI agent:
- Can generate code across the entire repository in a single session
- Optimizes locally rather than architecturally — whatever pattern reaches a passing test fastest
- Bypasses abstractions accidentally and repeatedly, reproducing the bypass pattern wherever it sees one
- Reproduces anti-patterns at machine speed once the wrong pattern enters the codebase
LLMs are very good at pattern continuation. They are not naturally good at preserving invisible architectural intent.
The encapsulation Liskov worried about was always advisory. As long as the rate of advisory violations was human-paced, code review could hold the line. At agent velocity, the same advisory boundary becomes a load-bearing assumption that the system was never designed to make.
Prompt files and memory are not enough
The current ecosystem’s answer has been to give the agent more guidance through the prompt surface: CLAUDE.md files, Cursor rules, sophisticated prompt engineering, RAG memory, large context windows. All of those help. None of them create enforcement.
The distinction matters. Context can suggest behavior. Governance constrains behavior. Suggestions degrade across long sessions, model upgrades, and conflicting instructions; constraints do not.
A context window is not an architectural boundary.
The mistake is the same one Liskov was identifying decades ago, applied to a new layer. Conventions in source files are advisory; the only thing that protected them was the social contract among humans reading the code. Conventions in prompt files are also advisory; the only thing protecting them is the model’s willingness to follow them this turn.
The missing layer: architectural governance
The shape of the missing infrastructure is becoming visible. Architectural governance is the category that adds:
- Executable architectural constraints — decisions compiled into machine-evaluable rules, not paragraphs
- Deterministic boundary enforcement — same input, same verdict, every time
- Machine-readable architectural intent — rules carried as structured artifacts
- Enforcement before merge or generation — not just after the diff exists
What that enforces in practice: forbidden dependencies, layer violations, prohibited imports, ADR-derived constraints, scope-aware boundary rules. The kind of thing Liskov’s argument said the language did not give you for free — supplied by a separate layer that sits between the agent and the codebase.
This is infrastructure evolution, not just tooling:
| Wave | Governance layer that emerged |
|---|---|
| Cloud | Security and compliance infrastructure |
| CI/CD | Observability infrastructure |
| AI coding | Governance infrastructure |
The full version of that argument is in The Next AI Infrastructure Category Is Governance. The relevant point here: Liskov was naming the gap a decade ahead of the wave that makes it operationally expensive.
Why this is bigger than Python
It is tempting to read the critique as a language argument. It is not.
Even languages with stronger encapsulation — Java with proper access modifiers, Rust with module privacy and trait boundaries, Go with package-level visibility — still face architectural drift, agent coordination problems, multi-agent inconsistency, and repository-wide governance gaps. Stronger encapsulation reduces the local damage of a single bypass. It does not solve the system-wide governance question.
The real problem is not which language allows the bypass. It is that AI systems can traverse abstraction layers faster than organizations can review them. Encapsulation is one local-scope answer to a problem that has become global-scope.
The shift Liskov was pointing at gets bigger in every language. Governance moves from a style preference to an infrastructure concern.
The future of AI development is constraint-aware
The next generation of AI development systems will separate exploration from enforcement. Agents remain flexible during discovery — trying patterns, prototyping, generating options. Architectural invariants become deterministic and machine-enforced. The agent gets to be creative; the architecture gets to be a contract.
Liskov’s argument predicted that distinction long before AI coding made it operationally urgent. The encapsulation debate was, underneath, an enforceability debate. As software generation becomes autonomous, enforceability stops being a language-design quibble and starts being the load-bearing assumption of the whole system.
The infrastructure that closes the gap exists now under a name Liskov would recognize the shape of: architectural governance. Same problem — modularity protected against implementation leakage. New layer.