There is a specific feeling that a lot of people have had in the last couple of years. You describe something you have wanted for a decade — the tool, the app, the thing that would fix the annoying part of your job — and forty minutes later it exists and works.
That feeling is real and it is worth taking seriously. Something genuinely changed. But the conclusion most people draw from it is wrong, and the wrong conclusion is expensive.
What actually changed
Andrej Karpathy named it vibe coding in early 2025: describing what you want in plain language, letting the model write it, and steering rather than typing. The name stuck because it captured something people were already sheepishly doing.
The current crop of tools split roughly into two shapes. There are the agentic ones — Claude Code and OpenAI's Codex being the obvious examples — which live in a terminal, read your whole project, run commands, and work through a task over many steps. And there are the assisted editors: Cursor, GitHub Copilot, and the AI features now baked into most IDEs, which keep you in the driving seat and speed up the typing. Gemini sits slightly apart on the strength of its very large context window, which matters when you want a model to hold an entire sprawling codebase at once.
People spend a lot of energy arguing about which is best. Having used them, the honest position is that the gap between frontier tools is much smaller than the gap between a vague prompt and a precise one. The differentiator is not the model. It is whether you can say clearly what you want, notice when what came back is subtly wrong, and know what to ask for next.
What this means if you build things
For developers the change is less dramatic than the discourse suggests, but it is real, and it lands in a specific place: the cost of the parts you already knew how to do has collapsed.
Scaffolding, boilerplate, test suites, the fiddly integration you have written six times before, the migration script, the CRUD layer, the CSS you have been avoiding — all of that has gone from hours to minutes. The parts that have not changed are the ones that were always hard: deciding what to build, designing something that will still make sense in a year, and debugging the failure that only happens in production on a Sunday.
The practical consequence is that your personal backlog of half-ideas is now tractable. The thing you always said you would build if you had a spare month is now a spare weekend. A lot of developers have discovered they can ship four products a year instead of one.
Which brings us to the trap. Shipping four products a year that nobody finds is not four times better than shipping one product that nobody finds. It is the same outcome, four times over, with more maintenance. If distribution was your constraint before, building faster does not help you — it just gets you to the wall sooner, more often.
What this means if you market things
The shift here is larger, and considerably less discussed.
For most of the history of marketing, the marketer's relationship to software was one of asking. You wanted a landing page variant, an event tracked, a report automated, a bit of data pulled out of an API — and you wrote a ticket, and you waited, and it was prioritised below something else, and eventually you stopped asking for the small things at all.
That constraint has substantially lifted, in four practical directions:
Stop queueing for small changes
Landing page variants, a new section, a form that posts somewhere sensible, a tracking script wired correctly. These are hours of a developer's time and were always hard to justify. They are now something you can do yourself in an afternoon and hand over for review.
Pull your own data
The most underrated use. Most marketing analysis is limited not by analytical skill but by access — the data is in an API, or three APIs, and joining them requires code. Describing that join to a model and getting a working script is now genuinely routine, and it changes what questions you are able to ask.
Prototype the idea instead of pitching it
A rough working version of a funnel, a tool, a calculator, an interactive comparison — the kind of thing that would have needed a spec, a design and two sprints. Building the crude version yourself lets you test whether anyone wants it before asking anyone to build it properly.
Build the thing itself
The largest one. If you already have an audience and you can now assemble a working product, the traditional reason to go and find a technical co-founder is weaker than it was. Plenty of marketers have quietly worked this out, and it is worth sitting with before you assume you need a developer at all.
Two people, same tool, opposite blind spots
What is interesting is watching each group use these tools and hit a wall the other would not have hit.
The developer builds something technically excellent that nobody wants, faster than before. Their blind spot is unchanged: they still do not know how a stranger finds this, and the model will happily write a hundred thousand lines without ever asking.
The marketer builds something people want that quietly does not work. It is insecure, or it loses data, or it falls over at fifty users, and — this is the crucial part — they cannot tell. The model produced something plausible, and plausible is exactly the failure mode you cannot detect without the expertise the tool was supposed to replace.
Neither is a criticism. They are symmetrical gaps, and each person's gap is the other person's ordinary Tuesday.
The bottleneck moved, it did not vanish
Here is the part the excitement obscures.
If building software is now dramatically cheaper for everyone, the number of products competing for attention goes up sharply. The amount of attention available does not. Every launch you make now lands in a market with far more launches in it than three years ago, all made by people who also had that forty-minute feeling.
So the honest reading of the vibe coding era is not anyone can build anything, therefore anyone can succeed. It is closer to the opposite: when building stops being the hard part, whatever is now the hard part becomes the entire game. And for indie software, that is being found.
The tools genuinely did remove one constraint. They also made the remaining one considerably worse. That is the trade, and it is worth being clear-eyed about it before spending another weekend building something excellent that nobody will ever see.