Spec-Driven Development vs. Intent-Driven Development: A Cyber Security Engineer’s Guide to Secure AI-Assisted Software Engineering

Why “vibe coding” is creating a security crisis — and why specification rigor is the only viable defense.

Introduction: The New Paradigm and Its Security Shadow

In 2026, software engineering is undergoing its most profound transformation since the advent of the internet. Two methodologies now dominate the AI-assisted development landscape: Spec-Driven Development (SDD) and Intent-Driven Development (IDD) — the latter more commonly known as “vibe coding.” Both leverage Large Language Models (LLMs) to accelerate development, but they diverge sharply in how they manage the relationship between human intent and machine execution.

For Cyber Security Engineers, this divergence is not merely philosophical — it is existential. The data is unambiguous: AI-generated code is functionally impressive but dangerously insecure when unsupervised. Carnegie Mellon’s SusVibes benchmark found that while the best-performing agent solved 61% of tasks functionally, only 10.5% were secure — meaning over 80% of functionally correct solutions contained exploitable vulnerabilities. Meanwhile, Veracode’s longitudinal testing of 100+ LLMs found that 45% of AI-generated code introduces OWASP Top 10 vulnerabilities, with Java applications failing at a staggering 72% rate — a figure that has remained flat across multiple testing cycles despite vendor claims of improvement.

This post is a structured security analysis for practitioners navigating both methodologies. Whether you are implementing SDD with constitutional constraints or auditing vibe-coded applications in production, the following framework will help you identify risks, anticipate challenges, and establish defensible security postures.

SDD Vs IDD, a guide for Security Engineer’s

Part 1: Overview of the Two Methodologies

Spec-Driven Development (SDD)

Spec-Driven Development is a spec-first methodology designed for the AI-native era. Rather than prompting an AI and aligning later, teams define structured specifications upfront — requirements, constraints, acceptance criteria, and edge cases — and use AI to generate code, tests, and artifacts from that shared, durable context.

The core philosophy is simple: specifications declare intent; code realizes it. In strong forms of SDD, humans edit intent while machines handle implementation. The spec becomes the “connective tissue” across the lifecycle, linking business intent to architecture, tests, and validation. This addresses a critical problem in AI-assisted workflows: LLMs are excellent at pattern completion but terrible at guessing unstated requirements. A vague prompt like “add photo sharing” causes the AI to hallucinate file limits, permissions, and security assumptions — many of them wrong. A precise specification eliminates this ambiguity.

A recent advancement in this space is Constitutional Spec-Driven Development, which embeds non-negotiable security principles into the specification layer itself. This approach introduces a “Constitution” — a versioned, machine-readable document encoding security constraints derived from CWE/MITRE Top 25 vulnerabilities and regulatory frameworks. In a banking microservices case study, constitutional constraints reduced security defects by 73% compared to unconstrained AI generation while maintaining developer velocity.

Intent-Driven Development (IDD) / Vibe Coding

Intent-Driven Development is a broader paradigm where the developer’s intent — expressed through natural language, high-level goals, or business objectives — drives the entire development process. The developer describes what they want to achieve, and AI systems figure out how to implement it. This is the essence of “vibe coding,” a term coined by Andrej Karpathy in early 2025, which by 2026 has become Collins Dictionary’s Word of the Year.

The appeal is undeniable: speed. A founder can go from idea to working prototype in hours. Developers complete tasks 55% faster with GitHub Copilot and merge 60% more pull requests per week. McKinsey’s February 2026 study found a 46% reduction in routine coding time across 150 enterprises.

However, this speed comes at a cost. AI code generators optimize for functionality, not security. They produce code that works, but “works” and “works safely” are very different things. The Moltbook breach — where a fully vibe-coded AI social network exposed 1.5 million API keys within three days of launch because the AI-generated code exposed a Supabase API key in client-side JavaScript without enabling Row Level Security — is the clearest example of what happens when security is treated as an afterthought.

Part 2: Security Considerations for Spec-Driven Development

When implementing SDD, Cyber Security Engineers must treat the specification layer as the primary security control surface. The following security aspects require rigorous attention:

Specification Integrity and Tamper Resistance

The specification is the source of truth. If it is compromised, all downstream security guarantees collapse. Engineers must ensure:

• Versioned governance: Specifications must be version-controlled with immutable audit trails, preventing silent modification of security constraints.
• Cryptographic signing: Constitutional constraints and security requirements should be cryptographically signed to prevent tampering during the AI generation pipeline.
• Specification injection attacks: Malicious actors may attempt to inject hidden instructions into specifications (a form of prompt injection at the spec layer). Input validation and sanitization of specification documents are essential.

Constitutional Constraint Enforcement

The constitutional framework must encode non-negotiable security requirements as first-class architectural artifacts. This includes:

• CWE-mapped constraints: Every security principle must map explicitly to Common Weakness Enumeration (CWE) identifiers, with enforcement levels (MUST/SHOULD/MAY) and amendment procedures.
• Compliance traceability: A systematic mapping of constitutional principles to implementation artifacts at file and line-number granularity, enabling automated compliance verification.
• Domain-specific regulations: For regulated industries (finance, healthcare, government), constitutional constraints must incorporate frameworks like PCI-DSS, HIPAA, GDPR, and SOX.

AI Agent Scope and Privilege Limitation

SDD does not eliminate the need to constrain the AI agent itself:

• Least-privilege agent access: The AI agent should operate with the minimum permissions necessary to read specifications and generate code — never with write access to production systems or secrets stores.
• Sandboxed execution: Generated code must be built and tested in isolated environments before any human review.
• Output attestation: Generated artifacts should include cryptographic attestation linking them to the specific specification version and constitutional constraints applied.

Specification-to-Code Verification

The gap between specification and implementation is where vulnerabilities hide:

• Formal verification pipelines: Where feasible, formal methods should verify that generated code adheres to specified security invariants.
• Differential testing: Compare AI-generated implementations against specification requirements to detect deviation or “hallucinated” functionality.
• Security-focused acceptance criteria: Every task in the SDD workflow must include explicit security acceptance criteria (e.g., “All database queries use parameterized statements,” “No secrets are hard-coded”).

Supply Chain and Dependency Governance

SDD agents must not autonomously introduce dependencies:

• Pre-approved dependency lists: The specification should define allowed package registries, version pinning requirements, and vulnerability scanning gates.
• SBOM generation: Every build must generate a Software Bill of Materials (SBOM) for dependency tracking.
• Slopsquatting prevention: AI models hallucinate package names approximately 20% of the time in generated code. Pre-approved lists prevent installation of non-existent or malicious packages.

Part 3: Security Considerations for Intent-Driven Development

Intent-Driven Development presents a fundamentally different security challenge: the specification is implicit, fluid, and often non-existent. For Cyber Security Engineers, this requires a reactive yet systematic approach.

Implicit Specification Reconstruction

In vibe coding, the “specification” exists only in the developer’s natural language prompts and the AI’s interpretation. Security Engineers must:

• Prompt audit trails: Capture and archive all prompts and AI responses for forensic analysis and compliance documentation.
• Intent extraction: Reverse-engineer the implicit security requirements from prompts and generated code, then formalize them into a retroactive specification.
• Assumption mapping: Explicitly document security assumptions the AI may have made (e.g., “AI assumed all users are authenticated,” “AI assumed input is trusted”).

Runtime Security Validation

Because static analysis alone is insufficient for AI-generated code:

• Dynamic Application Security Testing (DAST): Every vibe-coded application must undergo comprehensive DAST before production deployment.
• Behavioral fuzzing: Test AI-generated APIs and endpoints with malformed inputs to detect injection flaws, authentication bypasses, and business logic vulnerabilities.
• Runtime Application Self-Protection (RASP): Deploy RASP agents in production to detect and block exploitation of vulnerabilities that static analysis missed.

Secrets and Credential Management

AI models reproduce patterns from training data, inserting realistic-looking API keys, database passwords, and tokens directly into source files:

• Automated secrets scanning: Implement pre-commit hooks and CI/CD pipeline scanning for hardcoded credentials. Research shows 78% of AI-generated code stores secrets in plaintext or committed .env files.
• Environment isolation: Never allow AI agents to access production secrets or environment variables during code generation.
• Credential rotation protocols: Assume any credential that may have been exposed to an AI model during generation is compromised and must be rotated.

Authentication and Authorization Design

Vibe-coded applications frequently lack proper access controls:

• Mandatory auth review: Every generated authentication flow must be manually reviewed for weak hashing algorithms (e.g., MD5), missing rate limiting, timing side-channels, and session fixation vulnerabilities.
• Zero-trust architecture: Assume generated authentication is broken by default. Implement defense-in-depth with additional network-layer and application-layer controls.
• Privilege escalation detection: Apiiro’s research found that AI-assisted code introduced 322% more privilege escalation paths than human-written code. Automated scanning for overly permissive roles and missing authorization checks is essential.

Shadow IT and Governance

The most dangerous vibe-coded applications are the ones security teams don’t know exist:

• Asset discovery: Implement continuous scanning for unauthorized web applications, APIs, and cloud resources.
• Data loss prevention (DLP): Monitor for sensitive data being fed into AI coding tools or stored in vibe-coded applications.
• Employee training: The 63% of vibe coding users who identify as non-developers need security awareness training tailored to AI-assisted development risks.

Part 4: Current Security Challenges in Both Methodologies

The Functional Correctness vs. Security Paradox

The most alarming finding across both methodologies is that functional success and security success are inversely correlated in AI-assisted development. Preliminary security strategies — adding generic security guidance, self-identifying CWE risks, or providing oracle CWE hints — fail to solve the problem. While they slightly improve security, they cause a significant drop in functional correctness (about 6 percentage points), because the agent focuses more on security checks and less on required functionality.

Get Majid’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This creates a perverse incentive: teams under delivery pressure will prioritize functional correctness, accepting security debt that accumulates faster than organizations can remediate it. Apiiro’s enterprise data shows AI-assisted developers ship code at 3–4x the rate but introduce security findings at 10x the rate.

The Comprehension Gap

As teams rely on AI for implementation, they lose the ability to effectively debug or respond to incidents. A 2026 Pragmatic Engineer survey identified “Builders” — experienced engineers who make architectural changes — as reporting identity loss and grief over no longer doing hands-on coding, because AI generates decent code faster than they can type. This comprehension gap is particularly dangerous in security incidents where minutes matter. If an AI-generated system fails in a novel way, engineers who never deeply understood the code may be unable to fix it under pressure.

The CVE Acceleration

Georgia Tech’s Vibe Security Radar tracked 6 CVEs in January 2026, 15 in February, and 35 in March — a near-sixfold increase in two months directly attributable to AI coding tools. The researchers estimate the true count is 5–10x higher across the broader open-source ecosystem. This trajectory suggests we are only at the beginning of an AI-generated vulnerability surge.

Enterprise-Scale Shadow IT

RedAccess scanned over 380,000 web assets across vibe-coding platforms and identified 5,000 built for corporate purposes. Of those, 40% contained sensitive data deployed without basic security controls — no authentication, no access controls, no audit trail. Cases included a live financial dashboard at one of Latin America’s largest banks and strategic documents from a $200 billion company. This is not the shadow AI problem of employees pasting data into chatbots — this is employees building full applications, connecting them to production systems, and deploying them publicly while IT remains unaware.

Supply Chain Poisoning

The attack surface is bidirectional. AI coding tools themselves are now targets:

• CVE-2025–54135: Affects Cursor — malicious MCP servers can execute arbitrary actions.
• CVE-2025–55284: Affects Claude Code — DNS exfiltration of sensitive data.
• Slopsquatting: Attackers register hallucinated package names as malicious packages before developers install them.

Part 5: Future Challenges Cyber Security Engineers Must Anticipate

The Specification Arms Race

As AI models improve at generating code, they will also improve at generating specifications — creating a recursive loop where AI writes specs for AI to implement. Cyber Security Engineers must anticipate:

• Constitutional AI attacks: Adversaries will craft prompts designed to bypass or subvert constitutional constraints, requiring formal verification of specification integrity.
• Spec poisoning: Training data contamination will extend to specification templates, embedding hidden backdoors in “best practice” SDD templates.
• Cross-specification vulnerabilities: As systems are built from composable specifications, vulnerabilities may emerge at specification boundaries rather than in individual components.

Autonomous Agent Escalation

Current AI agents operate under human supervision. Future agents will:

• Self-modify specifications: Agents that can rewrite their own constraints will require cryptographic proof of authorized modification.
• Collaborate across organizational boundaries: Multi-agent systems spanning multiple companies will introduce novel trust and verification challenges.
• Operate in adversarial environments: Agents will face direct attacks from other AI systems (e.g., AI-driven penetration testing tools probing AI-generated code in real-time).

Regulatory and Compliance Evolution

Governments and standards bodies are catching up:

• OWASP LLM Top 10: Already includes AI-specific risks like prompt injection and insecure output handling.
• EU AI Act implications: High-risk AI systems — including those generating code for critical infrastructure — will face mandatory conformity assessments.
• Insurance and liability: Cyber insurance policies will increasingly exclude claims arising from unreviewed AI-generated code, shifting liability to organizations.

The Human Factor Crisis

As 63% of vibe coding users are non-developers, the security community faces an unprecedented education challenge:

• Security-by-default tooling: AI coding platforms must embed security controls that cannot be disabled by users lacking security knowledge.
• Automated security remediation: The volume of vulnerabilities will exceed human remediation capacity, requiring AI-driven security patching — creating a recursive security dependency.
• Skill bifurcation: The industry will split between engineers who deeply understand security fundamentals and those who merely orchestrate AI tools, with the former commanding premium salaries and the latter creating systemic risk.

Part 6: Recommendations for Best Practices

For Spec-Driven Development: Risk Management, Compliance, and Verification

1. Adopt Constitutional Frameworks: Implement versioned, machine-readable security constitutions with explicit CWE mappings, enforcement levels, and amendment procedures. Treat the constitution as a living security contract.
2. Establish Specification Security Gates: No specification should be considered complete without a dedicated security review section covering authentication, authorization, input validation, output encoding, secrets management, and logging requirements.
3. Implement Compliance Traceability: Build automated pipelines that map every constitutional principle to implementation artifacts at file and line-number granularity. This enables continuous compliance verification, not point-in-time audits.
4. Mandate Differential Security Testing: For every AI-generated implementation, run security tests that specifically validate against the specification’s security constraints — not just functional acceptance criteria.
5. Enforce Dependency Governance: Maintain pre-approved dependency lists with automated SBOM generation and vulnerability scanning. Never allow AI agents to autonomously add packages.

For Intent-Driven Development: Runtime Protection, Governance, and Recovery

1. Assume Vulnerability by Default: Treat every vibe-coded application as potentially compromised until proven otherwise through comprehensive security assessment. The data supports this: 92% of AI-generated codebases contain at least one critical vulnerability.
2. Implement Mandatory Security Review: No AI-generated code should reach production without human security review. Automated scanning catches syntax-level flaws; human review catches architectural and business-logic vulnerabilities.
3. Deploy Runtime Protection: Given the high probability of undetected vulnerabilities, RASP and Web Application Firewalls (WAF) are not optional — they are compensating controls for the limitations of static analysis on AI-generated code.
4. Establish Shadow IT Discovery: Implement continuous asset discovery and DLP monitoring. The applications you don’t know about pose the greatest risk.
5. Create Vibe Code Recovery Protocols: Develop incident response playbooks specifically for AI-generated code breaches. Assume the development team cannot explain how the vulnerable code works and plan remediation accordingly.

Cross-Cutting Practices: Culture, Skills, and Architecture

1. Invest in Security Architecture Skills: As AI handles implementation, human value shifts to system design, threat modeling, and security architecture. Organizations must invest in these high-level skills or risk being unable to validate AI output.
2. Build Security-First AI Toolchains: Integrate SAST, SCA, DAST, and secrets scanning directly into AI coding workflows — not as afterthoughts in CI/CD, but as real-time feedback during generation.
3. Maintain Human Comprehension Mandates: Require that at least one human on every team can fully explain every line of AI-generated code in production. This prevents the comprehension gap from becoming a security gap.
4. Develop AI-Specific Threat Models: Traditional STRIDE and DREAD models need augmentation for AI-specific threats: prompt injection, training data poisoning, model inversion attacks, and agent privilege escalation.
5. Champion Security-by-Construction: The ultimate goal is not to find vulnerabilities after generation, but to prevent them during generation. Constitutional SDD is a step in this direction, but the industry must evolve toward AI systems that are inherently security-aware — not merely security-constrained.

Conclusion: The Specification Is the Security Boundary

The fundamental insight for Cyber Security Engineers in 2026 is this: in a world where AI generates code faster than humans can type, the security boundary has moved upstream — from the code to the specification. Spec-Driven Development offers a disciplined framework for encoding security intent before generation, while Intent-Driven Development demands rigorous post-generation validation and runtime protection.

The data is clear. The breaches are real. The CVE count is accelerating. But the path forward is also clear: organizations that treat specifications as security artifacts, that invest in human expertise for validation and architecture, and that build security into AI workflows rather than bolting it on afterward, will be the ones that thrive in this new paradigm.

The choice is not between SDD and IDD — it is between intentional security and accidental vulnerability. As Cyber Security Engineers, our job is to ensure that every line of AI-generated code, whether born from a constitutional specification or a casual prompt, meets the security standards that protect our users, our organizations, and our profession.