Part 1: Why Building Fast Is Not Enough

By the end of this four-part series, you will know why building fast is not enough in enterprise software, what alignment actually means precisely enough to engineer against, the seven structural properties a system must have to produce the right thing by default, and what we have learned from building enterprise software at 8090 through Software Factory. If even one of those ideas reframes how you think about software delivery, the series will have done its job.

Before joining 8090 I spent months building software with the vibe methodology. Coding agents, prompt, generate, ship. Most of what I built worked. And most of it stopped working the moment requirements shifted even slightly. What felt like productivity was actually fragility. I had generated a lot of code that solved the exact problem I described at the moment I described it, and nothing more. The apps worked. But they were not the right thing. Not the thing a real customer would need if the project grew, if the requirements evolved, if someone other than me had to extend them.

That gap between generation and rightness is where I think most software is being built today, and it is the most expensive gap in technology. What I find genuinely exciting about alignment engineering as a discipline is that this gap is not a mystery. It is structural. It can be named, decomposed, and engineered against. That is what this series is about.

The Definition That Anchors Everything

Alignment is a word people use loosely. It shows up in retrospectives, in planning docs, in vague complaints that "we're not aligned." Almost nobody defines it precisely enough to build around.

The definition that anchors this entire series is this:

Alignment is the convergence of multiple systems, people, documents, and code, onto the same understanding of what should happen and why.

When alignment holds, the customer's intent, the team's interpretation, and the software's execution all point at the same target. When it breaks, they diverge. The distance between them is the cost. Everything else in this series follows from this single idea: what it takes to make convergence structural, what causes it to decay, and what happens when it compounds across projects.

What Alignment Engineering Is Not

Before going further, it is worth being precise about what this discipline is not. Alignment engineering is not documentation discipline. It is not sprint planning. It is not "better kickoffs" or "more alignment meetings." Those are all interventions on the symptoms of misalignment. They may help at the margins, but none of them change the structure of how intent flows from a customer's reality into running code.

Alignment engineering operates on the structure itself. It treats alignment as a property that the system must produce continuously, the way a factory produces output. That is why the word "manufacture" runs through this series. You do not achieve alignment. You manufacture it. Or you do not, and the system decays into misalignment by default.

The Thing Coding Agents Cannot Do

Coding agents like Claude Code and Cursor have quietly become the most capable code generation tools in history. They write working software faster than any team could write it by hand. They understand codebases, follow patterns, scaffold entire applications from short prompts. If your problem is that it takes too long to write code, that problem is effectively solved.

But if your problem is that the code you are writing is solving the wrong thing, coding agents do not help. They make it worse. Speed amplifies whatever is upstream. If your requirements are misaligned, a coding agent produces misaligned code faster. If your blueprint carries invisible assumptions, the agent implements those assumptions at scale.

Coding agents are exceptionally good at building things. They cannot, on their own, determine whether the thing is the right thing. That still requires alignment, and alignment still requires engineering. The bottleneck in software engineering has shifted. It is no longer writing code. It is knowing what code to write, and why.

This is not an argument against coding agents. We use them every day at 8090, and Software Factory is built to feed them better context than they could otherwise get. The point is that the agents solved one problem and left another one untouched. The remaining problem is the one this series is about.

The costliest failure mode in software engineering is not broken code. It is not missed deadlines. It is building the wrong thing.

Where I See This Most Clearly

The clearest example of this pattern in practice came from a healthcare client we took on early in my time at 8090. They needed an AI-enabled workflow optimization application, and we made a deliberate choice for the first project: start with a familiar, mostly single-player approach. One PM on discovery, one engineering lead on the technical plan, coding agents generating the implementation. Not because we thought that was the right way, but because we wanted to see what Software Factory's multiplayer capabilities would reveal against conventional delivery as the baseline.

The first build shipped. It worked. Customers could use it. But it was not yet the right thing. The PM's interpretation of the customer's needs had been compressed into a document no one else had scrutinized. The engineering lead's assumptions had never been surfaced. Customer meetings kept introducing new information, and that information lived in Slack threads and call notes instead of entering the artifacts that were actually driving development. The first build was a version of the right thing. Not the right thing itself.

What changed in the second phase was not effort. It was structure. Software Factory's connected artifact chain made it possible for the customer to scrutinize requirements directly in the Requirements module, for multiple engineers to challenge blueprints in the Blueprints module with full visibility into how every assumption connected to downstream code, and for new information from customer meetings to enter the Knowledge Graph as artifacts rather than dying in Slack. The structure produced scrutiny. The scrutiny produced a product that was the right thing.

The client brought us a second project with completely different business goals but the same regulatory environment. The alignment artifacts from the first project carried forward, and months of delivery compressed into weeks. A third project is now underway with the same compounding effect. This is what a factory actually produces: not code, but alignment that accumulates across projects.

What This Series Covers

So far we have established the problem. Enterprise software, built fast, often builds the wrong thing. Coding agents make this worse. Alignment is the missing discipline, and it has a precise definition worth engineering around.

The next three posts build the discipline up carefully.

In Part 2, we represent alignment precisely. Drawing inspiration from Patrick Henry Winston's representation principle, that a problem well represented is almost solved, we decompose alignment into five layers where it must hold, and three forces that cause it to decay by default.

In Part 3, we describe the seven properties we have found an aligned system must have. Each one maps to a specific capability in Software Factory. Each one is derived from first principles rather than borrowed from existing methodology.

In Part 4, we show what happens when alignment compounds. The healthcare project's second and third engagements, the feedback loops that keep the system honest, the failure modes we have hit, and what we are still learning.

The thread running through all four posts is the same: building fast is not enough. In enterprise software, where the cost of building the wrong thing is measured in quarters of rework and years of customer trust, speed without alignment is the most expensive way to build. The discipline that makes speed safe is alignment engineering. It is worth naming, studying, and building for.

Next: Part 2: What Alignment Actually Is