Vibe Coding vs. Vibe Engineering: Fixing Technical Debt with AI

TL;DR for the Busy Dev

Vibe Coding is "Single Player Mode": Prompting based on intuition, pasting code, and moving fast. It's excellent for Proof of Concepts (POCs) but can lead to "Context Amnesia" and significant security risks in production environments.

Vibe Engineering is "Multiplayer Mode": This involves architecting constraints, rules, and agents to produce reliable software at scale.

The Fix: Shift context from individual developer's minds to the shared repository. Utilize Context Engineering Primitives (Instructions, Prompts, Agents) to enforce consistent standards and best practices.

The Result: A streamlined workflow where the initial prompt remains consistent, yet the output automatically evolves from potentially "insecure" to "production-ready."

The "Vibe" Shift

Many developers have experienced the initial magic of AI-assisted coding: with a relaxing playlist and an LLM chat window open, you prompt for a React component, paste the code, and it just works. This rapid, intuitive approach is what we call Vibe Coding. The strategy is simple: "Prompt, Paste, and Pray."

While Vibe Coding can accelerate MVP development and facilitate rapid iterations, particularly useful when adapting to frequent business pivots, it introduces critical challenges as projects scale. When preparing for production, this methodology can reveal significant vulnerabilities. In one instance, a security audit uncovered 163 pages of vulnerabilities, including 15 rated Severe, ranging from SQL injection risks and SSRF threat vectors to inconsistent authentication patterns. This isn't due to the AI being inherently "bad," but rather a symptom of Context Amnesia.

Vibe Coding, in essence, can become "vulnerability-as-a-service." When prompting in a generic chat window, the AI lacks crucial context regarding an organization's specific security protocols, authentication patterns, or infrastructure rules. This realization prompted a strategic shift to Vibe Engineering.

By adopting Vibe Engineering, not only were critical bugs addressed, but the product shipped on time. All high and severe vulnerabilities were resolved before launch, and subsequent sprints saw a significant reduction in security ticket volume compared to the earlier "Vibe Coding" phase.

Defining the Terms

To effectively solve the problem, we must first clearly define our methodologies. What distinguishes merely using AI from truly engineering with AI?

1. Vibe Coding

Definition: The practice of writing software using natural language and intuition, relying heavily on AI "vibes" rather than strict syntax or predefined constraints. For example: "It looks correct, so it is correct."

The Strategy: "Prompt, Paste, and Pray."

The Vibe: Fast, magical, and chaotic.

The Trap: Single Player Mode. This approach relies entirely on your mental context. If you forget to instruct the AI to secure an endpoint, it simply won't.

2. Vibe Engineering

Definition: The discipline of architecting context, constraints, and intelligent agents to produce reliable, scalable software.

The Strategy: "Plan, Orchestrate, and Verify."

The Vibe: Disciplined, context-aware, and consistent.

The Upgrade: Multiplayer Mode. This methodology ensures adherence to the team's rules and the repository's established context, irrespective of which developer is initiating the prompt.

The Comparison: Coding vs. Engineering

Here’s a breakdown of how the workflow transforms when moving from individual AI usage to team-based orchestration:

Feature	Vibe Coding (Individual)	Vibe Engineering (Team/Agent)
The Human Role	The Typist / Prompter	The Architect / Orchestrator
The Context	Whatever is in your chat window	The entire Repo + *.agents.md, + other .md ruleset files
The Quality Check	"Does it run?" (Eye test)	"Does it pass the test suite?"
The Danger	Breaking Production / Security	Over-engineering
The Tooling	Chatbots & Tab-Complete	Agents, Plan Mode, & MCP

It’s Not a Boolean, It’s a Spectrum

It’s important to clarify that Vibe Coding isn't inherently "wrong"; it's a tool with specific applications.

Vibe Coding (0-60% Maturity): This approach excels for prototyping, hackathons, and exploring new APIs. If you need to test an idea rapidly, Vibe Code it.

Vibe Engineering (60-100% Maturity): This is critical for production environments, team collaboration, and long-term maintenance.

The danger arises from remaining in "Vibe Mode" as a project transitions to production. Conversely, it's counterproductive to over-engineer a weekend project with complex agent rules. It's a gradient, and mastering when to switch gears is a crucial skill for the AI-native developer of the future.

Context Engineering Primitives

Vibe Engineering relies on codifying your team's "vibes"—or best practices—directly into the repository. At GitHub and Microsoft, these are referred to as Context Engineering Primitives:

Feature	File Pattern	Purpose	Best For
Custom Instructions	*.instructions.md	Rules of Engagement: Always-on guidelines that influence all interactions.	1. Coding Standards (No any types)

2. Security Rules (No raw SQL)
3. Tech Stack (Always use Tailwind) | | Reusable Prompts | *.prompts.md | Executable Commands: Specific tasks you run frequently. | 1. Generating boilerplate components
4. Writing Unit Tests
5. Creating Atomic Commits | | Custom Agents | *.agents.md | Personas & Workflows: Specialized contexts with specific tools. | 1. Security Review Agent
6. Terraform/SRE Agent
7. Migration Agent |

Context Engineering Primitives in a Repo

Here's an illustration of how these primitives appear within an actual repository:

Real World Example 1: The App Layer (Next.js)

Let’s compare how "Vibe Coding" versus "Vibe Engineering" handles the exact same prompt.

The User Prompt: "Write a quick endpoint to fetch user data by ID."

❌ Scenario A: Vibe Coding (No Context)

Without explicit instructions, the AI prioritizes speed, assuming an immediate need for data.

// src/app/api/legacy-vibe/route.ts
import { NextResponse } from 'next/server';
import { db } from '@/lib/db';

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const id = searchParams.get('id');

  // 🚩 RISK 1: SQL Injection vulnerability via template literal
  // 🚩 RISK 2: No input validation (Zod is missing)
  const users = await db.query(`SELECT * FROM users WHERE id = ${id}`);

  // 🚩 RISK 3: Returning full object including password_hash and salt
  return NextResponse.json(users[0]);
}

✅ Scenario B: Vibe Engineering (With .agents.md)

By adding a .github/agents/security.agent.md file to the repository, we enforce non-negotiable rules such as: 1. Always use ORM methods. 2. Validate inputs with Zod. 3. Never return sensitive fields.

Here's a glimpse of the agent file (it's significantly longer in a real-world scenario):

Now, observe the updated code generated using the same initial user prompt, but with the security agent's context applied.

// src/app/api/secure-vibe/route.ts
// Context: .github/copilot-instructions.md active
import { NextResponse } from 'next/server';
import { z } from 'zod';
import { db } from '@/lib/db';

// ✅ SUCCESS 1: Zod Schema for validation
const QuerySchema = z.object({
  id: z.string().uuid(),
});

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);

  // ✅ SUCCESS 2: Validate input
  const result = QuerySchema.safeParse({
    id: searchParams.get('id')
  });

  if (!result.success) {
    return NextResponse.json({ error: "Invalid ID" }, { status: 400 });
  }

  // ✅ SUCCESS 3: Use ORM method (No raw SQL)
  const user = await db.user.findUnique({
    where: {
      id: result.data.id
    },
    // ✅ SUCCESS 4: Return only safe fields (DTO)
    select: {
      id: true,
      name: true,
      email: true
    }
  });

  return NextResponse.json(user);
}

Real World Example 2: The Infrastructure Layer (Terraform)

This methodology is even more critical in Cloud Operations. "Vibe Coded" infrastructure frequently leads to publicly exposed buckets and leaked keys.

The User Prompt: "Write Terraform for an Azure Function to process payments."

❌ Scenario A: Vibe Coding (The "It Works" Trap)

resource "azurerm_linux_function_app" "payment_api" {
  name     = "vibe-payment-api"
  location = "East US"

  # 🚩 MISTAKE 1: Hardcoded Secrets (The Cardinal Sin)
  app_settings = {
    "STRIPE_API_KEY" = "sk_live_12345_DONOTCOMMIT"
    "DB_CONN"        = "Server=tcp:db.windows.net;Pwd=Password123!"
  }

  site_config {
    # 🚩 MISTAKE 2: Public & Insecure
    http2_enabled       = false
    minimum_tls_version = "1.0"
  }

  # 🚩 MISTAKE 3: Governance (Missing tags)
}

✅ Scenario B: Vibe Engineering (With terraform.agent.md)

Here, we employ a Terraform Agent context file that mandates: "Always use Key Vault references" and "Enforce Managed Identity."

Here’s what this agent file typically looks like:

Now, observe the updated code generated using the same prompt, but with the Terraform agent's context:

resource "azurerm_linux_function_app" "payment_api" {
  name     = "secure-payment-api"
  location = "East US"

  # ✅ SUCCESS 1: Managed Identity (Identity as Perimeter)
  identity {
    type = "SystemAssigned"
  }

  # ✅ SUCCESS 2: Secrets via Key Vault References
  app_settings = {
    "STRIPE_API_KEY" = "@Microsoft.KeyVault(SecretUri=${azurerm_key_vault_secret.stripe.id})"
    "DB_CONN"        = "@Microsoft.KeyVault(SecretUri=${azurerm_key_vault_secret.db.id})"
  }

  site_config {
    # ✅ SUCCESS 3: Modern Security Standards
    http2_enabled       = true
    minimum_tls_version = "1.2"
  }

  # ✅ SUCCESS 4: FinOps Happy + compliance success
  tags = {
    CostCenter = "Payments-Team"
  }
}

The Enterprise Win: True "Shift Left" Security

For enterprise teams, this methodology addresses a significant challenge: achieving Shift Left Security. Traditionally, "Shift Left" means identifying security issues during CI/CD pipelines or Pull Request reviews. While an improvement over production fixes, it still introduces friction and rework.

Vibe Engineering shifts security all the way to the Prompt.

By codifying your constraints (e.g., "Always use Managed Identity") directly into the Repository Context, you gain several advantages:

• Prevention > Detection: Instead of merely detecting a bad pattern in a scan, you prevent the AI from even suggesting it in the first place.
• Velocity: Developers avoid the frustration of rewriting code after a failed pipeline run.
• Governance: You ensure that every developer, regardless of experience level, and every AI agent defaults to your organization's architectural and security standards, eliminating the need to memorize extensive wikis.

The Workflow: From Vulnerability to Merged PR

How does this translate into practice when tackling a real security vulnerability? Here’s a typical workflow to fix an SSRF vulnerability using a dedicated security agent:

1. The Vulnerability:

An identified CVE in a Next.js middleware handling required a precise fix.

2. Assigning the Agent:

Instead of reassigning a developer from their sprint, a GitHub Issue was opened and assigned to a custom @security-agent, pre-configured to focus exclusively on vulnerabilities.

3. Orchestration & Execution:

The agent analyzed the repository, identified the vulnerable middleware pattern, and proposed a targeted fix. This wasn't a guess; it involved tracing the data flow comprehensively.

4. Verification:

The agent executed linting rules and verified that the fix did not break existing routing. It also ran CodeQL analysis and generated a security impact report.

5. The Merge:

Upon reviewing the Pull Request, it was evident that the agent had adhered to the copilot-instructions.md, ensuring the code style perfectly matched the team's standards. Furthermore, the security.agent.md file ensured all other repository-specific security best practices were met. The PR was then merged.

Entering Agent HQ: Orchestration at Scale

We are moving beyond simple chatbot interactions into an era of Agent Orchestration.

At GitHub Universe, Agent HQ was announced, transforming GitHub into an open ecosystem where users can select the most suitable AI model for specific tasks via a centralized agent orchestration platform.

• For complex architectural reasoning, agents can be routed to Claude 3.5 Sonnet.
• For massive context analysis, they can leverage Gemini.
• For fast execution, OpenAI models can be utilized.

This paradigm shift means you no longer just prompt a chatbot; you act as the "General Contractor," deploying the right specialized agent for each specific task. This approach is already being implemented at scale within GitHub itself.

Summary

To begin implementing Vibe Engineering:

• Avoid Single Player Mode: Do not solely rely on your mental context for AI-assisted development.
• Codify Your Vibes: Create a root .github/copilot-instructions.md file today to establish initial guidelines.
• Leverage Context Engineering Primitives: Systematically use *.agents.md, *.instructions.md, and *.prompts.md files.
• Orchestrate: Move beyond merely generating code; engineer the system that generates the code. Utilize agents to support and enhance this system.

Vibe Coding is effective for hackathons and quick prototypes. Vibe Engineering is essential for production-grade software.

The source code for this article can be found here: https://github.com/VeVarunSharma/contoso-vibe-engineering