I have now shipped four production features that I did not write line by line. I specified what I wanted, I reviewed what came back, I corrected it, I pushed it, and it is currently running in front of real users. I suspect this is what people mean by "vibe coding", although I dislike the name and most of the people using it.
This piece is my honest report. Not the triumphalist version. Not the dismissive version. What it actually felt like and what I think it means.
How the four features broke down
- A CSV import feature for one of the advisory clients I work with. Medium complexity. Two days from spec to production, of which I'd guess ten to twelve hours were hands-on.
- A reworked rate-limiter for a friend's side project. Small, well-defined, ended up being a three-hour session in which I wrote approximately fourteen lines of code and the assistant wrote the rest.
- An internal admin UI for a client, probably eight hundred lines of React and a handful of API endpoints. Longer than I expected, mostly because I kept discovering ambiguities in the spec rather than because of any tooling issue.
- A webhook-processing service, about twelve hundred lines of Go. This was the most interesting one and I'll come back to it.
What it actually felt like
Faster, but also stranger. The closest analogy I have is running a team of one very capable junior engineer who can type at ten times my speed but who has no long-term memory, no product context, and a slightly alarming tendency to fabricate imports.
The first feature took me longer than if I'd written it by hand, because I was learning how to delegate. The second was about even. By the third and fourth I was meaningfully faster, particularly on the boilerplate-heavy parts. The proportion of my working day that was spent reading rather than writing code went from about 30% to about 60%. That is a structural shift, not a marginal one.
The webhook service, in detail
This is the one that convinced me the shift is real. A webhook processor for a payments integration, retries, idempotency, DLQ, metrics, the lot. The kind of service I've written by hand half a dozen times. I know exactly what good looks like.
I wrote the design doc — two pages — as I normally would. I handed it to the assistant with the existing codebase's conventions and asked for the first skeleton. The skeleton was not quite right; the assistant had invented a retry strategy that I didn't want. I corrected it, asked for the next layer, corrected again, and so on. By the end, I estimate I wrote about 8% of the lines and spent the rest of the time reviewing, correcting and prodding.
The finished code is, in my judgement, roughly as good as if I had written it myself. Maybe marginally better, because I was forced to articulate each decision at the level of a prompt, which is more thinking than I'd have done otherwise. Maybe marginally worse, because I didn't feel every line as intimately as I would have. The output quality is within the noise of my own work.
What it cost me in time was about 40% of what hand-writing would have cost. Not 10x. Not 1.1x. About 40%.
The things that are different
1. The skill ceiling has shifted
The skill that now most differentiates engineers is the ability to specify precisely what they want. This sounds obvious and is not — most engineers, myself included, have for years relied on iteratively fumbling towards the right answer by writing and rewriting. That habit is less useful now. The engineers who will look 2x productive against their peers are the ones who can hold a precise specification in their head and communicate it cleanly.
2. The skill floor is also shifting, but slowly
The claim that "anyone can build software now" is overstated. What is true is that someone with taste and judgement but little syntax can build more than before. Someone with neither taste nor judgement still cannot. The model amplifies whoever is in the driving seat, including their mistakes.
3. Debugging is harder in a specific way
I've said this in another post but it's the single biggest day-to-day friction point. Debugging code you didn't write line by line is slower because you have to reconstruct the author's intent rather than recall your own. A good review discipline at write-time is, at the moment, the main defence.
The future, as best I can tell
I will resist the temptation to make five-year predictions because the rate of change is silly. But the eighteen-month picture looks like this:
- Code generation continues to get better, unevenly. The gains compound in routine work (CRUD, plumbing, tests) and barely appear in novel work (distributed systems design, performance-critical code, anything with real concurrency).
- The bar for junior engineer productivity rises, because the model gives them a senior-ish collaborator for a subset of tasks. The bar for senior engineer productivity rises more, because leverage amplifies experience.
- The jobs that go first are not "software engineering". They are the adjacent roles whose output was mostly describable, non-judgement work: basic technical writing, simple integrations, some customer-facing technical-support roles, straightforward data pipelines.
- The job of "software engineer" bifurcates. There's a steadily-shrinking tier of people who mostly translate specs into code, and a steadily-growing tier of people who specify, architect and judge. The best engineers I know are already mostly doing the latter.
What I'd do if I were 22 now
Learn the fundamentals the hard way. Data structures, algorithms, operating systems, networking, databases. Not because the model can't do these for you — it can — but because without them you cannot judge whether what it produced is correct. Taste comes from understanding, and understanding comes from having done it yourself at least once.
Also: learn to write. Not marketing writing. Specification writing. Design documents. Clear, short, unambiguous English. This is the bottleneck skill in the new workflow, and it is unevenly distributed across the engineers I work with. The ones who can specify crisply are about to have a very good decade.
We are not being replaced. We are being handed an unreliable, fast, powerful apprentice. What we make of it will depend much more on us than on it.
— Nivaan