Developer-led AI vs vibe coding

The industry has collapsed all AI-written code into one conversation. "Did you use AI?" yes-or-no, as if that tells you anything about what you're buying.

It doesn't. There's a sharp line between AI used by an experienced engineer (as a peer, with review, tests, and architectural judgement around the output) and AI used as a substitute for that engineer ("vibe coding", prompt-only builds). The first ships better software than humans can write alone. The second demos well and falls over in month six.

This article is about that line, why it matters, and how to tell which side of it your developer is actually on.

What we mean when we say we use AI

First, the disclosure, because it matters for how the rest of this reads. Urban Lightbulb runs AI heavily. Claude Code is part of our daily workflow. The majority of our modern code starts as AI output. We're not writing this piece to sell you a handcrafted-artisanal-bespoke position. We think AI + an engineer produces better software than either alone, and we'll show our working.

The line we're drawing isn't AI-on vs AI-off. It's whether there's an engineer in the loop at all.

Vibe coding: the term and the problem

The phrase comes from Andrej Karpathy, who posted it on X in February 2025: "a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists... I 'Accept All' always, I don't read the diffs anymore." Karpathy meant it half-affectionately, describing a style that's useful for weekend projects. The industry picked it up and ran with it, and it now names a specific failure mode: a non-engineer prompts an AI to "build me a SaaS", accepts everything, and ships the result.

The output of that process isn't what you think it is. It's code that's optimised to pass the demo. Happy-path features work. Buttons do what buttons should do. The screenshots in the pitch deck are real. What isn't there: the error handling for the 20% of inputs outside the happy path, the security consideration that would have closed an injection vector, the architectural decision that would have made the next feature possible to add without rewriting the first one.

A Stanford study published in 2023 found participants with access to an AI coding assistant wrote significantly less secure code than those without, and were more likely to believe their code was secure than it actually was. The effect was strongest in the participants who trusted the AI most and engaged with the prompts least. That's the shape of the problem.

What developer-led AI actually looks like

An engineer uses AI differently from the start, before a single line is generated. The prompt itself is technical: type signatures, framework idioms, architectural constraints, the specific pattern the team uses in this part of the codebase. The AI gets context a non-engineer can't provide, and the output is proportionally better.

From there, the AI functions as a peer developer, not a sole developer. The engineer soundboards architecture decisions against it, pressure-tests trade-offs, asks for counterarguments to their own design. It's a technical conversation, not a request-and-receive transaction. The code the AI then writes moves through a rigorous process: automated review passes by separate AI agents, a full test suite, CI checks, and human review at the points where judgement actually changes the outcome — architectural decisions, commit boundaries, pull requests.

It's worth being clear about what that process does and doesn't require. The engineer doesn't need to watch every line being written in real time. With modern models, that's quickly becoming theatre. What they do need is to own the process that ensures the output meets the bar, and to be accountable when it doesn't. That's a different job from being the eyeball on every diff. An engineer who sets up rigorous AI review, comprehensive tests, CI that actually catches regressions, and a commit discipline that forces review at the right moments can let the AI run for hours and still ship better code than they'd write by hand.

That pipeline sounds like overhead. It isn't. A 2024 field experiment across Microsoft, Accenture, and a Fortune 100 company found developers with AI assistants completed 26 percent more tasks than the control group, with no measurable drop in quality when engineers were in the loop. The paired workflow is faster and better than solo human code. What it isn't is prompt-and-ship.

What the human brings that the AI can't

Here's the part most of the discourse misses. The AI is extraordinary at the code in front of it. It's blind to everything else.

An engineer holds the shape of the system in their head. They know which assumption in the auth layer is going to break when you add a second tenant next quarter. They know that the database index that's fine at a thousand rows will kill the query at a hundred thousand. They know that the innocuous refactor in module A is going to cascade into a bug in module C because the two talk via a contract that isn't written down anywhere. The AI sees the file it's been given. The engineer sees the next ten features, the scale curve, and the blast radius of every change.

That's what "human in the loop" actually means at Urban Lightbulb, and why we treat it as a load-bearing phrase rather than a marketing caveat. The AI handles the code. The engineer holds the boundaries: what can break, when, and why. Everything interesting about how software ages lives in those boundaries.