The hidden beauty of vibe coding
"It passed all the unit tests, the shape of the code looks right," he said. It's 3.7x more lines of code that performs 2,000 times worse than the actual SQLite. Two thousand times worse for a database is a non-viable product. It's a dumpster fire. Throw it away. All that money you spent on it is worthless."
https://www.theregister.com/2026/03/17/ai_businesses_faking_it_reckoning_coming_codestrap/
@gerrymcgovern
Vibe coding is fine as long as you use it for personal projects or for proofs of concept.
As soon as you start using it for "real" applications, you lost.
@poprox @PatrickTingen @gerrymcgovern
Given that, when a model is trained with GPL code, it has to be GPL'ed itself, would be fair.
No fun to say, but I think copyright/IP issues have a long way to go until the whole thing is settled and needless to say, is has to be fair
@poprox @PatrickTingen @gerrymcgovern The problem is that all coders take from other people, copy code, and vibe coding does this better, in theory.
There is a lot of harm, and there are - IME - better ways of ding this. Or at least, there were, until they were all enshittified.
Do you have a link you would like to share about this 1000 times slower implementation of a SQLite instance?
@curious_carrot @dpnash @gerrymcgovern yes. (and you have it too.)
oh, and it's 20000 times slower, actually.
@gerrymcgovern This is an unusual article. It mixes truth and misconceptions in awkward ways.
For example:
Smiley pointed to a recent attempt to rewrite SQLite in Rust using AI
This isn't what happened. It was a C Compiler that was rewritten. A different tester then rebuilt SQLite using both the AI and the official one. The AI one did worse.
But it did worse for very specific reasons. The AI version was only tested for correctness. It was only given unit tests as a parameter for success. It failed on real world performance tests, because it was never actually given that as a requirement.
Lines of code, number of [pull requests], these are liabilities. These are not measures of engineering excellence."... Measures of engineering excellence, said Smiley, include metrics like deployment frequency, lead time to production, change failure rate, mean time to restore, and incident severity.
So these are famously known as the DORA metrics. And they don't measure engineering excellence, ... /1
@gerrymcgovern ... they measure the capabilities of the engineering platform along with the expertise of the people using that platform.
There are lots of companies with excellent engineers and crummy DORA scores because they don't have the institutional support to improve those metrics. Nor does the score mean the business is successful. You can have great DORA metrics and still lack for paying customers.
"The other challenge here is that the incentives are misaligned,"
But then he proceeds to list a bunch of examples for competing incentives. His examples of "misaligned" are really examples of "I would like to deliver less and get paid more"... /2
@gerrymcgovern ...
If there's an incentives problem here, it's that companies have been paying for a lot of BS rituals and they're discovering that the BS generating machine is undermining part of the ritual. Companies have also been getting away with under-specifying success in order to pad results as "good". But Gen AIs will "fill in" the under-specificity with made up data. Or they will fail to deliver anything into the gap that some human was hoping would be filled.
But none of this is "misaligned". It's intentional ambiguity designed to protect business units. The AI is just exposing the BS for what it is.
OP is kind of talking about that BS problem. But he's taking weird micro angles to view subsets of the problem without calling out the greater problem. He's not wrong, but he's also not really right either. 🤷🏻♂️ //
"This isn't what happened. It was a C Compiler that was rewritten. A different tester then rebuilt SQLite using both the AI and the official one. The AI one did worse."
There seems to be some confusion on your part. I suspect you're thinking of Claude's C Compiler, which made a hash of building SQLite (although it's impressive it managed that at all).
If you follow the links from this article, they're referring to an analysis of FrankenSQLite (https://frankensqlite.com/), which is billed as a "clean room reimplementation", from the same guy who vibe coded an 80k LOC disk cleanup daemon to replace a one-line cron job. 🙄
And it runs. It's just awful.
https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code
The article quote is this:
It's 3.7x more lines of code that performs 2,000 times worse
Which is very close to this experiment here. They get over 3x the compiled size & slowdown numbers as bad as 150k times worse.
I had no idea about FrankenSqlite.
Based on the tenor of the original article though, it sounds like he was talking about the CCC experiment because that was a comparable attempt. This Franken thing actually tries to improve upon SQLite.
OP's article Links to a medium article which doesn't link to either the CCC thing or the Franken thing. The Medium article seems to reference the Franken thing, but doesn't link it directly either. OP's article seems like it could be either one 🤷🏻♂️
Thanks for the extra data, I think it's notable that the arguments I make stay the same either way. 😃
Even for FrankenSQLite, It's clear that they had a limited scope of performance tests.
@gatesvp @gerrymcgovern
"OP's article Links to a medium article which doesn't link to either the CCC thing or the Franken thing."
Please follow the links. Like, really read the articles in detail.
OP's article from The Register (https://www.theregister.com/2026/03/17/ai_businesses_faking_it_reckoning_coming_codestrap/)
links to >
Medium (https://medium.com/write-a-catalyst/an-ai-wrote-576-000-lines-to-replace-sqlite-7ea538826d72)
links to >
Katanaquant (https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code)
links to >
FrankenSQLite.
It's all there.
I don't discount that Smiley might have mixed up their stats in the Reg interview with the 3.7x LOC quote, since that is quite similar to the CCC figures.
Both are relevant to the articles tenor though - AI can output code that will run, but lacks domain knowledge and will do exactly what you ask it to, even if it's ridiculous ("Hey, write me a cleanup tool", instead of "what's the best way to do this cleanup - 1 line cron job").
It's all there.
3 links deep.
Honestly, there's a whole separate discussion to be had about how lazy the OP article actually is.
It's quite possible that you and I have not spent more time analyzing the article than the author spent and actually writing it. 😃
Which probably means we need to start writing our own and better articles. 😃
@gerrymcgovern You love to see it:
"Insurers, he said, are already lobbying state-level insurance regulators to win a carve-out in business insurance liability policies so they are not obligated to cover AI-related workflows. "That kills the whole system," Deeks said."
Someone will be left holding the bag when slop kills someone, bankrupts a business, or causes serious damage. Insurers will make sure it isn't them.
@gerrymcgovern The original article has it at 20000× worse x)
https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code
@gerrymcgovern there's so much good stuff in there
> Lines of code, number of [pull requests], these are liabilities. These are not measures of engineering excellence."
@matthewskelton @autonomousapps @gerrymcgovern
"But if I apply proper practice, I practically need to reject 100% of the generated code."
Yes. Yes indeed.
@matthewskelton @autonomousapps @gerrymcgovern
That would require taking full responsibility for the code, moving away from today's agentic coding back to using LLMs as an assistant only.
And to make that term less vague, I'm picturing just consulting the chat interface on an as needed basis, allowing only the most mundane self contained function commits maybe, that's it.
@orchun @matthewskelton @gerrymcgovern the institutional pressures are seemingly insurmountable in many cases. I myself worked somewhere where they counted token usage and treated that as an important input in perf review. Managers frequently said "you should use ai more." This is not uncommon. Many tens of thousands of jobs have been destroyed with "ai" as the putative cause.
Silicon Valley may have to burn to the ground before we can change directions on this
@autonomousapps we're being threatened with a good time again? 🤣
@bweller @autonomousapps @matthewskelton @gerrymcgovern
Really the core problem hasn't changed, exact same issue as the pre-LLM era: managers who don't know much about software development feel free to dictate how it should be done.
Agile was an attempt to take that control back, and they co-opted it.
Devs weren't the target audience.
@autonomousapps @orchun @matthewskelton @gerrymcgovern
We need to talk about your use of tokens
In addition to the often abysmal quality, there's also a big misunderstanding about what the role of the software engineer is in a project. It's not to produce code, but to vouch that the software created is fit for purpose. "Tests pass" can ever be only a tiny part of that.
Letting people use generated code you did not comb through and verify, shows that you have no respect for those people.
Thread on #VibeCoding In my 25 years of professional software engineering, I've written big chunks of code in about ten programming languages, and smaller bits with five more. Still, if I was tasked to build software with OCaml – a language I only know from Wikipedia – I'd need to take a long hiatus to learn OCaml before I could let anyone use a single line of code I've written in it. Why? Because software engineering is so much more than generating lines of code. 1/6
J4ck
Gerry McGovern
Martin Rundkvist
Tingelmans 😎
poprox
circus_maximus
Becca
Schroedingers_Cat
zipkid - Breaker of Systems
David Nash
Curious Carrot
Phil Dennis-Jordan
flere-imsaho 🇺🇦
tony 🏳️⚧️ 🏴 🚴🧗🏻
Morten
Cybarbie
Gaëtan Perrault
richh
arclight
Deborah Preuss, pcc 🇨🇦
UpLateGeek
Antoine Pintout
Mike Spooner
Matthew Skelton
Not a Spring Onion
Orchun Kolcu
Howard Chu @ Symas
Stoneface Vimes
Maarten Engels
mirabilos
Timo Tiuraniemi
Cameron Dutro
Adrian Morales