Ba con đường của một Junior dùng AI

Bạn đang đứng ở một ngã ba đường mà không ai báo cho bạn biết. Bài này nói về ba hướng đi, chuyện gì thật sự xảy ra với mỗi hướng, và cách các senior đời trước (những người học nghề khi chưa có AI) đã trở nên giỏi.

Đặt vấn đề

Giả sử bạn đi làm được một hai năm. Bạn dùng AI mỗi ngày. Nó giúp bạn xong việc nhanh hơn, và cảm giác đó là thật.

Có một câu hỏi tôi muốn bạn tự trả lời. Không phải hôm nay, mà cho ba năm tới:

Cứ dùng AI theo cách hiện tại, sau ba năm bạn sẽ thành người như thế nào?

Câu trả lời không chỉ có một. Có ít nhất ba hướng. Và điều đáng ngại là bạn không chọn hướng đi bằng một quyết định lớn nào cả. Bạn trôi vào nó qua hàng trăm quyết định nhỏ, mỗi lần chỉ tốn năm phút: đọc kỹ đoạn code này hay nhận luôn, hỏi thêm một câu hay merge (gộp code vào nhánh chính) cho xong, cố hiểu hay thử prompt (câu lệnh yêu cầu AI) lại.

Phần 1: Ba con đường

Con đường 1: Người bấm nút

Bạn mô tả yêu cầu, AI trả về code, bạn chạy thử, chạy được, merge. Rồi lặp lại. Bạn làm xong việc nhanh hơn chính mình năm ngoái, và bạn thấy như vậy là mình đang tiến bộ.

Nhưng thứ bạn tích lũy là số lần lặp, không phải hiểu biết. Sau ba năm, CV ghi “ba năm kinh nghiệm”, còn thực tế là một năm được lặp lại ba lần.

Dấu hiệu bạn đang ở hướng này:

• Ai đó hỏi “sao chỗ này lại làm vậy?”, bạn phải mở AI lên hỏi lại mới trả lời được.
• Khi AI đưa code sai, phản xạ của bạn là prompt lại, chứ không phải đọc để tìm chỗ sai.
• Hệ thống bạn làm ba tháng trước, giờ bạn không nhớ nó chạy thế nào.

Đây là con đường mặc định. Bạn không cần chọn nó. Không chọn gì thì bạn ở đây.

Con đường 2: Người tránh AI

Bạn không dùng AI, hoặc dùng rất dè dặt. Có thể vì tự trọng nghề nghiệp, có thể vì sợ mất nghề, có thể vì dự án cấm.

Cần nói cho công bằng: kỹ năng đọc code của bạn là thật, và nó rất có giá. Người quen đọc code kỹ thường review (soát lại code người khác) tốt hơn hẳn. Cái này không mất đi đâu cả.

Nhưng bạn sẽ bị người khác vượt lên bởi yếu tố tốc độ. Cùng một việc, đồng nghiệp dùng AI xong sớm hơn bạn đáng kể. Chuyện này không quan trọng trong một tuần, nhưng qua vài năm thì thành khoảng cách lớn.

Chuyện “tôi tự viết từng dòng code” không phải huy hiệu. Nó là cái giá bạn đang trả mà chưa tính ra.

Con đường 3: Người làm chủ hệ thống

Bạn dùng AI nhiều, có khi còn nhiều hơn nhóm 1. Khác biệt nằm ở đúng một quy tắc:

Không merge thứ mình không giải thích được.

AI viết, bạn đọc, bạn hỏi lại, bạn sửa, bạn hiểu, rồi bạn mới ký tên vào. Code là của AI. Hiểu biết về hệ thống là của bạn.

Sau ba năm, số việc bạn làm xong gần bằng nhóm 1. Nhưng bạn là người duy nhất trong ba nhóm trả lời được câu “hệ thống này sập thì bắt đầu tìm từ đâu?”. Và đó chính là câu quyết định lương của bạn.

Điều đáng nói nhất: khoảng cách giữa con đường 1 và con đường 3 mỗi ngày chỉ khoảng 15 đến 20 phút. Chỉ có vậy thôi. Nhưng nó cộng dồn, và sau khoảng một năm rưỡi thì không đuổi kịp nữa.

Phần 2: Chuyện gì xảy ra nếu bạn không kiểm soát được code AI viết

Phần này tôi mong bạn đọc kỹ nhất, vì hậu quả không tới ngay. Nó tới muộn, và tới một lúc.

2.1. Bạn không nhìn ra lỗi khó thấy

AI viết code trông rất đúng. Đó là thứ nó giỏi nhất. Vấn đề là lỗi nó tạo ra thường không phải lỗi cú pháp, vì loại đó máy bắt được rồi. Nó tạo ra những lỗi kiểu này:

• Race condition (hai việc chạy cùng lúc và giành nhau một chỗ dữ liệu). Chạy đúng 99 lần, sai đúng lần thứ 100, và thường là trên production.
• Transaction (một nhóm thao tác phải cùng thành công hoặc cùng hủy) khoanh sai vùng. Khi lỗi xảy ra, dữ liệu không quay về được trạng thái cũ.
• Sai quy tắc nghiệp vụ một cách rất hợp lý. AI đoán quy tắc dựa trên những gì nó từng thấy, và đoán rất thuyết phục. Chỉ có bạn, người đã đọc spec của khách, mới biết là sai.

Không ai nhìn lướt mà bắt được mấy lỗi này. Chỉ người đã hiểu hệ thống trong đầu mới thấy.

2.2. Cảm giác hiểu, nhưng thật ra chưa hiểu

Đây là cái bẫy nguy hiểm nhất, và nó là chuyện tâm lý.

Khi bạn đọc code AI viết và thấy nó quen thuộc, hợp lý, dễ theo dõi, não bạn ghi nhận cảm giác đó thành “à hiểu rồi”. Nhưng nhận ra và tự làm lại được là hai chuyện khác nhau hoàn toàn. Chuyện này đã được nghiên cứu nhiều trong khoa học về học tập: đọc càng trôi chảy thì càng dễ tưởng là mình đã nắm được.

Kết quả là bạn tự chấm điểm mình cao hơn thực tế. Và bạn chỉ phát hiện ra khoảng cách đó vào đúng lúc tệ nhất: trong lúc hệ thống đang sập, hoặc trong cuộc họp với khách hàng.

Cách tự kiểm rất đơn giản: tắt màn hình đi, giải thích lại đoạn code đó cho người ngồi bên cạnh trong hai phút. Ấp úng tức là chưa hiểu. Không có ngoại lệ.

2.3. Nợ kỹ thuật mà không ai nhìn thấy

Một hệ thống ghép từ nhiều mảnh AI viết, mỗi mảnh nhìn riêng thì đúng, nhưng ghép lại thì rời rạc. Cùng một dữ liệu được lưu ở ba nơi mà không nơi nào là bản chuẩn. Chỗ cần ghi log (nhật ký ghi lại hệ thống đã làm gì) thì không có. Không giới hạn số lần gọi. Lỗi xảy ra thì bị nuốt im lặng.

Nó vẫn chạy. Nó demo rất ngon. Rồi nó sập khi có nhiều người dùng thật, và lúc đó không ai biết bắt đầu tìm từ đâu, kể cả người đã viết ra nó.

Phần 3: Dùng AI đúng cách trông ra sao

Không phải là dùng ít đi. Là dùng ở vị trí khác.

Nguyên tắc gốc: AI đứng sau bạn, không đứng trước bạn. Bạn quyết định làm cái gì và tại sao. AI lo phần làm như thế nào. Nếu bạn để AI quyết cả ba thứ đó thì bạn không còn vai trò gì trong quy trình. Mà một quy trình không cần bạn thì sớm muộn cũng bỏ bạn lại.

Bảy thói quen cụ thể:

1. Vẽ trước khi hỏi AI. Vẽ ra các phần của hệ thống và dữ liệu chảy qua đâu. Đánh dấu chỗ dữ liệu được lưu và chỗ có thể phát sinh lỗi. Nếu bạn không vẽ ra được thì bạn chưa hiểu, và AI không hiểu thay bạn được. Mười phút ở bước này thay đổi chất lượng của cả phần sau.

2. Viết spec ngắn trước. Ghi ra: vấn đề là gì, ràng buộc gì, thế nào là làm xong, và những trường hợp lỗi cần xử lý.

3. Coi AI như người phản biện, đừng coi như thầy bói. Đừng chỉ hỏi “viết cho tôi X”. Hỏi thêm: “Cách này hỏng trong trường hợp nào?”, “Còn cách nào khác, và được mất ra sao?”, “Tìm điểm chưa tối ưu trong đoạn code tôi vừa viết.” Chất lượng câu trả lời khác hẳn, và bạn học được thay vì chỉ nhận.

4. Giữ quy tắc làm chủ. Không merge thứ mình không giải thích được trong hai phút mà không cần nhìn màn hình.

5. Thử xóa. Chọn một phần trong hệ thống rồi hỏi: xóa nó đi thì cái gì hỏng, hỏng nặng cỡ nào? Nếu trả lời “không biết” thì bạn vừa tìm ra bài tập về nhà của mình.

6. Mỗi tuần viết tay lại một đoạn. Không phải để chứng minh gì với ai, mà để giữ cho khả năng đọc code khỏi cùn đi.

7. Kiểm tra thư viện trước khi cài. Package này có thật không, bao nhiêu người tải, cập nhật lần cuối khi nào, license loại gì, có an toàn không?.

Bảy thói quen này tốn khoảng 20 đến 30 phút mỗi ngày. Đó đúng bằng khoảng cách giữa con đường 1 và con đường 3.

Phần 4: Tư duy hệ thống là gì, và ba câu hỏi cần thuộc

Có một ông tên Peter Naur, nhà khoa học máy tính người Đan Mạch, từ năm 1985 đã nói một câu mà giờ mới thấy đắt: chương trình thật sự nằm trong đầu người lập trình. Nó là hiểu biết về việc các phần nối với nhau ra sao, tại sao lại nối như vậy, và gỡ một mảnh ra thì chuyện gì xảy ra. Code chỉ là cái bóng của thứ đó.

AI bây giờ đổ bóng rất giỏi. Nhưng nó chưa tạo ra được thứ đổ bóng.

Nói cách khác: code giống như từng nhạc cụ trong dàn nhạc. AI giờ chơi được gần hết các nhạc cụ, nhiều khi còn hay hơn bạn. Nhưng hệ thống là bản nhạc, là chuyện các nhạc cụ hòa vào nhau. AI là dàn nhạc. Nó chưa bao giờ là nhạc trưởng.

Cụ thể hơn, chỗ AI yếu nhất là nhớ những gì đã thống nhất ở nơi khác, lúc khác. Nó nhìn rất rõ cái file đang mở. Nó không biết rằng quyết định này đang mâu thuẫn với một giả định đã đặt ra ở module khác từ sáu tháng trước. Cái nhìn đó là của bạn.

“Tư duy hệ thống” nghe to tát nhưng thật ra chỉ gói lại trong ba câu hỏi. Hỏi trước mỗi lần bạn định giao việc:

Câu 1: Dữ liệu đang nằm ở đâu, và chỗ nào giữ bản đúng?

Ví dụ cho dễ hình dung. Giỏ hàng của khách được lưu ở hai nơi: trên trình duyệt và trong database. Khách thêm một món trên điện thoại, rồi mở lại trên máy tính. Bản nào là bản đúng?

Nếu bạn phải ngồi nghĩ mới trả lời được, thì đó không phải “có thể sẽ có bug”. Bug đã có sẵn ở đó rồi, chỉ là chưa ai gặp thôi.

Trong mọi hệ thống, mỗi loại dữ liệu phải có đúng một chỗ giữ bản chuẩn. Những chỗ còn lại chỉ là bản sao, và bạn phải biết bản sao đó được cập nhật lúc nào.

Câu 2: Nếu nó chạy sai, bạn biết bằng cách nào?

Ví dụ. Năm giờ sáng, Batch lấy dữ liệu từ S3 về Snowflake bị lỗi.

Câu hỏi là: bạn biết vào lúc mấy giờ?

• Nếu câu trả lời là “khi khách hàng báo hệ thống phía sau bị lỗi”, nghĩa là hệ thống của bạn không có kênh báo về. Nó không phải đang chạy, nó chỉ đang tỏ ra là đang chạy.
• Nếu câu trả lời là “có cảnh báo tự động gửi vào slack của team lúc 3 giờ 02”, thì bạn có một hệ thống thật.

Nên trước khi ship, hãy tự hỏi: chỗ này hỏng thì ghi log ở đâu, ai nhìn thấy, và nhìn thấy bằng cách nào.

Câu 3: Xóa phần này đi thì cái gì hỏng theo?

Ví dụ. Bạn có một service (dịch vụ nhỏ chạy riêng) chuyên gửi email xác nhận đơn hàng. Giả sử nó chết.

• Nếu câu trả lời là “khách không nhận được mail, đơn hàng vẫn tạo bình thường”, thì thiết kế của bạn ổn.
• Nếu câu trả lời là “đơn hàng cũng không tạo được luôn”, vì code tạo đơn gọi thẳng sang gửi mail và ngồi chờ, thì bạn vừa phát hiện ra một quả bom. Một chức năng phụ đang có quyền làm sập chức năng chính.

Câu hỏi này còn có tên khác là blast radius (bán kính vụ nổ): một chỗ hỏng thì kéo theo bao nhiêu chỗ khác. Trả lời được câu này cho từng phần trong hệ thống của mình, bạn đã hơn rất nhiều người.

Ba câu hỏi này không cần biết ngôn ngữ nào, framework (bộ khung lập trình) nào. Dev dùng được, BrSE dùng được, PM dùng được, người không biết code cũng dùng được.

Phần 5: Senior đời trước học được những thứ này bằng cách nào?

Đây là phần quan trọng nhất của bài, vì hiểu đúng cơ chế thì bạn làm lại được.

Trước hết phải nói thẳng một chuyện: họ không giỏi hơn bạn. Rất nhiều người đời đó cũng copy từ Stack Overflow mà chẳng hiểu gì. Chúng ta chỉ nhớ những người trụ lại được, còn những người không trụ được thì không ai nhắc tới nữa.

Khác biệt không nằm ở thế hệ. Nó nằm ở chỗ hồi đó môi trường ép người ta vào ba cái vòng học tập, muốn hay không cũng phải đi qua:

Vòng 1: Không có đường tắt, nên buộc phải đọc. Không ai đưa sẵn đáp án. Muốn hiểu một thư viện thì phải mở source ra đọc. Muốn hiểu một lỗi thì phải đọc stack trace (danh sách các hàm đã gọi khi lỗi xảy ra) từng dòng. Việc đọc code người khác, vốn là nền của tư duy hệ thống, hồi đó là bắt buộc, không phải lựa chọn.

Vòng 2: Làm sai là có hậu quả thật. Deploy (đưa code lên chạy) hỏng thì phải thức đêm sửa. Sập production thì phải viết báo cáo rồi ngồi giải trình. Đau thì nhớ, đó là cách bộ não hoạt động, không phải triết lý gì cao siêu.

Vòng 3: Đi hết vòng đời của thứ mình làm. Họ viết, họ deploy, họ vận hành, họ dậy sửa lúc hai giờ sáng. Vận hành là chỗ mà thiết kế được chấm điểm. Bạn chỉ thật sự hiểu một thiết kế khi phải sống chung với hậu quả của nó vào tối thứ Bảy.

Bây giờ mới tới câu hỏi quan trọng: trong ba vòng đó, cái gì là phần cốt lõi và cái gì chỉ là khổ vô ích?

• Khổ vô ích: tài liệu tệ, tìm kiếm chậm, gõ nhiều, dựng môi trường mất ba ngày. Mấy thứ này không dạy bạn cái gì cả. AI xóa chúng đi. Đó là tiến bộ thật.
• Phần cốt lõi: làm sai thì thấy hậu quả, chịu trách nhiệm với thứ mình tạo ra, bị người giỏi hơn hỏi vặn. Mấy thứ này chính là nội dung của việc học nghề.

Và đây là toàn bộ vấn đề của thế hệ bạn:

AI xóa phần khổ vô ích, chuyện đó tốt. Nhưng nếu bạn không để ý, nó xóa luôn cả phần cốt lõi. Mà phần cốt lõi mới là thứ dạy bạn.

Nên việc của bạn không phải là quay lại chịu khổ như đời trước. Việc của bạn là chủ động dựng lại ba cái vòng đó, trong một môi trường không còn tự động ép bạn nữa:

Nếu bạn làm được cột bên phải, có một tin rất tốt: bạn sẽ giỏi nhanh hơn đời trước, chứ không chậm hơn. Vì phần khổ vô ích đã bị xóa, bạn được tiếp xúc với nhiều hệ thống hơn, nhiều tình huống hơn trong cùng một quãng thời gian. Thứ mà đời trước phải mất tám năm mới gặp đủ, bạn có thể gặp trong bốn năm. Với điều kiện là bạn giữ được ba cái vòng kia.

Đây không phải lời an ủi. Đây là cơ hội có thật, và nó chỉ mở cho người chọn con đường 3.

Phần 6: Junior bây giờ nên làm gì

Năm đầu: xây phản xạ

• Giữ quy tắc làm chủ, không ngoại lệ. Đây là thói quen quan trọng nhất trong cả bài này.
• Mỗi PR, viết thêm một câu vào phần mô tả: “tôi có cân nhắc cách X nhưng chọn cách Y vì Z.”
• Mỗi tuần viết tay lại một đoạn AI đã sinh ra.
• Tập đọc log và stack trace cho thật quen. Đây là kỹ năng bị coi nhẹ nhất nhưng trả công cao nhất.

Tự chấm: bạn giải thích được mọi dòng code mang tên mình mà không cần mở AI.

Năm thứ hai đến năm thứ ba: xây hiểu biết

• Vẽ được sơ đồ hệ thống mình đang làm, vẽ từ trí nhớ, không nhìn code.
• Trả lời được ba câu hỏi ở Phần 4 cho phần việc của mình.
• Chủ động xin tham gia thiết kế cơ bản, đừng chỉ nhận phần code.
• Xin theo một tính năng ra tới production rồi quan sát nó trong hai tuần.
• Bắt đầu review code người khác. Dạy lại là cách học nhanh nhất.

Tự chấm: có sự cố, bạn đoán được nguyên nhân trước khi mở log ra xem.

Từ năm thứ ba trở đi: nhận trách nhiệm

• Làm chủ một hệ thống, không phải làm chủ vài task.
• Dám nói “không” với một thiết kế, kèm lý do và phương án thay.
• Kèm junior mới bằng đúng cái bảng ở Phần 5.
• Nhìn ra được hệ quả về vận hành và bảo mật của một quyết định, trước khi nó được viết thành code.

Tự chấm: hệ thống có vấn đề, bạn là người được hỏi.

Rồi bạn sẽ thành người như thế nào?

Không phải người viết code nhanh nhất phòng.

Bạn sẽ thành người mà cả nhóm tìm tới khi hệ thống có chuyện. Người ngồi trong buổi thiết kế và nói “khoan đã, nếu phần này chết thì sao?”. Người mà khách hỏi “tại sao lại thiết kế như vậy?” và nhận được một câu trả lời rõ ràng, có căn cứ, ghi vào biên bản họp được.

Trách nhiệm không phải một khoảng trống đang chờ AI lấp. Nó là một vị trí, và vị trí đó là của con người.

Tư duy hệ thống chỉ là cách bạn xứng đáng với chỗ ngồi đó.

Sẽ có ít người đi hết đường để thành chuyên gia thật hơn trước. Nhưng ai đi hết thì sẽ có giá hơn bao giờ hết. Giống chuyện tập thể dục thôi: ngày xưa người ta khỏe vì làm việc chân tay, còn bây giờ vận động viên khỏe hơn nhiều, nhờ tập có bài bản.

AI đã dọn hết phần “việc chân tay” của nghề này. Phần tập có bài bản thì vẫn còn nguyên đó, chờ bạn.

Và nó thì không prompt ra được.

Hôm nay, ngay trên đoạn code bạn đang làm, thử ba câu hỏi này: Dữ liệu nằm ở đâu? Nó hỏng thì mình biết bằng cách nào? Xóa đi thì cái gì hỏng theo?

Có câu nào bạn trả lời “không biết” thì đó chính là việc đáng làm nhất tuần này.