Every developer feed I opened this week had some version of the same argument. Someone writes code with AI, ships it without really reading it, and somebody else asks: is that engineering, or is that just typing?
I read the post that started it, went through a chunk of the comments, and followed a few of the studies people kept linking in there. Here's what's actually in them, and who said what.
Giorgi Kobaidze started it
Vibe Coding Isn't the Problem. Calling It Engineering Is by Giorgi Kobaidze pulled in over 200 comments, which for dev.to is a lot. Not quick reactions either, people were writing full paragraphs, some coming back a second time to keep arguing.
Giorgi splits AI-assisted coding into three modes. Vibe coding is prompt, get code, ship it, without reading or really understanding what you shipped. AI-assisting is the AI writes it but a human reviews every line before it goes anywhere. AI-assisted is somewhere in between, human and model actually working together with the human still driving.
He's fine with the first one for personal stuff, weekend projects, things nobody depends on. Where he draws a hard line is anything touching money or personal data. His exact reasoning: if you build something real, something processing people's data or handling money, and you vibe code it start to finish, that tells him one of three things, you're not willing to spend two to four weeks learning the basics, you don't actually understand what you shipped, or you're doing it anyway just to prove a point. His line on that last one was blunt, doing it to prove a point will cause absolute chaos.
One commenter, who said they build things this way themselves, actually agreed more than they pushed back. They pointed out the trend toward more abstraction has been going on since assembly language, and maybe the job eventually becomes mostly prompting. But they landed in the same place Giorgi did, that's a question about where the industry is headed, not whether we're ready to run financial systems and health apps on unreviewed code right now. Their answer to that second question was no.
Someone else in the thread put it in a way I keep coming back to. It's not really about how much code the AI wrote. It's about whether someone can still explain the architecture, name the assumptions, and say where it's going to break. You could have AI write 95 percent of a system and it still counts as engineering, as long as a person can back up every part of it if asked.
Dhruv Jani brought the data
AI Didn't Remove the Engineering Work. It Just Made It Easier to Pretend You Did. by Dhruv Jani got its own solid comment thread going. Worth noting, Dhruv's an upcoming trainee engineer, still a student. So this isn't a twenty-year veteran being nostalgic, it's someone walking into the field right as this argument is playing out.
His piece leans on actual research instead of gut feeling. He cites a Carnegie Mellon study that tracked over 800 open-source projects after teams adopted AI coding tools, checked against a control group that didn't. The pattern showed up consistently, an early burst of speed, then code complexity and static-analysis warnings climbing, then eventually future velocity dropping below where it started. Faster at first, slower later. He also references similar METR findings, this time in developers who already knew their codebase well, so even familiarity didn't fully protect against the slowdown.
He's not arguing AI is bad. His point is closer to, AI speeds up the boring parts, boilerplate, prototypes, repetitive scaffolding, and that's genuinely useful. It just doesn't make the hard engineering decisions go anywhere, understanding failure modes, architecture, how something behaves under real load. Those two things get treated as the same thing in a lot of the AI-replaces-engineers takes, and they're not.
Elmar Chavez's post sits with you longer
The Slow and Quiet Cognitive Atrophy of a Modern Software Engineer by Elmar Chavez goes somewhere different. He's not worried about one project shipping broken. He's worried about what happens to your own instincts after months of accepting suggestions instead of actually working through a problem yourself. You don't notice it in any single sprint. You notice it the day the tool isn't there and you realize you've lost the thread of how you used to think something through.
The security research surprised me a bit
I expected the security angle to be the weak part of this argument, the part where people exaggerate. It wasn't. A security firm called Escape.tech scanned about 5,600 apps built on popular AI app-building platforms and found over 2,000 vulnerabilities, 400 exposed secrets, and 175 cases involving leaked personal data, some of it medical records and bank details. Separately, a different team tested five popular AI coding tools by having each build the same three applications, fifteen apps total, and found 69 vulnerabilities across them, six critical.
There's an academic study too, 200 real feature-request tasks pulled from actual open-source projects, run through several coding agents. Most of the solutions worked functionally. Only around one in ten were actually secure. Even hinting at the vulnerability in the prompt didn't fix that much.
None of this means the tools are useless, obviously they're not, people are shipping real things with them every day. It just means the gap between something that runs and something that's safe to hand to real users is bigger than most of us assume, and closing that gap is still mostly a person's job, not the model's.
Where I actually land on this
I run a small agency. Most of what we build is fast-turnaround client work, animation-heavy frontends, the kind of thing where the deadline is real and nobody's paying me to sit and admire my own code for a week before it ships. I use AI every day now, it's changed how fast I get from a blank file to something working.
But a few months back I had a client site where AI had generated a form submission handler that looked completely fine, worked in testing, and quietly duplicated database entries under load because of a race condition I didn't catch until a client complained about seeing double bookings. Nothing about the code looked wrong on a read-through. That's the part that stuck with me. Giorgi's framing matches that experience closer than I expected, it wasn't that AI wrote bad code, it's that I didn't understand it well enough yet to know what to check for.
For me the actual test isn't how much code the AI wrote. It's whether I still understand the decisions behind it well enough to fix it fast when it breaks, usually at a bad time, usually with someone messaging me about it.
You still review. You still ask why something works the way it does. You still need to know the architecture well enough to catch the thing that technically runs but is going to bite you in three months. The security numbers above make that review step feel a lot less skippable than it used to.
Where this leaves things
None of the three writers here are saying AI shouldn't touch serious codebases, Giorgi even said he'd welcome a future that's mostly prompting. The disagreement is about where responsibility sits once something ships, and that's worth arguing about properly instead of picking a side based on a headline.
I don't think there needs to be one universal rule for how much AI-written code still counts as engineering. But there's a point past which using the tool stops being useful if you can't explain what it actually produced. That's roughly the line I try to hold myself to, some days better than others.
Credit to @georgekobaidze , @dj29 , and @codingwithjiro for kicking off a conversation this week that was actually worth reading in full, not just skimming the title.
Curious if anyone else here has had a similar wake-up moment with AI-written code.
Top comments (0)