Seoul Labs

Claude Sonnet 3.7 can apparently generate a working FastAPI endpoint in roughly 40 seconds. In that same output, it will silently skip input validation, use a deprecated datetime call, and shadow variable names across the same scope, and none of that stops the demo from running. The usual framing treats this as a speed tradeoff. But speed isn't actually what separates vibe coding from traditional development. The real variable is when you pay the complexity cost, and that timing difference determines whether the failure hits you in a two-hour prototype session or a two-day production incident on code nobody fully read.

The vibe coding versus traditional coding debate is framed wrong most of the time. It gets presented as a generational argument or a speed argument, and it's neither. It's a question about where you're willing to carry uncertainty, and for how long. Vibe coding doesn't eliminate complexity. It defers it, concentrates it, and moves it to a part of the codebase that's harder to see until something in production surfaces it. That's the real tradeoff, and understanding it changes how you use both approaches.

Neither workflow is inherently better. The question is what kind of failure you're set up to absorb.

Where the Two Workflows Actually Diverge

Traditional development in 2026 still means what it meant five years ago at the core: you write code with intent, you understand the structure before you commit it, and you own the failure modes from the start. The toolchain has changed. Static analysis is faster, type checkers like Pyright and mypy are embedded in most CI pipelines, and pre-commit hooks catch a class of errors that used to require a full code review. But the underlying discipline is the same. You're expected to read what you ship.

Vibe coding inverts that contract. The loop is: describe intent, accept generated output, run it, observe behavior, correct via prompt. Reading the code is optional until it breaks. That's not a criticism of the workflow. It's just a description of it. The speed gain is real. A solo developer can scaffold a working CRUD API with auth, migrations, and basic error handling in well under a day using GPT-4o or Claude Sonnet 3.7, a task that might take a careful traditional developer a full day or more depending on how opinionated they are about structure.

The divergence shows up clearly in dependency management. A vibe coding session will often produce a requirements.txt like this:

fastapi
uvicorn
sqlalchemy
pydantic
python-jose[cryptography]
passlib[bcrypt]

No version pins. No hash checking. No consideration of whether python-jose is still maintained, a package that's been in low-activity states across multiple audited projects since 2023. A traditional workflow would produce pinned versions from the start, run pip-audit or safety against the lockfile, and flag the unmaintained dependency before it ships. The vibe session gets you running faster. The traditional session gets you to production with fewer surprises. Whether that tradeoff makes sense depends entirely on what you're building and for whom.

The other divergence is how cognitive load gets distributed. Traditional coding front-loads the thinking. You pay the complexity cost at design time. Vibe coding back-loads it. You pay at debug time, often under pressure, often on code you didn't write and never fully read. Both approaches involve the same total amount of thinking. The difference is timing and context, and that difference compounds badly at scale.

Why Vibe Code Failure Modes Hit Differently

When traditional code breaks, it usually breaks in traceable ways. You wrote the function, you know the assumptions, you can read the stack trace and map it back to a decision you made. The debugging process is uncomfortable but legible. When vibe code breaks in production, you're reading code that was generated, possibly revised through several prompts, and never fully internalized. The stack trace points to a line you didn't write intentionally. You have to reconstruct intent from output, which is backwards from how debugging normally works.

Here's a concrete example. A vibe session produces this authentication check:

def verify_token(token: str) -> dict:
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
        return payload
    except Exception:
        return {}

That bare except Exception: return {} is a trap. Any JWT failure, whether it's an expired token, malformed signature, or wrong algorithm, gets swallowed silently and returned as an empty dict. Downstream code that checks if payload: will treat a completely invalid token the same as a missing one, which is still a security gap depending on what comes next. A traditional developer reviewing this flags it immediately. A vibe session may not surface it until someone probes the auth flow in staging. The model generated syntactically correct, functionally plausible code carrying a real security implication. That's the failure mode that actually matters: not syntax errors, not crashes, but silent misbehavior that looks fine until it doesn't.

Traditional coding has its own failure modes, to be fair. Overengineering is one: a developer who designs a five-layer abstraction for a feature that gets cut in sprint review has wasted time and created debt. Analysis paralysis is another. The real pathology of traditional development isn't that it produces broken code. It produces correct code too slowly or too rigidly to adapt when requirements shift. Neither failure mode is worse in the abstract. Both are expensive in the wrong context.

There's also a failure category specific to team settings. Vibe code in a codebase that multiple people maintain creates a documentation vacuum. Nobody has a mental model of the generated sections. Pull requests containing AI-generated code often get approved faster because reviewers assume the model got it right, so the reviewer's job becomes checking surface behavior instead of auditing logic. That assumption is reasonable most of the time and wrong enough times to matter enormously in high-stakes systems. Treating reviewer speed as a proxy for review quality is the precise point at which AI-assisted development becomes a liability rather than an asset.

Choosing by Context, Not by Preference

The scenarios where vibe coding wins aren't mysterious: prototyping under time pressure, solo projects where you own the entire failure surface, internal tooling that serves a small audience and gets maintained by one person, exploration of unfamiliar frameworks where you want to see working code before you read the docs. In all of these contexts, deferred complexity is manageable because the blast radius is small.

The scenarios where traditional discipline earns its cost:

• systems processing financial transactions or health data


• codebases with multiple contributors across time


• services with compliance requirements or audit trails


• anything where a security regression has regulatory consequences, because at that point the incident review alone costs more than the time you saved

That list isn't about fear. It's cost accounting. In those contexts, the two-day debugging session that happens because nobody internalized the generated auth layer isn't a hypothetical. It's a scheduled expense. The front-loaded cost of traditional development is often cheaper than the back-loaded cost of vibe code in high-stakes systems, and the math shifts significantly once you factor in on-call hours and incident reviews. Teams that treat vibe coding as a universal accelerant without adjusting their review process aren't moving faster overall. They're moving the cost to a more expensive column.

A hybrid approach is where most experienced practitioners actually land. Use AI generation aggressively for scaffolding and boilerplate, but run the output through a review pass that treats generated code the same way you'd treat a junior developer's first pull request. Not hostile, but thorough. A reasonable configuration for a team shipping AI-assisted code looks like this:

repos:
 , repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.5.0
    hooks:
     , id: ruff
        args: [--fix]
     , id: ruff-format
 , repo: https://github.com/pre-commit/mirrors-mypy
    rev: v1.10.0
    hooks:
     , id: mypy
        additional_dependencies: [types-requests]
 , repo: https://github.com/pypa/pip-audit
    rev: v2.7.3
    hooks:
     , id: pip-audit

That configuration doesn't care whether the code was written by a human or generated by a model. It applies the same mechanical checks either way: type coverage, linting, dependency audit, all of it running before a commit lands. Verify these version numbers against current registries before adoption since Ruff, mypy, and pip-audit all move quickly. The point is that the tooling layer doesn't need to know how the code was produced. It just needs to run, and running it consistently is what closes the gap between vibe output and production-ready code.

What the Framing Gets Wrong About Skill

Positioning vibe coding and traditional coding as competing philosophies makes for better articles and worse engineering decisions. In practice the choice is granular and contextual. The same developer can write a migration script via prompt iteration on a Monday and spend Tuesday carefully designing a data access layer by hand. Both decisions can be correct given what each piece of work demands.

What the framing misses is that vibe coding changes the location of the skill requirement, not the total skill requirement. You still need to know that the bare except Exception in the JWT function is a problem. You still need to recognize the unpinned dependency as a risk. You still need to understand why the generated SQL query will produce a Cartesian join at scale. The model doesn't remove the need for that knowledge. It removes the need to produce the initial code, which is a genuinely different thing. A developer who adopts vibe coding without the underlying knowledge to audit the output isn't moving faster. They're accumulating debt at generation speed.

There's also a subtler issue around mental models over time. A codebase built primarily through vibe sessions tends to have uneven conceptual density. Some sections are deeply understood because they broke and someone had to actually go in and read them. Other sections have never been read carefully and exist as a kind of working mystery: the behavior is known, the mechanism is not. Traditional codebases have uneven density too, but the unevenness is usually correlated with age and turnover rather than generation method. That distinction matters when you're trying to onboard someone or scope a refactor, and it rarely shows up in the velocity metrics teams use to justify AI adoption.

The tools are getting better at surfacing this. GitHub Copilot workspace features observed around what some users have reported as version 1.220 or thereabouts, Cursor codebase indexing observed around the 0.42 release, and Claude Code context management across sessions are all pushing toward giving the model more structural awareness of the existing codebase before it generates new code. Whether that narrows the quality gap between vibe and traditional output is still an open question in mid-2026. Honestly, it depends heavily on how the developer uses those features rather than on the features themselves. The gap narrows most for developers who already know what questions to ask, which means the precondition for vibe coding at a high level is traditional fluency, not a replacement for it.