Kitze: Why 'Vibe Engineering' Works and 'Vibe Coding' Doesn't
Why Kitze Distinguishes Vibe Engineering From Vibe Coding
Kitze is the creator of Sizzy (a browser for developers), Zero to Ship, and several other tools. This conference talk distinguishes “vibe coding” (accepting whatever AI outputs) from “vibe engineering” (steering agents with technical knowledge). His thesis: the skeptics in the middle of the skill distribution are wrong, while juniors who love it and seniors who master it are both right—for different reasons.
On the spectrum of adoption: “On one hand you have juniors who are like ‘hell yeah, give me the thing, I love doing my own SaaS.’ Then you have super senior people doing libraries and frameworks. And then you have the majority in the middle like ‘this will never be good enough, my code is perfect.’ It’s hilarious, but it’s a pattern.” The distribution is bimodal: enthusiastic beginners and experienced practitioners, with skeptical mid-levels in between.
On what vibe engineering actually is: “I’m not vibe coding. I love this term someone coined—vibe engineering. When you’re actually using agents to code all the time but you just look at your screen like ‘I’m going to catch you.’ You’re suspicious of the code because it’s based on our knowledge.” The distinction: vibe coders accept blindly, vibe engineers supervise actively.
On Composer One changing everything: “Composer One made me realize I missed coding. What I would do is let a model run like GPT-5 Codex and it would take 37 years. Now I’m back in the driver’s seat. I can be like ‘Stop. No no no. We do the other thing.’ It feels like coding.” The speed of feedback loops matters more than model capability.
On PA devs (pain-in-the-ass developers): “You leave a nitpick comment on a two-line PR. You spend more than 2 minutes on a PR review. The thought of agreeing with a colleague causes stomach pain. You say ‘well actually’ in code comments.” The biggest barrier to AI adoption isn’t capability—it’s perfectionism that was already counterproductive.
On real productivity gains: “I achieved in two weeks more than I achieved in last year. This was solely due to Composer One. I was about to abandon projects… I moved Benji to Next 16 with App Router, TRPC, Monorepo, Turbo Repo, React Native app, and put in 90% of the features—in less than a week.” The speed enables projects that wouldn’t exist otherwise.
6 Insights From Kitze on AI-Assisted Development
- Vibe engineering ≠ vibe coding - Vibe coding is blindly accepting output; vibe engineering is supervising agents with technical knowledge and catching errors in real-time
- Give AI to seniors, not juniors - “Do not give AI tools to your interns and juniors. If you take your skeptical senior and convince them to do vibe engineering, you get 10x results”
- Composer One is a paradigm shift - Fast feedback loops let you stay in the driver’s seat; slow models pushed people to YouTube Shorts while waiting
- PA devs are the real blocker - Perfectionism that demands optimal abstractions and nitpicks two-line PRs is counterproductive with or without AI
- LLMs don’t care about repetitive code - This is a feature: humans over-abstract too early, LLMs happily duplicate when appropriate
- Skill requirements changed, not disappeared - Knowing model limits, context management, prompt engineering, and judging “good enough” code are new required skills
What This Means for Developer Productivity
Kitze’s talk reframes the AI coding debate: the problem isn’t AI capability, it’s human perfectionism. “Vibe coding” fails because it’s unsupervised gambling. “Vibe engineering” works because it combines AI speed with human judgment about what’s good enough. The irony: developers who were already pragmatic about code quality (vs. over-abstracting perfectionists) are the ones thriving. The skill isn’t writing English—it’s knowing when code is good enough, which was always the hardest part of engineering.