Are We in the Era of Shitty Code?

There isn't a day that goes by without discovering a major security flaw or data breach somewhere.

Just yesterday, it was Github, which apparently opened part of its code as open source. Unintentionally, of course, but we can still appreciate the gesture.

Meanwhile, in France, it's 3 data thefts per day on average according to this article. But don't worry, apparently our prime minister has a solution: fire the director of the national cybersecurity agency (ANSSI)…

That said, the massive breach of France's secure identity document agency (ANTS) by a 15-year-old hacker via a trivial vulnerability was kind of the straw that broke the camel's back.

And according to some, AI would be responsible for the general decline in software quality, for example at GitHub where uptime would be in constant decline since GPT3 on this chart (and the arrival of Microslop but let's focus on just one culprit).

Okay, that's trolling. But some people wonder seriously: is AI really the source of all these problems?

That's what we're going to try to see. We're going to talk about the real reasons for the CVE surge but it will mostly be a pretext to wonder if we're really at the dawn of an era of AI-generated shitty code.

The Rise in CVEs

First, why am I talking about CVEs, and what is a CVE anyway?

A CVE (Common Vulnerabilities and Exposures) is a standard that catalogs all known vulnerabilities in a large database. Each CVE is listed under a super sexy little name, like CVE-2024-12345.

(Yes, it's quite thrilling, isn't it?)

So you're going to tell me, in the software world we talk about bugs, not CVEs, and you'd be quite right. But there's no catalog of bugs for all known software.

So here I'm taking the number of annual CVEs as a kind of indicator of the number of bugs in software because I think there's a small correlation between a decline in quality and an increase in security holes. At first glance anyway, but we'll come back to that.

And if we look at it, well the acceleration could date from 2022 with however a first step around 2017.

If we take 2017 as the turning point, it becomes hard to blame AI for the problem even with the bad faith of a a Marseille football fan (hey Max, if you're reading this, you know how you guys love to exaggerate).

Broadly speaking, the CVE increase since 2017 is probably explained by a mix of factors:

• greater pressure on software which is now expected to have a new version every day
• a general explosion of digital technology
• many more security programs (bug bounties)
• an increase in the number of software dedicated to cybersecurity.
• major geopolitical conflicts and more frequent cyber attacks

Actually, it's not unlikely that we're measuring the number of thermometers (and not just the temperature), so the rise of the cyber industry, and on the other hand, the rise of digital technology which is becoming an economic and geopolitical stake in a rather unstable context for years.

Now we can still question the post-2022 period because the slope seems to be climbing as fast as Trump's court cases.

However, I'd say that CVEs aren't the best proxy for measuring software quality because as we've seen, CVEs can increase for rather exogenous reasons. It's not because we're controlling things better than before and scrutinizing more that there are really more bugs.

So we're going to go back to the starting point and look at a sentence I hear very often: AI is the death of craft.

With AI, It's the Death of Craft

Craft, for those not following along, is kind of an umbrella term to group together a whole set of practices aimed at producing "quality" software. Assuming we can define what quality software is, but that's another subject.

With AI we wouldn't be crafting anymore and technical expertise, the appeal of the profession for many, would have disappeared.

Wait, here we have two different subjects:

• the appeal of the profession would disappear because we wouldn't be crafting anymore
• the code produced by AI would be to computing what English cuisine is to world gastronomy, i.e., not great.

(Well, let's set the record straight on the second point: no, English cuisine is vastly worse)

So some people have tried to determine whether code produced by AI was necessarily less "sustainable" than code produced by a human, in short, whether we were really building mountains of technical debt at light speed.

AI Slop and Software Maintenance

Do you know Dave Farley?

Dave Farley is notably one of the authors of the book Continuous Delivery released in 2010.

It was one of my reference professional books for years at a time when there was a lot of talk about software factories, quality, and continuous deployment. I worked for years on these subjects, particularly from 2006 on distributed CI concepts. I then worked from 2010 on industrialization themes, then from 2012 on continuous deployment.

(okay grandpa but continue your story)

Well Dave Farley participated in a study that aimed precisely to determine which code was more maintainable between code produced by AI or code produced by humans. Was there more technical debt in AI-produced code? And the answer is… no.

To be frank, even I'm surprised, and yet not at all.

I'm surprised because I know the engineering effort required for AI to work well. Without that effort, the code quickly looks like a slightly lopsided Frankenstein.

But, I imagine the study is about professionals who had time to set up their usual tools.

Building an Agentic Software Factory

I told you, I love building software factories, I've been working on this subject for years.

A software factory is nothing more than a manufacturing process, more or less industrialized and automated.

A code generator, however powerful, is not a software factory, it's just one of the factory's machines.

And if you just let one machine run, it's not enough.

When a dev only does copy-paste from ChatGPT from a browser, it's barely 10% of the work and yes, the result isn't great and often requires a lot of manual adjustments.

Now, being a bit provocative, I'd say that tweaking the generated code is a failure. Imagine the same thing in a car factory. If artisans had to retouch every car produced, it would be a bit surprising. And, I'm no specialist, but I don't think that's how it works.

Anyway, you need the other tools.

In our profession, this consists of building test and validation harnesses, defining rules to follow and finding ways to verify they're being followed, creating skills to guide AI agents' work and prevent them from crashing, allowing them to verify themselves with tools and therefore correct themselves, etc…

And that, actually, is craft. Using AI agents makes those famous best practices mandatory that everyone talks about but you don't see so often in practice.

All the people I see right now in the DevWithAI community are craftspeople trying to improve their software factory. They're people working on token compression tools like rtk, tools to simplify and standardize usage at team scale like packmind, usage guides like Florian's.

Craft hasn't disappeared. It has changed.

For a company, there's substantial effort required to introduce these tools, build a software factory on top, create tooling, do platform engineering, and you need people for that, the same way you need people to design, maintain, and evolve production chains in factories.

Briefly, no, the appeal of the profession hasn't disappeared in my view, for people who love craft and technical work.

And if we talk about quality, I'm going to surprise you but, at my scale, I see significant quality leaps in my applications.

The Writizzy Example

I develop several products, Hakanai and Writizzy. I recently put Bloggrify in maintenance mode.

Bloggrify started in 2022, Hakanai in 2023 and Writizzy in 2025.

For the first two, I barely used AI at first then gradually introduced some copy-paste from very discreet use of inline agents. So more than 90% of the code was produced by hand.

Well today I'd say that it shows.

Wait, I'm proud of what I did with Hakanai and Bloggrify. But to build an application solo you have to be very good at everything: building the application, its logic, its ergonomics, its UI, its robustness. But that's not my case. So sometimes there are places where it's a bit less good and it shows.

And beyond that, doing everything very well takes time. When building a product, you always have to choose between "perfect" and "good enough for most uses". The difference between the two being the time available.

Sometimes you give up, you know it's not perfect, but you've just spent 1 week on it, and frankly for a 5% quality improvement, forget it, we're not spending another week on it. That will be for next time. That famous next time that never comes.

Actually the quality of Hakanai and Bloggrify was variable. There were shortcuts taken, pages with ergonomics straight out of the 2000s web, and it doesn't matter, that's how we used to build products.

With Writizzy, that's completely different. I don't take shortcuts. First and foremost because to produce correct code with AI, you need a proper software factory, and that includes safeguards like tests, linters, etc… So it's non-negotiable, whereas ultimately it was negotiable before for Hakanai and Bloggrify.

Plus, the cost of refactoring has become almost zero. The small thing missing for a feature to be perfect, now I can do it.

Actually today I can take the time to handle edge cases, those famous little exceptions that before you'd leave aside because "that never happens". I can use the time saved on dev to think more about security, robustness, scalability.

Producing code has become a commodity. So I take advantage of it to produce very good code.

Briefly, I'm still crafting, but its nature has changed.

And what I produce is better quality. So I'm not convinced we've entered an era of shitty code.

Now there's still a nuance to add. AI drastically lowers the barrier to entry. That's good, but it means we end up with a flood of stillborn software, things that won't survive longer than a shitcoin promoted by a Dubai influencer, and companies that are going to cut hard on R&D costs because… laziness, and what if we increased margins. So yes, under those conditions, we're going to have an increase in the number of poorly produced software, software that will die after 3 months because their creators will get bored very quickly faced with the reality of actually managing an IT product. But good products will on the other hand be much better because craft will be a sine qua non condition for not crashing in a world where everything will move much faster.