The vibe coding era has arrived

What vibe coding actually means

The term came out of a simple observation: you can now describe software in ordinary language and get working code back. Vibe coding is building that way on purpose, with a model doing most of the typing and a person deciding what gets built, what gets kept and what gets thrown away.

What it is not is a robot writing your product while nobody watches. The agencies worth hiring are the ones where a person reads every line before it ships, and where the speed comes from skipping the typing rather than skipping the thinking.

The practical result is that the first working version arrives in days. That changes what you can afford to find out. Instead of arguing about a specification for six weeks, you look at something running and discover you wanted a different thing.

When it fits, and when it does not

It fits when the shape of the thing is still uncertain and seeing it beats describing it. Internal tools, prototypes, the first version of a product, an integration nobody has built before.

It fits less well where the cost of being wrong is high and the requirements are already fixed. Payments infrastructure, anything regulated, anything that touches medical or safety systems. Not because the code is worse, but because the value of vibe coding is speed of iteration, and those projects are slow on purpose.

A good agency will tell you which of the two you have. Be suspicious of one that says yes to everything.

• Good fit: prototypes, internal tools, first versions, one-off integrations, migrations
• Reasonable fit: production applications with a person reviewing every change
• Poor fit: regulated systems, payments infrastructure, anything where a wrong answer is unsafe

Match the stack to the job

Agencies specialise by tooling more than they admit, and the tooling tells you what they are good at. A shop built around prompt-to-app platforms will get you something clickable extremely fast and will struggle when the requirements get awkward. A shop built around AI coding assistants inside a real codebase is slower to first demo and does not hit a ceiling.

Ask which they use before you ask anything else. It is the fastest way to find out whether they are the right shop for the thing you actually want.

How to check the work is any good

The failure mode of AI-built software is not code that does not work. It is code that works on the demo and falls over on the second real user, because nobody read it.

So ask about review rather than about output. The answer you want is that generated code is treated exactly like a junior developer's pull request: read line by line, tested, and never shipped on trust. An agency that cannot describe its review process has not got one.

Ask to see a repository from a finished project. You are looking for tests, for commit history that shows changes being revised rather than dumped in one go, and for readable code. Any of the three being absent tells you more than a portfolio site does.

• Who reads the generated code before it merges, and what do they look for
• What is the test coverage on a project you finished recently
• Show me the commit history on something real, not a demo repository
• What happened the last time a model produced something that looked right and was not

Agree who owns what, in writing

This is the part people skip and regret. You should own the code outright, and you should also get the things that make the code maintainable by somebody else: the repository with its full history, the prompts and context files the agency built up while working, and any custom tooling they wrote around the project.

The prompts matter more than they sound. On a project built this way, the accumulated context is a real part of the asset. An agency that keeps it has kept the ability to work on your codebase faster than anyone you hire next.

Get it in the contract before work starts. Asking afterwards is a negotiation; asking beforehand is a clause.

• All of the source code, assigned to you outright
• The full git history, not a single squashed commit
• The prompts, context files and instructions built up during the project
• Any internal tooling written specifically for your project
• A written handover, so a different team can pick it up

Start with a paid week, not a contract

Pick your two strongest candidates and pay each of them for a week on a small, real slice of the work. Not a pitch, not a proposal document. A week of the actual job.

It costs a fraction of the project and it answers the questions no reference call will. How do they communicate when something is unclear. Do they push back on a bad idea. Is the code readable. Did they hit the thing they said they would hit.

The agency that does not want a paid trial has told you something worth knowing.

What it costs, and how the pricing works

Rates vary enormously by region and by seniority, so a single number would be no use to you. What matters more is the shape of the deal.

Fixed price suits work where the outcome is genuinely known: a defined prototype, a specific integration. Time and materials suits everything else, which is most of it, because the entire point of building this way is that you change your mind once you have seen it running.

Watch for the arrangement where you pay for speed and inherit the cleanup. If a fixed price only works because nobody is going to write tests, you have not saved anything, you have moved the cost to whoever maintains it next.

A shortlist worth working from

Three or four agencies is the right number. More than that and you will not give any of them a proper conversation.

Filter by whether they have done something adjacent to your problem, not by whether they list your industry. Adjacent technical work travels; industry experience mostly does not.

Then talk to all of them about the same brief, on the same day if you can, so you are comparing answers rather than memories.

Vibe Coding companies on Brandligo

20 companies listed. Featured listings appear first; the rest are ordered by rating.