Làm sao để vẫn yêu thích lập trình trong kỷ nguyên LLM

Có bao giờ bạn cảm thấy mình đang dần kiệt sức vì AI? Lo sợ bị thay thế bởi một người gần như không biết lập trình, chẳng mấy quan tâm đến chất lượng code, nhưng lại sở hữu một tài khoản Claude "xịn"? Thất vọng vì chất lượng code trong dự án của mình — hay tệ hơn, trong chính đoạn code do mình viết? Nếu có, bài viết này dành cho bạn.

Trước khi đi vào nội dung, cần nói rõ: có những lo ngại đạo đức nghiêm túc và chính đáng về các mô hình ngôn ngữ lớn (LLM) do các ông lớn công nghệ vận hành. Những vấn đề đó đã được bàn luận nhiều và người viết hoàn toàn đồng tình — nhưng bài này không bàn về chúng.

Khi niềm vui lập trình bị đe dọa

Với một lập trình viên Haskell, việc viết Haskell là một niềm vui. Không chỉ là sản phẩm tạo ra, mà chính quá trình diễn đạt suy nghĩ bằng ngôn ngữ đó mới là điều thú vị. Khi để AI sinh code thay mình, phần lớn niềm vui ấy bị đánh đổi.

Điều đáng lo là chúng ta đang dần bị biến từ người chủ động sáng tạo thành một bánh răng trong cỗ máy. Kịch bản tồi tệ nhất là ta chỉ nhận một bản đặc tả, ném nó vào LLM, rồi khóc khi hết token vì một "lãnh chúa công nghệ" nào đó quyết định cắt bớt hạn mức.

Câu hỏi đặt ra: làm sao để vẫn giữ niềm vui lập trình, mà vẫn tận dụng được LLM để tăng năng suất một cách hợp lý — thay vì tỏ ra năng suất cao gấp nhiều lần nhưng đánh mất hết niềm vui?

Vì sao vẫn cần tự viết code

Nếu muốn thực sự làm chủ codebase của mình, bạn cần tiếp tục viết code. Để mặc tất cả cho AI sinh ra, codebase sẽ biến thành một vùng đất hoang chỉ có các coding agent sinh sống.

Một lý do quan trọng khác: kỹ năng sẽ mai một nếu không luyện tập. Ngưỡng để giao phó công việc coding cho agent rất thấp, nên chỉ sau vài tuần không tự viết code, bạn sẽ thấy rất khó quay lại.

Thêm nữa, LLM tạo ra code dễ đọc cho con người kém hơn nhiều so với lời quảng cáo. Chúng tạm ổn với code mà sau này chính chúng tiếp tục xử lý, nhưng bạn hẳn đã từng trải qua cảm giác tuyệt vọng khi nhìn vào một file hoàn toàn do máy sinh, chắc chắn có bug ở đâu đó, mà mình thì bất lực không tìm ra vì "địa hình" quá xa lạ.

Dùng LLM như một công cụ ghi chép

Vậy làm sao để có năng suất nếu không để agent viết code? Bằng cách cho chúng làm gần như mọi thứ khác — đặc biệt là những việc nhàm chán, khó chịu, không quá khó để làm đúng và dễ kiểm tra.

Từ thuở sơ khai, máy tính vốn là công cụ ghi chép. Hãy dùng LLM theo cách đó. Một số ứng dụng hữu ích:

• Chuyển một cuộc trao đổi dài giữa các chuyên gia thành danh sách việc cần làm (todo) cụ thể.
• Chạy thử nghiệm, ghi lại kết quả, để AI sắp xếp chúng thành kế hoạch sửa lỗi.
• Dùng công cụ todo, hoặc tốt hơn là file Markdown có frontmatter, để theo dõi các hạng mục kế hoạch.

Lưu ý: LLM có thể có context rất lớn, nhưng nếu nhồi quá đầy, nó vẫn có thể âm thầm mất thông tin.

Đừng để LLM đưa ra bất kỳ quyết định then chốt nào. Hãy bắt nó hỏi lại bạn.

Nếu bạn không hiểu câu hỏi của nó, đó là lỗi của LLM vì không cung cấp đủ ngữ cảnh — hoặc có thể bạn đang kiệt sức và cần nghỉ ngơi. Nếu cứ quay lại cùng một vấn đề mãi, hãy rời màn hình, tự suy nghĩ, rồi quay lại khi đã có hình dung rõ ràng.

Nghiên cứu song song, đừng chỉ ngồi nhìn

Khi giao một nhiệm vụ nghiên cứu cho agent, thật dễ bị cám dỗ ngồi xem nó truy vấn và "suy nghĩ", hoặc mở thêm agent khác ở dự án khác, hoặc đi pha cà phê. Trong ba lựa chọn đó, pha cà phê là tốt nhất. Nhưng lựa chọn tốt hơn nữa là: tự nghiên cứu song song bằng một công cụ tìm kiếm quen thuộc.

Đừng để nó nghiên cứu rồi chấp nhận kết quả như chân lý và lập kế hoạch dựa trên đó. Điều này sẽ dẫn đến nợ kỹ thuật đáng xấu hổ.

Mục đích của việc để agent nghiên cứu không phải là để nó trình bày hết kiến thức cho bạn hay ra quyết định tốt hơn bạn. Mục đích là để bạn không phải tự đi tra Google từng thứ. Bạn nên hiểu lĩnh vực mình đang mô hình hóa ít nhất ngang bằng agent, lý tưởng là tốt hơn.

Hãy bắt agent ghi lại kết quả nghiên cứu kèm liên kết nguồn. Khi nó đề xuất điều gì đó kỳ lạ, hãy hỏi nó dựa trên nghiên cứu nào, nguồn nào. Khoảng 50% trường hợp nó sẽ tự phát hiện sai lầm của mình. 50% còn lại, bạn đọc nguồn và tự mình quyết định.

Bạn code, không phải agent

Các công cụ coding thường dụ bạn theo mô hình "lập kế hoạch trước, rồi để agent code". Hãy từ chối. Lập kế hoạch cùng nhau, nhưng bạn là người viết code.

Hãy yêu cầu LLM nghiên cứu codebase, cho biết việc cần làm hiện tại, liệt kê mọi chỗ cần sửa, cảnh báo các cạm bẫy tiềm ẩn, và nhắc bạn về các nghiên cứu nền tảng liên quan.

Cách làm việc này mang lại nhiều lợi ích: luôn có todo rõ ràng, không phải lo về kế hoạch tổng thể, tập trung cao độ, và hoàn thành nhanh vì mọi thứ đã được lên kế hoạch kỹ. Nó giống như Agile nhưng không có các quy trình phiền phức.

Hãy để các agent xoay quanh cách làm việc của bạn, chứ không phải ngược lại. Những việc phù hợp để giao cho AI:

• Dọn dẹp, tác vụ nhỏ, công việc thường nhật, refactor ít rủi ro.
• Hoàn thiện các trường hợp lặp lại nhàm chán (bạn viết 3 ca thú vị, để nó viết 7 ca tương tự còn lại).
• Đo hiệu năng khi bạn muốn tái cấu trúc module.
• Thay thế một thư viện không còn được bảo trì.

Thiết kế một hệ thống phức tạp từ đầu không nằm trong danh sách này.

Vòng lặp kiểm tra tự động

Bạn có thể nhớ cách ảnh do AI tạo bỗng trở nên chân thực hơn nhiều nhờ mạng đối kháng sinh tạo (GAN): một mô hình sinh ảnh, một mô hình phán xét chất lượng. Áp dụng ý tưởng đó vào lập trình với LLM, ta có vòng lặp review tự động.

Nguyên tắc: đừng chấp nhận, thậm chí đừng đọc, bất kỳ sản phẩm nào của LLM mà chưa qua review tự động. Điều này đúng với code, và đặc biệt đúng với kế hoạch. Khi agent viết code xong, công việc chưa kết thúc — nó chỉ kết thúc khi một agent review không còn phát hiện vấn đề nào.

Việc để AI review code của chính bạn cũng khá hữu ích: đôi khi nó chỉ ra vài lỗi nhỏ, nhưng cũng thường tìm ra bug thật hoặc thiếu sót mà bạn bỏ qua.

Đừng phụ thuộc vào token

Hạn mức token trong một phiên là con số không minh bạch, thay đổi tùy theo ý muốn của nhà cung cấp. Bạn không mua nó như một món hàng trên thị trường công bằng rồi dùng một cách có kế hoạch.

Bạn cần ngừng coi việc hết token là "mua chưa đủ", mà hãy coi đó đúng như bản chất: một sự cố dịch vụ. Công ty LLM đã hứa bạn có thể dùng dịch vụ, và họ không giữ lời.

Hãy chuẩn bị như khi làm việc trên tàu xe không có internet: tải và lưu trước tài nguyên lớn, luôn có sẵn việc để làm offline. Với công việc dùng LLM, điều này nghĩa là phải có danh sách todo đã lên kế hoạch để bạn luôn có việc để làm.

Bảo vệ sức khỏe tinh thần

Văn bản do LLM tạo khác với văn bản con người, và trở nên tệ đặc biệt khi mô hình thực sự không hiểu điều nó đang nói. Hãy coi những đoạn văn bản vô nghĩa của LLM là có thể gây hại cho sức khỏe tinh thần. Đừng đọc quá nhiều.

Khi đầu óc quay cuồng, hãy nghỉ ngơi. Kể cả khi không có agent nào đang chạy nền và "tạo ra giá trị".

Sức khỏe tinh thần của bạn quan trọng hơn năng suất công việc.

Lập trình là hoạt động xã hội

Trong một công ty hay dự án mã nguồn mở, chúng ta gửi pull request, viết issue và commit message cho nhau. Đây là một hình thức giao tiếp. Ngay cả khi chỉ có một mình, bản thân bạn trong quá khứ cũng viết issue và PR cho bạn trong tương lai.

Hãy luôn tiếp cận con người trước. Đừng gửi một PR hoàn toàn do máy tạo cho ai đó. Nếu agent đề nghị viết cả nội dung PR bằng ngôn ngữ hoàn chỉnh, đó không phải giao tiếp — đó là đầu ra của công cụ. Hãy đối xử với chúng như số liệu benchmark hay log debug: thêm vào sau phần nội dung PR do bạn tự viết, để người khác tự quyết định có muốn đọc hay không.

Kết luận

Với cách làm này, người viết cho biết mình năng suất hơn khoảng gấp đôi so với khi không dùng LLM. Con số này khiêm tốn hơn nhiều so với các "vibe coder" thuần, nhưng điều đó không sao.

Tôi hình dung mình như một người làm vườn dùng phân hữu cơ nhẹ nhàng, trong khi các vibe coder thì nhấn chìm cánh đồng của họ trong hóa chất công nghiệp. Tôi tin cách của mình bền vững hơn.

Với lập trình viên Việt Nam đang làm việc trong các dự án outsource hay sản phẩm, bài học này đặc biệt đáng lưu tâm: áp lực tăng năng suất bằng AI là có thật, nhưng đánh đổi kỹ năng và sức khỏe tinh thần lấy tốc độ ngắn hạn là một canh bạc dài hạn rất đắt. Giữ quyền làm chủ code của mình — và giữ niềm vui với nghề.