Bản đồ công trìnhTờ này lắp: Sheet & sổ tay, Đăng nhập, vai trò, Database
Bài nàyĐã họcChưa tớiĐã thay thế
Bạn sẽ học được gì
Tiêu chí nghiệm thu
Vibe coding đến từ đâu
Đầu tháng 2 năm 2025, Andrej Karpathy, một nhà nghiên cứu AI nổi tiếng (từng là thành viên sáng lập OpenAI và phụ trách AI ở Tesla), viết một bài ngắn trên mạng xã hội mô tả cách ông làm một số dự án nhỏ: buông mình theo “cảm hứng” (vibe), nói chuyện với AI, chấp nhận mọi thay đổi nó đề xuất mà không đọc kỹ, gặp lỗi thì dán nguyên thông báo lỗi vào cho AI tự sửa, gần như “quên rằng code tồn tại”. Ông cũng nói rõ cách này phù hợp với những dự án cuối tuần làm xong có thể bỏ đi.
Cụm từ “vibe coding” lan nhanh, và như nhiều thuật ngữ thời thượng, nó bị dùng rộng hơn ý ban đầu. Có người gọi mọi việc viết code bằng AI là vibe coding. Chuỗi bài này dùng nghĩa hẹp và chính xác hơn, cũng là cách nhiều kỹ sư trong nghề phân biệt:
Vibe coding là khi bạn để AI viết code mà không hiểu, không đọc, không kiểm chứng nó một cách có hệ thống. Nếu bạn review, test, hiểu và chịu trách nhiệm về code AI viết, đó không còn là vibe coding, mà là kỹ thuật phần mềm có AI hỗ trợ (AI-assisted engineering).
Phân biệt này quan trọng, vì vấn đề không nằm ở việc AI viết code. Vấn đề nằm ở việc không ai nắm được cái được viết ra.
Câu chuyện app “vibe” của chị Lan
Khởi đầu đầy hứng khởi
Mùa Trung thu năm 2024, Bánh Mộc sót gần chục đơn bánh hộp quà vì đơn nằm rải rác trong Google Sheet, sổ tay và tin nhắn Zalo cá nhân của nhân viên. Có khách đến nhận bánh thì bếp chưa làm. Chị Lan quyết tâm “phải có phần mềm”.
Giữa năm 2025, chị đọc được nhiều bài viết về các nền tảng tạo app bằng prompt. Một tối thứ Bảy, chị mở một app builder (công cụ tạo ứng dụng từ mô tả bằng lời) và gõ:
Điền ô trống rồi sao chép
Tạo app quản lý đơn hàng cho tiệm bánh. Có danh sách đơn, khách hàng, sản phẩm,
đăng nhập cho nhân viên, báo cáo doanh thu. Giao diện đẹp, hiện đại.Hai mươi phút sau, chị có một ứng dụng web chạy được: màn hình đăng nhập, bảng đơn hàng có màu sắc, biểu đồ doanh thu. Chị gần như không tin vào mắt mình. Cả buổi tối hôm đó, chị liên tục thêm yêu cầu: “thêm ô ghi chữ trên bánh”, “thêm chatbot tư vấn bánh dùng AI”, “thêm nút gửi tin nhắn xác nhận cho khách”, “đổi màu chủ đạo sang nâu gỗ cho hợp thương hiệu”. Mỗi yêu cầu, app thay đổi trong vòng vài phút. Một giờ sáng, chị nhắn cho Hà: “Tuần sau mình dùng app mới nhé em!”
Tuần một và hai: mọi thứ có vẻ ổn
Hà và hai nhân viên tiệm Phú Nhuận bắt đầu nhập đơn vào app. Với vài chục đơn mỗi ngày ở một chi nhánh, app chạy mượt. Anh Tuấn thích màn hình danh sách bánh kem cần làm. Chị Lan khoe app với bạn bè trong nhóm chủ doanh nghiệp. Nhìn từ bên ngoài, đây là một câu chuyện thành công.
Tuần ba đến tuần sáu: những vết nứt
Rồi các vấn đề lần lượt xuất hiện, mỗi cái nhỏ, nhưng cộng lại thì đáng sợ.
Sửa chỗ này hỏng chỗ kia. Chị yêu cầu thêm lựa chọn “giao tận nơi” với ô địa chỉ. AI làm xong, nhưng trường “giờ nhận bánh” trong form tạo đơn bắt đầu lưu sai. Chị dán lỗi vào bảo sửa. AI viết lại cả màn hình tạo đơn, và lần này bộ lọc theo chi nhánh biến mất. Sửa bộ lọc thì nút in phiếu bếp hỏng. Sau ba vòng như vậy, chị không còn nhớ phiên bản nào là phiên bản chạy tốt.
Dữ liệu không nhất quán. Qua nhiều lần yêu cầu khác nhau, trạng thái đơn trong dữ liệu có đủ kiểu: “Đã xác nhận”, “xác nhận”, “confirmed”, “OK”. Báo cáo doanh thu chỉ đếm những đơn có chữ “Hoàn tất” viết đúng y như vậy, nên số liệu tháng 8 thấp hơn thực tế đáng kể. Giá tiền có đơn lưu là 350000, có đơn lưu là chữ "350.000", nên phép cộng ra kết quả vô nghĩa.
Không có phân quyền. Một bạn nhân viên thời vụ làm hai tuần cũng xem được doanh thu toàn chuỗi và toàn bộ danh sách khách hàng kèm số điện thoại. App có màn hình đăng nhập, nhưng ai đăng nhập vào cũng thấy mọi thứ.
Không quay lại được. Một lần, sau khi chị yêu cầu “làm gọn lại code cho nhanh hơn”, app không mở được nữa. Chị muốn quay về bản chạy tốt hôm thứ Ba, nhưng không biết bản đó nằm đâu. App builder có lưu lịch sử, nhưng chị không biết lần thay đổi nào gây lỗi, và quay lại bản cũ thì mất luôn các đơn đã nhập từ hôm đó.
Giọt nước tràn ly: chiếc chìa khóa để dưới thảm
Đầu tháng 10/2025, cháu trai anh Tuấn, sinh viên năm ba ngành công nghệ thông tin, ghé tiệm chơi. Nghe chị Lan khoe app, cậu xin xem thử. Năm phút sau, cậu quay sang, mặt nghiêm lại:
“Cô ơi, khóa truy cập database và khóa API của dịch vụ AI nằm ngay trong code chạy trên trình duyệt. Ai mở công cụ dành cho nhà phát triển của trình duyệt cũng thấy. Với khóa này, người ta đọc được hết danh sách khách hàng của cô, kể cả xóa dữ liệu.”
Cậu chỉ cho chị xem: bảng khách hàng không có lớp bảo vệ nào ở phía database. Lớp “đăng nhập” chỉ là một màn hình che phía trước, giống như khóa cửa chính nhưng để chìa khóa dưới tấm thảm. Cùng tháng đó, hóa đơn dịch vụ AI của chị tăng vọt so với mọi tháng trước, dù chatbot tư vấn bánh gần như không ai dùng. Rất có thể ai đó đã nhặt được khóa và dùng nó cho việc riêng.
Kết cục và quyết định
Tuần trước ngày 20/10/2025, lượng đơn tăng gấp ba. App chậm, thỉnh thoảng báo lỗi. Hà sợ mất đơn nên ghi song song cả vào Google Sheet cũ. Giờ Bánh Mộc có hai nguồn dữ liệu lệch nhau, tệ hơn cả trước khi có app.
Chị Lan nhờ một bạn freelancer xem giúp có cứu được không. Bạn ấy đọc mã nguồn hai ngày rồi trả lời thẳng: “Code này có bốn cách lưu đơn hàng khác nhau, không có test nào, không có tài liệu. Em có thể sửa từng lỗi, nhưng không dám hứa sửa lỗi này không làm hỏng chỗ khác.”
Sau ngày lễ, chị Lan làm bốn việc:
- Đổi ngay mọi khóa bí mật đã lộ, khóa tài khoản dịch vụ AI.
- Xuất toàn bộ dữ liệu đơn và khách hàng ra file, tắt app.
- Tạm quay về Google Sheet, nhưng chỉ dùng một file chung có quy tắc nhập rõ ràng.
- Quyết định học bài bản cách làm phần mềm với AI, bắt đầu từ chuỗi bài này.
Chị viết trong nhật ký: “Công cụ không có lỗi. Nó làm đúng những gì mình yêu cầu. Lỗi là mình không biết phải yêu cầu gì, không biết kiểm tra cái gì, và không có đường lui.”
Việc nên cứu hay viết lại một dự án vibe như thế này được phân tích kỹ ở bài Làm việc với codebase có sẵn và dự án ‘vibe’ bị rối06-08.
Phân tích: gốc rễ của thất bại
Nhìn lại, mọi vấn đề của chị Lan đều có thể quy về một vài nguyên nhân gốc:
| Triệu chứng | Nguyên nhân gốc | Thói quen kỹ sư khắc phục | Học ở đâu |
|---|---|---|---|
| Sửa chỗ này hỏng chỗ kia | Không có test tự động; thay đổi lớn mỗi lần | Bước nhỏ + test làm lưới an toàn | Vì sao kiểm thử08-01 |
| Trạng thái đơn lộn xộn | Không có mô hình dữ liệu được thiết kế trước | Thiết kế dữ liệu, ràng buộc trong database | Mô hình hóa dữ liệu04-02 |
| Ai cũng xem được mọi thứ | Yêu cầu phân quyền chưa từng được nêu | Ma trận quyền ghi trong spec | Xác thực và phân quyền04-07 |
| Không quay lại được | Không có quản lý phiên bản rõ ràng | Git, commit nhỏ, thường xuyên | Git: cỗ máy thời gian07-01 |
| Lộ khóa, database mở | Không có tư duy bảo mật | Bảo mật là yêu cầu, ghi vào spec | Rủi ro bảo mật của code AI09-01 |
| Không ai dám sửa | Không có tài liệu, kiến trúc rối | Spec, ADR, AGENTS.md, kiến trúc rõ | Tài liệu hóa kiến trúc04-09 |
Không có dòng nào trong cột “nguyên nhân gốc” là “AI viết code kém”. AI viết code khá tốt. Thứ thiếu là cách làm.
Vibe coding và kỹ thuật có AI hỗ trợ: so sánh trực diện
| Tiêu chí | Vibe coding | Kỹ thuật phần mềm có AI hỗ trợ |
|---|---|---|
| Điểm xuất phát | Một câu prompt chung chung | Vấn đề rõ, spec ngắn, tiêu chí chấp nhận |
| Ai lập kế hoạch | AI tự quyết trong lúc viết | AI đề xuất, con người duyệt trước khi code |
| Kích thước thay đổi | Lớn, nhiều thứ cùng lúc | Nhỏ, mỗi lần một việc |
| Đọc code | Không | Đọc diff, hỏi AI giải thích chỗ nghi ngờ |
| Kiểm chứng | Bấm thử thấy “có vẻ chạy” | Test tự động, build, ảnh chụp, kịch bản nghiệm thu |
| Quản lý phiên bản | Không có hoặc tùy công cụ | Git, commit nhỏ, nhánh, pull request |
| Bảo mật | Không nghĩ tới | Có yêu cầu bảo mật, rà soát trước khi ra mắt |
| Khi gặp lỗi | Dán lỗi, mong AI sửa | Tái hiện, khoanh vùng, sửa nguyên nhân gốc |
| Tốc độ ngày đầu | Rất nhanh | Chậm hơn một chút |
| Tốc độ tháng thứ sáu | Chậm dần, rồi bế tắc | Giữ ổn định, thậm chí nhanh hơn nhờ test và tài liệu |
| Phù hợp nhất cho | Thử ý tưởng, demo, công cụ dùng một lần | Sản phẩm có người dùng thật, dữ liệu thật, sống lâu |
Dòng đáng chú ý nhất là hai dòng tốc độ. Vibe coding nhanh như chạy nước rút; kỹ thuật bài bản giống chạy marathon. Một phần mềm kinh doanh, vốn phải sống nhiều năm, gần như luôn là cuộc marathon.
Vuốt ngang để xem hết sơ đồ
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Mức 0 Vibe thuần → Mức 1 Vibe + bấm thử
- Mức 1 Vibe + bấm thử → Mức 2 Có Git, đọc diff, file hướng dẫn agent
- Mức 2 Có Git, đọc diff, file hướng dẫn agent → Mức 3 Có spec, test tự động, review độc lập
- Mức 3 Có spec, test tự động, review độc lập → Mức 4 Kỹ thuật đầy đủ: CI/CD, bảo mật, giám sát
Hãy coi đây là một phổ (spectrum), không phải hai lựa chọn trắng đen. Cùng một người, cùng một ngày, có thể làm việc ở mức 0 khi vẽ thử một màn hình mới, và ở mức 4 khi sửa logic tính tiền cọc trên hệ thống đang chạy. Kỹ năng quan trọng là chọn đúng mức cho đúng việc.
Khi nào vibe là đủ, khi nào phải làm bài bản
Chị Lan giờ dùng năm câu hỏi đơn giản trước khi bắt đầu bất kỳ việc gì với AI:
- Có dữ liệu thật của khách hay nhân viên?
- Có người khác ngoài bạn sử dụng?
- Có liên quan tới tiền hoặc khóa bí mật?
- Cần dùng lâu hơn vài tuần?
- Làm bài bản
- Vibe thoải mái, nhưng sẵn sàng vứt đi
Xem sơ đồ gốc (Hình 2)
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Có dữ liệu thật của khách hay nhân viên? → Làm bài bản (Có)
- Có dữ liệu thật của khách hay nhân viên? → Có người khác ngoài bạn sử dụng? (Không)
- Có người khác ngoài bạn sử dụng? → Làm bài bản (Có)
- Có người khác ngoài bạn sử dụng? → Có liên quan tới tiền hoặc khóa bí mật? (Không)
- Có liên quan tới tiền hoặc khóa bí mật? → Làm bài bản (Có)
- Có liên quan tới tiền hoặc khóa bí mật? → Cần dùng lâu hơn vài tuần? (Không)
- Cần dùng lâu hơn vài tuần? → Làm bài bản (Có)
- Cần dùng lâu hơn vài tuần? → Vibe thoải mái, nhưng sẵn sàng vứt đi (Không)
Nếu tất cả câu trả lời đều là “không”, vibe là lựa chọn hợp lý và tiết kiệm. Một số ví dụ vibe phù hợp trong Bánh Mộc:
- Dựng nhanh một prototype bấm được của màn hình bếp với dữ liệu giả để hỏi anh Tuấn “anh muốn nhìn thấy như thế này không?” (xem User flow và wireframe03-07).
- Viết một đoạn script dùng một lần để gộp ba file Excel bảng giá cũ thành một file, chạy trên bản sao dữ liệu.
- Làm ba phiên bản trang giới thiệu bộ bánh Trung thu để chọn bố cục, trước khi giao cho người thiết kế làm bản chính thức.
Ngược lại, chỉ cần một câu trả lời “có”, bạn cần ít nhất mức 2–3 trên phổ. Chạm tới dữ liệu khách hàng hay tiền, mức 3–4 là bắt buộc.
Dịch chuyển từ vibe sang kỹ sư: năm thói quen đầu tiên
Bạn không cần học hết 112 bài mới bắt đầu làm khác đi. Năm thói quen dưới đây đưa bạn từ mức 0 lên mức 2 trong vài tuần, và mỗi thói quen đều được đào sâu ở các module sau.
-
Viết trước khi prompt. Trước mỗi tính năng, dành mười phút viết nửa trang: ai dùng, để làm gì, đúng là thế nào, không làm gì. Chỉ nửa trang đã loại bỏ được rất nhiều lần AI phải đoán. Đây là hạt giống của PRD và spec03-06.
-
Đòi kế hoạch trước khi code. Thay vì “làm đi”, hãy nói “đọc code liên quan và đề xuất kế hoạch, chưa sửa gì”. Duyệt kế hoạch mất năm phút nhưng tránh được hàng giờ sửa sai. Xem vòng lặp Khám phá → Lập kế hoạch → Code → Kiểm chứng → Commit06-03.
-
Lưu điểm khôi phục sau mỗi bước chạy được. Dùng Git và commit sau mỗi thay đổi nhỏ đã kiểm tra. Khi AI làm hỏng, bạn quay lại trong vài giây thay vì vài ngày.
-
Bắt AI chứng minh, đừng tin lời AI. “Đã xong” không phải bằng chứng. Bằng chứng là: lệnh test đã chạy và kết quả, ảnh chụp màn hình, kịch bản thử từng bước. Logic nào dính tới tiền, phải có test.
-
Khóa bí mật không bao giờ xuống trình duyệt. Một quy tắc duy nhất, không ngoại lệ. Nếu không chắc một khóa có phải bí mật không, coi như nó là bí mật.
Áp dụng vào dự án Bánh Mộc
Nhật ký công trình · Bánh Mộc
BM-261012-002
12.10.2026
- Chị LanChủ chuỗi
Sau bài học đắt giá, chị Lan lập “Quy ước làm việc với AI” dán ngay đầu sổ tay dự án. Quy ước này về sau trở thành một phần của file AGENTS.md trong repo banhmoc-oms:
# Quy ước làm việc với AI ở Bánh Mộc (phiên bản 0.1)
## Vùng vibe (thoải mái thử)
- Prototype giao diện với dữ liệu giả
- Script dùng một lần, chạy trên bản sao dữ liệu
- Bản nháp nội dung, bố cục trang
## Vùng bài bản (bắt buộc quy trình)
- Bất cứ thứ gì chạm vào đơn hàng, khách hàng, tiền, tài khoản nhân viên
- Bất cứ thứ gì nhân viên dùng hằng ngày
- Bất cứ thứ gì có khóa bí mật
## Quy tắc trong vùng bài bản
1. Có mô tả bằng chữ trước khi giao cho AI
2. AI đề xuất kế hoạch, mình duyệt rồi mới code
3. Mỗi bước nhỏ: kiểm tra, rồi lưu lại (commit)
4. Logic tiền và trạng thái đơn phải có test
5. Khóa bí mật không bao giờ nằm trong code trình duyệtChị cũng quyết định: dự án mới Mộc OMS sẽ được xây lại từ đầu theo quy trình bài bản, không cố vá app vibe cũ. App cũ được giữ lại làm “bản vẽ phác” để tham khảo giao diện mà nhân viên đã quen, và danh sách lỗi của nó trở thành danh sách “những điều phải làm đúng” trong spec mới.
Prompt mẫu
Prompt thứ nhất giúp bạn đánh giá một dự án vibe có sẵn (của bạn hoặc của người khác) mà không làm thay đổi gì:
Điền ô trống rồi sao chép
Bạn là kỹ sư phần mềm cấp cao đang đánh giá một dự án được làm nhanh bằng AI.
CHỈ ĐỌC, KHÔNG SỬA BẤT KỲ FILE NÀO.
Hãy rà soát mã nguồn và báo cáo theo các mục:
1. Bảo mật: có khóa bí mật nào nằm trong code chạy trên trình duyệt hoặc trong Git không?
Database có kiểm soát quyền truy cập ở phía server/database không?
2. Dữ liệu: các trạng thái, giá tiền, ngày giờ được lưu có nhất quán không?
3. Phân quyền: người dùng đăng nhập có thể xem/sửa dữ liệu không thuộc quyền của họ không?
4. Kiểm thử: có test tự động không? Phần nào quan trọng nhất đang không có test?
5. Khả năng bảo trì: có những chỗ nào cùng một việc được làm theo nhiều cách khác nhau?
Với mỗi vấn đề: nêu file/vị trí, mức độ (nghiêm trọng/cao/trung bình/thấp) và giải thích
bằng ngôn ngữ cho người không chuyên. Kết thúc bằng 3 việc cần làm ngay.Prompt thứ hai dùng khi bạn chủ động muốn vibe một prototype an toàn:
Điền ô trống rồi sao chép
Tôi muốn làm một PROTOTYPE để thử ý tưởng, không phải sản phẩm thật.
Ý tưởng: [mô tả màn hình hoặc luồng].
Ràng buộc:
- Chỉ dùng dữ liệu giả, viết cứng trong code. Không kết nối database hay dịch vụ ngoài.
- Không dùng bất kỳ khóa API nào.
- Thêm dòng chữ "BẢN THỬ – DỮ LIỆU GIẢ" ở đầu mọi màn hình.
Mục tiêu là để tôi cho [người dùng] bấm thử và góp ý trong 15 phút.Sai lầm thường gặp
-
Sự cố 01
Đánh đồng “dùng AI viết code” với “vibe coding”.
Triệu chứngDẫn tới hai thái cực: hoặc sợ dùng AI, hoặc dùng AI mà không có quy trình.
Cách tránhnhớ định nghĩa: vibe là khi không hiểu và không kiểm chứng. Dùng AI có quy trình là kỹ thuật bình thường của thời nay.
-
Sự cố 02
Để prototype tự trượt thành sản phẩm.
Triệu chứngBản demo được dùng “tạm” rồi thành chính thức.
Cách tránhdán nhãn rõ “bản thử”, chỉ dùng dữ liệu giả, và có một quyết định chính thức “xây thật” kèm quy trình riêng.
-
Sự cố 03
Sửa lỗi bằng cách dán lỗi vào và cầu may.
Triệu chứngMỗi vòng sửa lại sinh lỗi mới, càng lúc càng rối.
Cách tránhnếu đã sửa cùng một vấn đề hơn hai lần mà chưa xong, dừng lại, quay về điểm lưu gần nhất, viết lại yêu cầu rõ hơn và bắt đầu phiên làm việc mới. Chi tiết ở bài Debug cùng AI06-07.
-
Sự cố 04
Nghĩ rằng màn hình đăng nhập nghĩa là đã an toàn.
Triệu chứngĐăng nhập chỉ là cửa trước; nếu database không tự kiểm soát quyền, người có khóa vẫn vào được bằng cửa sau.
Cách tránhluôn hỏi “nếu ai đó bỏ qua giao diện và gọi thẳng vào dữ liệu thì sao?”; xem Bảo mật xác thực và phân quyền dữ liệu09-04.
-
Sự cố 05
Cố làm bài bản cho mọi thứ, kể cả bản nháp.
Triệu chứngViết spec năm trang cho một mockup sẽ dùng một lần là lãng phí.
Cách tránhdùng năm câu hỏi ở trên để chọn đúng mức; bài bản là để bảo vệ thứ quan trọng, không phải nghi thức.
Checklist
Bài tập thực hành
-
Bài 1
Cơ bản
Phân loại công việc
Liệt kê 10 việc bạn muốn nhờ AI làm trong ba tháng tới (cả việc phần mềm lẫn việc nhỏ như script, trang nháp). Áp năm câu hỏi để xếp mỗi việc vào “vùng vibe” hoặc “vùng bài bản”.
Kết quả mong đợi
một bảng hai cột; thường bạn sẽ thấy phần lớn việc liên quan tới khách hàng và tiền rơi vào vùng bài bản.
-
Bài 2
Cơ bản
Thí nghiệm hai cách
Chọn một màn hình nhỏ (ví dụ: form đăng ký nhận khuyến mãi). Làm lần một theo kiểu vibe, lần hai theo năm thói quen. Ghi lại thời gian và mức độ bạn hiểu kết quả (thang 1–5).
Kết quả mong đợi
lần hai chậm hơn ở bước đầu nhưng bạn trả lời được “dữ liệu lưu ở đâu, nếu nhập sai thì sao”.
-
Bài 3
Nâng cao
Rà soát dự án vibe
Nếu bạn có một dự án làm bằng app builder hoặc AI trước đây, dùng prompt mẫu thứ nhất để rà soát ở chế độ chỉ đọc. Nếu chưa có, hãy vibe nhanh một app nhỏ (dữ liệu giả) rồi rà soát nó.
Kết quả mong đợi
một danh sách vấn đề có mức độ; ít nhất một vấn đề về bảo mật hoặc dữ liệu mà bạn chưa từng nghĩ tới.
Thuật ngữ trong bài
- Vibe coding
- Làm phần mềm bằng AI theo cảm hứng, không hiểu, không đọc, không kiểm chứng code
- AI-assisted engineering
- Kỹ thuật phần mềm có AI hỗ trợ: AI viết nhiều, con người đặc tả, duyệt, kiểm chứng
- App builder
- Nền tảng tạo ứng dụng từ mô tả bằng lời
- Prototype (bản mẫu)
- Phiên bản thử để kiểm chứng ý tưởng, thường bỏ đi sau đó
- Secret key (khóa bí mật)
- Chuỗi ký tự cấp quyền truy cập dịch vụ; lộ ra là mất quyền kiểm soát
- Diff
- Phần khác biệt giữa hai phiên bản code: dòng nào thêm, dòng nào xóa
- Commit
- Một điểm lưu phiên bản trong Git
Đọc thêm
- Bản đồ công cụ AI coding02-03: app builder, IDE AI và agent dòng lệnh khác nhau thế nào.
- Làm việc với codebase có sẵn và dự án ‘vibe’ bị rối06-08: kế hoạch cứu dự án vibe của chị Lan.
- Rủi ro bảo mật đặc trưng của code do AI viết09-01.
- OWASP Top 10: danh sách các nhóm lỗ hổng web phổ biến nhất.
Nghiệm thu tờ 00-02
Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.
