Specification-First Delivery

The story of Specification-First Delivery

Specification-First Delivery grew out of a pattern I had seen across years of software delivery and could see much more clearly once AI accelerated implementation. A large AI-assisted software project kept exposing the same thing: better code generation could not compensate for professional judgment that never reached the work. My career across different parts of the delivery system gave me a way to recognize that pattern and test a different approach.

From practice to proposal

A delivery problem I kept seeing from different sides.

Seeing delivery from different positions

Over 15 years in financial-services technology, I worked across UI development, software engineering, quantitative engineering, site reliability, architecture, and technical education. The roles were different, but they repeatedly exposed the same delivery system from different positions.

A software change rarely succeeds through implementation skill alone. Intent, domain judgment, architecture, operational knowledge, and acceptance all have to survive the journey into working software. Moving between those responsibilities made me particularly sensitive to what gets lost between them.

AI made the hidden constraint visible

When I began using Codex from its first day of availability, the most interesting change was not simply that code could be produced faster. Implementation stopped hiding so much of the coordination problem.

Questions that engineers had previously absorbed during days or weeks of implementation became visible much earlier. Missing context, unresolved decisions, unclear authority, and weak acceptance logic could become the limiting factors before code generation became one.

A project became the laboratory

On a large software project outside my financial-services work, I initially focused on making AI-assisted development more reliable: better context, clearer instructions, and more explicit specifications.

Each improvement exposed another dependency further upstream. Better prompts still depended on decisions that had never been made. Better specifications still depended on knowledge spread across people and artifacts. Faster implementation still needed explicit authority and credible acceptance. The problem kept expanding beyond implementation.

The question changed

The turning point was realizing that I was asking the wrong question.

The question was no longer, “How should engineers instruct AI?” It became, “How should an organization make its professional judgment usable in software delivery?” Specification-First Delivery grew from that change in question. The framework came later; the pattern came first.

A particular point of view

Why I saw the problem this way.

What looks like career breadth matters here for a specific reason: it lets me follow the same decision across the places where software delivery usually divides responsibility.

Across the delivery stack

I have worked close to implementation, architecture, operations, domain-heavy systems, and technical education. That makes it natural for me to follow a decision across layers instead of treating each handoff as somebody else’s problem.

At the interfaces between specialists

Many of the hardest problems I have worked on sit between disciplines: business and engineering, architecture and implementation, platform teams and users, or experts and the people who need to act on their knowledge. I tend to look for the point where meaning is lost between them.

Through building and teaching

Building tests whether an idea works. Teaching tests whether the reasoning behind it can be transferred. Doing both has made me care not only about whether a system works today, but whether another capable person can understand and continue it tomorrow.

Origin and authorship

Specification-First Delivery was created by Marcus Peck through independent work on AI-assisted software delivery. Its documented public lineage began with Marcus’s Context Engineering publications in July 2025.

The named Specification-First Delivery publication series began in June 2026 and has been further formalized through the Spec-First Hub. It continues to evolve through published research, implementation experience, and comparison with adjacent work.

Related ideas may arise independently in neighboring fields. The authorship claim concerns this specific body of work, its terminology, specification architecture, and documented development lineage. Broad ideas and independently developed work retain their own histories.

From practice to a public framework

A proposal intended to be tested.

Specification-First Delivery is my attempt to turn those observations into a coherent engineering framework that can be examined beyond one project, one organization, or one person.

I am publishing it openly because the ideas should withstand scrutiny from people working in product, engineering, architecture, quality, operations, and research. The framework should continue to change where practice and evidence show that it should.

Its origin, however, remains simple: implementation became easier to delegate, and that made the quality of the knowledge and professional judgment surrounding implementation impossible to ignore.

Marcus Peck

Creator and maintainer of Specification-First Delivery