Vibe to Agentic Engineering Framework

The "Vibe Coding to Agentic Engineering" Framework

This skill teaches the conceptual model behind the presentation. Every slide and section exists to tell a single story: how a developer incrementally moves from unstructured "vibe coding" (Low level) to high-level agentic engineering (High level).

Core Concept

Vibe Coding (Low level) is when a developer uses Claude Code with no structure — no project context, no conventions, no reusable knowledge. Every prompt is a coin flip. Claude might create random endpoints, ignore existing patterns, skip tests, and produce inconsistent code. The codebase drifts toward entropy with every interaction.

Agentic Engineering (High level) is when Claude Code operates as a fully configured engineering system. It knows the project architecture (CLAUDE.md), follows scoped conventions (Rules), loads domain expertise on demand (Skills), delegates to specialized workers (Agents), orchestrates multi-step workflows (Commands), automates lifecycle events (Hooks), and connects to external tools (MCP Servers). Every prompt produces consistent, tested, production-quality code.

The journey between these two extremes is incremental and cumulative. Each best practice builds on the previous ones, and the presentation teaches them in the order a developer should adopt them.

The 4-Level Journey System

The presentation uses a 4-level scoring system instead of a percentage bar:

The journey bar is hidden on slide 1 (title slide) and appears from slide 2 onward. Levels are set via data-level attributes on key transition slides and inherited by subsequent slides until the next level change. A .level-badge is JS-injected on the slide's h1 when the level changes (do not hardcode these in HTML).

The Running Example: TodoApp Monorepo

Every technique is demonstrated on a realistic full-stack project. The presentation shows the transformation from a plain project (vibe coding) to one with full Claude Code configuration (agentic engineering):

Before (Vibe Coding):

todoapp/
├── backend/          # FastAPI (Python)
│   ├── main.py
│   ├── routes/
│   ├── models/
│   └── tests/
└── frontend/         # Next.js (TypeScript)
    ├── components/
    ├── pages/
    └── lib/

After (Agentic Engineering):

todoapp/
├── .claude/                  # Claude Code config
│   ├── agents/               # Custom subagents
│   ├── skills/               # Domain knowledge
│   ├── commands/             # Slash commands
│   ├── hooks/                # Lifecycle scripts
│   ├── rules/                # Modular instructions
│   ├── settings.json         # Team settings
│   └── settings.local.json   # Personal settings
├── backend/
│   └── CLAUDE.md             # Backend instructions
├── frontend/
│   └── CLAUDE.md             # Frontend instructions
├── .mcp.json                 # Managed MCP servers
└── CLAUDE.md                 # Project instructions

Why TodoApp? It's small enough to fit on slides but complex enough to demonstrate real problems: a backend with route patterns and test conventions, a frontend with component hierarchy and design tokens, and a monorepo structure where cross-cutting concerns (like adding a new feature) require coordination between both sides.

The TodoApp makes the vibe-coding problem concrete: without structure, asking Claude to "add a notes feature" produces a random /api/notes endpoint that doesn't follow routes/todos.py patterns, a standalone page with no sidebar navigation, and zero tests. With full agentic setup, the same request produces a route following existing patterns, a page integrated into the sidebar, and tests matching test_todos.py style.

The Journey Arc: Why This Order

The presentation follows a deliberate pedagogical sequence. Each section unlocks a new capability layer:

Part 0: Introduction (Slides 1–4, no weight)

Purpose: Set the stage. Introduce the TodoApp, define vibe coding, and show the destination.

• Title slide establishes the journey metaphor
• Example Project shows the transformation: before/after comparison of TodoApp — plain project structure vs one with full Claude Code configuration (.claude/, CLAUDE.md, .mcp.json, etc.)
• "What is Vibe Coding?" creates the 0% baseline — the pain point
• Journey Map provides a clickable TOC showing the full path ahead

Part 1: Prerequisites (Slides 5–9, no weight)

Purpose: Get Claude Code installed and running. This is purely logistical — no engineering practices yet.

• Installing, authentication, first session, interface overview
• No weight because knowing how to install a tool doesn't improve code quality
• The "first session" IS vibe coding — this is intentional, so the developer experiences the 0% state firsthand

Part 2: Better Prompting (Slides 10–17, Level: Low)

Purpose: The first real improvement. Better inputs produce better outputs, even without any project configuration.

• Good vs Bad Prompts: Specific, scoped prompts vs vague requests. The simplest possible improvement.
• Providing Context: Using @files to give Claude the code it needs. Reduces hallucination immediately.
• Context Window & /compact: Understanding the finite context window prevents degraded responses in long sessions.
• Plan Mode: /plan forces thinking before coding. Prevents wasted effort on wrong approaches.

Why Low level: Prompting is foundational but limited. It improves individual interactions but doesn't create lasting project knowledge. Each session starts from zero.

Part 3: Project Memory (Slides 18–24, Level: Medium)

Purpose: The leap from session-level to project-level knowledge. Claude now remembers across sessions.

• CLAUDE.md & /init: The project's "README for Claude." Establishes architecture, tech stack, and conventions. This is the single most impactful file.
• What to Include: Practical guidance on writing effective CLAUDE.md content (keep under 150 lines, focus on what Claude needs to know).
• Rules: Path-scoped conventions in .claude/rules/. Rules are a multiplier — they apply automatically to every matching file, enforcing consistency without developer effort. A single backend-testing.md rule ensures every test follows the same pattern forever.

Why Medium level: Project memory transforms Claude from a stateless tool into a context-aware collaborator. But knowledge alone doesn't create workflows.

Part 4: Structured Workflows (Slides 25–28, Level: Medium)

Purpose: Systematic approaches that prevent wasted effort and improve execution quality.

• Task Lists: Breaking complex work into trackable steps. Prevents scope drift and ensures completeness.
• Model Selection: Choosing the right model (Opus for architecture, Sonnet for implementation, Haiku for quick tasks) optimizes cost and quality.

Why still Medium level: Workflows are important but relatively simple concepts. They build on Part 3's project memory and use it more systematically. The step up to High comes with domain knowledge.