On September 15, India — along with Sri Lanka and Tanzania — celebrates Engineer's Day, marking the birth anniversary of Sir M. Visvesvaraya. He wa...
For further actions, you may consider blocking this person and/or reporting abuse
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.
The line about "having something that works" becoming synonymous with "understanding why it works" is the whole argument in one sentence. I've seen this firsthand — I run security APIs where the output has to be correct, not just plausible, and AI-generated code that "works" against 5 test cases falls apart on edge case 47 because the person who shipped it never read what the model actually wrote. The dam metaphor is perfect: a landing page that breaks at 100 users costs nothing, but the habit of not understanding your own code compounds every time you ship something bigger.
The notification bug is the perfect illustration because it inverts the usual AI-critique. Everyone worries about AI writing wrong code. Your bug was right code built on a wrong model of reality — the tab being visible didn't mean the user was looking at it. That's exactly the failure class AI makes more common, not less: the model optimizes for the stated rule (suppress ping when visible) with zero access to the unstated physics of human attention.
Where I part ways slightly: I don't think the "prompt → deploy → founder" crowd is pretending, exactly. I think free tiers have made the cost of being wrong about architecture effectively zero, so the penalty that used to force understanding — the 3am pager, the bill, the angry user — now arrives months later, after the person has moved on. The engineering work isn't skipped; it's deferred to someone else, usually the next hire.
I've been running my side projects entirely on free tiers (D1, Workers, Ollama on a home box) precisely to test this. The interesting finding: the moment latency or rate limits bite, you're forced to actually read what the AI generated. Free tiers are accidentally the best engineering teacher left, because they reintroduce scarcity.
Curious about your ShelfTalk experience: when you rebuilt it for production, how much of the original AI-assisted code survived review? I'm trying to figure out whether "finish AI work properly" mostly means rewriting it, or whether reviewable AI output is actually achievable with the right prompting discipline.
Wow, Cool comment.
Well, I revived it for A DEV Challenge Github's Finish-Up-A-Thon, and well it had to use copilot's assistance to revive it.
The later is actually achievable, I've seen a lot of people do it in companies, even my not so great internship. Also, from a lot of pre-placement talks, companies talk about how they first define specs for the project and then start generating, reviewing code. I don't have a lot of great details about it cause I'm still in my final year in college. But yeah!
Have A Great Day!
The line I use is recovery ownership. For an agent-generated change, “I reviewed it” is too vague unless I can explain the invariants, reproduce the tests, inspect the diff, and recover when the agent’s assumption fails. In brownfield work, I also want a small change boundary and a rollback path before letting an agent touch production-facing code. The typing is cheap; the evidence that the change is safe is the engineering.
Yeah,
Great Insights! I don't have anything to add to this so I'd rather not manufacture a conversation but, Have A Great Day!
I think the interesting part is that AI has exposed a distinction that was already there: building something and understanding what you built have never been the same thing.
AI just makes it much easier to cross that gap without realizing it.
For me, the real test isn't whether AI wrote 10%, 50%, or 90% of the code. It's whether you can still sit with the system when something unexpected happens and reason your way through why it happened.
A generated application can work perfectly and still be poorly understood by its creator. And ironically, that's probably where some of the most valuable engineering learning happens — when the thing you built behaves differently from what you expected.
The notification bug is a great example because the code wasn't necessarily "wrong." The mental model behind it was incomplete.
I think that's the line I'd draw: AI can reduce the amount of typing required to build a system, but it can't remove the responsibility of understanding the system you're shipping.
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.
My line: if I can explain the change, I'm using AI; if I can only parrot "the agent said so," I'm pretending. Now I make the agent output a "what/why/risk" summary and read it before merging. Time-to-get-caught went from "two weeks post-deploy" to "five minutes before merge" — better than nothing.
Visvesvaraya is the right anchor for this. A dam does not fail gracefully on a free tier. The closest thing I felt to this: the happy path of my payment webhook code worked on day one, and the real engineering was answering what happens when storage dies mid write, or the same event arrives twice. None of those questions fit in a prompt. Your notification bug is the same class of failure: the code did exactly what it was told, the assumption underneath it was wrong.
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.
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.
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.
This really resonates with me as a backend developer. AI has made boilerplate, scaffolding, and exploring solutions much faster, but it has not removed the responsibility of understanding what we ship.
In backend systems, the difficult problems often appear beyond the happy path: authentication, data consistency, idempotency, failure handling, performance, observability, and security. A solution may work in a demo while still failing under real users or unexpected assumptions.
For me, the line is simple: if I cannot explain the design, test the edge cases, debug the failures, and take responsibility for the result, I did not truly engineer it—I only requested it. AI is a powerful assistant, but engineering judgment still remains human.
What a Great Post, Honestly... and to be honest, Prompting an LLM or What ever AI to Build a Landing Page for a Website can be the " YES i did it moment" or just a "WOW Signal"... But Developing a thought , an idea or concept into Something, Well lets call it a STABLE Running SYSTEM is something Different. THE big BUT is , i guess. AI, KI, LLM, Agents and so on are Powerfull tools, if the Mind behind it keeps Track... Does the Develeopment... THKS 🤯
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.
AI can generate working code, but questioning the assumptions behind that code is still the real engineering work.
This is exactly it. AI can generate the implementation, but someone still has to interrogate the assumptions that led to that implementation. That’s the part that gets much harder to outsource.
I use AI to help me write code a lot of times but I will never call it vibe coding because I never commit any AI code without understanding exactly what the AI is doing.
That's the distinction between AI-assisted engineering and vibe coding.
BTW Thanks for the read, Have A Great Day!
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?
Non-engineers still need to know the basics. If you mess up the AI's foundation, you’ll end up rebuilding the entire system. That’s a lot more expensive than just rewriting code.
Yep — and that’s where “I can always fix it later” gets expensive. If you don’t understand the foundation, you may not even know what needs fixing until the whole thing starts fighting back.
The notification bug is such a good example. I've shipped enough AI-built tools to know the happy path is the easy part. The weird user behaviour is where the real work starts.
Writing code was always the easiest part of software engineering. Understanding what to build, handling edge cases, and keeping data private was always the hard work.
Sir @francistrdev, Hope you're doing well. If you're free I'd love an opinion in here.🙃
Also, @xulingfeng, I'm actually understanding your work right now, So, it'll take time for me to start commenting on your posts😅.
Yes yes I have it bookmarked for now. Will let onto it later today.
Cool. That's better its night here anyway. Also, my short break after exams is over. So I'll be in college tomorrow but well this really made me laugh very hard!🤣
na ur hallucinating. Prob a bug or something.
Take all the time you need. Happy you’re diving into the writings 😄
Yeah! I saw you've got a lot of good stuff and a well received ongoing series but I was still in my exams phase last week. Thing is I enjoy the kind of work you have. Also, I love the chinese anime called "Battle Through The Heavens" but lost track of it since las couple of months.
Anyways, Have A Great Day!😅
Glad you like the series! Hope your exams went smoothly. Battle Through The Heavens is amazing👏
For me, it's a matter of understanding what you want to hide AI to build. Is it repetitive work, or are you trying to just delegate it a task that you should handle on your own?.
The 2nd part which is something that shouldn't even be rocket science, learn to debug the code AI generated for you. It doesn't always get things right, especially scalability wise.
The line for me is knowing what to use AI for and where to use your skills as a developer to build a solid product.
That first question — what are you actually trying to hide from yourself — is a sharper way to put the thing I was circling around in the ShelfTalk story. I wasn't delegating the boring part, I was delegating the part I'd already assumed I understood. Same trap as offloading repetitive work, except worse to catch, because you don't know you're hiding anything from yourself until a user tells you.
Thanks for the read! Have A Great Day!
You're welcome!
I vibe with that. Have some batchmates who wrote founder @ X after their first OSS project and have no users.
Well, any of that isn't bad! Thing is I've seen now even teenage students deploying single page html files calling html/css/js as their stack and doing that.
Also, I had a friend who wrote something like that on resume. And he got job offer after me, even though having better GPA. 😅
thats it. I think now there should be definition of vibe coding and AI assisted engineering be taught in college too. ha.
Makes sense!😆
Cause sometimes its infuriating. Also, Congrats on winning the DEV challenge. But I'd like to ask how do you use AI in daily life like as a developer.
Thanks! Also, I'm right now just a final year student. But I'm placed. But I do use AI for hackathon projects and sometimes just to try an IDE. Do you want to ask anything specific?
A useful dividing line is whether the builder can describe the failure boundary before production describes it for them. What happens on a duplicate request, a partial write, an expired credential, or a rollback after the schema changed? AI can make the happy path remarkably cheap. Engineering is still the work of deciding which failures are acceptable, making the rest visible, and proving recovery actually works.
That's a great insight. I should've added that😅. These questions are what still define engineer. Have A Great Day!
the notification bug is the real story here. same thing happens in automated workflows all the time, something reports success and the actual state is wrong, and nobody finds out till a user complains. AI makes the code faster to write. it doesnt make you check your assumptions faster, that part is still on you.
This is basically the whole piece in three sentences. And the automated-workflow parallel is the right generalization — this isn't actually AI-specific, it's just how confidently-wrong systems have always failed. AI just made the "reports success" part cheaper to produce at scale, which is exactly why the checking has to scale with it instead of quietly getting skipped.
Thanks for the read! Have A Great Day!
Hmm ... I am not sure I get the gist of the article. The way I understand it is that the author has learned that "shaping the output of a program to make it look like the intended result of any kind of processing an input in a desired way" is not the same as developing an actual workflow.
Or, putting it another way, the article to me feels like a first experience of "wait, AI does not understand what it's doing, it's just outputting something that makes me feel like it does".
If a software - or any kind of process - is only built around the "visual" (or any other perceiptive way of considering) output instead of a well-defined process, then it is what today's software (including operating systems) most often is: features without functions.
"Engineering" (see other articles here and elsewhere) is NOT "create a desired output by defining the output only". Engineering includes understanding the process from a to b, if required including a pit-stop at c. No vibe-code, no AI-assisted "make output from input" is "engineering", it is "massaging an unknown pipeline into virtually doing something I feel like it might do the job".
I may be completely wrong though and misunderstand what the article is saying.
Hey Marc, thanks for actually engaging with it — you got a good chunk of this right. "Shaping output to look like the intended result" vs. "developing an actual workflow" is basically my thesis said better than I said it.
One correction though: it's not really about discovering that AI doesn't understand what it's doing. I already knew that going in — that's not news to anyone who's used these tools for more than a week. The actual bug in the piece was a wrong assumption sitting in my head, not the model's: I conflated "the OS can render this pixel" with "a person is paying attention," and no amount of AI competence or incompetence was ever going to catch that for me. The engineering was noticing I'd shipped a wrong idea about the world, not noticing AI was limited.
Your "features without functions" line is close to that from a different angle, though — I'd say it's less that visual-output-only software skips a well-defined process, and more that the person building it stopped before finding out whether their mental model of that process was even correct. Same failure mode, different vocabulary for it.
Appreciate the pushback — tells me I should be clearer that the target here is complacency about your own assumptions, not AI's competence.
Oh, if only that was true! I'd say it's about 50:50. Unfortunately, most of the 50 that are on the other side of that colon punch decisions and fire people from this side of it.
Maybe the music context drives the point home much easier than software development: people are amazed by what SUNO outputs (except for those who want to do non-country-pop or non-hip-hop) and say that AI makes music "making available to everyone". Until you try to make it create YOUR style of music - and it can't. It just ... can't. Even if your "engineering" is spot on, no matter how many times you repeat the phrases "the drums play a syncopated highhat on the downbeat" or "have the bass play about a 64th before the base drum to drive the rhythm forward", it CAN'T DO IT. No engineering will ever make it do it.
Yes, granted, there's YuE2 and it blasts SUNO's "engineering" flexibilty not merely out the pond, it sends it to a different universe. Still ... try to get a Synthex LFO controlled high pass "swelling sound" out of it ... it can "produce it", but not by any kind of instruction you give it. It just can't. It is completely and absolutely unable to follow the ENGINEERING instructions.
I think that's my point really: Your headline is cool, as it alludes to exactly the point of "someone did engineering". With AI ... you don't. There is no "engineering" when AI is writing code, except, if you check it (and the time you spend on that you could have spent on writing it yourself).
Don't get me wrong, I don't see the days of hacking code manually coming back. AI is cool for the dirty work. But not bells and no whistles of "result-based output shaping" should make anyone think that engineering was part of the process.
Marc — fair, and I'll grant the 50/50 might undersell how many people are getting burned by this exact confusion right now. That's a real cost even if it's not the one I was writing about.
The SUNO point is a good example of a different failure mode though — that's AI not being competent enough to follow explicit instructions. My bug wasn't downstream of AI competence at all. Even a perfectly instruction-following model doesn't check whether the person looking at the output can actually see what you think they're seeing. That check was never going to get automated by better-instruction-following AI — it's a step I skipped, not a step AI failed.
Where I think you're right: "trust-based output shaping" as a description of what's replacing engineering is sharp, and the verification-cost point deserves its own post. When checking the output costs more than building it right the first time, you haven't automated engineering, you've just moved the cost around. Worth writing about separately from what I was trying to say here.
the notification bug is the real example here. same thing happens when you deploy code you didn't write, ai or human, you inherit the assumptions without ever having made them. debugging turns into archaeology instead of memory.
Sex Toys buy online store in pakistan
BDSM Toys buy online store in pakistan
Dildos Buy online store in pakistan
Vibrators buy online store in pakistan
Chastity Cage buy online store in paksitan
Strap-on Dildo buy online store in pakistan
Butt Plugs buy online store in pakistan
Sex Doll buy online store in pakistan
Pocket Pussy buy online store in pakistan
Penis Sleeves buy online store in pakistan
sex sofa buy online store in pakistan
@dj29 Great article. AI has dramatically lowered the barrier to writing code, but it hasn't lowered the bar for true system ownership. Generative tools can output a working implementation in seconds, but taking responsibility for edge cases, invariants, and failure modes remains purely human work. The typing is the easy part, proving and ensuring safety in production is where the engineering actually happens.
Where do you think teams should draw the line between using AI for initial prototyping versus letting it touch critical production paths?
the shelftalk bug is the real story here honestly. code was working exactly as designed, the design's assumption was just wrong. thats the part vibe coding skips, not the typing. and its usually the same gap that shows up after deploy too, works in the demo then breaks somewhere nobody's watching and no one's there to catch it.
Sir, is this account hacked or something? This is same comment from you for the 4th time!
Easier to pretend is the sharper framing than most AI replaces engineers takes get to. The work didn't disappear, it just moved somewhere less visible, from the diff into the decisions nobody wrote down about why the diff looks that way.
same bug shows up on the deploy side, not just the code side. an agent ships a working app, but nobody owns what happens when the free tier host recycles the container or the db connection pool maxes out at 2am. the demo works. the failure mode is invisible until someone is actually depending on it staying up.
I agree there is a personal balance that each of us needs to figure out internally, regarding our own learning and responsibility while we build more with AI. Perhaps the other unfortunate side of the problem is the outward perception of productivity. It's so difficult right now for people (including managers) to know the difference between engineering rigor paired with agentic coding vs. free rein AI with vibe coding. Evaluating someone's effort and skill is practically impossible when only looking at the surface of their output.
Taking shortcuts and giving AI more autonomy for POCs or private side projects doesn't hurt anybody else and maybe causes the person to miss out on some learning opportunities. But, people taking similar shortcuts in a broader setting -- a founder vibe coding a new "secure and stable" SaaS platform, a software engineer shipping code they've barely looked at or had input on, or even a student turning in a paper written fully by AI -- is not just detrimental to that individual's growth. It's irresponsible and in many cases dishonest, with real consequences for themselves and others.
Absolutely