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.
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?
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!
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.
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!
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.
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!
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.
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.
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.