Lãnh đạo tư tưởng
Chúng ta cần ngừng gọi mọi thứ là Vibe Coding

Tôi quay lại lập trình sau một khoảng nghỉ dài, và Lovable là nơi tôi tiếp tục. Các ứng dụng trông tuyệt vời, hoạt động ngay lần đầu nhìn, và được hoàn thiện trong vài giờ. Ban đầu, điều đó thật đáng chú ý. Nhưng nó không còn đủ khi tôi muốn biết mã đang làm gì – và tại sao. Đó là lúc cách tiếp cận của tôi bắt đầu thay đổi.
Sự khác biệt không phải về công cụ, hay lượng mã AI viết cho bạn. Nó liên quan đến hợp đồng bạn chấp nhận với sản phẩm của mình: liệu bạn có thể giải thích những gì bạn vừa phát hành ra thế giới, hay không.
Vibe coding, trong nghĩa gốc, có nghĩa là chấp nhận phần mềm do AI tạo ra mà không kiểm tra hoặc hiểu đúng những gì nằm dưới nó. Phát triển hỗ trợ AI lại khác. Mô hình vẫn có thể viết phần lớn mã, nhưng người xây dựng hệ thống vẫn chịu trách nhiệm hiểu hành vi của nó, kiểm tra các giả định và quyết định liệu nó đã sẵn sàng để phát hành hay chưa.
Đối với một thí nghiệm tạm thời không bao giờ rời khỏi máy của bạn, sự khác biệt có thể có ít hậu quả. Khi phần mềm được triển khai, được người khác sử dụng hoặc kết nối với dữ liệu thực, nó lại quan trọng đến mức đáng kể.
Cách “Vibe Coding” Mất Ý Nghĩa
The term “vibe coding” was coined in tháng 2 2025 by Andrej Karpathy, co-founder of OpenAI. His example was deliberately casual: a “throwaway weekend project” built by automatically clicking “Accept All,” ignoring the diffs and allowing the code to grow beyond his understanding.
Weeks later, developer and tool-maker Simon Willison noticed the term was being used very differently: as a stand-in for any AI-assisted programming at all, which he argued dilutes the term and gives a false impression of what responsible AI-assisted development can achieve.
What’s telling is that Karpathy eventually agreed. A year later, he introduced a different term for more disciplined work with coding agents. He described “agentic engineering” as a workflow in which developers direct and oversee agents rather than simply accepting what they produce. The distinction matters: professional AI-assisted development requires planning, scrutiny and accountability in ways that casual vibe coding does not.
Ranh Giới Là Trách Nhiệm
Willison’s rule is simple, and it works as a test for anyone: don’t commit code you can’t explain to someone else. That doesn’t mean reading every single line: with agents generating hundreds of lines at once, even experienced developers don’t do that anymore. It means understanding the core logic and being able to justify why the code does exactly what it does. If you can, it doesn’t matter whether a model wrote it or you did: that’s not vibe coding, that’s using a tool to build software.
Research published in tháng 12 2025 supports that distinction. Drawing on field observations and a qualitative survey of professional developers, the researchers found that experienced practitioners retained control over software design and implementation rather than handing the entire process to AI. They treated agents as collaborators, planned their work carefully and remained involved in oversight.
So, experience alone doesn’t explain it. It’s about whether you’re willing to take responsibility for what AI generated. That’s a decision every developer makes over again on every project.
Điều Gì Xảy Ra Khi Thiếu Kiểm Soát
The consequences of releasing software without understanding or verifying its security aren’t abstract. Tea, an app meant to help women stay safe while dating, exposed tens of thousands of ID photos and more than a million private messages across two security incidents. The failures included an unsecured storage bucket and a separate database accessible without authentication.
The same underlying problem – software appearing to work while its authorization logic remained dangerously wrong – showed up in an application built on the Lovable platform: security research found the authorization logic inverted, locking out logged-in users while letting unauthenticated attackers in freely, affecting more than 18,000 users, including students.
These aren’t isolated cases that only happen to “bad” projects. According to Google’s 2025 DORA report, 90% of developers now use AI at work, while roughly a third report little or no trust in what it generates.
AI use is now widespread, even though trust remains limited. And that makes careful review especially important when generated code handles authentication, permissions or sensitive data.
Kiểm Soát Được Xây Dựng Theo Tầng, Không Cùng Lúc Một
In my case, I didn’t begin with a formal security audit. I simply refused to move on whenever I could not explain why something behaved the way it did – a natural instinct I bring to work as an analyst. I care less about the syntax than whether the result matches what we originally needed. When it doesn’t, I keep digging.
My workflow became more structured as the projects became more serious. Instead of relying on prompts alone, I began preparing specifications before generating anything. I documented the business requirements, tech stack and integrations. Then came unit tests and Playwright tests for the main user journeys.
Security checks were added in much the same way. I reviewed the libraries the AI selected and introduced malware scanning for uploaded files. Each check came from asking what could go wrong next, rather than following a control list I had prepared at the beginning.
That habit caught a problem on one project. The AI introduced a library that was incompatible with the framework version I was using. The application had not failed outright, so the incompatibility could easily have remained unnoticed. Finding it later would have made the cause far harder to identify.
Compared with the Tea and Lovable cases, this was an ordinary problem. I found it early, fixed it and moved on. That is what review usually looks like in practice. Most of the time, it prevents small problems from growing into larger ones.
I don’t distrust code simply because AI produced it. I also don’t trust it simply because the application runs. Tests and review are how I establish whether it behaves as intended.
Từ Vibe Coding Đến Agentic Engineering
Karpathy’s own move away from “vibe coding” toward “agentic engineering” isn’t just a change in vocabulary. “Agentic engineering” gives us a more useful name for the direction professional development is taking. Developers may write fewer lines themselves, but that does not reduce their responsibility. It shifts their work toward specifying what the system should do, directing agents, testing their output and deciding what is safe to release.
Nguy hiểm không phải AI tạo mã nhanh chóng. Mà là việc quá trình tạo mã có thể nhanh hơn khả năng hiểu. Khi điều đó xảy ra, năng suất bề ngoài che giấu những rủi ro mà không ai đã kiểm tra kỹ lưỡng.
Một Quy Tắc Đáng Giữ
Stop using “vibe coding” as a label for every form of AI-assisted development – it dilutes the term and erases a distinction in control that matters. Set a simple rule: do not ship what you cannot explain. And build control into the project as it grows, layer by layer, adding checks in step with the risks that emerge.
AI có thể viết phần lớn mã. Nó không thể chịu trách nhiệm phát hành nó. Điều đó vẫn thuộc về chúng ta.












