# 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.

## Marcus Peck, CFA, FRM

Creator and maintainer

- **15 years in financial services technology:** Engineering · Architecture · Reliability · Quantitative systems · Technical education
- **CFA:** Chartered Financial Analyst
- **FRM:** Financial Risk Manager

### Previous roles

- Vice President at Bank of America (Vice President, Global Markets Core Solutions. Worked on deal and instrument models, software architecture and code review, and platform and developer enablement. Bank of America is a global investment bank ranked in the top five by fees.)
- SRE & Software Engineer at Citadel (Worked across Equities Data Engineering and Commodities, including research-platform engineering, reliability engineering, CI/CD, runtime environments, and developer support. Citadel has led the all-time ranking for hedge fund net gains since 2022.)

### Selected professional credentials

- MongoDB Lead Certification SME (MongoDB Certification Subject Matter Expert since 2024 and Lead Certification SME since 2025. Writes, reviews, and approves certification exam items, with the Lead SME role responsible for quality review of certification content.)
- Microsoft Certified Trainer
- 25+ active Microsoft certifications (More than 25 active Microsoft certifications across software development, cloud, AI, data, and related technologies, including two Expert-level certifications.)
- Microsoft MVP (2004–2008) (Microsoft MVP for Classic ASP from 2004 to 2008. Marcus first received the award at age 16 and was among the youngest Microsoft MVPs in the Asia-Pacific region at the time.)

[Visit Marcus Peck on LinkedIn](https://www.linkedin.com/in/marcuspeckcuhk/)

From practice to proposal

## A delivery problem I kept seeing from different sides.

### 1. 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.

### 2. 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.

### 3. 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.

### 4. 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.

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