AI-native Engineering Pipeline: Verifiable Intent, Auditable Artifacts, Humans Hold Merge and Release

AI-native engineering is a system that makes the whole delivery chain intent-verifiable, artifact-auditable, and still human-gated at merge and release.

Tools can be swapped. The gate order stays stable: write the Spec and executable checks first, then generate code, then run an independent review, and only then let a person approve merge and production. The gap that matters sits in governance and artifacts — whether intent can be checked, whether outputs can be audited, and whether merge and release still sit with people.

The diagram has three bands: upstream intent (Discovery → PRD → Spec + repo rules → Plan), a build-and-verify loop (Coding⇄Test → Security → CR∥CI → Preview), and a human-gated release lane (Merge → Release → Ops → Incident). Change Ops (CO) — the human checkpoints — runs across the whole chain.

This is a public practice note for teams to compare against their own process. A Chinese edition is available for domestic reuse. It sits next to the July note AI Native Workflow: that piece splits human and AI responsibilities; this one pins gates, artifacts, and checkpoints onto the chain from Discovery through Ops.

End-to-end order

Discovery → PRD → Spec + repo rules → Plan → Coding⇄Test → Security → CR∥CI → Preview → Merge → Release → Ops → Incident / write-back, with CO throughout.

Coding and Test usually interleave: write a thin slice, run the matching tests, then fix what failed. Code review (CR) and continuous integration (CI) usually run in parallel: someone reads the diff while the pipeline runs build, tests, and scans. Discovery, evals, and Incident can appear by scene and shrink to a sidebar when space is tight. Keep “verify before generate” in that order.

Stages, artifacts, and common mechanisms

The tools in the table are examples. Editors, Agents, and CI brands can change. After the swap, artifacts still have to be verifiable and checkpoints still have to be auditable.

Overview: redesign the process around Agents

GitLab’s AI-Native Engineering Playbook lays out the path: find the bottleneck that actually slows delivery, change the process, split human and Agent work, make the repo and context usable by Agents, verify the artifacts, then keep the permissions and evidence.

Uvik’s What Does AI-Native Mean? puts the gap in governance and artifacts. Moving attention to intent, constraints, and review is more stable than chasing a new model. Thoughtworks’ Claude Code Radar flags two habits: stay skeptical of AI-written code, and turn context engineering plus shared instructions into repo assets.

Redesigning the process around Agents still leaves the merge button with people. Agents widen the execution surface; people own direction, constraints, acceptance, merge, and release.

PRD: write intent so an Agent does not have to guess

Standalone “AI PRD” templates are scarce in public writing. The usual move is a short vision — goal, users, success criteria — then a verifiable Spec. Addy Osmani’s How to Write a Good Spec for AI Agents and GitHub Spec Kit both take that path.

Tickets should be complete enough that an Agent does not have to guess: who the user is, what “done” looks like, which constraints cannot break, which files may change. Uvik frames this as writing the work so an Agent can pick it up.

If the product itself is GenAI, attach evals alongside it. Emerging Patterns in Building GenAI Products by Fowler and colleagues is about building AI products. When you are writing business code, treat those evals as a side harness for answer quality; the Spec and test contract below still accept the change.

Spec and repo rules: the thickest evidence

Treat the Spec as a contract. Razorpay’s Spec-first lists the minimum fields: goal, files touched, steps, executable checks, Done. Augment’s Spec-Driven Development adds six elements: expected outcome, in-scope and out-of-scope, constraints, decided calls, task breakdown, and how you will verify.

Osmani splits repo-level rules into six blocks — Commands, Testing, Structure, Style, Git, Boundaries — and asks teams to write Always / Ask first / Never. AGENTS.md, Cursor rules, and Claude instructions all land here. Specific rules are easier for an Agent to follow; slogan-like rules get ignored.

Spec Kit gates the work as Constitution → Specify → Clarify → Plan → Tasks → Implement. GitLab’s Human Checkpoints places the main stop at plan and intent. Pin “what we will do, what we will leave alone, and how we will accept it” before coding, so later generation has a contract to match.

Coding, Test, Security, CR

Keep Plan read-only at first: let the Agent list files touched, risks, and verification commands; open write access after a person confirms. Keep coding to small diffs, limit writable files, and forbid an Agent from merging to production on its own. Osmani, Razorpay, Uvik, and Cursor’s Reviewing and testing all point at that same set of constraints.

Separate the generate role from the verify role. In one session, “write it, then declare it passed” tends to go easy on itself. Augment and Google SRE on AI in operations both recommend splitting the side that produces from the side that accepts, so the evidence can stand.

Tests are the contract. Run the full unit suite, typecheck, and lint; add contract tests or E2E on the critical path. GitHub’s Review AI-generated code calls out a specific failure: Agents deleting tests, loosening assertions, or skipping failing cases to turn the suite green.

Park Security between Coding and CR, then let CI catch what remains. Check at least three things: dependencies that actually exist (watch for hallucinated packages), secrets that stayed out of the repo, and permissions that stay inside the allowlist. A hallucinated package is a dependency name the model invented; once it lands in the manifest, a poisoned registry becomes a live risk.

Move mechanical CR items into lint, types, and scanners so people spend time on behavior, permissions, and data compatibility. Run a second session or a second model for an independent review, and read the diff against the acceptance checks and test evidence. GitLab’s Verify what agents produce and CircleCI’s AI-driven SDLC both see the bottleneck move to review once generation speeds up. When review lags, unreviewed risk only stacks faster.

CI, Preview, Merge, Release

Deterministic gates stay authoritative. The CD Foundation’s Engineering Trust in AI-Native CI/CD is blunt: build, test, and secret-scan results cannot be overwritten by model output. An Agent can explain a failure and propose a patch; the green light still comes from the pipeline.

Preview can be the half-step before merge: auto-deploy a clickable environment so product and reviewers see real behavior, not only a diff. Merge and release still take a human click. CircleCI reminds teams that the verification loop has to keep up with generation speed. Slow verify plus fast generate fills the queue with PRs that look mergeable and have not been fully read.

Ops, Incident, and CO across the chain

Operations can borrow Google SRE’s transparency, real-time risk, and gradual authorization, plus dry-run, circuit breakers, and a Red Button. Those write-ups come from very large organizations. Smaller teams should treat them as an upper bound: get logs, alerts, and rollback working first, then widen authority by risk. Leave high autonomy as a later, earned state.

After an incident, write the postmortem back into the Spec and repo rules. A postmortem page with unchanged repo rules leaves the next Agent repeating the same failure. The loop closes when the write-back lands.

Change Ops (CO) is the human-checkpoint layer across the chain: pre-set the “stop and ask a person” points by risk, keep the rules in the repo, and retain the Spec → Plan → PR audit trail. GitLab, Uvik, and Spec Kit all treat checkpoints as process assets. Who approved what, against which Spec, on which green CI run — all of that should be recoverable later.

Evidence strength and the speed story

Public material is uneven. Treat that honestly in both writing and rollout:

The “AI makes us faster” story conflicts with itself. Some reports cite about +55% speedup; some expert-user settings cite about −19% slowdown. Use those numbers as a warning: more generated lines do not mean faster delivery. Review, rework, and incident write-back belong in the total. Turning speed into a slogan invites people to skip gates “just this once.”

Related reading

• Chinese edition: AI-native 工程全链路
• AI Native Workflow
• AI Coding project initialization
• AI code review practice
• AI product delivery
• Human-in-the-loop

Sources

1. The AI-Native Engineering Playbook (GitLab)
2. Build human checkpoints into the workflow (GitLab)
3. Verify what agents produce (GitLab)
4. What Does AI-Native Mean? (Uvik, 2026-10-08)
5. How to Write a Good Spec for AI Agents (Addy Osmani / O’Reilly, 2026-02-20)
6. Spec-first / agentic-loop design (Razorpay AI Playbook)
7. Spec-Driven Development Quickstart (GitHub Spec Kit)
8. What Is Spec-Driven Development? (Augment Code)
9. Reviewing and testing code (Cursor)
10. Review AI-generated code (GitHub Copilot Docs)
11. The new AI-driven SDLC (CircleCI, 2025-10-10)
12. Engineering Trust in AI-Native CI/CD (CD Foundation, 2025-09-26)
13. AI in SRE: How Google is Engineering Reliable Operations
14. Claude Code — Thoughtworks Technology Radar
15. Emerging Patterns in Building GenAI Products (Fowler et al., 2025-02)

Closing

AI-native engineering is a verifiable, auditable system that still leaves authority with people. Tools will change. Gate order and human checkpoints belong in the repo rules first, then Agents can widen the execution surface.

讨论

继续讨论这篇笔记

有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。