What 25 years across web, software, data, and AI taught me about durability

The latest AI framework promises to change everything, but the hum of a server room from 25 years ago still echoes a fundamental truth: some architectural problems never truly disappear. From Perl scripts processing web forms to Python agents orchestrating complex workflows, the specific tools become almost unrecognizable, yet the underlying challenges of building resilient systems remain constant. I've watched waves of "revolutionary" technology wash over our industry, much of it proving to be just fashion. But beneath the hype, a few ideas consistently proved so foundational they just kept working, decade after decade. These are the patterns that buy you durability, regardless of the stack.

The Great Separation: State vs Logic

The first and most important lesson came from untangling those early web scripts. A single file would often hold HTML markup, business rules, and raw SQL queries, making them impossible to test, debug, or scale. The breakthrough wasn't a new language; it was the discipline of three-tier architecture, where presentation, application logic, and data storage became separate concerns. This pattern has never left us. It's the most reliable way to manage complexity I've ever found, aligning with foundational principles articulated by practitioners like Martin Fowler in his seminal work, *Patterns of Enterprise Application Architecture*. Whether it was Java EE application servers talking to Oracle databases in the 2000s, or stateless microservices in containers accessing managed Postgres in the 2010s, the core idea holds. Today, we see serverless functions (pure logic) reading from and writing to dedicated state stores like S3 or DynamoDB. Even in the new world of AI, this separation is critical. An LLM agent's reasoning capacity is its logic. Its memory, its access to tools, the vector store it queries—that's its state. I've seen early agentic prototypes fail when they try to cram session state into an ever-expanding prompt. The durable solution looks familiar: externalize the state to a reliable store and keep the logic component clean. The names change, the principle holds.

Every Abstraction Leaks, and You Pay the Bill

Every new platform promises to make the hard parts disappear. In the early 2000s, Object-Relational Mappers (ORMs) were going to free us from ever writing SQL again. For a while, it seemed to work. Then you’d hit a performance wall and discover the ORM was generating thousands of tiny, inefficient queries. To fix it, you had to understand SQL after all. The abstraction leaked. They always do. This phenomenon is famously captured in Joel Spolsky's "The Law of Leaky Abstractions," which posits that all non-trivial abstractions, to some degree, are leaky. Kubernetes is an astonishingly powerful abstraction over a fleet of machines. But when the pod networking fails at 3 AM, you can't fix it by editing a YAML file. You have to understand IP tables, DNS, and the CNI plugin. Serverless abstracts away servers until a cold start adds 10 seconds to your API latency, forcing you to understand the container lifecycle you thought you’d escaped. The lesson isn't to avoid abstractions. It's to choose them knowing you will eventually have to pay the "leakage tax." This means understanding, at least one layer down, what your tools are actually doing. For modern AI systems, this means knowing how an embedding is generated, what a context window really is, and why a Retrieval-Augmented Generation (RAG) pipeline can fail. The durable engineer isn't the one who knows the framework's API best; it's the one who knows what to do when the framework's magic fails.

Data Has Gravity, and You Can’t Fight It

For the first half of my career, software was the star. The database was a peripheral, a place to persist the application's state. The big data explosion of the 2010s flipped that script completely. We learned a hard, expensive lesson, often summarized by Dave McCrory's concept of "Data Gravity": compute moves to the data, not the other way around. Trying to pull terabytes of data over the network to a cluster of application servers is a losing battle. The network is too slow, and the cost is too high. This is the simple, physical reality of data gravity. It’s why technologies like Spark, BigQuery, and Snowflake won. They all push the computation logic—the query, the transformation, the model training—into the storage layer where the data already lives. This principle is more relevant now than ever. Retrieval-Augmented Generation (RAG) is the perfect example. We don't stuff a million documents into an LLM's context window. Instead, we use a small query to find the relevant chunks of data (in a vector database, located right next to the embeddings) and bring just that sliver of context to the model. We are moving the compute to the data. Any architecture that tries to fight this will be slower, more expensive, and more brittle than one that embraces it.

The Unchanging Job of the Architect

We're now entering an era of agentic work, where systems are designed to pursue goals with a degree of autonomy. It feels like a radical departure from the deterministic automation we've spent decades perfecting. And it is different. But it doesn't invalidate the old rules. My job as an architect feels surprisingly similar. I'm still asking the same questions: * How do we separate the volatile logic (the LLM's reasoning) from the durable state (the agent's memory and tools)? * What is this agent framework abstracting away, and what will it look like when it leaks? * Where is the center of data gravity? Is it the vector store? The operational database? The model weights themselves? The goalposts have moved, but the playing field is the same. It's a system of trade-offs, failure modes, and physical constraints. The challenge isn't to predict the future, but to build systems based on principles that don't change.

What Endures

The technology will change again next year, and the year after. The specific skills you have today will eventually become obsolete. But the underlying principles of building robust, maintainable systems will not. If you focus on these, you'll be building for the long haul. In another 25 years, our tools will likely be unrecognizable. But I'm willing to bet we'll still be spending our time separating state from logic, peering underneath our favorite abstractions, and designing our systems around data's unyielding center of gravity. The path to durable systems relies on these three unchanging disciplines.