Sloppapocalypse: everyone's a Developer now.

Mi appaiono molto spesso post o video di persone che fanno vedere il loro nuovo bot o il loro nuovo sito definendosi developer, poi provo il loro sito e vedo chiaramente i segnali che è stato fatto con l'utilizzo esclusivo di AI.

A volte parlo direttamente con il proprietario del progetto e gli chiedo:

Every week I see the same pattern repeat itself. Someone posts a screenshot of their new bot, their new app, their new "SaaS," with a caption like "built this in a weekend." The replies fill up with fire emojis. Nobody asks the one question that actually matters: do you understand what you just shipped, or did you just direct something else to build it for you?

I've been thinking about this a lot, and not really because of AI itself. It's about how easy it has become to call yourself a developer without ever earning the label.

Some context on me

I don't have a computer science degree to wave around. I'm an independent developer. I build things on my own: Discord bots, backend services, etc... whatever it takes to keep projects running that I designed, wrote, and broke myself dozens of times before they ever worked.

I learned to program without AI. Not because I was against it on principle, it just didn't exist yet. I learned by reading documentation to the end even when it was boring, by opening a stack trace and understanding, line by line, why my code wasn't doing what I thought it should. I learned to hate concurrency bugs by writing them myself, not by reading an explanation generated by a model.

That doesn't make me better than anyone who started later. It just means I had to build, brick by brick, a real mental model of how things actually work. That's exactly the part I see disappearing, replaced by a title people give themselves without the substance behind it.

Calling yourself a developer isn't the same as being one

Here's the thing I actually want to talk about: how easy it has become to call yourself a developer, a builder, an engineer, even a founder, without knowing what any of those words used to require.

Open any freelance platform and you'll find people with "Full Stack Developer" in their bio whose entire portfolio is a handful of apps an AI generated in an afternoon, apps they cannot explain, extend, or debug without going straight back to the same chat window that wrote them. Scroll LinkedIn and you'll see "I built and shipped an app in one weekend" posts from people who cannot tell you what a database index is, what happens under load, or why their authentication flow has a security hole in it. Some of them are already taking client work. Some are already calling themselves CTOs.

This isn't about gatekeeping credentials. Plenty of the best developers I know are self-taught and never finished a degree. This is about the gap between doing the work and directing a tool to produce something that looks like the work. Those used to be roughly the same thing, because there was no way to fake the second part without actually doing the first. That's not true anymore, and a lot of people are quietly building an entire identity on that gap.

Hashing a password that was never a secret

A while back I came across the source of a website built for a FiveM roleplay community. The repo was public on GitHub, with real data belonging to real community members sitting right there for anyone to clone.

The part that stuck with me was the "security." Somewhere in the code there was an admin password and an emergency override password, both run through a hashing function before being stored. Reasonable, on the surface. Except the actual plaintext passwords were sitting in the exact same file, hardcoded right next to the function call that hashed them. Something like taking a password, hashing it, and writing both the hash and the original password into the same public source file.

At that point the hashing does nothing. The entire reason you hash a password is so that even if someone gets access to where it's stored, they still can't read the original. If the original is sitting in plain sight two lines above the hash, in a public repository, you haven't protected anything. You've just added a line of code that looks like security without being security. On top of that, the rest of the data (settings, votes, candidate records, everything) was stored as flat JSON files with no access control at all.

And here's the detail that makes it almost funny if it wasn't also concerning: their own site's marketing copy described their setup as having an "encrypted and protected database." It didn't. It had a folder of JSON files and a password hash sitting next to its own plaintext answer key, made public for anyone with a GitHub account.

Nobody involved seems to have understood what hashing is actually for, what problem it's supposed to solve, or why putting secrets in source control defeats the entire point regardless of what you do to them afterward. That's not a skill issue in the sense of "didn't know a fancy technique." It's not knowing what the basic technique is even protecting against.

Crying in the chat window

The other pattern I keep seeing plays out differently but comes from the same place. I watched someone's AI coding session where every request bounced off a quota limit. "Quota exceeded, please try again later," over and over. Their response wasn't to read what had actually changed or check the code themselves. It was typing back into the chat, almost pleading: "There was an unexpected error. Finish what you were doing."

Eventually the agent ran again for over ten minutes, read a file, hit the same quota wall partway through, and came back with exactly two words: "I made some changes." No explanation of what, no diff to review, nothing. And the response to that was just to accept it and move on, until something broke badly enough that the only option left was restoring from a backup timestamp picked more or less at random, with zero understanding of what had actually gone wrong in between.

That's the whole failure mode in one screenshot. Not "using AI to write code," which is fine, but outsourcing the entire feedback loop: not reading the error, not reading the diff, not reading the fix, just waiting and hoping and occasionally begging. When the thing you're building only exists as a conversation history with a chatbot, you're not maintaining software anymore. You're maintaining a relationship with a tool that occasionally produces working code as a side effect.

Calling yourself a developer isn't the same as being one

This is the thread connecting both cases. Open any freelance platform and you'll find people with "Full Stack Developer" in their bio whose entire portfolio is a handful of apps an AI generated in an afternoon, apps they cannot explain, extend, or debug without going straight back to the same chat window that wrote them. Scroll LinkedIn and you'll see "I built and shipped an app in one weekend" posts from people who cannot tell you what a database index is, what happens under load, or why storing a password hash next to its own plaintext source defeats the purpose. Some of them are already taking client work. Some are already calling themselves CTOs, or advertising their product as having an encrypted database when it has nothing of the sort.

Vibe coding isn't the wrong word. Misusing it is

The term "vibe coding" doesn't bother me on its own. It describes a real way of working: throw an idea out, let the AI generate a rough structure, iterate fast, see if the vibe of the code feels right. For a prototype, a personal experiment, or quickly testing whether an idea holds up, that's a legitimate and honestly pretty smart way to move.

The problem starts when vibe coding stops being a starting point and becomes the only tool in the box, applied to things that end up in production, handling real users' data, things people actually pay for. At that point, "it feels right" isn't good enough anymore. You need to know why it's right, and more importantly, you need to be able to fix it when it stops being right.

The chess engine comparison people keep making actually holds up well here. Using a chess engine to play a match doesn't make you a strong player, it makes you someone who handed the thinking over to a machine that thinks better than you. Nobody calls someone a good chess player for winning by copying an engine's moves. Yet in software, for some reason, "I shipped a bot with a language model writing all the code" still gets treated, sometimes proudly, sometimes on social media, as proof of technical skill. It isn't. It's proof you can write a decent prompt. That's a real skill, to be fair, but it's a different one, and it deserves its own name instead of borrowing "developer."

What actually gets lost

This isn't only about technical purity, even though I know some people will read it that way. What worries me more is what gets lost in the process: the motivation to actually understand things, and with it, the real fun, the kind that comes from banging your head against a problem and beating it yourself.

When I was working on my early projects, the best moment was never "the bot works." It was the moment right before that, hours of not understanding why it didn't work, and then suddenly, often nowhere near a keyboard, getting it. That feeling is what kept me glued to this for years, unpaid, as a hobby, long before it became anything more serious. If you skip that phase systematically because the AI hands you an answer in thirty seconds, you're not just saving time. You're throwing away the part that actually builds skill, and along with it, the part that builds the reason to keep doing this at all.

So here's the question I'd actually ask, especially to anyone younger still figuring out their relationship with this work: why are you doing it? If the answer is "because I like understanding how things work," then use AI, but use it to speed up that understanding, not to replace it. Make it explain the code it generates, line by line, until you actually get it, and only then use it. If the answer is just "because I want the end result, the working bot, the followers, the install count," that's fine too, but at least be honest with yourself about it, and don't call yourself a developer for work you didn't actually do.

No solution, just an ask

I don't have a clean fix, and I doubt anyone does. Models will keep improving, the temptation to hand everything off will grow right along with them, and I don't think banning anything ever really works anyway.

What I can ask for is smaller. If you're starting out today, take the time to break things yourself before letting a model fix them for you. Learn to read a stack trace before you learn to paste one into a chat window. Understand what a line of code does before trusting that it does what it's supposed to. Not out of nostalgia for a way of working that isn't coming back, but because that kind of understanding, the ability to actually know what's happening inside the machine, is the one thing no AI will ever fully do for you forever. And when something really breaks, it's the only thing that will save you.