Difficulty: Intermediate Time Investment: 1-2 hours Prerequisites: Experience with modern development workflows
The workflow for engineers is being extended:
Understanding this new way of working provides insight into:
Vibe Coding (coined by Andrej Karpathy):
Vibe Engineering (the speaker’s distinction):
The difference: Vibe Coding is casual experimentation. Vibe Engineering is a professional discipline.
With vibe engineering, the development bottleneck* fundamentally changes:
Old bottleneck: Writing implementation code (80% of time) New bottleneck: Providing clear context and maintaining architectural judgment (60% of time)
This shift has profound implications for team structure, skill requirements, and how we measure productivity.
As AI code generation velocity increases, a critical gap emerges:
┌─────────────────────────────────────┐
│ AI Code Generation Velocity │ ← Exponentially increasing
│ (300-1000+ lines/hour) │
├─────────────────────────────────────┤
│ │
│ ← COMPREHENSION GAP → │ ← Growing over time
│ │
├─────────────────────────────────────┤
│ Human Comprehension Capacity │ ← Relatively constant
│ (~50-200 lines/hour) │
└─────────────────────────────────────┘
The problem: Engineers can generate 300-1000+ lines of AI code in an hour, but can only deeply comprehend 50-200 lines in that same time. Velocity exceeds understanding capacity.
Definition: Accepting AI-generated code without critical analysis because it “looks right” and passes tests.
Symptoms:
Real-world example:
Engineer: "Add rate limiting to the API"
AI: [generates 200 lines with redis, sliding window, token bucket]
Engineer: "Looks good!" → Merge
3 months later: Memory leak discovered
Root cause: No one understood the token bucket implementation
The danger: As AI handles the “how,” engineers lose the “why.”
Impact:
Ensure vibe engineering doesn’t become “vibe guessing.”
The Problem: LMs are “not mind readers.” Without context, they generate generic slop.
The Solution: Provide rich context through:
.cursorrules): Project conventions, architecture decisionsExample .cursorrules:
# Project Conventions
- Always use TypeScript (no JS)
- Follow feature-based folder structure: /features/[feature-name]
- Use Tailwind for styling, no CSS modules
- API calls go through /lib/api wrapper
- All forms use React Hook Form + Zod validation
# Architecture Decisions
- Authentication: NextAuth.js with JWT
- State management: Zustand (no Redux)
- Database: Prisma + PostgreSQL
Impact: With good context, AI is more likely to generate code that fits your project instead of generic examples.
Definition: The ability to judge when code is “clean enough” for the agent to continue, rather than striving for perfection. The trade-off:
When “good enough” fails: When you let the AI continue building on fundamentally flawed architecture.
Architect’s role: Define minimum acceptable quality standards.
Traditional wisdom: “Don’t abstract until you have 3 examples” (avoid premature abstraction)
With LLMs: You can delay abstraction indefinitely because LLMs don’t care about repetitive code.
Example:
// Traditionally, you'd abstract this after 3 similar components
<UserCard name="Alice" email="alice@example.com" />
<UserCard name="Bob" email="bob@example.com" />
<UserCard name="Charlie" email="charlie@example.com" />
// With AI, you can have 20 similar components
// Then ask AI: "Abstract these 20 components into a reusable pattern"
Benefit: You see the actual usage pattern before creating abstraction (better API design).
Caveat: You still need to abstract eventually (for maintainability).
What it does: AI-powered code editor with “Composer” feature for multi-file edits
Why it matters: Developer stays in the “driver’s seat”
Comparison to other tools: | Tool | Control Level | Use Case | |——|—————|———-| | GitHub Copilot | Autocomplete | Line-by-line suggestions | | Cursor Composer | Architect-driven | Multi-file refactors, features | | Devin, GPT Engineer | Fully autonomous | Entire projects (less control) |
Architect’s takeaway: Cursor-style tools give you control while keeping velocity high.
What it does: Speak requirements out loud; AI translates to code
Why it’s powerful:
Example Workflow:
[Voice]: "Hey, I'm seeing a bug where the modal doesn't close when you click outside of it.
I think it's because we're not handling the onClickOutside event in the Dialog component.
Can you fix that and also make sure it still closes when you hit Escape?"
[AI]: Generates fix across 2 files (Dialog.tsx, useOnClickOutside hook)
When to use:
PITA: “Pain in the Ass” (speaker’s humorous term)
Profile:
The irony: If a PITA developer adopts Vibe Engineering, they become 10x more productive.
Why: Their attention to detail becomes auditing AI output instead of writing boilerplate.
Takeaway: Resistance to AI tools might lead to missed opportunities to amplify our strengths.”
Observation: AI will replace junior/intern tasks first.
Why: Juniors can’t yet distinguish “good enough” code from “wrong” code.
Implication: Juniors need more mentorship, not less, when using AI tools.
Prediction: A new market for “Vibe Code Fixers”—senior engineers hired to finish the “last 20%” of AI-generated projects.
Analogy: Like “Cobol Cowboys” maintaining old systems, future engineers will maintain AI-generated codebases.
Our role: As ever; design systems today that won’t become “legacy spaghetti” tomorrow.
Problem: Model capabilities change often when you look across all vendors (Claude → Gemini → GPT updates).
Solution: Follow developer communities (Twitter/X, Discord, Reddit) to know which model is “currently smartest.”
Example: “GPT-4 was best for coding last month, but Gemini 2.0 is better this month.”
Implication: Tool selection is now a continuous evaluation process, not a one-time decision.
Setup: Use Cursor or Claude Code with voice input enabled
Task: Explain a UI bug out loud instead of writing a ticket
Observe:
Setup: Ask AI to generate a React component
Workflow:
Observe: Which approach ships faster? Which produces better architecture?
Setup: Same task, two scenarios
Scenario A: No .cursorrules file
Prompt: "Build a login form"
Scenario B: With .cursorrules
Rules:
- Use React Hook Form + Zod
- Tailwind styling
- Error messages below inputs (not toast)
- Submit button disabled while validating
Observe: How different are the outputs? How much manual fixing is needed?
Problem: AI generates inconsistent UI components Solution: Start with a design system (Shadcn, Radix) so AI has “good primitives” to work with
Problem: Merge AI code without review → bugs in production Solution: Treat AI code like junior developer code (review structure, test edge cases)
Problem: Juniors can’t tell “good enough” from “wrong” Solution: Pair programming (junior + AI + senior oversight)
Problem: Constant model switching → inconsistent coding style Solution: Pick a model, use it for a project, switch only when clearly beneficial
Vibe Engineering is real. Senior engineers are already 10x-ing productivity with AI tools.
What you can do to get better outcomes:
The shift: From “writing all the code” to “writing the critical paths, providing context, and auditing code.”
Start: Pick one tool (Cursor or Claude Code), set up a .cursorrules file, try voice-to-code for a few days. Measure: How much faster did you ship?