Tech Stack for NLPg-Driven AI-Assisted SDLC

Key takeaways

• Vibe coding optimizes for local speed. NLPg SDLC optimizes for reliable delivery over time.
• In NLPg, language is the primary artifact and code is an execution artifact.
• The differentiator is not model choice. It is instruction quality, policy gates, and traceability.
• If the method does not reduce ambiguity, defect rate, and rollback frequency, it is still a concept, not a system.

This document defines a staged, method-aligned stack for NLPg-driven AI-assisted SDLC. The goal is to move from “prompt to deploy” toward a repeatable flow: intent, structure, execution, validation, and governed change. If you want the higher-level framing behind this page, start with Dual NLP for AI-assisted SDLC, then return here for the stack design.

Act I: The fundamentals

Why this is not vibe coding

The distinction is not semantic. It changes where engineering control lives.

In NLPg, language is not ad hoc input. It is a structured interface for system behavior. That places language above code in the design pyramid: intent first, implementation second.

Altitude analogy: blueprint vs bricklaying

A useful analogy is construction. Bricklaying speed matters, but a faster crew cannot rescue a bad blueprint.

• Vibe coding treats the request like a sketch on a napkin and optimizes how quickly the wall appears.
• NLPg treats the request as a blueprint with load assumptions, safety constraints, and inspection checkpoints.

Another analogy is air traffic control.

• The pilot is execution.
• Air traffic control is governance.
• Weather radar is validation.
• The flight plan is the instruction spec.

Without the plan and checkpoints, takeoff is fast and arrival is uncertain. This is also why Prompting Is Not the Skill You Think It Is matters: prompting is only useful when it feeds a repeatable runtime instead of acting as a one-off trick.

The NLPg SDLC loop

1. Intent
2. Instruction spec
3. Compilation
4. Execution
5. Validation
6. Approval
7. Delivery
8. Telemetry back into learning

Most software failures begin before code: ambiguity, hidden assumptions, and unstated constraints. NLPg reduces this by forcing intent into machine-interpretable structure before any file is changed.

Instruction spec as contract

The minimum contract for safe execution is explicit and versionable.

objective: Add role-based access control for dashboard
inputs:
  - routes
  - api_handlers
constraints:
  - do_not_modify_billing_routes
  - preserve_existing_session_model
acceptance_criteria:
  - unauthorized_users_receive_403
  - role_persisted_in_users_table
risk:
  category: auth-change
  level: high
approval_gates:
  - before_db_migration
  - before_middleware_deploy
rollback:
  - revert_migration
  - revert_middleware

Act II: The modern paradigm

Staged rollout plan

You can stage this method from documentation to runtime without overbuilding early.

Stack layers, method-aligned

The familiar execution stack still matters. It moves down the hierarchy while language and policy move up.

Workflow diagram: intent to governed delivery

Mindmap: NLPg system surface

Act III: Principles in practice

Governance primitives

To keep NLPg operational, four primitives are non-negotiable.

1. Instruction schema: objective, inputs, constraints, acceptance criteria, risk, rollback.
2. Prompt compiler: natural language to structured execution plan.
3. Execution ledger: what changed, why, risk score, approvals, validation outcomes.
4. Validation harness: lint, schema validation, tests, static risk checks before merge.

This is where many teams stall. They add an agent runtime before they define policy grammar. The result is automated output without accountable control.

Risk gate matrix

Workflow example A: RBAC (auth risk)

Instruction spec

objective: Add role-based access control for dashboard
scope:
  - dashboard_routes
  - api_route_handlers
roles:
  - admin
  - editor
  - viewer
constraints:
  - do_not_change_billing_routes
  - preserve_session_model
acceptance_criteria:
  - unauthorized_users_receive_403
  - role_stored_in_users_table
risk:
  category: auth-change
  level: high
approval_gates:
  - before_db_migration
  - before_middleware_deploy
rollback:
  - revert_migration
  - revert_middleware

Compiled plan

1. Add role column to users.
2. Add role seed and defaults.
3. Add dashboard middleware gating.
4. Add API authorization checks.
5. Add access-matrix tests.
6. Verify no impact to billing routes.

Gate behavior

The run halts before migration and middleware deploy. The ledger stores risk category, approver identity, and validation traces.

Workflow example B: Stripe billing (billing risk)

Instruction spec

objective: Add subscription billing using Stripe
constraints:
  - no_secrets_committed
  - verify_webhook_signature
acceptance_criteria:
  - subscription_status_stored_in_db
  - premium_routes_gated_by_entitlement
risk:
  category: billing-change
  level: high
approval_gates:
  - before_webhook_deploy
  - before_entitlement_enforcement
rollback:
  - disable_webhook
  - revert_entitlement_middleware

Compiled plan

1. Install Stripe SDK.
2. Create subscriptions table.
3. Implement webhook endpoint with signature verification.
4. Update entitlement state on webhook events.
5. Gate premium routes.
6. Add tests for verification and entitlement checks.

This is the practical break from vibe coding: billing changes are treated as high-risk operations with mandatory controls.

Operating metrics for this method

A method is real only if outcomes move.

Template repo shape

nlpg-sdlc-template/
  docs/
    method/
      01-intent-to-spec.md
      02-spec-schema.md
      03-risk-taxonomy.md
      04-approval-gates.md
      05-ledger-format.md
      06-validation-harness.md
      examples/
        rbac.md
        stripe-billing.md
  nlpg/
    schemas/
      instruction.schema.json
      plan.schema.json
      ledger.schema.json
    policy/
      policy.yaml
    specs/
    plans/
    ledger/
  app/
  supabase/
    migrations/
  .github/
    workflows/
      ci.yaml

Minimal CLI surface

nlpg init
nlpg spec new
nlpg spec validate
nlpg plan
nlpg run
nlpg gate
nlpg ledger view
nlpg pr create

A practical storage model is file-first: specs and plans as YAML, ledger as append-only JSONL.

What this changes in practice

NLPg-assisted SDLC changes your engineering center of gravity. The differentiator is no longer how fast code appears. It is how reliably intent becomes governed, verifiable change.

Treat language as contract, compilation as control, and governance as default. Speed then compounds instead of amplifying risk.

Related resources

• From Prompt to Production: A Human Checklist
• What LLM-Ops Actually Means
• Natural Language Is the New API
• The I-7 Reliability Standard deck
• Everything as Code deck

Proof Block

• 16-minute deep dive on NLPg SDLC architecture
• Core reference for from-prompt-to-production.mdx
• Referenced in tech-stack documentation

FAQ

What is NLPg SDLC?

NLPg (Natural Language Process Governance) SDLC is a language-first software development lifecycle where natural language is the primary artifact and code is an execution artifact. It optimizes for reliable delivery over time rather than local coding speed.

How does NLPg differ from vibe coding?

Vibe coding prioritizes immediate productivity by accepting AI-generated code without systematic validation. NLPg SDLC adds governance layers including intent specification, risk assessment, interface design, validation, monitoring, and human fallback to ensure reliable delivery.

What are the key components of an NLPg tech stack?

The stack includes: intent parsing (converting natural language to structured intent), instruction compilation (transforming intent to executable specifications), execution governance (runtime controls and policy gates), validation layers (output verification), and observability (runtime monitoring and drift detection).