Bài viết này phân tích một câu chuyện thực tế trong một dự án phần mềm để làm rõ các kỹ năng AI cộng sinh.
1. Bối cảnh Case Study
Một dự án sử dụng ngôn ngữ C, với khoảng 2Gb source code. C là một ngôn ngữ rất dễ gặp memory leak (rò rỉ bộ nhớ).
Như thông lệ, đội ngũ dự án luôn cố gắng review source code thật kỹ trước khi merge vào nhánh master. Định kỳ, họ chạy code bằng tool Valgrind để phát hiện memory leak trong trường hợp hệ thống hoạt động bình thường.
Tuy nhiên, trong source code có những đoạn if – else – goto mà chỉ nhảy vào khi hệ thống gặp lỗi. Hệ thống test không thể cover (bao phủ) hết được các trường hợp này. Họ muốn đảm bảo rằng không có memory leak trong những luồng hiếm gặp đó.
Họ bàn luận với nhau, dự định sẽ chọn ra một số file code quan trọng, chia đều cho các thành viên trong nhóm (khoảng 20 người) và dành ra khoảng 3 tuần để cùng nhau review.
Họ nhận thấy việc review source code trong 3 tuần có vẻ sẽ rất nhàm chán và dễ bỏ sót lỗi. Vì vậy, họ nghĩ đến việc sử dụng AI để review.
Họ cùng nhau bàn bạc, tìm cách làm thế nào để AI có thể phát hiện được memory leak trong source code C. Đây không phải là mảnh đất phù hợp cho AI, vì ngôn ngữ C trong các dự án lớn có luồng code rất phức tạp.
Cuối cùng, họ đề ra phương án như sau:
Đầu tiên, họ tự phân tích xem, bản chất khi một lập trình viên review code để tìm memory leak, bộ não hoạt động như thế nào. Họ nhận ra một số “pattern” (khuôn mẫu) trong đầu mà họ hay dùng để phát hiện memory leak, bao gồm:
- Tập trung nhìn vào những điểm thoát của hàm (như return mã lỗi, câu lệnh goto, exit()).
- Tại từng điểm thoát, họ sẽ nhìn lại toàn bộ những vùng nhớ đã được cấp phát trong hàm, xem chúng đã được free chưa.
- Sau khi kiểm tra trong hàm, họ kiểm tra đến những vùng nhớ được cấp phát ở con trỏ global. Tại tất cả các điểm mà chương trình có thể kết thúc, chúng đã được free chưa.
Sau đó, họ “dạy” (training) cho Copilot thông qua những câu lệnh prompt như sau:
- Các hàm allocate memory sẽ có tên là A(), B(), C()…
- Các hàm free memory sẽ có tên là C(), D(), E()…
- Function có thể kết thúc thông qua các câu lệnh như: return, goto…
- Chương trình chính có thể kết thúc thông qua các câu lệnh như: return trong hàm main, exit() tại bất cứ điểm nào.
- Nếu một vùng nhớ bất kỳ được allocate bởi bất cứ hàm nào trong (1) thì nó phải được free bởi (2), nếu không sẽ bị memory leak.
- Thực hiện phân tích source code, bằng cách đọc từng hàm một, kiểm tra trước khi hàm kết thúc, có memory leak không.
- Kiểm tra các câu lệnh return trong hàm main, hoặc trước các câu lệnh exit(), các con trỏ được cấp phát bộ nhớ có bị memory leak không.
- Kết quả phân tích đưa ra bằng dạng bảng (cột 1: tên hàm, cột 2: tên file và số dòng gây lỗi, cột 3: mô tả ngắn về nguyên nhân).
Sau đó, họ đưa cho Copilot danh sách các file. Công cụ này tự thực hiện phân tích và đưa kết quả ở dạng bảng. Họ chỉ cần đối chiếu và kiểm tra lại theo source code một lần nữa.
2. Câu hỏi phân tích
- Trong câu chuyện trên, những ý nào thể hiện rõ ràng nhất kỹ năng Mindset Rebuilding?
- (Câu hỏi mở) Ngoài Mindset Rebuilding, trong câu chuyện này có thể hiện ý nghĩa của Identity Realignment không? Tại sao?
3. Phân tích đáp án
Bài học thực tế về Mind Observer
Trước khi đi vào đáp án chính, quá trình biên soạn bài phân tích này cũng là một bài học thực tế về Mind Observer.
Phiên bản phân tích ban đầu (của chúng tôi) có xen lẫn một ít cảm xúc, nguyên nhân là do nỗ lực bỏ ra viết bài vẫn chưa nhận được sự đồng điệu như kỳ vọng từ người đọc. Sau khi dùng Mind Observer để tự quan sát, chúng tôi đã điều chỉnh lại câu chữ, đưa bài viết về hướng trung tính, phù hợp với mục đích cốt lõi là chia sẻ kiến thức.
Mục đích của case study này là muốn cộng đồng thấy 4 kỹ năng AI, tuy đọc lý thuyết có vẻ trừu tượng, nhưng phần ứng dụng thực tế lại rất sát sườn với công việc hàng ngày.
Mấu chốt của Mindset Rebuilding (Kỹ năng cốt lõi)
Cốt lõi của việc Mindset Rebuilding (Tái cấu trúc tư duy) trong bài viết là gì?
- Thay đổi 1: Đội ngũ lập trình viên đã nhận ra rằng hiện tại, AI có thể thay họ làm một số việc trong dự án, miễn là họ chia nhỏ và giải thích được cho nó hiểu.
- Thay đổi 2: Họ nhận ra rằng, có những loại công việc trước kia họ vẫn nghĩ là phức tạp (ví dụ: review code tìm memory leak), thực ra lại có thể chia ra thành từng bước đơn giản, để cho AI có thể làm được một cách máy móc.
Hai điểm thay đổi tư duy ở trên là cốt lõi nhất. Chỉ cần thay đổi được hai điểm này, tự đội ngũ sẽ tìm ra giải pháp để thực hiện nó (ví dụ: cắt cử người nghiên cứu AI, hoặc thuê thêm nhân sự trẻ để đảm nhiệm việc này).
Các bước mà họ thực hiện (như ngẫm lại cách mình làm, chia nhỏ bước, mô tả…) được gọi là giải pháp thực hiện. Giải pháp là phần nổi, được quyết định bởi tư duy. Khi đội ngũ đã nhìn ra việc “Review code AI có thể làm tốt hơn con người”, kiểu gì họ cũng sẽ tìm ra giải pháp.
Phương pháp luận: Phân biệt Tư duy (Lõi) và Giải pháp (Vỏ)
Câu chuyện trong case study được chia làm 2 tầng:
- Tầng Vỏ (Giải pháp): Cách thức thực hiện, các bước prompt.
- Tầng Lõi (Tư duy): Sự thay đổi trong nhận thức.
Tầng giải pháp thì rất dễ nhận biết và học theo. Nhưng làm thế nào để phát hiện được tư duy? Phương pháp là đặt tiếp một câu hỏi để đào sâu: “Tại sao tự nhiên họ lại nghĩ ra giải pháp đó?”
Ở ngoài đời, khi bạn thấy một Senior đưa ra cách debug, fix bug, nếu bạn chỉ học lại theo kiểu “pattern” (dạng lỗi đó thì làm như vậy), bạn sẽ mãi mãi là người đi sau. Vì bạn chỉ học được lớp vỏ, mà không học được cái lõi tư duy của người Senior kia. Muốn học được lõi, bạn phải đặt câu hỏi: “Tại sao anh/chị lại nghĩ ra cách fix đó?”
Con người thường ngại học tư duy tầng sâu, vì chúng trừu tượng và học vất vả. Các kỹ năng ở tầng bề mặt thì hấp dẫn hơn vì chúng trực quan, học nhanh dễ áp dụng. Nhưng với xu hướng của AI, những loại công việc ở tầng bề mặt (code, test, viết tài liệu…) sẽ dần bị thay thế. Các khóa học dạy về prompt, ChatGPT… nhiều nơi dạy theo kiểu “pattern”, “form mẫu”. Người học dễ áp dụng, dễ hứng thú, nhưng không giải quyết được vấn đề tư duy cốt lõi.
Phân tích câu hỏi mở: Identity Realignment
Câu trả lời là Có, ở mức độ nhẹ.
Đó là khi đội ngũ lập trình viên đã biết chấp nhận giới hạn của mình về mặt sinh học.
Họ biết rằng nếu review 1 file code C khoảng 10k line, họ có thể làm tốt hơn AI, nhưng nếu phải review 10, 20 files, họ sẽ thua AI. Họ thua ở đây không phải vì trình độ, mà vì bộ não của họ là một bộ não sinh học: nó biết mệt mỏi, ghét sự nhàm chán, và có thể bị nhầm lẫn.