AI coding assistants generate code fast, but every “accept” is a decision. The 8-criteria Decision Gate framework (Benefit, Necessity, Overhead, Conflict, Performance, Security, Bottleneck, Currency), adapted from Stage-Gate, systematizes these decisions. Security and Conflict are “must-meet” (knockout), others are scored.
| Quick Reference | |
|---|---|
| Origin | Stage-Gate (Robert Cooper, 1980s) |
| Adaptation | Micro-scale decision filter for solo developers |
| Criteria count | 8 (2 knockout + 6 scored) |
| Decision types | Go / Kill / Defer |
| Related concepts | ADR, OpenSpec |
Continuing the series that includes KISS, SoC, and ADR/OpenSpec, I want to cover a concept that is becoming increasingly critical in AI-assisted development: Decision Gate.
The Problem: Speed Without Filters
In February 2025, Andrej Karpathy introduced the term “vibe coding”1: accepting whatever LLMs produce without questioning, not reading the code, not checking diffs. A year later, Karpathy himself declared this approach “passe,” moving to the concept of “agentic engineering”2.
In the meantime, data accumulated:
| Metric | Value | Source |
|---|---|---|
| AI-generated code share | 41% | Qodo, 20253 |
| Major issue increase in AI co-authored code | 1.7x | CodeRabbit, December 20254 |
| Security vulnerability increase in AI co-authored code | 2.74x | CodeRabbit, December 20254 |
| Actual speed change for experienced devs with AI | -19% (slower) | METR, 20255 |
| Developers’ subjective speed perception | +20% (we think we’re faster) | METR, 20255 |
The numbers point to a paradox: AI produces more code, but more code means more quality issues. In corporate environments, natural filters exist: code review, PR approval, tech leads. For solo developers, you are the only filter, and AI’s confidence bias (we think we’re 20% faster) weakens that filter.
There’s also a pipeline problem: in 2024-2025, many organizations cut or froze junior developer hiring. Within 2-4 years, the number of experienced engineers who can answer why code works or breaks will shrink. The human resources to clean up AI-generated technical debt are narrowing.
So, how do we systematize this filter?
Stage-Gate: Origin of the Concept
Phase-Gate (or Stage-Gate) is a project management technique developed by Robert G. Cooper in the 1980s6. The core idea is simple: a project is divided into phases, with a “gate” (decision point) between each phase. At gates, a management committee evaluates the project and renders one of these decisions:
- Go: Proceed to the next phase
- Kill: Stop the project
- Hold: Pause, re-evaluate when conditions change
- Recycle: Go back, rework
Gates are not status reports or information updates. In Cooper’s terms, “gates with teeth”: decision points that prune weak projects and keep the pipeline clean7.
Gate criteria have two layers:
- Must-meet (knockout): If not satisfied, the project is stopped immediately
- Should-meet (scored): Evaluated through scoring, expected characteristics
Decision Gate: Micro-Scale Adaptation
Stage-Gate was designed for corporate product development: phases span months, committees convene at gates, a presiding manager makes decisions. Solo developers or small teams don’t need this, at least not in this form.
However, the core mechanism, criteria-based Go/Kill decisions before each advancement, works regardless of scale. Decision Gate adapts this mechanism to individual decision points:
| Stage-Gate (Cooper) | Decision Gate | |
|---|---|---|
| Scope | Project lifecycle (Idea-to-Launch) | Individual decision point |
| Decision maker | Management committee, steering board | Solo developer |
| Decisions | Go / Kill / Hold / Recycle | Go / Kill / Defer |
| Process | Monthly gate meetings | Seconds-long mental checklist |
| Context | Corporate product development | AI-assisted individual development |
In Decision Gate, “Hold” and “Recycle” merge into a single Defer: put in backlog, re-evaluate when conditions change.
The 8 Criteria
Decision Gate evaluates every technical decision against 8 criteria. The first two are must-meet (knockout): if either is red, the decision is an immediate Kill. The remaining six are should-meet (scored): if the total score falls below threshold, it’s Kill or Defer.
| # | Criterion | Type | Gate Question |
|---|---|---|---|
| 1 | Security | Must-meet | Does it introduce a security risk? |
| 2 | Conflict | Must-meet | Does it conflict with existing patterns? |
| 3 | Benefit | Should-meet | What does it gain for the user/project? |
| 4 | Necessity | Should-meet | Is it actually needed right now? |
| 5 | Overhead | Should-meet | How much maintenance burden does it add? |
| 6 | Performance | Should-meet | What’s the bundle size/latency/runtime impact? |
| 7 | Bottleneck | Should-meet | Does it create a single point of dependency? |
| 8 | Currency | Should-meet | Is the dependency maintained, is the approach current? |
Should-meet criteria use a 1-10 scale: 1-3 low (negative), 4-6 neutral, 7-10 high (positive). The threshold is determined per project and team; as a general starting point, an average above 6/10 means Go, 4-6 means Defer, below 4 means Kill.
Must-Meet (Knockout)
1. Security
Gate question: Does this change introduce a security risk?
Security vulnerabilities are 2.74x more common in AI-generated code4. Missing input validation, auth bypass, secret exposure, XSS, and injection vectors are frequently seen in LLM outputs.
If Security is red, there’s no need to evaluate other criteria. Priority ordering is irrelevant here.
Example: An LLM suggests an API endpoint but includes no rate limiting or input sanitization. Gate result: Kill. Add the security layer first, then re-evaluate.
2. Conflict
Gate question: Does it conflict with existing patterns, conventions, or dependencies?
LLMs can mix patterns from different projects. Suggesting Redux when Zustand is used, producing CommonJS syntax in an ESM project, writing a new helper when a utility already exists: these are direct conflicts.
Example: The project uses a fetch wrapper throughout, but the LLM suggests a code block importing axios. Gate result: Kill. Make it compatible with the existing pattern.
Should-Meet (Scored)
3. Benefit
Gate question: What does this change gain for the user or the project?
LLMs sometimes make “nice to have” suggestions: extra abstractions, unused configs, premature optimization. Benefit in its broad sense: does it improve user experience, reduce maintenance cost, or increase performance?
If the benefit cannot be clearly articulated, that’s a warning sign.
4. Necessity
Gate question: Is this actually needed right now, or is it “nice to have”?
This is the gate form of the YAGNI (You Ain’t Gonna Need It) principle. AI coding assistants tend to expand the scope of problems: you want to add a button, and a theme system appears. The Necessity criterion is the first line of defense against scope creep.
Example: For a one-time data transformation, the LLM suggests a general-purpose transformer class. Gate assessment: Necessity is low, a simple function suffices.
5. Overhead
Gate question: How much complexity and maintenance burden does this change introduce?
Every added dependency, every new abstraction, every configuration has a maintenance cost. LLMs don’t account for this cost; they’re not the ones doing the maintenance.
Overhead assessment: number of new dependencies, abstraction layers created, config/env change requirements, documentation needs.
6. Performance
Gate question: What’s the impact on bundle size, latency, or runtime?
LLMs sometimes suggest importing entire libraries (tree-shaking incompatible), add unnecessary polyfills, or use performance-costly patterns. Especially in frontend and edge environments, every kilobyte matters.
Example: The LLM suggests moment.js (300KB+) for date formatting when Intl.DateTimeFormat is already used in the project. Gate assessment: Performance is red, existing solution suffices.
7. Bottleneck
Gate question: Does this change create a bottleneck or single point of dependency?
Dependency on a single service, a single API key, or a single database connection creates scalability issues. LLM outputs are generally optimized for the “happy path”; error scenarios and scaling are not considered.
Example: The LLM routes all cache operations to a single Redis instance with no connection pool or fallback mechanism. Under traffic spikes, this single point halts the entire system. Gate assessment: Bottleneck is red, add at least a fallback strategy.
8. Currency
Gate question: Is the suggested dependency maintained? Is the API deprecated? Is the approach current?
LLMs have a knowledge cutoff. Cases where the suggested library is no longer maintained, the API is deprecated, or better alternatives have emerged are common. This criterion guards against LLMs’ temporal limitations.
Example: The LLM suggests HTTP calls using the request library (deprecated 2020). Gate result: Currency is red, use fetch or undici.
Decision Matrix
AI presents a suggestion
|
v
[Security check] --Red--> KILL
|
Green
v
[Conflict check] --Red--> KILL
|
Green
v
[6 criteria scored]
Benefit + Necessity + Overhead
+ Performance + Bottleneck + Currency
|
v
Total score >= threshold? --No--> KILL or DEFER
|
Yes
v
GOThe Defer decision differs from Kill: the suggestion may be valuable but the timing is wrong. If Necessity is low but Benefit is high, it goes to the backlog and re-enters the gate when conditions change.
Practical Scenarios
Scenario 1: New State Management Library
The project uses Zustand. An LLM suggests a solution using Jotai for a component.
| Criterion | Assessment | Result |
|---|---|---|
| Security | Neutral | Pass |
| Conflict | Conflicts with existing Zustand patterns | KNOCKOUT |
Gate result: Kill. Re-implement with Zustand.
Scenario 2: “Nice to Have” Feature
Adding a “remember me” checkbox to the auth flow is suggested. Not on the roadmap.
| Criterion | Assessment | Score |
|---|---|---|
| Security | Session duration extension risk, but manageable | Pass |
| Conflict | Compatible with existing auth pattern | Pass |
| Benefit | Improves user experience | 7/10 |
| Necessity | Not on roadmap, no user demand | 3/10 |
| Overhead | Additional complexity to session management | 4/10 |
| Performance | No negative impact | 6/10 |
| Bottleneck | No single point of dependency | 6/10 |
| Currency | Standard pattern, current | 8/10 |
Average score: 5.7/10. Gate result: Defer. Add to backlog, re-evaluate when user demand arises.
Scenario 3: Deprecated Library
The LLM uses the request library for HTTP requests.
| Criterion | Assessment | Score |
|---|---|---|
| Security | Not maintained, known vulnerabilities may exist | Pass (with warning) |
| Conflict | Project uses fetch | KNOCKOUT |
Gate result: Kill. Rewrite with fetch.
Relationship with ADR and OpenSpec
Decision Gate has a complementary relationship with the concepts discussed in the ADR and OpenSpec article. The three together form a complete decision cycle:
| Question | Tool | Timing |
|---|---|---|
| Should we? | Decision Gate | Pre-decision |
| Why did we choose this path? | ADR | Post-decision |
| What will we build, how will we verify? | OpenSpec | Pre-implementation |
flowchart TD
A[AI presents a suggestion] --> B[Decision Gate - 8 criteria]
B -->|Kill| C[Reject]
B -->|Defer| D[Add to backlog]
B -->|Go| E{Decision type?}
E -->|Architectural decision| F[Write ADR - WHY]
E -->|Feature/capability| G[OpenSpec proposal - WHAT]
E -->|Minor change| H[Implement directly]
F --> I[Implementation]
G --> I
H --> IThe Gate is the first filter before ADR/OpenSpec. Answering “what will we build” and “why” matters, but first the question “should we?” must be answered.
Implementation Guide
Incorporating Decision Gate into your daily workflow doesn’t require complex tools. A few practical approaches:
Mental Checklist
Before accepting any AI output, 30 seconds:
- Is there a security issue?
- Does it conflict with existing patterns?
- Is it actually needed?
- What’s the maintenance overhead?
If the first two answers are “yes,” it’s an immediate Kill. The others are debatable.
PR Self-Review Routine
Open PRs even when working solo. Scan diffs with Gate criteria. Instead of AI “accept all,” evaluate commit by commit.
The “Why?” Question
Ask the LLM why it suggested a particular solution. If it can’t defend its reasoning or gives a generic answer, that’s a weak signal.
Weekly Debt Review
Once a week, review the past week’s decisions. Are there decisions that passed the Gate but caused problems? If so, calibrate your criteria.
Conclusion
AI coding assistants are becoming increasingly capable. But capability is not decision-making capacity. LLMs function as suggestion engines; the accept/reject decision still belongs to the developer.
Decision Gate moves this decision from intuition to system. It establishes a balance between speed and quality. It adopts “Accept with Intent” instead of “Accept All.”
Eight criteria let you filter every technical decision in 30 seconds. The Gate doesn’t cut speed; it directs it.
Further Reading
- The Stage-Gate Model: An Overview
- Wikipedia: Phase-gate process
- ADR, OpenSpec and Spec-Driven Development
- Addy Osmani: Code Review in the Age of AI
- Addy Osmani: My LLM Coding Workflow Going Into 2026
- Qodo: State of AI Code Quality 2025
- AI-Powered Codebase Audit: Applying Decision Gate to 6 audit tracks, guardrailed AI-assisted coding approach
Footnotes
- Andrej Karpathy, Vibe Coding, February 2025 ↩
- The New Stack, Vibe Coding is Passe, 2026 ↩
- Qodo, State of AI Code Quality 2025 ↩
- CodeRabbit analysis, 470 open-source GitHub PR review, December 2025. IEEE Spectrum, AI Coding Degrades: Silent Failures Emerge ↩ ↩2 ↩3
- METR, Randomized Controlled Trial on AI coding tools, 2025 ↩ ↩2
- Robert G. Cooper, Stage-Gate Systems: A New Tool for Managing New Products, 1990. The concept was developed in the 1980s, inspired by NASA’s Phased Review Process from the 1960s. ↩
- Robert G. Cooper, Winning at New Products, for the “gates with teeth” concept see Stage-Gate International resources. ↩
- 01 Decision Gate is a micro-scale adaptation of Robert Cooper's Stage-Gate concept for solo developers
- 02 Of the 8 criteria, Security and Conflict are 'must-meet' (knockout); the remaining 6 are scored
- 03 AI co-authored code contains 1.7x more major issues and 2.74x more security vulnerabilities; blind acceptance is dangerous
- 04 Gates don't slow you down, they direct your speed: 'Accept with Intent' instead of 'Accept All'
+ What is Decision Gate?
Decision Gate is an 8-criteria evaluation framework applied at every technical decision point in AI-assisted development. It is adapted from the Stage-Gate concept and systematizes Go/Kill/Defer decisions.
+ What is the difference between Decision Gate and Stage-Gate?
Stage-Gate involves management committee decisions between project phases across a project lifecycle. Decision Gate is a micro-scale filter applied by solo developers at individual decision points.
+ Why does vibe coding need a Decision Gate?
Vibe coding provides speed but lacks quality filters. Research shows AI co-authored code contains 1.7x more major issues and 2.74x more security vulnerabilities.
+ How does Decision Gate relate to ADR and OpenSpec?
Decision Gate answers 'should we?' (pre-decision). ADR documents 'why did we choose this path?' (post-decision). OpenSpec defines 'what will we build?' (pre-implementation). Together, the three form a complete decision cycle.