On September 15, India — along with Sri Lanka and Tanzania — celebrates Engineer's Day, marking the birth anniversary of Sir M. Visvesvaraya. He was responsible for major irrigation and water-management projects, including the Krishna Raja Sagara Dam, and pioneered an automatic water-floodgate system first installed at the Khadakvasla Reservoir. He never called himself a founder. He was too busy building things that had to actually hold water.
I bring him up because somewhere between AI coding tools and the "building in public" era, a lot of people have quietly lowered the bar for what counts as engineering — and it's starting to show.
The New Delusion
You've seen the pattern. Someone drops a single prompt into an AI tool, gets a working landing page, deploys it on a free-tier host, and by evening they're introducing themselves as a "founder." No architecture decisions made. No idea what happens when the free tier's rate limit gets hit. No review of what the model actually wrote. Just a URL and a post about "building in public."
The problem isn't that they used AI.
The problem is that having something that works has quietly become synonymous with understanding why it works.
That's asking a vending machine for a soda and calling yourself a bartender.
The scary part isn't that AI can generate a working app in minutes — that part's genuinely great. It's that generating something and understanding something have quietly become interchangeable in a lot of people's heads. Ship fast, sure. Just don't confuse it with the part that makes you an engineer.
What The Difference Actually Looks Like
I got a concrete lesson in this earlier this year, solo.
The Rebuild
ShelfTalk started as a college assignment — a full MERN book-club app I built alone in a semester, shipped just well enough to pass, then left untouched on GitHub for months. GitHub's Finish-Up-A-Thon — a challenge built specifically around finishing AI-assisted work properly instead of leaving it half-done — gave me the deadline to go back in and rebuild it for production: real Socket.io chat instead of REST polling, a live synchronized reading room, a migration to MongoDB Atlas with GridFS, and a move off Create React App onto Vite that cut HMR times by roughly 80%.
I placed top 10 out of 500+ entries.
The Bug That Made the Point For Me
None of that taught me as much as a bug that showed up weeks later, in production. I'd added what I thought was a clever optimization to push notifications — suppress the desktop ping if the tab was visible, since nobody likes getting notified about a message they're already reading. Clean UX, I figured. Then users started missing direct messages, and my own testing couldn't reproduce it: the code was working exactly as I'd designed it.
The bug turned out to live in an assumption, not a line of code.
My code had quietly conflated "the OS can render this pixel" with "a person is paying attention" — and anyone running ShelfTalk on a second monitor was silently losing every notification, because a tab in full view is technically "visible" even if nobody's looked at it in twenty minutes. The fix was to delete the optimization I was proud of. A slightly redundant ping is mildly annoying. A silently dropped message is a broken product.
Nothing about that bug shows up in a demo, and you don't discover bugs like that by simply prompting your way through a project — noticing it required a user complaint and me sitting with "it's working exactly as designed" long enough to realize the design's core assumption was wrong.
Copilot wrote a lot of the ShelfTalk rebuild with me — it scaffolded the socket event handlers, caught import errors during the Vite migration, autocompleted UI patterns I'd have looked up manually anyway. But I wouldn't call any of it "vibe coded," because the version of vibe coding I'm criticizing skips the part where you find out your own project is broken and have to fix it under pressure.
That part — the reviewing, the debugging, the actually-knowing-what-you-built part — was the entire job. Solo, with no one else to catch what I missed. It was true for Visvesvaraya with concrete and steel. It's still true now with Copilot doing some of the typing, and it was just as true for one dumb boolean on a second monitor.
So — Where's the Line?
I don't think AI is the problem. I think the problem is how easy it's become to skip the part that makes you an engineer while keeping the part that makes you sound like one.
AI didn't remove the engineering work. It just made it easier to pretend you did it.
So I'll ask directly: where do you draw the line between using AI to build something and just watching AI build it for you?
Have you ever caught yourself on the wrong side of it? 👇
Top comments (65)
This is basically saying "If you print hello world, you are a programmer" with extra steps basically. It is easy to imagine that someone who is new to AI would assume they are engineers because how easy it is to build an app. In reality, there is so much that goes behind the scenes when you are releasing an app to the world to see such as design. best practices in engineering, authentication, and more.
Good stuff @dj29
Thank you! 😄. This is a better short summary of the post that I was looking for.
Genuine question: when AI writes most of the code, what part of the process still makes you the engineer?
Is it reviewing the output? Debugging it? Understanding the architecture? Knowing when the AI is confidently wrong?
Or is “it works” enough now?
I’m genuinely curious where people draw that line.
the notification bug is the real story here. it passed every test because it was never a code bug, it was an assumption about what visible means. that is the exact gap between demo and production that never shows up until a real user hits it. i think about this a lot from the hosting side, most vibe coded apps die from this kind of silent wrong assumption in prod, not from bad code
Absolutely
Yes. that's the thing. Even IITB's Eureka website. It's like really really slow retrieving data.
BTW Thanks for the read, Have A Great Day!
Honestly. Greenfield, I step back. I rather let AI write it and I focus my attention on making it document it properly. To get to a POC, is easy work, what comes after is where you need to really use your noggin.
Brownfield though... There's no such thing as 'just trust AI', anything that's not in isolation, especially if it's production, every single prompt has to be explicit and surgically scoped. Essentially all AI does then, is type it for me. But that's the difference between recognizing a bug's origin and it getting lost in optimizations? The days I tried to be lazy and just prompt a fix, I reviewed the work it did and it either blew it out of scope, or it made core changes that break the feature (eg. costs not adding up right). That's why if it's fixing, it's manual. If it's a fresh implementation, you can sit back while it preps the POC, then refine it hands-on from there.
This maps almost exactly onto the ShelfTalk story, actually. That notification thing wasn't a fresh POC — it was a small optimization dropped into an already-running production feature. By your rule that's exactly the kind of change that needed to be surgically scoped and reviewed manually, and it's exactly where it went wrong: the code did what I asked, it just wasn't scoped against an assumption I hadn't actually checked (what document.hidden really means on a second monitor).
Greenfield POC, sit back and let it prep. Anything touching a live assumption, you're back to doing the noggin part yourself regardless of who typed it. That's a cleaner split than "trust AI vs. don't" — it's really "did you validate the assumption you're patching around, or did you just trust that the fix matched your mental model of the system."
Exactly. People think that AI makes everything faster... Sure, at first... Then it slows down to just about the same pace, because if it's not in isolation, you need to be careful... AI isnt careful...
Yes! that's the proper conclusion. And it does slow down, there's a threshold/limit to everything. Also, I'll say again All The Best to you. Hope you get it. Have A Great Day!😄
Thanks! Fingers crossed!
The difference between using AI and understanding what you build is becoming more important every day. AI can write the code, but debugging unexpected behavior and making the right architectural decisions still require real engineering judgment. Your notification bug is a perfect example of how a small assumption can break an otherwise working product.
For more programming resources and developer tools, check out codecan.net.
Exactly. That distinction between “the code works” and “the solution is correct” is where things get interesting. The notification bug taught me that sometimes debugging means questioning the assumption behind perfectly working code, not just fixing broken code.
For me, the line is less about who typed the code and more about who owns the contract around it. Before calling an agent-generated change done, I want to be able to state the invariant, the failure modes, and the rollback or recovery path.
The “visible tab” bug is a great example: “the OS can render this pixel” is not the same as “a person is paying attention.” An agent can implement the handler, but the engineer still has to define the notification semantics, test multiple windows and background tabs, and observe whether delivery was acknowledged rather than merely attempted.
That is the bar I use for AI-assisted work: the model can compress implementation, but it cannot outsource responsibility for the assumptions.
This is probably the clearest way I've seen the distinction framed so far: AI can compress implementation, but it can't outsource responsibility for the assumptions.
The “contract around it” point especially resonates with me. In my bug, I had effectively defined “visible” as “being attended to” without ever making that assumption explicit. The code was fine; the contract was wrong.
And I really like the distinction between delivery attempted and delivery acknowledged. That’s the kind of detail that only becomes obvious once you stop treating the implementation as the whole problem.
the "asking a vending machine for a soda and calling yourself a bartender" line is the cleanest version of this i've read.
the part that trips up most AI assisted devs: the happy path looks fine. the unhappy path is optimistic by default. you only find out when production load is nothing like the prompt you wrote.
we caught this on a Next.js API route where the AI wrote a valid response cache — perfect in dev, eviction storm in prod under concurrent load. the prompt never mentioned concurrency.
what's your heuristic for knowing when AI generated code has been actually reviewed vs just tested green?
Well, I don't think “tests are green” is enough. My heuristic is whether I can explain the generated code, its assumptions, and its failure modes without asking the AI to explain it back to me.
Tests tell me this case works. Understanding tells me why it works and what happens when the assumptions change.
And that concurrency example is exactly the kind of thing that makes the distinction painful — the prompt can be completely reasonable while the production environment exposes an assumption you never explicitly made.
Really good point. AI can make the coding part much faster, but the real engineering still comes from understanding the problem, reviewing the output, testing it, and catching the assumptions that AI might miss. The notification example is a great reminder that “working code” and “correct solution” aren't always the same thing.
Exactly. “Working code” is such a low bar when the real question is whether it solves the actual problem. The notification bug was a pretty painful reminder of that distinction for me.
Really good perspective. The part about the production bug stood out to me — the code was working as designed, but the underlying assumption was wrong.
As a frontend developer, I’ve also found that AI can make implementation much faster, but it doesn’t replace the need to understand the code, question assumptions, and debug when things behave differently in the real world.
I think that’s the important distinction: AI can help us write code faster, but engineering still requires us to understand and take responsibility for what we ship.
Great read! 👏
Exactly. “Working as designed” is a surprisingly dangerous sentence when the design itself contains the bug. That’s probably the part of engineering AI makes easiest to underestimate.
If AI can mimic effort, where do we draw the line between skill and illusion?
That’s a really interesting way to put it. If AI can reproduce the visible signs of effort — code, commits, a deployed product — then maybe the harder thing to measure becomes the reasoning underneath it. Where would you draw that line?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.