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 (98)
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.
@francistrdev Spot on! Expanding on the "Hello World" analogy, AI essentially lets people auto-generate the whole application's skeleton instantly, but the invisible infrastructure, security, rate limits, performance, edge cases, is where real engineering actually lives. Relying purely on the output without understanding those underlying layers is a recipe for silent production failures.
In your own workflow, what’s one non-negotiable step or check you always run manually before letting AI-assisted code go live?
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.
@dj29 I believe the whole idea of "Engineer" is the one who fix the problems. If one can do it quicker with the help of AI for redundant task and then fix the broken linkages and get it done Fine tuned with own 'Engineering Mind", still a good engineer.
Day is not long where reviewing, debugging, architecture building will also have distinct AI agents, then it will be interesting part to know, AM I STILL A ENGINEER or AI AGENTS MANAGER?
This really hits the core issue with AI-assisted development: generating code and engineering a solution are two different things.
AI can dramatically reduce the time spent writing boilerplate, but it doesn’t remove the need to understand the system, question assumptions, debug unexpected behavior, and validate the result in real-world conditions.
The notification bug is a great example. The code was technically correct—the assumption behind it was wrong. That’s exactly the kind of problem that a working demo can easily hide.
I think the real skill in the AI era is becoming less about “Can you write the code?” and more about “Can you understand, validate, and take responsibility for what the code does?”
I think the biggest distinction for me is whether you understand what you built well enough to take responsibility for it.
I use AI when I code, and I don’t think having AI write a large amount of the actual code automatically makes the work less legitimate. But “it generated something that runs” and “I understand this system, can debug it, recognize when the architecture is wrong, and know what to do when it breaks” are very different things.
That notification bug is a perfect example. The code was technically doing exactly what it was supposed to do. The problem was the assumption behind it. That’s the kind of thing you only really learn by actually working with your own software beyond the initial generation step.
AI can remove a ton of typing. It definitely doesn’t remove the thinking.
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!
I think the line is less about how much code AI writes and more about whether you can still explain, debug, and change it when the assumptions break.
Your point about the bug living in an assumption really hit me. When you come back to an AI-assisted project weeks later, what do you rely on to recover why those assumptions or decisions were made — your memory, docs, commit history, or something else?
That’s a really good question. Honestly, I try not to rely on memory alone. For anything non-trivial, commit history, PR discussions, docs, and the code itself become the trail back to why a decision was made.
But I think there’s still a limit to how much you can reconstruct later. If I can’t explain the assumption without digging through everything again, that’s usually a sign I didn’t understand it deeply enough when I made the change.
That’s probably where I draw the line with AI-assisted work: the codebase can preserve the decisions, but the engineer should still understand them.
Yeah, I think that’s a really important distinction. The codebase can preserve the trail, but being able to reconstruct that trail isn’t quite the same as having the context available when you need it.
Especially when a project gets old and the “why” is scattered across commits, PRs, docs, and old discussions. That gap between preserving context and actually recovering it is interesting.
The "easier to pretend" framing is the part most teams skip. The trap isn't that AI writes bad code — it's that the output looks finished in a way that pushes the real work (edge cases, failure modes, the boring integration) past the moment you'd normally notice it's missing. One habit that helped me: before reviewing the diff, I ask "what would break this in production that the diff doesn't show?" Almost all the actual engineering ends up being that second question, not the first draft.
The notification bug story is the sharpest illustration of this I've read — the failure lived in an assumption, not a line of code, and that's exactly the kind of thing a prompt-generated app never surfaces until production.
I've been running the mirror experiment: I use AI to generate a first draft of a service, then I force myself to write the load tests and failure-mode tests before I look at the generated code. The AI output passes "does it compile" and "does it return 200" instantly. It fails "what happens when Neon autosuspends mid-transaction" or "what happens when the free tier rate limiter kicks in" almost every time. The delta between those two test suites is where engineering actually lives.
Your vending machine analogy is brutal but fair. The part that worries me is that free-tier hosting (Vercel/Neon/Supabase) makes the "vending machine works" phase last longer — you can get to real users before the assumptions collapse, which raises the blast radius when they do.
When you rebuild projects like ShelfTalk, how do you decide which parts to hand to AI and which parts you refuse to delegate? Is there a specific class of problem (auth, data integrity, concurrency) where you've drawn a hard line, or is it more of a gut-feel boundary that moves with the deadline?
Well, before I revived it for the DEV challenge. It had normal features like auth, posts, chat, which weren't that hard to implement cause it was originally a college assignment, to build a MERN project.
Then when I revived it for the challenge, the task was to use copilot only. So, whatever things I added I won't lie did with help of copilot, cause that was the challenge and then deployed it to vercel-render and tested everything and solving bugs one by one.
The danger is that generated output can make progress look complete before anyone has accepted responsibility for the system behavior. A useful countermeasure is to require an owner to state the invariant, the test evidence, and the rollback plan for any material change, whether or not AI helped write it.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.