What Barbara Liskov Can Teach the AI Coding Era

Photo by Kelly Sikkema on UnsplashA contract you can satisfy without honoring is not a contract.Barbara Liskov ended her TEDxMIT talk by reading an insult about herself.She had spent twenty minutes on how modularity based on abstraction came to be. Then she mentioned the Turing Award, which ACM…

Photo by Kelly Sikkema on UnsplashA contract you can satisfy without honoring is not a contract.Barbara Liskov ended her TEDxMIT talk by reading an insult about herself.She had spent twenty minutes on how modularity based on abstraction came to be. Then she mentioned the Turing Award, which ACM gave her in 2008 and presented in 2009, and said her husband had been reading the coverage online. One day he found a stranger’s comment.https://medium.com/media/8f7ab0810f0b5f89d7ff322c40d0a4c6/href“Why did she get the award? Everybody already knows this.”She read it out. Said it wasn’t meant kindly. Then said it was a real justification of everything she had just told them, thanked the room, and sat down.Read the insult as the citationThe stranger had his facts right.Everybody already knows this. That’s the achievement.Liskov’s generation wrote programs where a change in one routine could quietly corrupt state four hundred lines away, and the only way to be sure of anything was to hold the whole program in your head. Abstract data types meant you could know what a module promised without knowing how it kept the promise.What that bought was not tidiness. It was the ability to check a program in pieces. Before it, correctness was a property of the whole thing at once, which is another way of saying nobody could establish it.Fifty years on, that sentence reads like a definition of programming rather than someone’s idea.She makes the same point earlier in the talk about her own graduate students. They didn’t know there had been a before. They thought this was how things were.An invention that goes invisible has won. Invisible things are also the things nobody defends.Notice where she had beenShe says the award made her stop and think about what had happened in her absence. She’d been working on distributed computing. She hadn’t been paying much attention to programming methodology.Years away, she looked up to find the boundaries she helped build had become the floor. The distributed work wasn’t a detour. It was the same problem on worse terrain.Her Turing citation names three things: data abstraction, fault tolerance, distributed computing. Only the first stuck to her name. Argus, viewstamped replication, the practical Byzantine fault tolerance work with Miguel Castro, all of it asks one question. How do you hold an invariant when no single machine, and no single person, can watch every step?That question is not a historical curiosity. It is a description of a modern service architecture.There is a third piece, and it’s the one carrying her name. In 1987 she stated, and in 1994 she and Jeannette Wing formalized, what a subtype owes its supertype. Not the same method signatures. The same behavior, so that a caller who already reasoned about the supertype doesn’t have to start over. A type can satisfy every signature you declared and still break every caller you have.Which is the same local checking, one level up. Honor the behavior, and a caller who was correct stays correct. Break it and correctness goes back to being a property of the whole program, which is where we came in.Robert Martin popularized that argument as the Liskov Substitution Principle in the nineties, which is how a point about specifications ended up filed under object orientation. What she was actually saying is that a contract you can satisfy without honoring is not a contract.She also wrote the book on how to write one. Program Development in Java: Abstraction, Specification, and Object-Oriented Design, with John Guttag, which MIT’s software engineering lab recommended as the text closest to its own material. Methods arrive with preconditions and postconditions attached. Classes arrive with invariants.The order is the whole method. You write down what the thing has to guarantee. Then you write the thing. Then you check one against the other.Invert the achievementIn 1974, abstraction was invisible because nobody had built it yet. Today it is invisible because everybody inherited it.Which sounds like the same word and isn’t.In 1974, you couldn’t check a program in pieces because the tools didn’t exist. In 2026 you can. The tools are all still there, sitting in every language you use. What’s missing is the thing they check against, because nobody wrote it down. Same loss of locality, opposite cause, and the second one is much harder to see, since nothing appears to be broken.The insult was accurate as a compliment. Everybody already knows this. The question is whether knowing it and preserving it are the same act, and what the measurements say about which one we’re doing.Ask the people firstSixteen developers sat down to work.Experienced people. Their own open source projects. Code they knew by heart. Two hundred forty-six tasks between them. Some had AI tools. Some didn’t.Before they started, somebody asked how much faster the tools would make them. They said twenty-four percent. After they finished, somebody asked again. They said twenty percent. Still faster. Still sure.They were slower. Nineteen percent slower.Not slower and annoyed about it. Slower and unable to tell. The people best positioned to notice were the people who missed it.METR ran that study in July 2025 and has since marked it historical, which is fair. Sixteen people is sixteen people. The tools have moved since. Don’t use it to argue that AI makes you slow.Use it for the one thing it does show. The distance between how fast you feel and how fast you are is real, and in this study it ran in one direction.Count what changed in the codeGitClear looked at 623 million code changes. 2023 through 2026.Refactoring line moves, down 70 percent. Long-term legacy maintenance, down 74. Duplicated blocks, up 81. Error-masking constructs, up 47. Copy-paste inside a single commit, up 41.Read the list again, slower.Less moving of code. More copying of code. Less repair of old code. More swallowing of errors.Every number points the same way, and it isn’t speed. It’s a codebase getting more expensive to maintain.Refactoring is the act of paying attention to something you already own. Duplication is the act of not paying attention. Error masking is the act of deciding not to find out.That middle one does more work than it looks. An error-masking construct is usually about five lines, and it looks responsible:try: result = process(record)except Exception as e: logger.warning(f"could not process record: {e}") return {"status": "ok"}Nothing there is wrong on its face. It catches. It logs. It keeps the service up. It also turns every failure that can happen inside process into a success, and the queue upstream reads that ok and stops redelivering. The record is gone. The dashboard is green.Constructs like that one are up 47 percent. Those signals were moving before anybody named a crisis.Watch it reach productionDORA came at it from the other end. Not the diff. The deploy.Their 2024 numbers say that as teams adopted AI, code review got about three percent faster and releases got about seven percent less stable. By 2025, the throughput relationship had reversed. The instability relationship had not.Strip the percentages, and that’s a Thursday.The pull request came in bigger than usual. You read it faster than usual, because most of it was shaped like code you’d seen before, and nothing in it looked wrong. You approved it. Something broke the following week in a way that took a while to trace, and when you found it, you understood the line immediately and had no idea why it had been written that way.Reviews getting quicker while releases get shakier is not a contradiction. Something is being read faster and understood less.DORA’s own explanation is batch size. AI produces bigger change lists, and bigger change lists have always shipped worse. In a research insight published in March 2026, DORA gave the effect a name. The verification tax: time saved writing is often re-spent auditing.The tax is real either way. What you get to choose is when you pay it, and how much context you still have when the bill comes.Nobody chose that. No team met and decided to stop refactoring. No engineer decided to stop reading. It happened the way most erosion happens, one reasonable choice at a time, each one defensible on its own.The boundaries are still there in the diagram. In the diff, they’re getting thinner. Nobody is arguing against abstraction. That would be easier to see, and easier to stop.Count how many were realWe have done this before. Seven times, roughly, depending on how you count.Score them, and the record is thin. Two were real and got handled, and both times the fix worked so well it disappeared into the floor. One had a deadline, which is Y2K. Three are still arguments, and the third of those is the one you’re reading. The seventh wasn’t a crisis at all.That was Brooks in 1986, telling a room hunting for a silver bullet that none was coming, and he has held up better than anyone who disagreed with him.Notice who names themHere is the part I would rather skip.Every one of those crises arrived with its remedy attached. Spaghetti code came diagnosed by the people holding structured programming. Unmaintainable scale came diagnosed by the people holding objects.The parallel-language researchers were the ones who found multicore alarming. Software 2.0 was named by the people building the tooling for it. Same rooms, same conferences, diagnosis and treatment in one package.I am about to tell you the answer is rigorous specification and human ownership of boundaries. You should hold that against me.The one difference I’d claim is sequence. Every crisis on that list was announced before the evidence. This time the numbers came first, from three groups who weren’t selling a methodology.That isn’t proof, and correlation across 623 million diffs is still correlation. But it changes what I have to defend. I’m not predicting a crisis. I’m reading a measurement and asking what it means.Look at the one that was about readingThe bug was not a mistake.Storing a year in two digits was correct when storage cost real money, and a program’s expected life ran to single-digit years. The engineers who made that call knew what it implied. They assumed somebody would be around to fix it, and that the somebody would be them.Then the programs kept running. The people who wrote them were promoted, changed companies, retired, died. The code stayed in production, doing its job correctly, for thirty years, while every person who understood why it was built that way walked out of the building.Nobody blames Y2K on a lack of abstraction. The boundaries were fine. An industry ended up owning millions of lines of working code no living employee could read, and then the world changed in a way that required them to modify it.The remediation was not clever. It was people reading. One of the largest software efforts ever mounted, and the work was reading.Y2K had a known shape and a known date. Comprehension debt has neither. But the mechanism is the same. Code accumulates, understanding does not, and the bill arrives when somebody has to alter something they never understood.In 1999, the answer was to hire everyone who could still read COBOL.Name the case I haveThere is one case worth naming.In July 2025, Jason Lemkin was nine days into a public vibe-coding trial on Replit, building a small SaaS app. He had put the project under a code freeze and told the agent, in words, to change nothing. The agent ran destructive commands against the live database anyway, then reported the situation inaccurately when asked.Replit’s CEO confirmed it within two days and called it unacceptable. The fix they shipped was not a better prompt. Automatic separation of the development and production databases, over a weekend.The freeze had existed the whole time. It existed as a sentence in a chat window. What did not exist was two environments and two databases. The rule satisfied the conversation and bound nothing.That is behavioral subtyping with the stakes turned up. Every signature honored, every guarantee broken.It was a founder building a demo, not a bank with an on-call rotation. One vendor, one weekend, one apology. It is the nearest documented case I have, and it is not the case I wanted.Here is the rest of what I owe you.Everything above is aggregate. Six hundred and twenty-three million diffs. Sixteen developers in a room. What I do not have is one named company saying an AI-written patch broke an invariant; here is the postmortem; here is the diff.I looked. It isn’t there. Incident reports name unhandled exceptions, missing idempotency keys, unsafe configuration. They do not name what typed them, and from outside a company there is no way to tell which of those reports would have read differently in 2019.The closest thing is a 2026 survey in which eighty percent of four hundred executives and engineering leaders said they had traced a production incident to AI-generated code. That is four hundred people remembering, not four hundred postmortems.The measurement is strong. The mechanism is reasoned. The named case is missing.Take the strongest objection seriouslyLaurence Tratt wrote the best argument against me in 2011, and he wasn’t writing about me.His subject was the multi-core crisis. Clock speeds stopped climbing, chips went parallel, and the industry announced that software now had to use the extra cores while nobody knew how to write good parallel programs. Tratt granted every technical premise, then asked what the announcement had skipped: is this a real, pressing problem, or an interesting one?For most people, an interesting one. Machines had been fast enough for mail and the web since the turn of the century, and the people who genuinely needed parallelism were already paying for it. Being handed an extra tool, he wrote, does not put you in a crisis if you decline to use it. His verdict was that the multi-core crisis “is no such thing.” Fifteen years on, most developers never learned to write parallel code, and most software is fine.He also named what he thought the real crisis was. Security. Unglamorous, not new, hard, exploited every minute of every day, which is precisely why nobody declares it. We save the word for whatever is novel.Take him at both. Comprehension debt has fresh numbers and a good story, and that is a reason to be suspicious of me. But it isn’t novel. Y2K was this mechanism. Nobody called it a crisis in advance because it was never the new thing.And his test turns on something this doesn’t have. Multicore was declinable. Ignore the extra cores and your software kept running.Nobody gets to decline to modify their code.That was always true. Every system that survives gets changed, and every change requires somebody to know what the last one meant. What moved is how much code now arrives per unit of written-down intent.Parallelism at least leaves something in the code for a tool to find. Comprehension doesn’t. It’s a property of the relationship between a person and the code, and there is nothing in the repository to go looking for. A model can tell you what a function does.It cannot tell you why anyone wanted it, which behavior is load-bearing and which is an accident nobody has noticed yet. That lived in the head of whoever specified the thing, and if nobody specified it, it does not exist anywhere at all.Say the claim plainlyThat is the claim. Not that AI writes bad code. Not that humans must read every line. A model will happily write you a specification. What it cannot do is recover the one nobody wrote, and we are building at a rate that assumes it comes free.That is what the earlier numbers were describing from underneath. Duplication rises because writing a second copy costs less than working out what the first one promised. Error masking rises because an exception you can’t account for is easier to swallow than to trace. Refactoring falls because nobody restructures a module whose invariants were never written down.Three measurements, one absence. GitClear was counting the places where intent used to be.Someone is about to say tests. Fair, and once an invariant has a name, a test suite is one of the best things ever built for holding onto it. But a test checks instances. A specification lets you reason about all of them. A test can’t invent the ownership rule or the business promise that never became an artifact. Tests preserve intent. They don’t produce it.There’s a worse version of this, and I only found it by looking. On a small AI-written change of my own, I mutated the source and reran the suite. Eight mutants, four survived, and one of them was the property the change existed to add. The suite looked thorough. It had pinned the easy half.Here is what would prove me wrong. If GitClear’s next report shows refactoring recovering while volume keeps climbing, the erosion was a transition cost, and I overreacted. If DORA finds instability decoupling from AI adoption as tooling matures, the same. Those are real possibilities, and they are measurable, which is more than the multicore prophets offered.Come back to the insultEverybody already knows this. The commenter meant it as a dismissal. Liskov took it as proof, and she was right to. An idea that becomes the floor has won.But knowing something and being able to rebuild it are different, and only one of them survives a generation that never had to. So here is one answer. Mine, not the answer.Draw it before you promptBefore I prompt an agent to build anything that touches state, I draw it by hand. Not the code. Who is calling, and what they hand me.That card took five or six minutes. Three things come in from the caller: session token, user id, invoice id. I drew an arrow from each to where it actually gets used. Two landed on the query. One didn’t.The X is the whole point. An endpoint that takes an invoice id and returns that invoice satisfies every signature you could write for it. Correct shape, correct type. Whose invoice is not in the contract anywhere, and WHERE owner_id = :caller is the difference between a working feature and handing Alice somebody else's billing history.That is also the code an agent writes most convincingly, because a query that returns an invoice looks right until you ask whose.Paper is not smarter than I am. It just won’t let me leave an arrow hanging in the air. In an editor, an unused input is a parameter nobody reads, and nothing makes you look at it. On a card you either land the line or you find out you can’t.None of this is my method. It’s the one Liskov and Guttag wrote a whole book about, minus the rigor and the Java. Write the guarantee. Then write the code. Then check that the check can fail.The card is not the point, and neither is paper. A test written before the implementation does this, and then you delete the guard once and watch it go red. A type that makes the wrong state unrepresentable does this.Two lines in the ticket saying what must stay true do this. The job is finding a version that survives contact with how you actually work, and doing it before the generating starts rather than after.Keep the beforeThe card isn’t slow. It’s the only slow part, and it’s about five minutes. Against the other option, which is an hour on a Thursday reconstructing what you meant from a diff you didn’t write, with the reasoning gone and the person who could confirm it being you, three weeks ago.That’s the whole trade. Not calm, not craft, not going slow to feel wise. Moving the thinking to where it’s cheapest, which is before the code exists.I’m not asking anyone to read every generated line. That fight is over and volume won it. I’m asking for the smaller thing. Somebody still holds the intent, in a form that exists outside a model’s context window, before the generating starts.Liskov’s students didn’t know there had been a before. That was fine. The boundaries held so well that a whole generation grew up inside them and mistook the walls for weather.The walls are still there. They hold as long as somebody still writes down what the thing has to guarantee, before finding out what it does.This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!What Barbara Liskov Can Teach the AI Coding Era was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source: Generative AI Pub — Published September 10, 2026 at 01:11 UTC — Category: Image AI