What is Vibe Coding? The New Way Developers Build Software | Zowie Langdon | Beyond Coding #200

Summary: “Vibe Coding” (Beyond Coding #200)

The episode discusses vibe coding as a modern workflow where developers use AI coding tools (notably Cursor with large models like Gemini 2.5) to rapidly generate code through prompts—then improve it via iterative refinement, taste, and practical review.

---

1) Why some developers don’t adopt it immediately

• Some teams/developers find tools underwhelming at first because early attempts produce bad or usable-subpar output.
• The speakers argue adoption depends on:
  • giving it time, and
  • learning how to steer the model toward better results rather than expecting perfect code immediately.
• There’s a “tipping point” where developers start identifying as “vibe coders” after they learn the tool’s strengths and limits.

---

2) Benefits in early-stage product work (and small-scale continuous delivery)

Vibe coding is described as especially useful for:

• Early-stage product development
• Faster iteration toward continuous delivery—typically for smaller scopes rather than extremely high-stakes, large-scale systems

Claimed outcome: when the workflow lands well, you can reach ~95% of the way quickly; the code is “damn good,” even if not perfect.

---

3) Key limitation: you may need a “learning week” of messy iterations

A recurring theme is that the process often includes:

• a week or two of poor output while learning prompting/workflow

It’s likened to learning a new ecosystem (e.g., Python/pandas):

• early code feels great,
• later you realize it was sloppy,
• requiring iteration and improved judgment.

---

4) “Asymptote” effect: getting close, but not reaching correctness

One speaker describes starting with 1–2 prompts and getting close (e.g., “40% there”), but then:

• more prompting moves you toward correctness without reaching it
• the model may respond confidently with “fixes” that are actually wrong

Important practice: If it’s not sufficiently correct after a couple iterations, reset rather than brute-forcing more prompts.

---

5) Practical workflow: when to revert/reset vs keep iterating

For an existing project building a feature:

• After prompting drives the code to a “stuck” state (e.g., ~60% working), the recommendation is not to keep prompting indefinitely.
• Instead, use version-control ideas such as:
  • check out a previous commit (“previous comment/commit” / restore baseline)
  • note: stashing multiple versions can become messy

Emphasis: avoid compounding mistakes into a deeper broken baseline.

---

6) Tooling specifics: models + IDE behaviors

Cursor and model references

• Cursor is the main environment, and it was described as improving later due to better agent/model behavior.
• Gemini 2.5 (and another mentioned: 3.7) are cited as delivering strong results in Cursor.

Prior model testing (as described)

• Claude was preferred when codebase context could be staged intentionally.
• GPT-3.5 (early experience) was criticized as initially “garbage/unusable,” due to unrealistic code/function/library suggestions.
• Earlier GPT variants (e.g., “o3 mini”, “o1”) were mentioned as slower but better at reasoning/context.

Agent-mode caution

• Agent-like auto-writing can be unreliable early; it may need multiple iterations before it “reasons through.”

Prompting strategy in Cursor

• Ask for a development plan first (don’t apply code immediately).
• Provide constraints, docs, and guidelines.
• Then apply suggested code after review.

---

7) Code quality is still bound by human judgment and seniority

The episode repeatedly ties vibe coding outcomes to:

• developer taste
• review discipline
• organization’s seniority and toolchain standards

Seniority is framed as a set of trade-offs, such as:

• duplication vs refactoring
• risk vs business priority
• controlling technical debt

---

8) Developer workflow and “human-like” planning

Vibe coding is described as exhibiting human-ish iteration patterns:

• exploring options conceptually before implementation
• still requiring careful orchestration—especially for understanding interactions and architecture

---

9) Cross-interface productivity: MCP / agent ecosystems

A major forward-looking theme is crossing boundaries between tools:

• moving beyond “one tool in isolation” (e.g., Figma-only, docs-only)
• building a protocol layer so models can access multiple tools/systems via one interface

References include:

• MCP and agent-to-agent ideas
• Google’s “Agent Space” concept and tool connectivity (e.g., Slack/Confluence/SharePoint)
• third-party search/connectors (e.g., “glean” searching across Confluence/Jira/Slack/SharePoint)

Goal: a single “middle layer” that can reason over available tools and retrieve/execute across the org.

---

10) Prototyping examples and constraints of existing tools

• Live example: building a Rubik’s Cube in VR within a one-day “Innovation Day” window
  • started with V0, hit package mismatch issues for VR
  • switched to Cursor + VR browser integration to get a working VR Rubik’s Cube quickly
  • biggest missing element was interaction logic (moving/controlling the whole cube vs individual pieces)
• UI prototyping tools (e.g., lovable/V0) may not be ideal for native workflows, though designers can import Figma for faster layout iteration.

---

11) Product bets: ideas, risk, and tool adoption friction

Vibe coding adoption inside companies depends on:

• experimentation culture
• risk tolerance (startups vs banks/insurance orgs)
• whether teams can define guidelines (especially for juniors)

Some developers may prefer:

• gradual rollout via tooling/guidance rather than a full “all-in” workflow change

The speakers argue the best systems will:

• reduce friction for onboarding and “stuck” moments
• provide guardrails instead of only generating code

---

12) Related developer-experience and learning products

One speaker shifts to a product idea:

• an app/platform to help users learn and consume knowledge with less noise
• ingestion of newsletters/podcasts and extraction of relevant bits

Notes mentioned:

• beta via TestFlight, later launch on the App Store
• user research insight: people save information (e.g., Obsidian/notes) but struggle to actually use/retain it.

---

Key speakers / sources

• Patrick Akil (podcast host)
• Zowie Langdon (guest speaker)