Ảo giác từ Vibecoding, Vibecoders

Đạt Trương Thành — Sun, 10 May 2026 17:09:38 +0000

Nay tôi viết blog này vì nhận ra bản thân tôi và có thể các SV đang theo khối ngành IT/Software Engineer nói chung đang gặp phải. Đó là việc dùng AI trong việc xây dựng mã nguồn!!!

Lập trình bằng cảm giác thay vì hiểu biết

Vibecoding là việc tạo ra phần mềm chủ yếu thông qua các prompt bằng ngôn ngữ tự nhiên với AI. Người dùng tập trung vào kết quả hiển thị có vẻ đúng, bỏ qua việc hiểu cấu trúc mã nguồn bên trong.
Khả năng dựng prototype nhanh chóng tạo ra ảo giác về một lập trình viên 10x. Không cần lo nghĩ về cú pháp, chỉ cần ra lệnh là có kết quả.

Không thể mở rộng quy mô

Bề mặt mượt mà đã che dấu đi một cỗ máy đang rỉ sét. Vibecoding đang tạo ra nợ kỹ thuật ở tốc độ chưa từng có trong lịch sử phần mềm.

Một vài lí do đã tạo ra các repo rác, code rác, khó scale up

1. Sự sụp đổ của System Architecture

AI rất xuất sắc trong việc viết các đoạn mã chức năng nhỏ lẻ, nhưng hoàn toàn thiếu khả năng thiết kế hệ thống một cách toàn diện và tổng thể bao quát.
Hệ thống chắp vá từ hàng ngàn đoạn mã rời rạc → Điều này dẫn đến các logic bị lặp lại, luồng dữ liệu rối rắm và tạo ra spaghetti code. Không có tầm nhìn kiến trúc bao trùm, mỗi prompt mới lại làm gãy vỡ cấu trúc cũ

2. Tạo ra cơn ác mộng mang tên Debug

Mã nguồn hoạt động được chưa chắc là mã sạch. Việc tìm lỗi trong một hệ thống mà không phải do bạn xây dựng chẳng khác nào mò kim đáy bể.
Và điều này cũng dẫn đến việc biến bản thân thành trò hề trong chính mã nguồn của mình → Khi lập trình viên không tự tay viết các logic cốt lõi, họ không hiểu luồng xử lý thật sự. Việc sửa một lỗi nhỏ mất thời gian gấp 10 lần vì họ phải học lại chính hệ thống do mình tạo ra.

3. Tạo ra các lỗ hổng bảo mật

Bề ngoài trong có vẻ tốt nhưng bên trong chưa chắc ổn định. Các Vibecoders hiếm khi check kỹ lưỡng các trường hợp ngoại lệ
Các mô hình ngôn ngữ lớn thường xuyên bị ảo giác tạo ra các thư viện không tồn tại hoặc sử dụng các phiên bản cũ → Các lỗ hổng được tạo ra giúp hacker dễ dàng xâm nhập, hay cho cái gọi là code vẫn chạy được.

4. Sự thui chột kỹ năng cốt lõi (làm ngu đi) =))))

Đây là cái giá phải trả đắt nhất trong tương lai. Sự phụ thuộc vào AI hiện nay đang làm xói mòn khả năng tư duy và giải quyết vấn đề một cách độc lập.
Mất đi khả năng tư duy thuật toán: Các lập trình viên dẫn mất đi khả năng tư duy độc lập. Khi một vấn đề khó, trừu tượng phức tạp xuất hiện vượt ngoài khả năng xử lý của AI → Vibecoders bó tay chịu thua =))))

5. Cạm bẫy MVP, Prototype với doanh nghiệp

Vibecoding tạo ra các sản phẩm MVP tuyệt vời, nhưng lại là thảm họa khi triển khai thành production.
Chi phí triển khai đập đi xây lại quá tốn kém: Nợ kỹ thuật tích lũy theo cấp số nhân khiến việc bảo trì trở nên khó khăn. Cuối cùng doanh nghiệp phải bỏ ra số tiền lớn thuê người có chuyên môn viết lại toàn bộ mã nguồn hệ thống.
Khi có lỗ hổng khiến dữ liệu rò rỉ hay hệ thống sụp đổ khi dùng Vibecoding, ai là người chịu trách nhiệm? AI hay là Vibecoders????

→ Sử dụng AI một cách thông minh:

Thay đổi phương pháp tiếp cận từ lười biếng sang có kỷ luật.
Những Software Engineer thực thụ sử dụng AI vào các tác vụ lặp đi lặp lại, nhưng họ luôn là người kiểm soát AI theo System Architecture và Bussiness Logic của họ.
Thiết lập các ràng buộc như phải review code, check syntax error,... do AI generate.
Luôn xác định kiến trúc tổng thể dự án trước khi prompt cho AI bởi lập trình viên mới là những người có quyết định cao nhất về dự án.

Và lời cuối cùng tôi muốn truyền tải tới mọi người rằng:

Các lập trình viên sử dụng AI không sai, nhưng hãy sử dụng nó để tạo ra các sản phẩm có giá trị thực tế, bởi một sản phẩm được tạo ra từ AI có giá trị cao khi được điều khiển bởi bộ não trí tuệ thực sự của con người!!!

Cookie, Session và Token-based authentication

Đạt Trương Thành — Sun, 10 May 2026 04:29:12 +0000

1. Phân biệt Authentication và Authorization

Rất nhiều lập trình viên mới hay nhầm lẫn hai khái niệm này:

Authentication (Xác thực): Ví dụ: Hành động bạn nhập Username và Password để đăng nhập vào hệ thống.
Authorization (Phân quyền): Ví dụ: Sau khi đăng nhập thành công, hệ thống kiểm tra xem bạn là Admin hay User thường, bạn có quyền xóa bài viết hay chỉ được xem.

2. Giao thức HTTP và vấn đề "Stateless"

Giao thức HTTP bản chất là Stateless. Nghĩa là server xử lý xong một request là sẽ forget luôn client đó là ai.
Nếu không có cơ chế lưu trữ lại trạng thái, mỗi lần bạn bấm sang một trang mới trên website, hệ thống sẽ lại bắt bạn đăng nhập lại. Để giải quyết vấn đề này, người ta sinh ra Cookie, Session và Token.

3. Cơ chế Cookie và Session

Cookie:

Là một đoạn dữ liệu nhỏ (khoảng vài KB) được Server yêu cầu Client (browse) lưu trữ lại ở dưới máy của người dùng.
Mỗi khi Client gửi một request mới lên Server, nó sẽ tự động đính kèm các Cookie này theo. Nhờ đó, Server biết được request này đến từ ai.

Session:

Lưu toàn bộ thông tin nhạy cảm ở phía Client (bằng Cookie) là rất nguy hiểm (dễ bị hack). Do đó, người ta sinh ra Session.
Cách hoạt động: Khi bạn đăng nhập thành công, Server sẽ tạo ra một vùng nhớ chứa thông tin của bạn (gọi là Session) và sinh ra một Session ID. Server chỉ gửi cái Session ID này về cho Client để lưu vào Cookie.
Các lần request sau, Client chỉ gửi Session ID lên. Server lấy Session ID này dò trong bộ nhớ/DB Session của mình để biết bạn là ai.

4. Token-based Authentication

Nhược điểm của Session: Khi hệ thống scale lên nhiều Server, Server A lưu Session của bạn nhưng Server B thì không. Nếu request của bạn bị điều hướng sang Server B, bạn sẽ bị bắt đăng nhập lại.
Giải pháp Token (JWT - JSON Web Token):
- Thay vì lưu trạng thái ở Server, sau khi đăng nhập thành công, Server sẽ gom thông tin của bạn (như ID, Role), mã hóa và sign bằng một khóa bí mật, tạo thành một chuỗi gọi là Token.
- Server gửi Token này cho Client lưu lại (thường lưu ở Local Storage hoặc Cookie).
- Lần sau gửi request, Client đính kèm Token này vào Header (thường là Authorization: Bearer <token>).
- Server không cần tìm trong bộ nhớ nữa, chỉ cần dùng khóa bí mật để giải mã và kiểm tra chữ ký của Token là biết bạn là ai và có quyền gì.
Ưu điểm: Cực kỳ phù hợp cho Web API, các ứng dụng Mobile, và hệ thống Microservices vì nó hoàn toàn "Stateless" (Server không cần tốn RAM để nhớ người dùng).

Forem: Đạt Trương Thành