I did a fireside chat at The Kinn in Venice a while back — an AI Café session called "Stop Coding, Start Thinking," about the shift from writing code to defining constraints. Afterward, standing outside on the sidewalk, I had a conversation with Jim Goodman that stuck with me more than the talk itself. His takeaway from the whole thing was something like: "everything new is old." Not dismissively — the patterns we're treating as breakthroughs have been here before. The world just wasn't ready for them, or the tools weren't.
He gave me three examples: vector search, a badge that tracked you through an office in 1992, and engineers who've never heard of TDD. Each one makes the same point in a different costume, and the point is this: the experienced builder's real skill isn't remembering that something failed before. It's knowing which layer that failure lived on.
A remembered failure can live in the job: "semantic similarity needs enough signal to work with" was true in 1993 and it's true now. Or it can live in the tooling: "vector search needs a massive corpus" was an artifact of 90s compute, not a law of nature. Confuse the two and you get one of two bad outcomes — dismiss a good idea because an old implementation choked on it, or rebuild a bad implementation from scratch because nobody checked whether it had already been tried. That's the mistake this piece is about. The three historical examples are the training data. What happened next, watching a good idea get prototyped badly, then almost thrown out along with the prototype, is the test case.
#Vector search was called something else
The thing everyone's excited about right now — vector search, semantic similarity, embeddings — descends from Latent Semantic Indexing, which researchers at Bellcore started publishing on in 1988. Decompose a term-document matrix with singular value decomposition, and you can surface documents that are conceptually related even when they share no words. Search "car," get results about "automobile," because the math captures the relationship.
It worked, kind of. Compute wasn't there to do it at scale, the dimensionality reduction was lossy, and keyword matching was good enough for most use cases — so it stayed a research curiosity through the 90s.
Modern embeddings aren't LSI with better hardware. LSI squeezes its representation out of whatever local corpus you feed it. A transformer shows up already trained, on hundreds or thousands of dimensions learned from a corpus the size of the internet, which is why a thin corpus still trips it up, just not for LSI's reason. What the two share is the older idea underneath both: meaning lives in the relationships between words, not in the words themselves. That's the thing worth knowing before you ship vector search: its failure modes — short documents, narrow domains, thin corpora — were documented thirty-five years before yours hit the same wall.
#Your badge knew where you were in 1992
Jim described a system where your badge tracked your location in the building. Miss a call at your desk, and the system would ring the nearest phone as you passed it — he remembered walking down a hallway hearing phones ring room to room, someone picking up and saying "that's probably for you."
This was the Active Badge system, built at Olivetti Research Cambridge between 1989 and 1992: infrared signals, room sensors, a service that tracked everyone and routed calls accordingly. Its usefulness inside the building existed right alongside what continuous location tracking implied from outside it — the New York Times ran the headline "Orwellian Dream Come True: A Badge That Pinpoints You," and the system's own designers had already been wrestling with the privacy question before the press caught up to it.
That's what we're building now with AI agents that check your calendar, read your messages, and decide what needs your attention — the Active Badge with better sensors and a language model instead of a PBX. The infrastructure changed completely. The privacy question didn't go anywhere; it just got quieter for a while.
#New engineers don't know about TDD
Jim also works with engineers who've never heard of TDD — not "tried it, didn't like it," but never encountered the concept. Straight from bootcamp to AI-assisted development, where the model writes code that works without anyone writing the test first.
Kent Beck says he "rediscovered" TDD in the late 90s — his word, because the discipline traces to a 1957 programming textbook that described hand-calculating your expected output before the machine ran the program. Write the test. Watch it fail. Write the code. Watch it pass. The test is the constraint you define before you know if you're right.
What's lost when engineers skip that loop isn't the ritual — plenty of senior engineers write tests after the code and still ship fine software. It's the practice of defining "correct" before you've seen the output, which is what makes a test worth anything. AI sharpens this problem rather than creating it: when a model writes the implementation and the tests in the same pass, both inherit the same blind spots, and a human who never independently specified "correct" has no way to notice. The fix is tests specified independently of the implementation — contracts, invariants, adversarial cases, acceptance criteria written before the model ever sees the spec. That part still has to come from someone who did the thinking.
There's a deeper cost underneath that, the kind that doesn't show up for years. Thinking and understanding aren't separate tracks — thinking deposits understanding, and understanding shapes the next round of thinking. The senior engineer who sees a bug on sight is running on compressed cycles from ten thousand prior debugging sessions, not instinct. Skip the cycles, and the compression never happens — reading a model's explanation and nodding along isn't the same as having done the work, no matter how correct the explanation was.
An axiom is a test for judgment the same way a unit test is a test for code — a constraint you write before the work starts, so you can tell whether the output matches your intent. TDD is constraint-first engineering; axioms are constraint-first product thinking. Define what "right" looks like before you build, or you'll only discover what's wrong after it ships.
#When the prototype outgrows the tool
Those three examples kept rattling around in my head. A few weeks later, I watched the same pattern play out in real time.
Our CEO built a shared brain — a living system where the team's thinking becomes queryable: specs, research distillations, roadmaps, project progress, architectural decisions, all in one place both humans and AI agents can pull from. The idea was to replace the default mode of most companies, endless meetings and knowledge trapped in someone's head, with something you could actually ask questions of.
Markdown was the obvious choice for that surface. It's the one format both humans and machines can read without tooling — you open the file, you read it, you grep it, you diff it in a PR. It's inspectable in a way a database isn't unless you already know SQL or trust whatever client sits on top of it. For a semi-technical leader building a thinking layer for a whole team, markdown is the most accessible starting point. That choice made sense.
What happened next is what always happens with prototypes: the system grew past what the tool could hold.
Every change got recorded as a prose changelog entry inside the document itself — not a git commit, not a PR, a paragraph with a version number that the agent has to read every time it does any work. The agent doesn't care about the history; it cares what to do right now. But it has to wade through v1.0, v1.1, v1.2, and every "EXTEND" and "REVISE" annotation to get to current state. Git already solved this — diffs, blame, bisect, branches, tags, decades of refinement.
The indexing hit the same wall. Dozens of markdown files needed to reference each other (which spec covers the dashboard, which rules define the data quality tiers), and the system relied on naming conventions instead of anything structural. Rename a file and every reference to it breaks silently. Move a section and everything pointing at it now points at nothing, and nobody notices, because without an enforced validation step an agent just consumes the broken reference and moves on, degrading its output in ways that trace back to a stale link three documents away. None of this required abandoning markdown — markdown-as-source-of-truth is a legitimate choice. It required stable identifiers, an enforced link-validation step, and a generated index sitting on top of the files, the way any documentation system that scales past a few dozen pages eventually grows one. That's decades-old plumbing. The system rebuilt search from scratch using naming conventions and hope.
The job, though, was right. "Give the team a shared context layer that AI can participate in" is a real problem nobody's cleanly solved yet. The prototype hit exactly the limitations prior art would have predicted, which is what prototypes are supposed to do: they show you where the edges are. The person who reviewed the system, a 25-year veteran who'd shipped consumer software at Apple, Snap, and a dozen other places, could see immediately that the changelogs belonged in git and the indexing belonged in something structural. The CEO wasn't wrong to try markdown — the prototype had done its job, and now someone with deeper technical history could see which parts to keep and which to replace.
The irony is that the system became the problem it was trying to solve. I've written about kipple — Philip K. Dick's word for the entropy of objects, the junk that accumulates when nobody's paying attention. The changelog entries piling up inside each document, the cross-references slowly going stale, that's kipple. The system built to manage agent context became the thing clogging it, and nobody felt the weight, because agents don't complain about messy files the way humans complain about messy codebases — until someone with enough history walks in and says I've seen this before.
Which is exactly what happened. The CEO knew it was a prototype; he'd been saying he wanted a full-time engineer on it precisely because the system was becoming central to how the company organizes its work. The vision was right and new — a shared surface where human thinking and AI context overlap. Nobody's shipping that cleanly yet. It just needed someone who'd seen the failure modes before to say which parts to keep and which to rebuild with sharper tools.
#The owl is where the work lives
Fred Brooks named the deeper pattern in 1986, in No Silver Bullet: "There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity." I've been guilty of a version of the belief he was arguing against — that code is just serialized context, and if you get the context right, the code follows. There's truth in it. Context matters. But the belief drifts toward something more dangerous: that if you give an agent enough markdown, it can leap straight from spec to working code. A colleague referenced the old "how to draw an owl" meme — step one, draw two circles; step two, draw the rest of the owl. That's what a spec-to-implementation leap looks like. The circles are easy. The owl is where the work lives.
Building software isn't a pipeline where context goes in and code comes out — it's a conversation between the spec and the implementation. You climb the mountain from one face, hit a wall, come back down, try the other side. The summit doesn't move, but the route does, and what you learn on the failed attempt changes your understanding of the mountain itself. If someone climbed that exact face before and found a sheer drop, knowing their route saves you a broken leg. History can't replace the climbing. It can tell you which faces have already been tried.
There's a deeper reason the owl can't draw itself. Describe something to a model and it says "great idea" — it says that about everything outside its training data, because unfamiliar and innovative look identical from inside it. It can't tell you whether your idea is new or just something nobody was foolish enough to try before; that distinction still lives in whoever's been in the problem space long enough to know the difference. The gap between "I know what I want" and "it works at scale in production" gets filled with iteration: failed deploys, edge cases, feedback that contradicts your assumptions. That's not a limitation of AI. It's a property of building things. The model can draw the owl once you've told it what kind of owl. It can't tell you if the owl is the right bird — and you're still redrawing it a dozen times before it ships.
#The ways you get this wrong
One builder moves fast without knowing the history — sees a real problem, reaches for the most accessible tool, builds something that works and then buckles under its own weight. Not careless, just never needed heavier tools before. The problem they saw was real; what they reached for wasn't enough.
Silicon Valley has a name for this energy with conviction behind it: first-principles thinking. Real first-principles reasoning treats existing solutions as evidence, not authority: you're free to reject them, but ignoring them outright throws away the record of what reality already pushed back on. The version that skips the evidence isn't first principles, it's pattern-matching on confidence instead of history, and it's a trap that catches smart, confident people more than careless ones, because the conviction feels earned. It looks like the fast builder but more certain: reinventing git in markdown from scratch because you reasoned your way there without checking who'd already walked the path.
Then there's the builder who carries the history like luggage. LSI didn't scale in the 90s, so they're skeptical of embeddings. The Active Badge was creepy in 1992, so they resist context-aware AI. "We tried that" is useful right up until it becomes "we can't do that" — until an old tooling constraint gets mistaken for a permanent one.
The worst outcome is when these two aren't in the same room. The fast builder ships something that fails, and everyone concludes the idea was bad when the implementation was. A bad prototype kills a good idea. That's almost what happened here: if the veteran had written a critique and walked away, the CEO would have heard "this doesn't work" when the real message was "this works — these specific parts need different tools." The job would have gone down with the implementation.
#The job outlives the prototype
The thing that survives all of this, the first-draft failures, the cargo-culted skepticism, the prototypes that hit walls, is the job to be done.
"Help me find the best deal so I know I'm not leaving money on the table" is a job. The first half is a feature request; the second half is the human need. The need persists whether your first implementation uses markdown flat files or a decade of accumulated data infrastructure. The implementation is disposable. The job isn't.
When you lead with the job, a failed prototype doesn't kill the concept — it just means that approach didn't work, try a different one. When you lead with the solution, "we're building a markdown-based agent orchestration system," failure is total, because the idea and the implementation were fused from the start. There's nothing to come back to.
The hierarchy: the job survives everything (what are we trying to do). The constraints survive implementation changes: what does "done right" look like, and is a given constraint tracking the job or just the tooling. The prototype is disposable — it either answers "does this approach work for this job," or it doesn't, and either way the job is still there tomorrow.
That's the layer question from the top of this piece, run backward through an actual example. "The indexing is wrong" turned out to be a tooling-layer critique. "The job needs a shared context layer" turned out to be a job-layer truth. Confuse which layer a failure lives on and you either kill a good idea over a bad prototype, or you defend a bad prototype because the idea underneath it happened to be sound.
The person who sees the job keeps the team oriented. The person who knows the history keeps the prototypes honest. In conversation, they produce something better than either builds alone: prototypes that fail productively, each one revealing which constraints matter and which tools already exist to handle them. Out of conversation, you get one of two failure modes — a system that reinvents decades of prior art because nobody in the room knew it existed, or a critique so thorough it kills the job along with the implementation.
#The thread
Everything new is old. The question is which old.
Vector search is more powerful than LSI, AI agents are more capable than the Active Badge, AI-generated code ships faster than a hand-run TDD cycle. Nobody's arguing for going back. But build semantic search without knowing why LSI struggled with short documents, and you'll rediscover that problem the hard way. Build context-aware AI without knowing why location-tracking raised privacy questions in 1992, and you'll be surprised when users push back. Ship AI-generated code without the TDD discipline of specifying "correct" independently of the implementation, and you'll build things that work and are wrong. Build a context layer in markdown without knowing that stable IDs, link validation, and git already solved your problem, and you'll spend months maintaining cross-references a generated index would have handled for free.
AI doesn't make us lazy so much as ahistorical, and that cuts two different ways that need two different fixes. The engineer who's never heard of LSI is ignorant of the prior art: fixable, hand them the history. The engineer who's heard of LSI and says "yeah, but transformers are different" has already dismissed the history without checking which layer the old failure lived on — harder to fix, because they think they've already accounted for it.
There's a flip side. Ask a model "what's the prior art for this" or "what broke the last three times someone tried this," and you'll get a starting point that used to take an afternoon in a library. But treat the answer as a lead, not a citation, and verify it against a primary source before you build on it — or the tool that was supposed to make you a better historian just handed you a confident, invented one.
The experienced builder knows what broke last time. The naive builder knows what's possible this time. The job to be done is what keeps both of them honest. Everything new is old, and knowing which layer a failure lives on is how you tell an old constraint from a current one — that gap is where the interesting work still is.
Thanks to Jim Goodman for the conversation after the talk that started this. And to the CEO and the veteran engineer whose argument made me realize Jim was talking about next week, not just last decade.