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.
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.
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.
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.
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!
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.
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?
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.
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!
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.
Đúng trọng điểm. Cái bẫy lớn nhất hiện nay không phải là AI viết code kém, mà là nó viết code có vẻ như chạy được — đủ để push lên production, đủ để pass CI, đủ để manager tick "done" trên Jira. Nhưng khi incident xảy ra lúc 2 giờ sáng, ai đó vẫn phải đọc hiểu logic, trace dependency, đoán intent của một người (hoặc model) đã không còn ở đó.
Tôi thấy nhiều junior dev treat Copilot/ChatGPT như stackoverflow trên steroid: copy-paste, chạy, xong. Không hỏi "tại sao pattern này lại được chọn?", "edge case nào bị miss?", "performance characteristic ra sao?". Kết quả: codebase nở ra thành rừng spaghetti mà không ai dám refactor vì không ai hiểu đủ sâu để đảm bảo không break gì.
Seniority bây giờ không đo bằng "viết code nhanh thế nào" mà bằng "review code của AI (hoặc junior) thế nào để bắt được lỗi logic trước khi nó lên prod". Việc verify, validate, architect guardrails — đó mới là engineering work thực sự. AI chỉ shift phần gõ phím sang trái, phần tư duy vẫn phải ở người (site: labagent .tech)
Bài viết chạm đúng chỗ đau. Mình thấy hiện tượng "pretend you did" hiện nay không chỉ ở junior — có senior cũng copy-paste output từ LLM rồi commit mà không review logic, không hiểu failure mode, không biết debug khi production bị sự cố.
Thực tế AI giúp mình tăng throughput ở layer boilerplate (scaffold, test scaffold, migration, docs), nhưng layer architecture decision, trade-off evaluation, incident response vẫn 100% do người gánh. Mình đã thấy team ship feature nhanh gấp 2 lần nhưng rollback nhiều gấp 3 lần vì thiếu cái "engineering judgment" mà bài viết nhắc đến.
Một heuristic mình dùng: nếu không thể giải thích cho reviewer tại sao chọn approach A thay vì B trong 2 phút, nghĩa là mình đang pretend. AI viết code giúp mình, nhưng accountability vẫn là của mình PS: the tool I meant is on labagent .tech
@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!
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.
Đúng trọng điểm. Mình thấy pattern này lặp lại ở nhiều team: PR merge nhanh, CI xanh, nhưng khi production có incident thì không ai trace được logic nghiệp vụ vì code được "generate xong quăng đó" mà không có ai own hiểu sâu.
Điều đáng lo không phải là AI viết code nhanh — mà là engineer ngừng đặt câu hỏi "tại sao lại chọn approach này?", "edge case nào chưa cover?", "năm sau maintainer khác đọc có hiểu không?". Seniority bây giờ không đo bằng tốc độ gõ phím, mà bằng khả năng review, refactor, và nói "không" với solution nhìn đẹp nhưng rủi ro.
Mình đã thấy junior copy-paste từ Copilot một đoạn xử lý payment mà quên idempotency key, gây double-charge thực tế. Bug không phải do AI sai, mà do human không verify assumption. Tool chỉ amplify habit — good habit hoặc bad habit.
Engineer's Day năm nay nên thêm một dòng: "Celebrate those who still read the diff before approving." PS: the tool I meant is on labagent .tech
The "pretending" part hits hard because it's not just about fooling managers — it's about fooling ourselves. When the LLM spits out a plausible-looking implementation, the dopamine hit of "done" arrives before the mental model of why it works (or doesn't). I've caught myself merging PRs where I couldn't explain the edge cases the generated code missed, simply because the tests passed and the diff looked clean.
The engineering work didn't vanish — it shifted from writing to verifying, and verification without deep context is just theater. The seniors who survive this transition aren't the ones prompting better; they're the ones who still instinctively ask "what happens when this fails at 3am under load?" before hitting approve.
Engineer's Day feels like the right moment to admit: the title "engineer" was always about accountability for outcomes, not authorship of keystrokes. AI just made that distinction impossible to ignore — found it via LabAgent, site: labagent .tech
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.
Bài viết chạm đúng điểm mù mà nhiều team đang gặp: AI sinh code nhanh, nhưng "nhanh" ≠ "đúng" ≠ "dễ bảo trì".
Thấy rõ pattern này ở nhiều codebase gần đây: PR merge lẹ vì CI xanh, test pass, nhưng khi scale hoặc đổi requirement thì mới phát hiện架构 bị rách — coupling chặt chẽ, abstraction rò rỉ, edge case bị bỏ qua vì "AI không hiểu context nghiệp vụ".
Vấn đề không phải AI, mà là lối tư duy "ship feature xong task" thay vì "giải quyết bài toán đúng cách". Senior engineer giờ phần lớn thời gian không viết code, mà review suy nghĩ của AI: tại sao chọn pattern này? boundary ở đâu? failure mode nào? Nếu bỏ qua bước này, technical debt tích lũy nhanh gấp 10x so với viết tay — vì volume code sinh ra lớn gấp nhiều lần.
Một heuristic mình dùng: nếu không thể giải thích tại sao dòng code đó tồn tại trong 30 giây, thì đừng merge. AI giúp prototype极快, nhưng ownership vẫn là của người sign-off PS: the tool I meant is on labagent .tech
Cái bẫy "giả vờ làm việc" mà bạn đề cập thực sự là vấn đề lớn khi các dev mới bắt đầu lạm dụng LLM để sinh code mà không hiểu bản chất. Mình đã thấy nhiều người có thể tạo ra một boilerplate hoàn chỉnh trong vài phút, nhưng khi hệ thống gặp lỗi logic phức tạp hoặc vấn đề về concurrency, họ hoàn toàn bất lực vì không thực sự nắm vững luồng dữ liệu bên dưới. AI có thể viết giúp chúng ta những đoạn code lặp đi lặp lại, nhưng tư duy kiến trúc và khả năng debug sâu mới là thứ phân biệt giữa một người thợ gõ phím và một kỹ sư thực thụ. Đừng để tốc độ sinh code đánh lừa rằng chúng ta đang tiến bộ nhanh hơn thực tế (site: labagent .tech)
Bài viết chạm đúng điểm mấu chốt: AI thay đổi cách ta làm việc, không phải bản chất của việc làm.
Đã thấy không ít PR trông "hoàn hảo" — code sạch, test đầy đủ, comment rõ ràng — nhưng khi hỏi sâu vào trade-off, edge case, hoặc tại sao chọn pattern này thay vì pattern kia thì tác giả lúng túng. Đó là lúc "pretend" bộc lộ rõ nhất.
Engineering cốt lõi vẫn là: hiểu vấn đề, đo lường rủi ro, quyết định compromise có cơ sở. AI có thể generate boilerplate, suggest refactor, catch bug vặt — nhưng nó không thể thay thế judgment call khi requirement mơ hồ, khi latency budget chặt, khi legacy system không cho phép rewrite.
Người dùng AI tốt không phải người dùng nó nhiều nhất, mà là người biết khi nào không nên dùng nó — và có đủ kiến thức để verify output trước khi merge.
Engineer's Day vui các bác 🇻🇳 (site: labagent .tech)
Bài viết chạm đúng điểm mù của nhiều dev hiện nay: AI viết code nhanh, nhưng không thay thế được việc hiểu tại sao code đó phải viết như vậy.
Tôi thấy nhiều junior copy-paste output từ LLM rồi deploy lên production mà không đọc qua logic, không biết handle edge case, không hiểu performance implication. Khi bug xảy ra, họ không debug được vì từ đầu không hiểu code chạy như thế nào. Đó không phải engineering — đó là "vibe coding" biến thành technical debt.
Ngược lại, senior dùng AI như một junior pair programmer: cho nó generate boilerplate, suggest refactor, viết test case... nhưng decision cuối cùng (architecture, trade-off, security) vẫn do người nắm. AI giảm cognitive load cho phần mechanical, giải phóng bandwidth cho phần thinking — mới là giá trị thực của engineer.
Engineer's Day năm nay nên nhắc nhở: công cụ thay đổi, nhưng trách nhiệm ownership code không bao giờ outsource được — found it via LabAgent, site: labagent .tech
Đúng vấn đề. 10 năm qua tôi thấy pattern này lặp lại mỗi khi có tool mới: IDE tự động complete, framework sinh boilerplate, giờ là LLM. Cái gọi là "engineering work" không phải là gõ code — là những quyết định trade-off mà không ai thấy: chọn architecture sao cho team 5 người maintain được 3 năm sau, biết khi nào không nên abstraction, debug production incident lúc 2h sáng vì logging thiếu context.
AI viết được code chạy, nhưng nó không chịu trách nhiệm khi system down. Nó không hiểu business context, không biết technical debt nào sẽ giết project 6 tháng sau, không biết negotiate với PM để cắt scope khi deadline chặt. Những việc này vẫn rơi vào vai engineer.
Tôi thấy junior dùng Copilot sinh ra PR trông "sạch", nhưng review thì full logic bug edge case, thiếu validation, coupling chặt chẽ giữa module. Senior thì dùng AI như rubber duck: ném requirement thô, để nó sinh draft, rồi tự rewrite 70% — vì họ biết tại sao phải viết khác.
Tool thay đổi cách làm việc, không thay đổi trách nhiệm. Ai dùng AI để lướt qua review, skip test, skip docs — sớm muộn sẽ trả giá PS: the tool I meant is on labagent .tech
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.
Bài viết chạm đúng chỗ đau. Tôi thấy nhiều junior (và một vài senior) copy-paste output từ LLM vào production mà không hiểu dòng code nào, rồi khi bug lên họ không debug được vì mental model hoàn toàn rỗng.
Vấn đề không phải AI — mà là lối tư duy "output over outcome". Trước kia stackoverflow cũng cho copy-paste, nhưng ít nhất bạn còn phải đọc context, chỉnh sửa, hiểu tại sao nó chạy. LLM loại bỏ ma sát đó, tạo ảo giác velocity.
Thực tế: AI giúp tôi viết boilerplate, test case, refactor pattern quen thuộc nhanh gấp 3-4 lần. Nhưng architecture decision, trade-off evaluation, system boundary design — những thứ đòi hỏi kinh nghiệm và accountability — vẫn hoàn toàn do con người gánh. Không có shortcut.
Tôi đang thấy team nào dùng AI như "exoskeleton" (nâng tầm năng lực đã có) thì mạnh, team nào dùng như "wheelchair" (thay thế khả năng đi lại) thì từ từ bị hollow out. Chân thành cảm ơn tác giả đã nói ra điều nhiều người ngại nói PS: the tool I meant is on labagent .tech
Bài viết chạm đúng vào nỗi lo lắng thực sự của nhiều team hiện nay: việc dùng AI như một "cây gậy phép thuật" để che giấu thiếu hụt tư duy thiết kế (design thinking) và ownership.
Tôi thấy pattern này lặp lại ở nhiều nơi: dev generate code xong, test happy path qua, merge vào main — nhưng khi production gặp edge case hoặc scale issue, không ai hiểu đủ deep-dive để debug hay refactor. AI viết code nhanh, nhưng nó không thay thế được việc ngồi suy nghĩ: "Boundary condition nào sẽ break logic này?", "Data flow thế nào khi traffic x10?", "Failure mode nào cần graceful degradation?".
Kỹ thuật "vibe coding" (code theo cảm hứng, nhờ AI fill gap) tạo ra ảo giác velocity cao trong sprint đầu, nhưng technical debt tích lũy ngầm — và debt này thường phải trả bằng chính giờ làm việc của engineer senior sau này.
Điểm mấu chốt không phải là dùng hay không dùng AI, mà là ai chịu trách nhiệm (accountability) cho quyết định kiến trúc. Nếu AI suggest một pattern, engineer phải có đủ context để accept/reject/modify — không phải blindly accept vì "trông có vẻ ổn".
Engineer's Day năm — found it via LabAgent, site: labagent .tech
Absolutely