What Is Vibe Coding? What AI-Written Code Means for Your Business

As a software company, one of the sentences we have heard most over the past year is: "Could we just have AI write this?"

Most of the time the answer is yes. Sometimes it is "yes, and it will come back in six months at twice the cost." This article looks at vibe coding not through marketing language but through what it actually changes.

What is vibe coding?

Vibe coding means describing what you want in plain language, without technical detail, and letting an AI write the code. You say "add a filter to this screen" or "convert this table into that format"; the model produces code, you try the result and carry on.

Andrej Karpathy coined the term in early 2025, and it started out as a half-joke: moving forward by feel, without reading the code. By 2026 it had become serious — today it is part of how professional teams work day to day.

Let us set out the crucial distinction up front, because the whole debate rests on it: AI writing code and generated code being accepted without being read are not the same thing. The first is a tool, the second is a risk.

What does it genuinely speed up?

From what we see in practice, the gains are clear in these areas:

• Prototypes and idea testing. Getting an answer to "should the screen work like this?" within hours is now realistic. In a prototype you intend to throw away, code quality is secondary anyway.
• One-off jobs. A script to clean a spreadsheet and load it into a database, converting an old format into a new one, generating test data. For code that runs once and disappears, the productivity gain is striking.
• Understanding existing code. On a project you inherited, answering "what does this function do?" used to be hours of archaeology.
• Necessary but tedious work. Test skeletons, sample data, repetitive conversions, documentation outlines.
• Small internal tools. Simple panels the team uses itself and never exposes publicly.

The common thread is telling: work where mistakes are cheap and results are immediately visible.

Where does it get expensive?

Now the other side. The problems we meet most often with AI-generated code are not technical but managerial:

Code nobody read. The biggest risk is not that the model makes a mistake; it is that its output is accepted unread. Something that works and something that is correct are not the same. The code may run today, but if nobody knows what it does at the edges, that knowledge never existed in the company.

Quiet technical debt. AI usually produces the shortest thing that works. It may not fit your existing structure and may repeat the same logic in three places. Looked at in isolation, nothing seems wrong. Six months later, when a change request arrives, the complexity sends its invoice.

Security holes. Unvalidated input, missing authorisation checks, passwords and keys hard-coded into files, outdated dependencies. Models also sometimes suggest libraries that do not exist, which creates an opening for attackers to publish fake packages under those names.

Data leakage. Pasting real customer data, connection strings or contract text into a tool while generating code means moving data outside without noticing. We covered this separately in protecting personal data while using AI.

Systems with no owner. A system stood up over a weekend with AI help can become, three months later, a system nobody takes responsibility for. The root problem is not how the code was written but who owns it.

For a business owner: what should you ask, and of whom?

The practical conclusion for a company buying software:

Where mistakes are cheap, use the speed for everything it is worth. Testing an idea, seeing a screen, running a conversion — none of that needs to take weeks any more.

Where mistakes are expensive, the question is not "who wrote it" but "who verified it and who owns it". Payment flows, a module handling personal data, an integration talking to accounting, authorisation logic. There, AI produces a draft; the architecture, the data model and the final call belong to a person.

Three questions clarify things when you are collecting quotes: Is the code reviewed, and by whom? Are dependency and secret scans run? Are there tests, and what do they cover? These follow naturally from the preparation list in before requesting a software quote.

An old question is also back on the table: custom software or off-the-shelf? AI has lowered the cost of building custom, but it does not manufacture the maintenance, updates and accountability a packaged product carries. The decision criteria have not changed; one side of the scale simply got lighter.

Simple rules that work inside a team

The way we work, and what we recommend to clients, comes down to five points:

1. Every line that reaches production gets read. No exceptions. The writer may be a machine; the responsibility is a person's.

2. Dependencies and secrets get scanned. An automated dependency scan and a check for credentials committed into the code are the cheapest insurance in this business.

3. Tests are written before the AI, or verified by hand. Having the same model write both the code and its tests, then declaring it passed, is marking your own homework.

4. Real data does not go into the tool. Work with sample data; share the schema, not the contents.

5. Every system has an owner. "AI wrote this" is not a statement of ownership. A name has to go on it.

The easiest way to get a team to adopt these is a one-page usage policy — you can take the outline straight from our AI literacy guide.

So what happens to developers?

Short answer: the writing got faster, the deciding did not transfer.

Choosing what to build, designing the system as a whole, modelling data correctly, diagnosing a production failure and standing behind the outcome are still human work. What shifts is the balance of the role: writing fewer lines, reviewing, verifying and designing more.

Our own observation runs this way: AI does not close the gap between a good team and a weak one — it widens it. Because evaluating generated code requires exactly the knowledge needed to write it.

In short

Vibe coding is not a fad but a lasting way of working. It is not a method on its own, though; it is a multiplier. It speeds up a well-run process and sinks a badly-run one faster.

The right question is not "should we use AI" but "where at full speed, and where with the handbrake on".

If you would like to talk about using AI-assisted development safely in your own processes, or want us to review an existing system, get in touch; you can also look through our services to see how we work.