Commune

The ancient Ship of Theseus poses a deceptively simple question. If every plank in a ship is eventually replaced, does it remain the same ship? Software teams encounter a practical version of this question every day. Databases are replaced. Frameworks are upgraded. Services are rewritten. Entire platforms are rebuilt piece by piece. At some point, every part of the implementation may have changed. Philosophers may debate identity. Engineers have a different concern: how do we know the system still behaves as expected? Subscribe now Preventing drift Much of software engineering is the management of change. New features are added. Frameworks are upgraded. Databases are replaced. Monolithic applications are decomposed into services. Entire platforms are rewritten. Through all of these transitions, one concern remains constant: preventing behavior drift while supporting internal modernization. Users rarely care whether an application runs on a monolith or a collection of microservices. They care whether it still does what they expect. A familiar challenge For much of my career, I have worked on systems undergoing exactly these kinds of changes. During the industry’s shift from monolithic applications to distributed service architectures, a significant part of the work involved confirming that externally visible behavior remained stable while the implementation underneath was transformed. To address this problem, teams often built custom validation tools. Some were simple scripts. Others evolved into more sophisticated test harnesses. Their purpose was always the same: capture expected interface behavior and verify that the new implementation continued to honor it. Today, AI-assisted development has changed the scale of this challenge. A team can regenerate substantial portions of an application in hours. Entire subsystems can be refactored, reorganized, or reimplemented with a handful of prompts. In some environments, generated code may change every day. Variability is increasing As implementation variability increases, so does the risk of unintended behavioral change. That makes durable descriptions of expected behavior increasingly important. Consider statements such as: A task can be created. A completed task cannot be completed again. Archived tasks do not appear in active task lists. Invalid requests return meaningful error responses. These statements describe observable outcomes rather than implementation details. They remain meaningful regardless of programming language, framework, deployment model, or architectural style. They describe behavior. More importantly, they describe intent. What remains stable For decades, source code served as one of the primary artifacts of trust in software systems. We reviewed implementations, inspected architectures, and examined changes to understand whether a system continued to behave as intended. Generated software changes that relationship. Multiple implementations can satisfy the same requirements. A feature may be regenerated several times while preserving the same externally visible results. The source code remains important, but it no longer provides the same durable assurance it once did. The implementation may evolve faster than humans can realistically inspect it. Trust increasingly depends on something more stable than the implementation itself. Observable behavior survives implementation change more effectively than source code. Formalizing the practice Over the years I spent helping people with their IT transformations, I found myself accumulating a collection of tools, scripts, and testing approaches designed to capture and verify behavior across changing implementations. Eventually, maintaining those techniques as isolated solutions became less practical. When the need to confirm behavioral stability surfaced yet again recently, I decided to consolidate years of custom validation tools into a single framework. TRAM emerged from that effort. TRAM models observable API behavior as executable assertions that produce evidence. Instead of focusing on how a system is built, it focuses on what an observer should be able to verify at the interface. In TRAM, each assertion becomes a small experiment that produces evidence about how the interface behaves. And these same assertions can be applied to both the pre- and post-transform versions of the system. The implementation may change, but the behavior should not. The goal is to gather evidence that expected behavior has not drifted as the implementation evolves. That perspective becomes increasingly valuable in an environment where software can be regenerated faster than humans can realistically inspect every line of code. Managing change As implementation variability continues to increase, the ability to capture, document, and verify expected behavior becomes more important. Durable behavioral assertions provide a stable reference point. They preserve intent across rewrites, migrations, upgrades, and generated implementations. We learned the value of this approach during earlier waves of modernization. The age of generated software makes it harder to ignore. And relying on behavioral assertions may turn out to become one of the primary ways we establish trust at scale in AI-generated systems. Subscribe now

Jun 9, 2026

In a previous life, I was a full-time musician and composer. I spent time every day in practice. Practicing my instrument. Sharpening my ear for harmonies and melodies. Honing my ability to convert what was in my head into notes on a page that others could interpret and perform. Those years taught me something that feels increasingly important in the age of generative AI: repetition matters. Subscribe now I practiced scales not because they were musically interesting, but because of the skills they developed. At the time, scales felt annoyingly simple. Repetitive. Mechanical. Detached from any “real” creativity I was trying to achieve. But over time, that changed. My fingers stopped fumbling. My ear began hearing relationships automatically. Harmonies seemed to create themselves. My musical ideas moved more fluidly from imagination into sound. The practice was reshaping how I thought about sound and rhythm. It increased my ability to articulate what was in my head. I gained new capabilities. The Struggle Is the Craft Often, while practicing, I ran into roadblocks. A difficult melodic turn. A harmonic progression I could hear internally but could not yet execute cleanly. A passage that exposed the gap between what I wanted to express and what I was currently capable of performing. But those moments did not discourage me. They motivated me. Practice taught me not to fear mistakes. It taught me to seek out the edge of my ability; that boundary between facility and struggle where growth actually happens. Over time, I began to understand that the struggle itself was not separate from the craft. The struggle was the craft. That same feeling followed me into software development. Long debugging sessions. Architectural dead ends. Systems that resisted easy answers. And I experience it now while writing; pushing through incomplete ideas, awkward drafts, and concepts that refuse to settle cleanly on the page. In each case, the important work happens when I reach the edge of my abilities. I discovered that creative struggle is evidence that I am stretching, growing, learning. The Cost of Speed Most of the public discussion around AI today centers on speed and efficiency; the ability to increase output without increasing the size of your team. What often goes unspoken is how that efficiency is achieved. In many cases, it comes from removing creative struggle. Staying well within the comfort zone. Avoiding the difficult edge where existing skills are not quite enough. Reducing the need to wrestle with ambiguity, failure, revision, and persistence. But that difficulty boundary is precisely where growth traditionally occurs. That is where musicians develop technique. Where programmers sharpen judgment. Where writers learn clarity. Where architects learn restraint. Where expertise forms. Much of today’s generative AI workflow is designed to export difficulty. The LLM tools flatten out the uncertainty, hide the iteration, the rough drafting, the dead ends, and the partial failures that humans work through themselves in order to gain mastery. Without practice, dexterity wanes. The immediate result is, as so often noted, increased productivity. The long-term risk is reduced capability, atrophied creativity, and weakened skills. Because when difficulty disappears, practice disappears with it. And when practice disappears, so does much of the mechanism through which people improve their skills, sharpen their thinking, and develop durable expertise. Without practice, dexterity wanes. Careful What You Wish For If we are not careful, we could end up creating environments, at work and at home, where people gradually lose their tolerance for creative struggle. Where we assume that valuable work should never feel difficult. That uncertainty is a defect. That friction should always be removed. A world where we get used to giving up early because the system is always ready to complete the thought for us. But that boundary line, the one between competence and challenge, is where growth has always occurred. Instead of building systems that remove struggle, we should be building tools that support growth, demand engagement, and encourage people to remain active participants in the work. We need tools that push us beyond our current capabilities. We do not need more systems that have already looked up all the answers. We need tools that push us beyond our current capabilities. Tools that help us sharpen judgment, extend creativity, and strengthen persistence. Tools that keep us practicing our scales, exploring the harmonies and melodies of everyday life while learning to orchestrate our own future. We need systems where difficulty is not feared, but embraced. We need tools that help us practice. That’s an AI future I can get excited about. Subscribe now

Jun 1, 20261 likes

In a future where digital data passes through society as easily as blood through the body, a small groups of devotees isolate themselves in dim, soundproof rooms. There, away from the endless flow of generated output, they engage in a long-lost meditative art. The practitioners claim the practice sharpens perception, transports devotees to new lands, and occasionally yields moments of unusual clarity. But it requires persistence, discipline, and sustained attention, qualities increasingly rare in the digital age. The almost monastic order preserves the practice carefully, even as the broader culture dismisses them as rude, reclusive, even reactionary. What is this rebellious act? They read books. Subscribe now

May 25, 2026

Two recent statements, one from Nature Reviews Bioengineering and another from the Modern Language Association, arrive at the same conclusion from different directions: Writing is part of thinking and assessing writing is part of teaching. The Nature editorial makes the cognitive case. Writing forces structure onto ideas. It turns scattered research into a narrative, and in doing so, reveals what the work actually means. If that’s true, then outsourcing writing of scientific works to an LLM is not just a productivity play. It is also a shift that threatens to weaken academic work. Subscribe now The MLA statement makes the institutional case. Assessment is a human act of communication. It depends on context, judgment, and experience. Automating it risks hollowing out the role of the educator and redefining learning as something that can be measured mechanically, without being understood. Both land in the same place. While AI can assist, it should not replace. This lines up with an emerging broader pattern as institutions deal with the rise of generative AI. The real risk is not just hallucination or misplaced confidence. It is the steady removal of the steps where people develop skill. Things like drafting, struggling, revising, interpreting, etc. The parts that feel slow, that provide friction, are often the parts where the most important work is done. This is where an AI coaching model, like the one I’ve been exploring, fits in. When used properly, AI can support the creative thinking and writing process: prompting reflection, offering alternatives, helping organize ideas, etc. Used poorly, generative AI short-circuits that creative struggle process and delivers a shallow answer without the thinking that is needed behind it. Generative AI tools can be used to, as Doug Engelbart said, help people “get better and getting better.” Academia, at least in these cases, is leaning into that approach. That’s a good sign. Subscribe now

May 18, 2026