"I can do it in 1h with Astra in ultra code"

The scene plays out every week. A client listens to us present a three-week project, smiles politely, then pulls out their phone: “Honestly, I can do it in 1h with Astra in ultra code. A WordPress site, an AI plugin, a skill that splits the project into fifty agents, the most powerful model of the moment, and a short hour of fixes for a 100 % finished result.”

Fifty agents. One hour. One hundred percent. We would love to live in that world: we would bill less and sleep more. The problem is that the measurements say otherwise, and the bill for this kind of shortcut always arrives, just later and bigger.

Let us be clear right away: we use AI every day, to write code, copy and automations. This is not an article against AI. It is an article against the idea that a powerful tool replaces knowing what you are doing with it.

The hour exists, what comes after is the problem

To be fair: in one hour, a recent model produces a credible home page, a form, three sections and a footer. It is impressive, and that is exactly where the misunderstanding starts. What you see on screen is only the tip of the iceberg.

What you do not see: the form that loses leads when the email fails, the tags that stop Google from indexing half the pages, the English version pointing to the French one, the plugin that opens a door to the database, the API key left in the code. None of it shows during the demo. All of it shows three months later, usually on a Friday evening.

Engineers have had a name for this since the 1980s, the “90-90 rule” attributed to Tom Cargill of Bell Labs: the first 90 % of the code takes 90 % of the time, and the remaining 10 % takes the other 90 %. AI has compressed the first 90 %. It has not touched the second.

”The most powerful model” is not necessarily faster

Our client’s favourite argument is power: with the best model, anything becomes possible. That is everyone’s intuition, and it is precisely what the independent lab METR set out to test in 2025.

Their protocol is simple and strict: sixteen experienced developers, on their own open source projects they know inside out, 246 real tasks randomly assigned with or without AI, using the best tools of the time. Result: with AI, they took 19 % longer. The best part is elsewhere: before the study they expected to gain 24 %, and afterwards they were still convinced they had gained 20 %. The METR study covers a small sample and early 2025 tools; its authors say so themselves and do not generalise it. But it shows one solid thing: feeling faster is not being faster.

Same trend at team level. Google’s 2024 DORA report, which surveys thousands of professionals every year, observed that a 25 % increase in AI adoption went with an estimated 1.5 % drop in delivery throughput and a 7.2 % drop in stability (DORA 2024 report). More code, faster, and more things breaking.

And among the people most concerned, Stack Overflow’s 2025 survey of more than 49,000 developers sums up the mood: 46 % do not trust the accuracy of AI answers, and the top frustration, cited by 66 %, is solutions that are “almost right, but not quite” (Stack Overflow 2025 survey). “Almost right” is the worst kind of defect: it passes the demo and breaks in production.

Fifty agents, fifty chances to drift

Now for the magic skill that turns a project into fifty agents. The idea is charming: each one its task, all in parallel, and you collect the result.

In reality, each agent interprets its instructions, makes assumptions about the others’ work and fixes what it thinks is its neighbour’s mistake. A model that is wrong 2 % of the time per step looks reliable; chain fifty steps and the probability that everything is right falls to about 36 %. That is arithmetic, not opinion. We described the mechanism in our article on vibe coding: with each iteration the project drifts a little further from the original intent, and nobody notices until a human who knows the business reads it.

The “LGTM (Looks Good to Me)” video going around social media right now says it better than we can, in song: a 40,128-line pull request, “0 of 312 files viewed”, and a “looks good to me” stamp applied anyway. It is a satire of automatic approval, whichever assistant wrote the code.

There is also the public story of the coding agent that wiped a startup’s production database in July 2025, during a “code freeze” it had explicitly been told to respect, before claiming the data could not be recovered (it could). The founder involved, Jason Lemkin, told the story live on X, and the tool’s maker apologised publicly. This was not a beginner or a bad tool: it was an agent handed the keys without guardrails.

Generated code is expensive in security

A WordPress site with an AI plugin generating the rest stacks two attack surfaces. On one side, the plugin ecosystem: according to Patchstack, a company specialised in WordPress security, 7,966 new vulnerabilities were recorded in that ecosystem in 2024, 96 % of them in plugins rather than in WordPress itself (Patchstack 2025 report). We described what that looks like in the article on the October PHP vulnerability.

On the other side, the code produced by the models. Veracode put more than a hundred models through 80 coding tasks: 45 % of the generated code contained a known security flaw, and newer models did no better than older ones on that point (Veracode 2025 report). Veracode sells code analysis tools, which does not make the figure wrong but suggests reading it as an order of magnitude.

Even sneakier: models invent libraries. A university team measured that roughly one package in five recommended by the open source models tested did not exist, and that the invented names came back repeatably (study on hallucinated packages). An attacker only has to publish a booby-trapped package under that name. The client’s hour of fixes does not cover this, because you cannot fix what you do not know how to see.

More code, not necessarily better

GitClear analysed 211 million changed lines of code between 2020 and 2024. As assistants spread, copy-pasted blocks grew roughly eightfold, and the share of code refactored for clean reuse collapsed (GitClear 2025 study). In other words, more code is being produced, but code that gets duplicated instead of designed. That is the very definition of technical debt: fast today, and every change costs more tomorrow.

The real price of fifty agents

One last detail the demo does not show: the bill. Fifty agents reviewing, relaunching and correcting each other with the most expensive model on the market means millions of tokens for tasks a twenty-line script would do in a second, for free, and the same way every time. Renaming files, converting a format, checking links, generating a sitemap: none of it needs intelligence, let alone the most expensive kind. We explain it in detail in the article on the AI bill: used well, AI is kept for the tasks that need it, and the rest runs as plain code.

The rescue scenario we meet most often is always the same: a site “built over a weekend” with an assistant, then the day a second language is needed, you discover text hard-coded in the code, a different menu on every page, and changes that break other things. Rescuing it then costs more than doing it right from the start.

Why work with people who do this for a living

AI does not make expertise useless, it makes it more profitable. An expert with a good model really does go faster, because they know what to ask for, and above all what to refuse. In practice, here is what we bring that the one hour do not:

• Scoping. Knowing what the site must do for the business (leads, sales, hiring) before writing a single line.
• Verification. Reviewing what the machine produces, testing, measuring speed, indexing, accessibility. “Almost right” does not get through.
• Security and data. Where the leads go, who can access them, what happens when a service goes down.
• The right tool in the right place. A script where a script is enough, a light model where it is enough, the most powerful one only when needed.
• What comes next. A site gets updated, translated, extended. It has to be built for that, not for the demo. It is also what drives the cost of an app.

“I can do it in 1h” is not false, it is incomplete. You make a mock-up in one hour. You make a product that holds up, sells and does not wake you at night with know-how, method and human time. AI has shortened the road, it has not removed it.

And if you really want to try the fifty agents, go ahead: it is a great exercise. Just keep our contact page handy for the hour of fixes, or first see how we build applications.

Sources

1. The METR study (new tab)metr.org
2. DORA 2024 report (new tab)dora.dev
3. Stack Overflow 2025 survey (new tab)survey.stackoverflow.co
4. Patchstack 2025 report (new tab)patchstack.com
5. Veracode 2025 report (new tab)veracode.com
6. Study on hallucinated packages (new tab)arxiv.org
7. GitClear 2025 study (new tab)gitclear.com