Three Decades of Building Software

Mike Merchant has spent his career building software. A self-taught programmer from age 12, he studied computer science at Cal Poly Pomona and worked on enterprise systems at Southern California Edison and Kaiser Permanente before founding Codazen in 2007. Over nearly two decades leading Codazen, he and his teams delivered enterprise applications and global-scale websites; working through every dominant model of software delivery along the way, from Waterfall to Agile to scaled Agile inside large enterprises.

When the Old Models Started to Break

For years these processes worked, but the established approaches were built around fixed primitives that govern scope without being opinionated about workflow or quality. There was never a clear, shared standard for what made an epic or a story good. As AI coding agents matured, the cracks widened: teams could suddenly move far faster, but tools and the planning primitives beneath them were never designed for durable scope or memory; the persistent context that lets both people and agents do their best work.

The Watershed Moment

By December 2025, something fundamental had shifted. AI agents had become capable of writing production code faster than any human team — which meant execution was no longer the bottleneck. What remained was everything upstream: the clarity of the destination, the coherence of the capability definitions, the preserved reasoning behind decisions. These were always the harder problems. AI had just made them the only ones that mattered.

Legacy delivery frameworks had never been designed to address them. Epics and stories were built to manage scope, not to give agents — or the people working alongside them — the context they need to build the right thing. Without that, agents could generate code quickly, but had no reliable way to know whether they were solving the actual problem. This is the shift behind AI-native software delivery: when AI coding agents execute, the scarce resource is no longer engineering capacity but structured intent.

Merchant saw this clearly and decided to design for it directly. Starting from a blank slate, unconstrained by inherited terminology or ceremony, he set out to define primitives that give both people and agents what they actually need: a clear destination, durable capability definitions, and structured context that survives handoffs. The result was a new set of building blocks — Codas, Beats, Beat Versions, Revisions, and the structured Notes that preserve the reasoning behind them — each designed to answer a question that existing frameworks left open.

From a Tool to a Methodology

The ideas first took shape as a tool, later named Harmonica. As the Codazen team used it to build software, including the tool itself, a methodology surfaced from the practice. They extracted and named it Harmonic Composition, using the tool to refine the method and the method to improve the tool — a virtuous cycle in which the system helped build itself.

The Coda Connection

The musical naming runs through everything here. Harmonic Methods treats software delivery the way music treats sound, as many independent parts brought into a coherent whole, then performed reliably, again and again.

The name Codazen shares that root. A coda is the passage that brings a piece of music to its resolution, taking all that came before and carrying it to an intentional close. It is a fitting word at the heart of a methodology built to bring work to a clear and reliable point of completion.

Harmonic Methods Today

Harmonic Composition is one of three frameworks under Harmonic Methods. Alongside it sit Harmonic Orchestration — coordinating human and AI agents to execute against shared context — and Harmonic Portfolio Management, mapping and arranging capabilities across the wider landscape. Together they form a connected approach to building software where intent is explicit, context is preserved, and teams plus agents stay aligned.