BlogAI for eCommerceOctober 15th, 2026 · 11 min read

This is not vibe coding

410,017 lines of product code. 2,784 human hours. 37 weeks. The classic estimation models say it should have taken at least 34 times longer. This is the method behind that gap.

Hal 9000 not vibe coding

In 2001: A Space Odyssey, HAL9000 boasts that no computer of his series has ever made a mistake. The problem with HAL was never that he could fail. It was that nobody on board had a way to check him.

That is, more or less, the state of AI-assisted software in 2026. Models write code at a speed no team can match, and most of the industry deals with the result the way the crew of the Discovery dealt with HAL: trusting it until the day it locks you out of the pod bay.

We spent 2026 building Clione, a SaaS platform that syncs, enriches, publishes and verifies the semantic layer of ecommerce catalogs so that ChatGPT, Gemini, Perplexity, Claude and shopping agents can understand them, cite them and recommend them. It writes into our clients’ live storefronts. A HAL-style ​“trust me” was never an option. So we had to change how we work, and then we measured what that change was worth.

What we pulled off

The short version, before the maths:

  • We built a production SaaS platform of 410,017 lines of code with the equivalent of two people, in 37 weeks. Nobody on the team worked on it full time.
  • By the industry’s own yardsticks, that is a job for 65 to 107 people. The classic estimation models predict between 34 and 138 times the hours it actually took.
  • Faster did not mean sloppier. Every change goes through automatic checks, an AI reviewer whose job is to say no, and a human. Only 0.14% of commits ever had to be reverted.
  • It cost about 83,520 € in human time, at an average Spanish labour cost. At historical productivity, the same system would have cost between 2.85 and 11.55 million euros.
  • And we can prove it. Every number in this article can be recomputed from a single frozen commit, with open source tools and published formulas.

Why read on: if you are about to build software with AI, or hire someone who says they do, this is what the difference between a demo and a system looks like, measured.

Here’s the technical story.

Lead with numbers

We froze the measurement at a single production commit, what production was serving on 13 October 2026:

  • 410,017 lines of product code (TypeScript and JavaScript, monorepo), across 2,765 files, with a total cyclomatic complexity of 56,983. Tests, migrations, generated code, docs and data are excluded.
  • 2,784 human hours, measured, over 37 weeks.
  • 8 people contributed. None of them full time. Average combined dedication: 75 hours a week, the equivalent of two people.

Then we ran the same code through the classic software estimation models, the ones the industry has used for decades and that were calibrated on projects where humans wrote every line. Published parameters, nothing tuned to our case:

  • COCOMO basic, semi-detached:384,860 hours (138x what we spent).
  • COCOMOII, nominal:333,802 hours (120x).
  • Jones function point rules:281,636 hours (101x).
  • COCOMO basic, organic:202,068 hours (73x).
  • ISBSG median delivery rate (12.3 hours per function point, from thousands of real projects): 95,155 hours (34x).

Even the most conservative full lifecycle model predicts 34 times more effort than the system actually cost. And there is a floor: Halstead’s software science, which ignores design, testing, meetings and mistakes and only models the act of writing and understanding code, still lands at 10,094 hours. That is 3.6 times what we spent, under the absurd assumption that someone typed the final version of every function in one go, without ever talking to anyone.

How we measured (so you can check)

Numbers like these may arouse suspicion, so here is how they were built.

Size. Counted with scc4.1.0 on a clean ​“git archive” of that commit. We stripped tests, migrations, generated code and build artifacts, plus documentation and data files. That last cut was not cosmetic: 271,000 lines of backlog Markdown, changelogs, localisation JSON and scraped datasets would have pushed COCOMO to 819,600 hours. Nobody typed them, so they don’t count.

Hours.30.8% come from manual time tracking. The rest come from git history, using a ​“daily span” per author (first to last commit of the day, plus 45 minutes). We calibrated that method against the two people who both track time and commit: it reproduces their logged hours with a 3 to 5% error, and always comes up short. So we multiplied it by 1.04 for everyone else. The biggest contributor’s figure was cut by 10% at their own request, to remove time spent in the repo that wasn’t work.

Machines don’t count as people.736 hours of machine clock (259 of coding agent sessions, 403 of pipeline bots, 74 of the review agent) are logged separately and not added to the human total. Every agent session is opened and supervised by a person, and that supervision is already inside the 2,784 hours.

Reproducible. Every figure can be recomputed with open source tools. The replication package, available on request, swaps author emails and time tracking IDs for salted SHA-256 hashes, so anyone can rerun the calibration without knowing who is who.

What we had to change

None of this comes from a better model. Everybody has access to the same models. It comes from treating AI as a team member with a written job description instead of an autocomplete with a personality. Here are the main changes.

1. Every task is born as a contract

Each task starts with acceptance criteria labelled as automatic (with the exact command that proves it) or manual (with the name of the person who verifies it). A criterion without a proof is rejected by the tooling before the task even exists. The agent doesn’t get a vibe. It gets a spec it can fail.

2. Quality gates before anything is merged

Type checking, static analysis, more than 590 contract tests, internationalisation checks in two languages, screenshot coverage of every product route, and a code-enforced ban on hardcoded URLs, keys or credentials, anywhere, including deployments. If the gate says no, it’s no.

3. An adversarial reviewer called Atropos

Named after the Fate who cuts the thread, Atropos is a separate agent that did not write the change and is there to reject it. Every review has a budget, a trace and a recorded verdict. A change that doesn’t survive Atropos doesn’t get in. So far that’s 242 commits signed by the reviewer alone.

4. Everything is signed

Every commit says who wrote it: 1,076 by the coding agent, 702 by pipeline bots, 242 by Atropos, the rest by people. Every change carries a changelog entry in English and Spanish as mandatory metadata. Every product decision is dated and authored. Every production release is verified against the digest of the deployed image and a deep health check after deployment.

5. Technical debt is a ticket, not a feeling

Debt gets logged as a task, with an owner and a date, the moment it’s detected, in a backlog versioned next to the code. Nobody ​“remembers to come back to it later”.

6. A written division of labour

People decide, review and verify on real environments. AI explores, implements, tests and documents. The split is written down, it’s auditable, and it improves every iteration.

The result in operational terms: delivery cycles measured in hours instead of weeks, a continuous flow of releases to production with zero recorded data loss, and a revert rate of 0.14% (6 of 4,400 non-merge commits up to the measured release, none since September).

Vibe coding vs AI-native, in three numbers

In February 2025 Andrej Karpathy coined ​“vibe coding”: accept whatever the model proposes, don’t read the diff, paste the errors back until it seems to work. Wonderful for a weekend prototype. Terrifying for a system that writes into someone else’s store. Both approaches use the same models. The difference is who verifies, what gets measured and what gets written down.

  • Who verifies. In the 2025Stack Overflow Developer Survey (49,000 responses), 66% of developers complain about AI solutions that are ​“almost right, but not quite”, and 46% distrust their accuracy. In Clione, three layers check every change: automatic gates, Atropos, and a human on a real environment.
  • Error rate.Veracode found that 45% of code samples generated by more than 100 models introduced an OWASP Top 10 vulnerability. CodeRabbit found AI-authored pull requests carry 1.7 times more issues than human ones, and up to 2.74 times more security issues. In Clione, 0.14% of commits had to be reverted.
  • Productivity. In METR’s randomised trial, experienced developers were 19% slower with AI while believing they were 20% faster. In a randomised controlled experiment by Peng et al., a single task got done 55.8% faster. Clione, measured on a whole system in production: 34x to 138x below what the classic models predict.

Fair warning: these comparisons are not the same experiment. The published studies measure tasks, one at a time, without a verification process like ours. They’re the best public proxy for vibe coding, which by definition nobody measures. Ours measures a complete system. That’s exactly the point: task-level studies answer ​“how much faster is a task with an assistant”. The question we wanted to answer was ​“how far is a real system from what the textbooks say it should have cost”.

METR itself has since updated that result: with late-2025 tools, its follow-up points to a speedup (around 18% for returning developers and 4% for new ones, with intervals that include zero), and the authors now call per-task experiments an unreliable proxy, partly because many developers refuse to work without AI. Which is exactly why we measured a whole system instead.

Two more signals of what happens without discipline: GitClear, analysing 211 million changed lines, saw copy-pasted code overtake refactored code for the first time in history, and the DORA2025 report concludes that AI amplifies whatever an organisation already is, virtues and defects included.

Where the gap comes from

The full lifecycle models don’t just model writing code. They model a project: analysis, design, construction, testing, management and the communication overhead of a team. For a system this size, COCOMO infers a team of around 65 people. Ours was the equivalent of two.

That gives two readings, both compatible with the data: Either AI removed most of the construction effort, or AI let two people build what the models assign to sixty-five, and in doing so skipped the coordination cost that grows faster than the team itself. Our study can’t separate the two. The second reading is the more interesting one, because it says the expensive part of software was never typing, but coordination.

In money, using an average fully loaded employee cost in Spain (30 €/​h), the 2,784 hours cost about 83,520 €. The same system at the hours predicted by the most conservative model (ISBSG) would be about 2.85 M€, and at the COCOMO ceiling, 11.55 M€. The cost of AI itself (tokens, subscriptions, agent infrastructure) wasn’t subtracted because we haven’t measured it precisely yet; at 2026 prices it’s several orders of magnitude below even the most conservative saving.

Yes, we know

  • It’s one case, with no control group. It doesn’t say how long this team would have taken without AI. It measures the distance between real cost and what models calibrated before AI predict.
  • Lines of code are not functionality. Function points were approximated by backfiring (53 lines per point, QSM’s JavaScript median), and AI-generated code may be more verbose, which inflates line-based estimators. We haven’t measured by how much.
  • 69.2% of the hours are estimated, not logged. The calibration rests on two people. Every bias we could identify points towards undercounting hours, but its plausible size (tens or a few hundred hours) doesn’t change the order of magnitude.
  • Quality isn’t measured yet. The revert rate is not a defect density. Delivered defects, maintainability and technical debt are the next metrics on the list.

The exact ratio depends on the model. That it exceeds an order of magnitude does not.

Next: someone else checks our homework

A self-reported case study is a starting point, not a verdict. Three steps will turn it into a third-party verified one, in increasing order of cost: an agreed-upon procedures report (ISRS4400) by an auditor over the time tracking and git history; a manual function point count by a certified IFPUG counter, replacing the backfiring; and an ISBSG delivery rate filtered by size, language and application type instead of the global median.

If you do any of those three things for a living, we’d love to hear from you.

HAL never let anyone check his work. We built the whole method around the opposite idea. Vibe coding is a massive speed boost for whoever writes the code. AI-native development gives whoever answers for the result the speed and the confidence to put their name to it.

Sources

Tags:
AIClioneSoftware Development
Categories:
AI for eCommerce

You might also like these