Khi production sập lúc 2 giờ sáng, không ai muốn nghe câu "AI viết đoạn đó" — và câu nói ấy cũng không giúp bạn debug nhanh hơn một giây nào.
Sự Chuyển Dịch Tâm Lý Mà Công Việc AI-Assisted Đòi Hỏi
Trước thời AI coding assistant, code ownership (quyền sở hữu code) là một khái niệm khá rõ ràng: bạn gõ từng dòng, bạn hiểu từng quyết định, và khi có bug, bạn có thể lần lại chính xác tại sao mình viết như vậy. AI-assisted development phá vỡ sự rõ ràng đó theo một cách tinh vi: bạn vẫn là người "ship" code, nhưng khoảng cách giữa việc "viết ra" và "hiểu sâu" bị kéo giãn.
Đây chính là chỗ tâm lý con người dễ bị đánh lừa. Khi bạn tự gõ code, quá trình gõ buộc bạn phải tư duy qua từng bước — bạn không thể viết một câu điều kiện mà không nghĩ qua các nhánh của nó. Nhưng khi AI generate ra 200 dòng code trong 10 giây, não bộ không tự động trải qua quá trình tư duy tương đương. Bạn đọc lướt, thấy "trông ổn", và có xu hướng approve nhanh hơn nhiều so với khi tự viết. Đây gọi là hiện tượng automation bias (thiên kiến tự động hóa) — xu hướng tin tưởng quá mức vào output của hệ thống tự động, đặc biệt khi hệ thống đó thường đúng.
Sự chuyển dịch tâm lý cần thiết ở đây là: bạn phải chủ động tạo ra "ma sát nhận thức" (cognitive friction) mà việc gõ code thủ công từng tạo ra một cách tự nhiên. Nói cách khác, bạn cần built một kỷ luật cá nhân để bù đắp cho việc quá trình sinh code không còn buộc bạn phải tư duy sâu như trước. Ownership giờ đây không còn là "tôi viết cái này" mà là "tôi hiểu và bảo chứng cho cái này, bất kể nó từ đâu ra".
Điều quan trọng: đây không phải lời kêu gọi đạo đức suông. Đây là kỹ năng nghề nghiệp sống còn. Senior engineer trong kỷ nguyên agentic engineering (kỹ thuật phát triển phần mềm với agent AI) được phân biệt với junior không phải ở việc ai gõ code nhanh hơn, mà ở việc ai chịu trách nhiệm và hiểu sâu hơn về những gì được ship.
Mẹo: Mỗi khi AI generate xong một đoạn code, tự hỏi: "Nếu ngay bây giờ tôi phải giải thích đoạn này cho một junior mà không nhìn lại code, tôi có làm được không?" Nếu câu trả lời là "không chắc", đó là tín hiệu bạn chưa thực sự sở hữu đoạn code đó.
Vì Sao "AI Viết Đoạn Đó" Không Phải Là Lời Bào Chữa
Về mặt tổ chức và pháp lý, người approve pull request, merge code, và deploy lên production luôn là con người — và trách nhiệm đi kèm với hành động đó không hề thay đổi vì công cụ sinh ra code khác đi.
Hãy nhìn vào phép so sánh tương tự: một kiến trúc sư sử dụng phần mềm CAD để thiết kế không thể nói "phần mềm tính sai tải trọng" khi tòa nhà sập — vì trách nhiệm chuyên môn của kiến trúc sư bao gồm việc kiểm tra và bảo chứng cho output của công cụ. Engineer dùng AI coding assistant ở vị trí tương tự: công cụ có thể sai, nhưng người dùng công cụ chịu trách nhiệm cho quyết định merge.
Về mặt thực tế nghề nghiệp, câu "AI viết đoạn đó" mang lại ba hệ quả tiêu cực rõ ràng:
Nó phá hủy uy tín cá nhân. Đồng nghiệp và quản lý sẽ nhớ rằng bạn từng đổ lỗi cho công cụ thay vì nhận trách nhiệm — điều này ảnh hưởng trực tiếp tới việc họ có tin tưởng giao task quan trọng cho bạn trong tương lai hay không.
Nó không giải quyết được vấn đề kỹ thuật. Dù bạn nói câu đó hay không, bug vẫn cần được fix, root cause vẫn cần được tìm ra. Thời gian dùng để bào chữa là thời gian không dùng để debug.
Nó tạo tiền lệ xấu cho team. Nếu một người dùng lý do này mà không bị phản đối, nó âm thầm hạ chuẩn trách nhiệm chung của cả team — dần dần review trở nên hời hợt vì "dù sao cũng đổ lỗi được cho AI".
Thực tế, các tổ chức đã áp dụng AI-assisted development trưởng thành đều có chung một nguyên tắc bất thành văn: "Bạn approve, bạn sở hữu" — không có ngoại lệ cho nguồn gốc của code.
Mẹo: Tập bỏ hẳn cụm từ "AI viết..." ra khỏi vốn từ vựng làm việc của bạn khi nói về bug hoặc incident. Thay vào đó luôn dùng "Tôi đã merge code có [vấn đề X], nguyên nhân là..." — cách nói này buộc bạn tư duy đúng vai trò của mình.
Thói Quen Ownership Thực Tiễn
Ownership không phải là một tuyên ngôn trừu tượng — nó là tập hợp các thói quen cụ thể, lặp lại hằng ngày. Dưới đây là những thói quen đã được chứng minh hiệu quả với engineer làm việc agentic (dùng AI agent để hỗ trợ phát triển phần mềm) hằng ngày:
Đọc toàn bộ diff trước khi accept, không chỉ đọc phần "quan trọng". AI thường thay đổi nhiều hơn bạn nghĩ — một request nhỏ có thể kéo theo thay đổi ở file import, config, hay side effect không liên quan trực tiếp.
Tự chạy code trước khi commit, không tin vào "AI nói nó chạy được". Một số coding agent có thể tự chạy test và báo "pass", nhưng bạn vẫn nên tự verify ở máy mình hoặc trong CI, không nhận báo cáo của agent làm sự thật cuối cùng.
Viết lại commit message bằng chính lời của bạn. Đừng copy nguyên message do AI generate mà không đọc kỹ — commit message là nơi bạn thể hiện mình hiểu "tại sao" đằng sau thay đổi, không chỉ "cái gì" đã đổi.
Chuẩn bị sẵn câu trả lời cho câu hỏi "tại sao lại làm thế này" trước khi mở PR. Nếu bạn không tự trả lời được câu hỏi này, đó là dấu hiệu bạn chưa đủ hiểu để merge.
Giữ một "decision log" cá nhân cho các quyết định kỹ thuật quan trọng do AI đề xuất. Ghi ngắn gọn: AI đề xuất gì, bạn đồng ý hay sửa, và lý do. Đây là tài sản quý khi cần trace lại quyết định sau này.
Không bao giờ merge code mà bạn không thể giải thích ít nhất ở mức "luồng chính". Nếu có phần logic phức tạp bạn chưa hiểu rõ, dừng lại, hỏi AI giải thích, tự trace code, hoặc hỏi đồng nghiệp — trước khi merge, không phải sau.
Mẹo: Áp dụng luật "5 phút hiểu": trước khi merge bất kỳ PR nào có AI-generated code, dành ít nhất 5 phút đọc lại toàn bộ diff một lượt với câu hỏi duy nhất trong đầu "tôi có tự tin giải thích đoạn này cho manager không?"
Hiểu Thật Sự (Understanding) và Ký Duyệt Hình Thức (Rubber-Stamping)
Có một khoảng cách rất lớn giữa "đọc qua và thấy ổn" (rubber-stamping — ký duyệt hình thức) và "hiểu thực sự". Rubber-stamping là khi bạn scan code, thấy indentation đẹp, tên biến rõ ràng, không có lỗi cú pháp rõ ràng, và approve. Vấn đề là: những tín hiệu bề mặt này hoàn toàn không tương quan với tính đúng đắn của logic.
AI-generated code đặc biệt dễ khiến người review rơi vào rubber-stamping vì nó thường có "vẻ ngoài" rất chuyên nghiệp — comment đầy đủ, naming convention nhất quán, structure gọn gàng. Đây chính xác là những gì khiến não bộ con người tin tưởng nhanh hơn, dù chất lượng bề mặt không đảm bảo chất lượng logic bên trong.
Dấu hiệu bạn đang rubber-stamp thay vì thực sự hiểu:
- Bạn approve PR trong thời gian ít hơn thời gian đọc lướt qua một lần.
- Bạn không thể trả lời câu hỏi "điều gì xảy ra nếu input rỗng/null/âm" mà không mở lại code.
- Bạn dựa vào việc "test pass" như bằng chứng duy nhất, không tự hỏi test có cover đúng case quan trọng không.
- Bạn thấy comment giải thích logic và tin luôn comment đó đúng, thay vì đối chiếu comment với code thực tế (một trong những hallucination phổ biến là comment không khớp với logic thật).
Ranh giới giữa hai trạng thái này không phải lúc nào cũng rõ ràng ngay lập tức — nó thường chỉ lộ ra khi có sự cố xảy ra và bạn nhận ra mình không thể trả lời câu hỏi cơ bản về đoạn code mình đã approve.
Mẹo: Tự đặt cho mình một "bài kiểm tra Feynman" nhanh: thử giải thích to (nói thành tiếng hoặc viết ra) logic của đoạn code AI-generated như thể đang dạy cho một thực tập sinh. Nếu bạn vấp, lúng túng, hoặc phải nói "chắc là nó làm thế này" — đó là rubber-stamping, không phải understanding.
"Hiểu" Thực Sự Nghĩa Là Gì Với AI-Generated Code
"Hiểu" code không có nghĩa bạn phải có khả năng viết lại y hệt nó từ đầu. Nhưng nó đòi hỏi bạn đạt được một số mức độ nắm bắt cụ thể:
Hiểu luồng dữ liệu (data flow). Bạn biết input đi vào từ đâu, biến đổi qua những bước nào, và output đi ra đâu — không cần nhớ chi tiết implementation của từng bước, nhưng phải nắm được bức tranh tổng.
Hiểu các quyết định thiết kế chính. Tại sao dùng cấu trúc dữ liệu này chứ không phải cấu trúc khác? Tại sao xử lý đồng bộ thay vì bất đồng bộ? Nếu bạn không biết câu trả lời, hãy hỏi AI — và verify câu trả lời đó có hợp lý không, đừng chỉ chấp nhận vì nó nghe "có vẻ đúng".
Hiểu điều kiện biên và trường hợp lỗi. Code này xử lý gì khi input rỗng, khi network timeout, khi hai request chạy đồng thời? Nếu code không xử lý những case này, bạn cần biết — và quyết định có chấp nhận được không cho ngữ cảnh cụ thể.
Hiểu tác động lên phần còn lại của hệ thống. Thay đổi này có ảnh hưởng tới module khác không? Có thay đổi contract của API mà service khác đang phụ thuộc không?
Hiểu đủ để debug nếu có sự cố. Đây là bài kiểm tra thực tế nhất: nếu code này gây lỗi trong production lúc 2 giờ sáng, bạn (hoặc đồng đội đọc code của bạn) có đủ manh mối để bắt đầu debug không, hay phải đọc lại từ đầu như thể lần đầu thấy nó?
Bạn không cần hiểu ở mức "tôi tự tay implement được y hệt" — mức đó là không thực tế và cũng không phải mục tiêu của AI-assisted development. Mục tiêu là mức hiểu đủ để chịu trách nhiệm một cách có căn cứ.
Mẹo: Dùng "quy tắc 2 giờ sáng" làm thước đo: nếu code này crash lúc 2 giờ sáng và bạn phải tự debug một mình, không có AI hỗ trợ, bạn có đủ hiểu biết để bắt đầu không? Nếu không, bạn chưa "hiểu" đủ để merge.
Chuẩn Mực Team Cho AI Code Ownership
Ownership cá nhân là cần thiết nhưng chưa đủ — team cần những chuẩn mực chung để đảm bảo tính nhất quán và tránh tình trạng "mỗi người một kiểu".
Yêu cầu công khai việc dùng AI trong PR description. Không phải để "bêu" ai, mà để reviewer biết cần soi kỹ hơn ở đâu — ví dụ ghi rõ "phần xử lý logic tính phí được generate bởi AI, đã verify bằng test A, B, C".
Không giảm chuẩn review vì "AI viết". Một số team có xu hướng nghĩ code AI-generated "chắc ổn" nên review nhanh hơn — đây là sai lầm phổ biến. Chuẩn review nên giữ nguyên hoặc thậm chí khắt khe hơn với phần logic phức tạp.
Thiết lập quy tắc rõ ràng về việc ai "sở hữu" đoạn code khi có sự cố. Trả lời trước: khi một service bị lỗi và code liên quan phần lớn do AI generate, ai là người chịu trách nhiệm điều tra đầu tiên? (Câu trả lời đúng: người đã merge, không phải "đội AI" nào cả.)
Chia sẻ pattern hallucination và lỗi đã gặp trong team. Tạo một kênh hoặc tài liệu ngắn ghi lại các lỗi AI-generated code đã từng gây ra trong project, giúp cả team học từ kinh nghiệm của nhau thay vì lặp lại.
Đưa "mức độ hiểu code" vào tiêu chí review, không chỉ "code có đúng không". Reviewer có quyền yêu cầu tác giả PR giải thích logic trước khi approve, kể cả khi code có vẻ đúng.
Mẹo: Đề xuất team thêm một dòng bắt buộc vào PR template: "Phần nào của thay đổi này được AI generate, và bạn đã verify bằng cách nào?" — câu hỏi đơn giản này thay đổi hành vi rất nhanh.
Thực Hành: Xây Dựng Thói Quen Ownership
Bước 1 — Chọn một PR gần đây có phần code AI-generated đáng kể. Nếu chưa có, tạo một task nhỏ và dùng AI assistant để generate implementation, ví dụ với prompt:
Viết một hàm TypeScript refundOrder(orderId, reason) xử lý hoàn tiền đơn hàng:
- Chỉ hoàn tiền nếu đơn hàng ở trạng thái "delivered" và trong vòng 7 ngày kể từ ngày giao.
- Nếu đơn hàng đã được hoàn tiền một phần trước đó, chỉ hoàn phần còn lại.
- Ghi log lý do hoàn tiền vào bảng refund_logs.
- Trả về số tiền đã hoàn và trạng thái đơn hàng mới.
Bước 2 — Thử bài kiểm tra Feynman. Không nhìn lại code, viết ra (hoặc nói thành tiếng, ghi âm lại) một đoạn giải thích 3-5 câu về logic chính của đoạn code đó. Sau đó mở lại code và so sánh — bạn giải thích đúng bao nhiêu phần trăm?
Bước 3 — Liệt kê 3 câu hỏi "điều gì xảy ra nếu..." và tự trả lời. Ví dụ: "Điều gì xảy ra nếu tham số truyền vào là null?", "Điều gì xảy ra nếu hai request chạy đồng thời?", "Điều gì xảy ra nếu external API timeout?"
Bước 4 — Verify câu trả lời bằng cách đọc code thật hoặc chạy thử. Nếu câu trả lời tự đưa ra không khớp với thực tế code, đó là khoảng trống hiểu biết cần lấp đầy trước khi merge.
Bước 5 — Viết lại PR description hoặc commit message bằng chính lời của bạn, mô tả rõ "tại sao" đằng sau thay đổi, không chỉ "cái gì" đã đổi.
Bước 6 — Ghi vào decision log cá nhân. Một dòng ngắn: task gì, AI đề xuất gì, bạn đã verify/sửa gì, và mức độ tự tin của bạn (thang 1-5) về việc hiểu đoạn code này.
Lặp lại quy trình này trong vài tuần sẽ biến ownership từ một khái niệm trừu tượng thành phản xạ tự nhiên — bạn sẽ nhận thấy tốc độ hoàn thành bài kiểm tra Feynman tăng dần vì bạn bắt đầu đọc code AI-generated với tư duy chủ động hơn ngay từ đầu.
Mẹo: Đặt lịch nhắc hàng tuần để review lại decision log — bạn sẽ thấy pattern trong chính hành vi của mình: mình hay bỏ qua verify ở loại task nào, và cần cải thiện thói quen ở đâu.
Những điểm chính
- AI-assisted development đòi hỏi một sự chuyển dịch tâm lý: ownership không còn là "tôi viết cái này" mà là "tôi hiểu và chịu trách nhiệm cho cái này".
- "AI viết đoạn đó" không phải lời bào chữa hợp lệ — người approve và merge luôn là người chịu trách nhiệm cuối cùng, về mặt chuyên môn lẫn tổ chức.
- Ownership thể hiện qua thói quen cụ thể: đọc toàn bộ diff, tự chạy code, viết lại commit message bằng lời riêng, giữ decision log.
- Có khoảng cách lớn giữa rubber-stamping (ký duyệt hình thức dựa trên vẻ ngoài) và understanding (hiểu thực sự) — vẻ ngoài chuyên nghiệp của AI-generated code càng khiến rubber-stamping dễ xảy ra.
- Hiểu thực sự nghĩa là nắm được data flow, quyết định thiết kế, điều kiện biên, và đủ để debug nếu có sự cố — không nhất thiết phải tự viết lại được y hệt.
- Team cần chuẩn mực chung: công khai việc dùng AI trong PR, không hạ chuẩn review, và chia sẻ bài học về hallucination trong nội bộ.