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. More like — the patterns we're treating as breakthroughs have been here before. The world just wasn't ready for them. And if you don't know the history, you end up reinventing things badly.
He gave three examples that I can't stop thinking about.
#Vector search was called something else
The thing everyone's excited about right now — vector search, semantic similarity, embeddings — is conceptually what Latent Semantic Indexing was doing in 1988. Researchers at Bell Labs figured out that if you decompose a term-document matrix using singular value decomposition, you can find documents that are conceptually similar even when they don't share any words. You search for "car" and get results about "automobile" because the math captures the relationship.
That was almost 40 years ago. The technique was called LSI, then LSA. Search engines experimented with it through the 90s. It worked — kind of. The computing power wasn't there to do it at scale, the dimensionality reduction was lossy, and keyword matching was good enough for most use cases.
Now we have transformers generating dense embeddings in 768 dimensions, GPUs that can do nearest-neighbor search across millions of vectors in milliseconds, and databases built specifically for this. The math is different, but the insight is identical: meaning lives in the relationships between words, not in the words themselves.
If you're building with vector search today and you've never read about LSI, you're missing context that would sharpen your intuitions. The failure modes rhyme. Semantic similarity breaks down when documents are short, when domains are narrow, when the corpus is small — same problems, 1993 and 2026. We just have more compute to brute-force past them.
#Your badge knew where you were in 1992
Jim described a system where your employee badge tracked your location in the building. When someone called your desk and you weren't there, the system would figure out where you were and ring the nearest phone. You'd walk down the hallway and the phone in the closest cubicle would ring.
This was the Active Badge system, built at Olivetti Research in Cambridge around 1992. Infrared signals, room sensors, a centralized service that tracked everyone's location. Applications on top: automatic call routing, finding colleagues, meeting coordination. The New York Times covered it with the headline "Orwellian Dream Come True."
That's basically what we're building now with AI agents. Context-aware systems that know where you are, what you're doing, and can route information to you accordingly. My AI assistant checks my calendar, reads my messages, decides what needs my attention — it's the Active Badge with better sensors and a language model instead of a PBX.
The infrastructure changed completely. The pattern didn't change at all.
#New engineers don't know about TDD
This one hit different. Jim mentioned that a lot of new engineers he works with have never written a unit test. Not "don't prefer TDD" — have never done it. They've gone straight from bootcamp to AI-assisted development, and the AI writes code that works without the discipline of writing the test first.
Kent Beck "rediscovered" TDD in the late 90s — his word, because the concept goes back to a 1957 programming textbook that described writing expected outputs before writing code. Write the test. Watch it fail. Write the code. Watch it pass. Refactor. The test is the constraint.
And now we have engineers who've never felt that loop. The AI produces code that passes CI because the AI also wrote the tests. The human never experienced the discipline of defining "done" before starting.
The testing discipline isn't dead, though — it's shapeshifting. Even before AI, the classic test pyramid was cracking. Kent C. Dodds proposed the "testing trophy" — shifting weight toward integration tests. Spotify's team pushed further with a diamond shape: integration-heavy, thin on both ends. The common insight: unit tests often just confirm the developer's own assumptions. The valuable tests check boundaries — where your system meets reality. AI makes this obvious. When the model writes both the code and the unit tests, it's the same brain checking its own homework. The tests that still catch real bugs are integration, contract, adversarial — does this actually work when it hits production? Does it handle the edge case the training data never saw? The discipline moves up the stack. Less "did I write the function correctly." More "did I specify the right constraints."
Which connects to something I keep coming back to. An axiom is just a test for your judgment — a constraint you write before the work starts, so you can tell whether the output matches your intentions. TDD is constraint-first engineering. Axioms are constraint-first product thinking. The red-green-refactor loop might be evolving into something like prompt-critique-verify-iterate, but the core pattern is the same: define what "right" looks like before you start building, or you'll only discover what's wrong after it ships.
#The system that forgot about git
A few weeks after that conversation, I watched it happen in real time.
Our CEO built an AI agent orchestration system — a shared context layer to manage how AI coding agents understand the codebase and how the team shares ideas in a way that AI can see them too. Specification documents, evolution histories, architectural decisions, procedures. All in markdown. The instinct was right: we need a place where human thinking and machine context overlap. A shared surface.
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 paste it into a Slack thread. You diff it in a PR. It's inspectable in a way that databases aren't — SQLite is more capable, but you need a client, or you need to know SQL, or you're trusting whatever abstraction sits on top. For a semi-technical leader trying to build a thinking layer for the 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, pasted into the file the agent has to read every time it does work. The agent doesn't care about the history — it cares about 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 the current state. Git already does this. Git has diffs, blame, bisect, branches, tags. It's been refined for decades by millions of developers.
The indexing hit the same wall. Dozens of markdown files that needed to reference each other — which spec covers the dashboard, which rules define the data quality tiers, which procedure handles deployments. Instead of a database, the system relied on naming conventions and manual cross-references. Rename something, and the references break silently. B-trees have been the standard indexing solution since the 70s. SQLite is free and functionally indestructible. But the system rebuilt search from scratch using flat files.
Here's the thing, though: the job was right. "Give the team a shared context layer that AI can participate in" — that's a real problem that nobody has cleanly solved yet. The prototype hit the exact limitations that prior art would have predicted, which is what prototypes are supposed to do. It showed 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 a database. Not because the CEO was wrong to try markdown. Because the prototype had done its job, and now someone with deeper technical history could see which parts to keep and which parts 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, the version annotations that nobody reads but every agent has to process — that's kipple. The system designed to manage agent context became the thing clogging agent context. And nobody felt it, because agents don't complain about messy files the way humans complain about messy codebases. The weight was invisible until someone with enough history walked in and said I've seen this before.
Fred Brooks called the deeper pattern in 1986. No Silver Bullet: "there is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity." The system was built on the belief that if you just give the agent enough markdown context, it can leap from spec to working code. There's an old meme — "How to Draw an Owl." 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 all the work lives. But creative work has never been linear. You don't go from spec to implementation in one pass. You iterate. You discover the problem while solving it. The spec can't contain the work because the work changes the spec.
And there's a deeper reason the owl can't draw itself. I've watched this play out. You describe something to an AI and it says "great idea" — but it says that about everything outside its training data, because unfamiliar and innovative look the same from inside the model. It can't tell you whether your idea is genuinely new or just something nobody was foolish enough to try before. That distinction still lives in the person who's been in the problem space long enough to know the difference. Nobody has ever one-shot an idea into production-grade code. Not a human, not an AI, not a team of either. The gap between "I know what I want" and "it works at scale in production" is filled with iteration — failed deploys, edge cases, load testing, user feedback that contradicts your assumptions. That's not a limitation of AI. That's a property of building things. The AI can draw the owl once you've defined what kind of owl you're drawing. It can't tell you whether the owl is the right bird. And even once you've picked the bird, you're going to redraw it forty times before it ships.
#The ways you get this wrong
Jim's examples and the context layer story are the same problem from different angles.
There's a kind of builder who moves fast and doesn't know the history. They see a real problem — "the team needs to share context with AI" — and reach for the most accessible tool. They build something that works, then grows, then buckles under its own weight. They don't know about git blame or B-trees or SQLite, not because they're careless, but because they've never needed those tools before. They're solving the problem with what they have. Sometimes what they have isn't enough. But the problem they saw was real.
Silicon Valley has a name for this energy when it comes with conviction: first-principles thinking. "I'm not going to assume the existing solution is right — I'm going to reason from the ground up." This is powerful when it works. SpaceX rethought rocket economics from physics and cut launch costs by an order of magnitude. But first-principles thinking has a failure mode: it skips the reading. Real first-principles reasoning starts with understanding what exists and then asks "does it have to be this way?" The version that skips step one isn't first principles — it's just not doing the homework. And the result looks like the fast builder but with more conviction: reinventing git in markdown, on purpose, because you reasoned your way there from scratch.
Then there's the builder who knows all the history and carries it 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 exactly until it becomes "we can't do that" — until old constraints get treated as current ones. They can tell you everything that broke last time. They can't always see that the road changed.
The worst outcome is when these two aren't in the room together. The first builder prototypes something, it doesn't work, and everyone concludes the idea was bad — when really the implementation was bad. A bad prototype can kill a good idea. "We tried a shared AI context layer and it didn't work" might mean you tried it in flat files without indexing. The idea was fine. The prototype drew the wrong conclusion. And the experienced engineer who says "told you so" just buried a valid job under an invalid test.
That's what almost happened with our system. If the veteran had just written a critique and walked away, the whole project could have died. The CEO would have heard "this doesn't work" when the real message was "this works, but these specific parts need different tools." The job — shared context for humans and AI — 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" is a job. It 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. The anchor holds.
When you lead with the solution — "we're building a markdown-based agent orchestration system" — then failure is total. The idea and the implementation were fused from the start. There's nothing to come back to.
The hierarchy is something like:
The job survives everything. What are we actually trying to do?
The constraints survive implementation changes. What does "done right" look like? This is where the experienced builder earns their keep — not as a gatekeeper, but as someone who can tell you "the idea is good, the indexing isn't." That's the skill. Knowing which failures are real and which are artifacts of a first draft.
The prototype is disposable. Does this approach work for this job? It might not. That's fine. The job is still there tomorrow.
The person who sees the job keeps the team oriented. The person who knows the history keeps the prototypes honest. When those two are in conversation, you get something better than either could build alone — prototypes that fail productively, each one revealing which constraints matter and which tools already exist to handle them.
When they're not in conversation, you get 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 is faster than hand-written TDD cycles. Nobody's arguing we should go back.
But if you're building semantic search without understanding why LSI struggled with short documents, you'll rediscover that problem the hard way. If you're building context-aware AI without studying why location-aware systems raised privacy concerns in 1992, you'll be surprised when users push back. If you're shipping AI-generated code without the TDD discipline of defining constraints first, you'll build things that work and are wrong. And if you're building an agent orchestration system in markdown without knowing that git, SQL, and B-trees already solved your problems — you'll spend a lot of time maintaining fragile cross-references that a SELECT statement would have handled.
The danger isn't AI making us lazy. It's AI making us ahistorical. Every tool we skip learning, every pattern we don't internalize because the model handles it — that's a failure mode we won't recognize when it shows up wearing new clothes. And it will show up. It always does.
There's a flip side to this, and I want to be honest about it: AI can also accelerate historical learning if you use it deliberately. Ask a model "what's the prior art for this approach" or "compare this to similar systems from the 90s" and you'll get a starting point that would have taken hours of library research a decade ago. The tool that makes us ahistorical can also make us better historians — if we think to ask. The risk is in shallow use. The risk is in never asking. Kipple drives out nonkipple. The universe trends toward it. You can fight it locally — with the right constraints, the right history, the right people in the room — but you have to know you're fighting it. You have to know what it looked like last time.
The experienced builder knows what broke last time. The naive builder knows what's possible this time. The job to be done is the thing that keeps both of them honest. Everything new is old — and old constraints aren't always current constraints — and the gap between those two truths is where the interesting work lives.
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.