Quevin

Standardize the Gate, Not the Framework

Kevin P. Davison
AI Claude Code Agentic AI Developer Tools Web Development
Standardize the Gate, Not the Framework

GitHub Spec Kit and GitHub Agentic Workflows answer different questions. Spec Kit standardizes what a developer does at a desk, between pressing Enter and pressing Continue: it takes design decisions away from someone whose job is to deliver what was planned. Agentic Workflows removes the desk. Agents run in GitHub Actions, and people stand at the gates where work is accepted or sent back. Of the ten lessons from our Spec Kit pilots, the four worth keeping are gates, and none of them needs Spec Kit to exist.

So the standard should be the gates. Spec Kit is one way to install them on a team that has little process today. A factory is where they scale.

Spec Kit standardizes the person at the keyboard

At the end of October I finished a proposal asking three engineering groups to standardize on Spec Kit: one pinned version, one team model, one workflow for features, bugs and existing codebases. In September I published The Spec Was Never the Goal, which argued that Spec Kit’s place is narrow and getting narrower. The proposal is still a reasonable document. For a team without established process or CI/CD, Spec Kit hands every developer the same sequence of specify, plan, tasks and implement, and the developer’s job shrinks to delivering what the spec says. That is a real improvement over everyone improvising.

It also fails the checklist I published in September. That post told teams adopting Spec Kit anyway to start with the lean preset, add the bug extension, pin a version and decide how specs age. The proposal pins a version and adds the bug extension. It never mentions the lean preset, and its feature workflow runs all nine steps. In September I priced the four optional ones at 9,200 words of prompt on top of the core procedure. I wrote a checklist for limiting the damage and then turned it into a strategy without the part that limits the damage.

My team ran Spec Kit on two codebases: a legacy PHP intranet tool on GitLab and our Drupal platform on GitHub. By my count, six of the ten lessons were costs the framework imposes on itself: a constitution read from one path only, specify init overwriting it on re-run, CLI versions generating different scripts, two pilot repos already drifted to 1.0.4 and a development build of 1.2.6, a GitHub-only command failing on GitLab, and --force to install Copilot next to Claude Code. You could classify these differently and move the count by one or two. It wouldn’t reach zero. This is the migration where half the tickets are about the deploy tool and not the site.

The factory moves the keyboard into Actions

The other model was on stage at GitHub Universe on October 29. Peli de Halleux of GitHub Next opened by describing a summer 2025 trip when his laptop died. With only a phone, he assigned an issue to Copilot, then a second, third and fourth while the first ran. By the time the fourth was queued, the first was back for review: merge it, steer it, or close it because it derailed. “I have a factory in my pocket.”

That habit became GitHub Agentic Workflows, which GitHub made generally available on October 28. A workflow is a markdown file: YAML frontmatter declares the trigger, permissions, tools and engine (Copilot, Claude Code or Codex, among others), and the body states the task in prose. gh aw compile turns it into a .lock.yml that Actions runs. The agent job is read-only and sandboxed by default. Anything it wants to write, such as a pull request or a comment, goes out through declared “safe outputs” in a separate job with scoped permissions. De Halleux says more than half the pull requests in the gh-aw repository now start from agentic workflows, and his test for a process is blunt: if every pull request needs a forensic human intervention, “you don’t trust your process.”

The talk has three speakers. De Halleux covers the factory GitHub built for itself, Tim Mason of Marks & Spencer starts at 9:36 with rolling it out to a company with 5,000 more repositories waiting, and Paul Snider, CTO of Provation (a Fortive company), starts at 21:08 with doing it in healthcare. Watch for the same review loop showing up three times.

Three factories built the same review loop

All three teams arrived at one loop. Reviewer agents read a pull request through separate lenses (tests, security, code quality, documentation). A finisher agent, which two of the teams call the sous chef, applies the feedback. The loop repeats until the reviewers stop objecting, and then a person decides to merge, continue or give up. At Marks & Spencer that handoff is a label, “ready for human review,” and the engineers walk away until it appears.

Mason’s most useful decision was what his workflows don’t do. Building and testing inside the workflows was too hard across their stacks, so they rely on each repository’s existing CI to fail. A “CI doctor” workflow fires on the failure, reads the logs and leaves a diagnosis that the finisher puts ahead of everything else. The agent never decides that the code works; the pipeline does.

Provation’s version is the closest to Spec Kit, and the comparison is the point of this post. An issue goes through triage, requirements, design, planning and test-case agents before any code exists. Each hands its documented context to the next, and a person approves the evidence before Copilot writes code. That is Spec Kit’s specify, plan and tasks sequence, run in the cloud by agents with a human gate at the end, instead of on a laptop by a developer pressing Continue. Snider counted 71 agents, 32 triggered workflows and six entry points “all converging on one governed process.”

The gates I’d defend are the ones a factory runs on

The four pilot lessons that survive any tool change are gates:

  1. Analyze before writing rules. Our first agent rules stated something false about which shared code was live. The code analysis caught it before a spec was written.
  2. One rules file every agent reads. A bug-assessment rule lived only in CLAUDE.md, so Copilot users never saw it. Shared rules belong in AGENTS.md or the constitution.
  3. “Not run” is not “pass.” Every verification report lists each check as PASS, FAIL or NOT RUN, with a reason.
  4. A person reviews every spec, diff, SQL statement and test report before merge.

Add the shape of the bug extension: assess without editing, have a person approve the diagnosis, fix within the assessed scope, then rerun the original reproduction. That’s Spec Kit’s best idea, and it’s a paragraph long.

The factory talks explain why these four are the ones that last. A format is machine-readable when an agent can parse it. It’s machine-checkable when a CI step can fail because of it. A three-value verdict, a pinned version file and a failing pipeline are checkable, and they are exactly what a CI doctor or a reviewer agent can act on at 2 a.m. with nobody watching. Spec Kit’s central artifact, tasks.md, is markdown with checkboxes. An agent reads it, and nothing fails when it’s wrong. A factory can’t run on that.

A small team of reviewers is the scale

What I want from this is throughput that doesn’t depend on someone at a desktop approving each step. The model I’d build toward is a small team whose members act as developer, QA and stakeholder at once, people who know what the business needs and spend their day at the gates: approving a diagnosis, rejecting a spec that misreads the requirement, merging what the loop has already cleaned up. More keyboards don’t produce that scale. A process the reviewers trust enough not to redo the work does. My own version of this, still in progress, routes every request, agent run and test result onto a single pull request.

Snider’s framing is the right one for regulated work. Provation’s software runs in 3,300 hospital systems, and “none of that matters if we don’t have trust and quality.” His team’s line is “everyone likes to cook, no one likes doing the dishes”: automate the toil, keep judgment with people. The gates are where the judgment lives.

The case for Spec Kit anyway

The factory assumes things many teams don’t have. Mason’s CI doctor only works because the repositories already have pipelines that fail when something breaks. Provation turned its factory off after usage-based billing arrived in June, because it couldn’t say what each workflow cost or returned. It came back only after OpenTelemetry traces made cost visible workflow by workflow, and Snider credits that with cutting pipeline cost by 90%. The gh-aw README still says “use it with caution, and at your own risk,” and a security advisory retired several releases. A team without tests, CI or budget instrumentation can’t start there.

Spec Kit runs on a laptop with none of that. My September post allowed a spec “only when a specific person will read it before the code exists,” and three organizations reviewing each other’s changes across time zones is that case exactly. A shared framework is a coordination device: everyone runs the same command and gets the same artifacts. A homegrown version of the same gates is one more internal tool to document and maintain, which is how you end up automating a Rube Goldberg machine. The people reading the proposal need a command to run on Monday.

That case is strong for teams starting from zero. It makes Spec Kit an on-ramp, not the standard.

What I’m changing in the draft

The hierarchy flips. The standard is the gates: one rules file, analysis before rules, assess before fix with the original reproduction, human review of every artifact, and a three-value verdict that CI can read. Spec Kit becomes the on-ramp for teams without CI, installed with the lean preset and pinned. The pin needs an owner who reads release notes: the proposal named v1.2.6 on November 2, v1.3.0 shipped the next day, and that’s 25 releases in the 74 days since 1.0.0.

Every gate gets written so it can move into an agentic workflow later, which is Snider’s advice to “lift your harness” instead of building a second one. The proposal gets an exit test: could a repo remove Spec Kit tomorrow and keep every gate? The success measures drop “100% of repos on the pinned version,” because a yardstick that counts tool usage gets tool usage. They keep first-test verified rates, reports with no unexplained NOT RUN, and the time from a bug’s assessment to its merge.

The developer pressing Continue was never the part worth standardizing. The reviewer at the gate is, because that’s the one role a factory still needs.

Resources

Kevin P. Davison

About the Author

Kevin P. Davison has over 20 years of experience building websites and figuring out how to make large-scale web projects actually work. He writes about technology, AI, leadership lessons learned the hard way, and whatever else catches his attention—travel stories, weekend adventures in the Pacific Northwest like snorkeling in Puget Sound, or the occasional rabbit hole he couldn't resist.

Learn More → LinkedIn →