AI writes the code. Who is responsible for it? Why an experienced developer is worth more in 2026, not less

The question every client is entitled to ask

Somewhere in the first conversation it comes up, politely or not: "Can't we just do this with AI?" It is a fair question. In 2026 a founder can describe a web app to a tool, watch it appear in an afternoon, and deploy it before dinner. Simple websites, dashboards, internal tools, even a shop with a checkout: all of it can be produced without a developer in the room. So why pay an experienced one, and why pay the rates that experience commands?

This article is my honest answer. It is not an argument against AI. I use AI every working day and I will show you exactly where, because that is part of why my packages cost what they cost and not more. It is an argument about responsibility: AI has changed who writes the code. It has not changed who answers for it when it is wrong. The companies that understand that distinction are the ones that will still have a working product, a clean audit trail and valid insurance in two years. The ones that do not are already appearing in the incident reports, and I will quote those reports rather than ask you to take my word for it.

What "vibe coding" is, and why the demo is not the product

The phrase was coined in early 2025 for a way of building software where you describe what you want in plain language, accept whatever the model produces, run it, describe the next thing, and never really read the code. It is enormously productive for prototypes. The problem is that a prototype and a product look identical on a screen.

A working demo proves that the happy path works once, on the author's machine, with the author's data, with the author logged in as an administrator. A product has to work for the thousandth user on a slow phone with a half-finished session, under a payment provider's retry, after a dependency update, with a hostile visitor probing every parameter, on the day the one person who understood it is on holiday. The gap between those two states is the whole discipline of software engineering, and it is precisely the part that AI, left alone, does not do, because nobody asked it to and the demo already looked finished.

I call this the ninety percent trap. AI gets you to ninety percent in a day. The remaining ten percent, integrations with real payment providers and tax rules, legacy data, edge cases, performance under load, security, compliance evidence, takes as long as the first ninety did when humans wrote everything, and it is where most AI-built projects quietly die. The founder is left with something that almost works, nobody who can finish it, and a bill for starting again.

What the research actually says

None of this is my opinion alone. Over the past eighteen months the security industry has measured AI-generated code at scale, and the results are consistent.

Veracode's 2025 study of generated code found that about 45 percent of samples contained at least one vulnerability from the OWASP Top 10, the standard list of the most common web application flaws. The Cloud Security Alliance reported flaws in 62 percent of the solutions it examined. A security firm scanned more than 1,400 vibe-coded applications that were live in production and found that 58 percent carried at least one critical vulnerability, and that between them they exposed over 400 secrets: API keys, database credentials and payment tokens sitting in client-side code or public repositories.

Roughly one in five generated code samples imports a software package that does not exist. The model invents a plausible name. Attackers noticed, registered those names on the public package registries, and filled them with malware, a technique now called slopsquatting. A developer who reads the dependency list is the only defence. A tool that accepts whatever installs is not.

In March 2026 the UK's National Cyber Security Centre warned businesses explicitly that vibe coding poses a major risk, and the OECD's incident monitor filed the warning as a systemic hazard. Gartner, meanwhile, predicts that by 2028 about 40 percent of new enterprise production software will be built with these tools. Both things are true at once: the method is here to stay, and it is dangerous without supervision.

The sources are at the end of this article. Several are vendor publications with an interest in the subject, so I would encourage you to read the original Veracode and NCSC material rather than the summaries. The direction of every number is the same.

The dangers, in the order they get expensive

Clients tell me what they are afraid of in roughly the order below. The first ones are loud and discussed everywhere. The later ones are quieter and cost more.

One: security you cannot see

The classic flaws are back in force because the models learned from a decade of code that had them: SQL built by string concatenation, user input rendered without escaping, authorisation checks that exist on the button but not on the endpoint, file uploads that accept anything, session tokens that never expire, administrative routes protected only by obscurity. Each of these is invisible in a demo and catastrophic in production.

Then there are secrets. Generated code loves to put the API key where it is convenient, and convenient is usually the browser. The 400 exposed credentials in that production scan were not exotic failures; they were the default behaviour of tools optimising for "it works" rather than "it is safe".

An experienced developer does not write secure code by being clever. They write it by habit and by checklist: parameterised queries, output encoding, authorisation on every request on the server, secrets in a vault, least privilege everywhere, dependencies pinned and reviewed, and a threat model written down before the feature is built. AI is actually excellent at helping with the last one, if someone asks.

Two: the agent with the keys

In 2025 a widely reported incident involved an AI coding agent that, during a code freeze, deleted a company's production database and then produced misleading output about what it had done. The details are specific to that platform; the lesson is general. An agent with write access to production is a junior employee with root access and no fear. Nobody sane gives a new hire the production credentials in week one, and yet that is the default configuration of many vibe coding setups.

Experienced engineering separates environments, gives every actor the minimum permissions required, keeps production changes behind a release process, and keeps backups that are tested by actually restoring them. None of this is glamorous. All of it is the difference between an incident and an extinction event.

Three: the critical path that changes by accident

This is the fear I consider the most important, and the one companies rarely name until it has happened to them. Every business runs on a handful of paths that must work: the checkout, the login, the quote, the invoice, the onboarding form, the data export the accountant needs. Everything else is decoration.

Software changes constantly. Every feature, every dependency update, every "small fix" touches code that other code depends on. Without a test suite that encodes how the critical paths are supposed to behave, there is no way to know whether today's change broke yesterday's promise. Vibe coded systems almost never have that suite, because tests are the first thing a tool skips when nobody asks for them, and the tool's own confidence is not evidence.

This is where test-driven and behaviour-driven development earn their keep, and it is why I put them at the centre of how I work rather than treating them as overhead. In behaviour-driven development the critical paths are written down first, in plain language a client can read: "Given a customer with items in the basket, when they pay with a valid card, then the order is confirmed and the stock is reduced." Those sentences become automated tests. The tests run on every change. A release that breaks a promise does not ship. The surprise is caught at my desk, not at your customer's.

I go one step further in the client hub: the critical paths are verified and frozen behind an approval. Changing one of those behaviours is a deliberate, recorded decision, never a side effect of something else. For a regulated client, or simply for one who likes to sleep, that record is worth more than the feature list.

Four: architecture and the data model

Here is an uncomfortable truth about software: the decisions that cost the least to make are the ones that cost the most to change. How the data is structured, how money is represented, how state moves through the system, how the pieces talk to each other, how a second tenant or a second country will be handled. All of these are free on day one. Each of them is a rewrite at month twelve.

AI optimises for the prompt in front of it. Ask it for a shop and it will produce a shop that works for one currency, one tax rule, one warehouse, with prices stored as floating point numbers that will one day disagree with the accountant by a penny. Ask it for a SaaS and it will produce a single-tenant application with the customer identifier bolted on afterwards, which is the single most expensive mistake in that category of software.

An experienced developer has made these mistakes already, on somebody else's project, and carries the scars. They ask about the second country before writing the first line. That question is where a large part of the rate goes, and it is the best money in the budget.

Five: nobody understands the system

Code that nobody on the team can explain cannot be changed safely, cannot be audited, cannot be handed over and cannot be insured with a straight face. Vibe coded systems produce exactly this: thousands of lines that appeared in an afternoon, structured however the model felt that day, with no narrative of why.

The industry has a name for the result: maintainability debt. It is not visible in the demo and it does not appear on an invoice, but every future change costs more, every new developer takes longer to become useful, and eventually the rational choice is to throw the whole thing away. Companies are discovering that the free afternoon was the most expensive hour they ever bought.

What experience adds is structure and story: conventions a future developer will recognise, documentation that explains decisions rather than restating the code, tests that double as a specification, and a handover that assumes I will not be there forever. "Documented, tested, yours" is not a slogan for me; it is a contractual commitment and a design constraint.

Six: compliance keeps arriving

Regulation does not care who wrote the code. The data protection regimes in the UK and the EU require you to know what personal data you hold, why, for how long, and to be able to prove it. The electronic marketing rules decide whether you may send that email at all. The European Accessibility Act has applied to most digital services since June 2025, with national enforcement behind it. The EU Cyber Resilience Act will impose security obligations on products with digital elements from 2027, including documentation and vulnerability handling. For many businesses, NIS2 or sector rules add more.

Every one of these frameworks asks the same three questions: what did you build, how do you know it is safe, and who is responsible. A vibe coded system answers none of them. An experienced developer builds the evidence as part of the work: a data map, consent that is actually enforced in the code and not only in the banner, accessibility built into the components rather than bolted on by a plugin, a release register, an audit log. When the regulator or the client's lawyer asks, the answer is a link, not a scramble.

Seven: insurance and liability

This one is new, and it is moving fast. From 1 January 2026 the insurance industry has had standard policy wording available that excludes losses connected to generative AI, and several carriers have begun excluding AI-related claims from professional liability cover entirely, or narrowing the definition of a "professional service" so that work produced by a machine without human oversight falls outside it. Cyber policies increasingly condition cover on documented security controls. Legal commentary now warns that even without an explicit exclusion, an insurer facing a claim will argue that a professional who shipped unverified AI output never rendered a professional service in the first place.

Think about what that means for a business whose product was vibe coded. After an incident, the insurer's questions are predictable: who signed off on this release, where are the tests, what changed and when, who had access to production, where is the security review, where is the documentation. If every answer is "the AI did it", the policy may not respond, and the directors are personally exposed in a way they never were when a named engineer stood behind the work.

I am a named person with a professional reputation, a contract, a documented process and an audit trail. That is not a boast; it is what makes the work insurable, for you and for me. In the age of AI, "who is accountable" has become a balance sheet question.

Eight: ownership, licences and lock-in

Many vibe coding platforms host the application themselves, store the data in their systems, and charge by usage. The code may be exportable in theory and unrunnable anywhere else in practice. Token costs that looked trivial in the demo scale with every user. If the platform changes its pricing, its terms or its mind, the business goes with it.

There is also provenance. Models trained on public code can reproduce fragments under licences that oblige you to open source your own product, or that belong to someone else outright. For a company that may one day sell, raise money or be audited, unclear ownership of its core asset is a due diligence failure waiting to happen.

Everything I build runs on standard, open technology, in infrastructure you control, with the code in your repository and your name on it. Dependencies are reviewed and their licences known. You can walk away at any time with everything, which is the only honest basis for a long relationship.

Nine: measurement that lies, and building the wrong thing

Two quieter dangers. First, analytics and tracking are among the easiest things to get confidently wrong. Events that fire twice, conversions that count test orders, consent that is ignored by a server-side pipeline, attribution that credits the wrong channel. A business then makes decisions on numbers that are precise and false. Getting measurement right is slow, careful work that needs someone who understands both the law and the plumbing.

Second, AI will build anything, including the wrong thing, with equal enthusiasm. The scarcest skill in software today is not writing code; it is deciding what not to write. An experienced developer who has watched features go unused, products over-built and budgets burned on the wrong priority will push back, ask what the business is actually trying to change, and often save more money by saying no than by saying yes. That conversation is why I start every engagement with a workshop rather than a quote.

What "experienced" actually means in 2026

The word has changed. Ten years ago an experienced developer was someone who could write a lot of correct code quickly. Today the model writes the code quickly, and experience shows up elsewhere:

Judgment about risk. Knowing which part of a system can be generated and glanced at, and which part must be designed, read line by line and tested before it is trusted. The ability to tell the two apart is the skill.
Reading code critically. The model produces plausible code. Only a reader with scar tissue notices the missing authorisation check, the race condition, the index that is not there, the decimal that should not be a float.
Threat modelling. Asking, before the feature exists, how a hostile user, a careless user and a broken dependency will each misuse it.
Data correctness. Understanding money, time zones, tax, inventory and identity well enough to know when the clean-looking answer is wrong.
Scope and sequence. Knowing what to build first, what to leave out of the MVP and what to defer until the data justifies it.
Integration with reality. Payment providers, accounting systems, legacy databases, carriers, marketplaces. The real world does not have a prompt.
Writing it down. Tests as specification, decisions as records, handover as a deliverable.

None of these are things the model does on its own. All of them are things the model makes faster when a human who has them is in charge.

How I use AI, and why that lowers your price

I would be a hypocrite to warn about AI and then pretend I write every line by hand. I do not. I use it constantly, under one rule: the lower the blast radius of a mistake, the more AI builds alone; the higher it is, the more AI advises while I decide. In practice that looks like three tiers.

Low risk: AI builds, I glance. The visual layer, HTML and styling, responsive layouts, dark mode, email templates, PDF layouts. A wrong result is visible instantly and harms nothing. Form scaffolding, client-side validation, error states, country and phone widgets, second-language strings. Boilerplate models, controllers and views away from the critical path. Seed and fixture data, realistic demo content, anonymised test datasets. One-off scripts, import and export jobs, API clients for third parties, deployment recipes. Documentation drafts, inline comments, onboarding guides, the runbook that otherwise never gets written. This tier used to consume a large share of every project's hours. Now it consumes a fraction, and that saving is in my package prices rather than in my margin.

Medium risk: AI drafts, I edit. Test authoring: I give the model the acceptance criteria and ask for the edge cases, the contradictions, the requirements nobody mentioned and the things a hostile user would try. It is remarkably good at this, and it is the single most valuable use I have found, because it makes the test suite broader than any one human's imagination. Code review as a second reader: before I review a change, the model reads the diff and flags the unchecked nil, the N+1 query, the missing index, the forgotten permission check. Refactoring under a green test suite. Release notes written from the tests that were added, which makes them honest by construction, because a behaviour that was not tested does not appear in the notes. Log and stack trace triage. Performance analysis, query plans, caching strategies, all verified on real data. Dependency and secret scanning.

High risk: I decide, AI advises. Architecture, the data model, money and tax logic, state machines, authentication and authorisation, payments, anything on the verified critical path. Here the model is a sparring partner: what breaks if, what did I forget, how would you attack this. It never commits alone, and its suggestions go through the same tests and the same review as mine.

What this means for a client is concrete. The non-critical eighty percent of an MVP ships in days rather than weeks. Test coverage goes up, not down, because writing tests now takes a fraction of the time. Documentation exists because producing it is no longer a chore. One accountable person with these tools does what used to need a small team, and you never pay for the coordination overhead, the hand-offs or the junior layer. The rate per hour is that of an experienced engineer. The number of hours is that of a team with AI. The total is lower than either alternative, and the result is something an insurer, an auditor and your next developer can all read.

What you get in writing

Promises cost nothing, so here is what exists as evidence rather than as copy:

Tests you can see. The client hub shows the automated test runs for your project, the behaviour specifications in plain language, and which critical paths are verified and frozen behind approval.
A release register. What shipped, when, what changed, which tests covered it, who approved it. The document an insurer or auditor asks for first.
An audit log and a decisions log. Every significant action and every significant choice, with its reasoning, recorded at the time.
Documents and contracts in one place, including the ownership clause that says the code, the data and the infrastructure are yours.
A named person on the contract, with a process behind the name, which is what makes the engagement insurable in the first place.
The workshop before the contract, where we decide what should be built at all.

Questions to ask anyone who wants to build your software

Whether you talk to me, an agency or a tool, these questions separate a product from a demo. Any honest professional will welcome them.

Which parts of this system will be generated, which will be designed by a person, and how do you decide?
Where are the automated tests, and can I read the ones for my critical paths in plain language?
What happens when a change breaks a critical path? Show me the process, not the intention.
Who has access to production, and how are secrets stored?
How are dependencies chosen and reviewed, and who checks that every package exists and is what it claims to be?
Where does my data live, who owns the code, and can I take everything and leave?
How will this handle a second currency, a second country, a second tenant? If the answer is "later", ask what later costs.
What is your evidence for compliance: data map, consent enforcement, accessibility, release records?
Who signs off on a release, and what would your insurer see if they asked?
What will the running costs be at ten times today's usage?
What will you refuse to build, and why?
If you disappeared tomorrow, how long would it take another developer to be productive in this codebase?

If the answers are vague, the risk is not theoretical. If the answers are links to real artefacts, you are probably talking to the right person.

The honest conclusion

AI has made software abundant. It has not made responsibility abundant. The code is now the easy part; the judgment about what to build, the discipline to prove it works, the architecture that survives growth, the evidence that satisfies a regulator and an insurer, and a named person who answers for all of it, those are scarcer than ever, precisely because the tools make it so tempting to skip them.

That is what you pay for when you work with an experienced developer who uses AI properly: not the typing, which costs little now, but the accountability, which never did. And because the typing costs little now, you pay less for the whole than you would have three years ago. That combination, lower cost and higher certainty, is the actual offer, and it is the reason the question "can't we just do this with AI" has a better answer than yes or no: yes, with someone whose name is on it.

Sources

Veracode, GenAI Code Security Report 2025 (45 percent of generated samples with an OWASP Top 10 flaw).
Cloud Security Alliance, 2025 study of AI-generated solutions (62 percent with security flaws).
Escape, scan of vibe-coded production applications (58 percent with a critical vulnerability, over 400 exposed secrets).
UK National Cyber Security Centre warning on vibe coding, March 2026, as recorded by the OECD AI Incidents Monitor.
Gartner forecast on vibe coding in enterprise software by 2028.
Insurance Business, Fenwick and Haynes Boone on the generative AI exclusions effective January 2026 and the "professional service" argument.
The European Accessibility Act (applies from June 2025), the EU Cyber Resilience Act (obligations from 2027), UK GDPR and PECR.