Trong thời đại AI tuôn ra mã nguồn, khi nước rút sẽ lộ ra ai bơi mà không mặc gì
(evan-moon.github.io)Tóm tắt cốt lõi
- Chỉ 3 năm sau khi ChatGPT xuất hiện, một ngày làm việc của lập trình viên đang dịch chuyển từ "viết mã" sang "kiểm tra đầu ra của AI"
- Vai trò của lập trình viên không biến mất, mà trọng tâm đang chuyển từ người viết mã sang người review và phê duyệt
- AI không phải là một thực thể pháp lý nên không thể chịu trách nhiệm; các quy định như EU AI Act cũng đang được siết theo hướng quy trách nhiệm cho con người
- Năng lực cốt lõi cần có trong thời đại AI không phải là kỹ thuật prompt, mà là dự đoán chi phí thay đổi dài hạn, đánh giá mức độ trừu tượng hóa, diễn đạt tri thức ngầm thành ngôn ngữ — về bản chất vẫn giống với những gì một lập trình viên giỏi luôn cần
- Nếu giải thích bằng khái niệm độ phức tạp ngẫu nhiên vs độ phức tạp bản chất của Fred Brooks, thì thứ AI giải quyết chỉ là độ phức tạp ngẫu nhiên; còn độ phức tạp bản chất của domain vẫn cần phán đoán của con người
- Hiệu lực của kỹ năng thành thạo công cụ (như prompt engineering) bị ràng buộc vào chu kỳ thay thế công cụ, nhưng năng lực phán đoán thiết kế và diễn đạt tri thức ngầm vẫn còn giá trị chừng nào độ phức tạp bản chất của phần mềm còn tồn tại
Tóm tắt chi tiết
3 năm sau ChatGPT
- Vào cuối năm 2022 khi ChatGPT xuất hiện, không ai ngờ nó sẽ phát triển với tốc độ này
- Định nghĩa truyền thống về lập trình viên: người thực hiện toàn bộ chuỗi "phân tích yêu cầu ngôn ngữ tự nhiên → thiết kế → tự triển khai"
- Hiện nay, phần lớn một ngày làm việc là "truyền ngữ cảnh cho AI → đọc mã được sinh ra, chỉnh sửa rồi yêu cầu lại"
- Các AI coding agent đã vượt qua mức hỗ trợ đơn giản, đạt tới mức ở đơn vị hàm hoặc mô-đun mà khó phân biệt với mã do con người viết
Từ người viết sang người ra quyết định
- Hành vi sản xuất mã đang chuyển từ "tự tay viết mã" sang "đưa ra phán đoán về mã"
- "Phán đoán" ở đây không chỉ là kiểm tra xem đầu ra của AI có đúng ý không, mà là xác minh xem ý định kinh doanh đã được chuyển dịch đúng thành hiện thực kỹ thuật hay chưa
- Câu hỏi cốt lõi là: "Nếu mã do AI viết gây ra lỗi thanh toán thì ai chịu trách nhiệm?"
- Vì AI không phải là thực thể pháp lý, chủ thể chịu trách nhiệm là lập trình viên và tổ chức đã review, phê duyệt đoạn mã đó
- EU AI Act có hiệu lực năm 2024: bắt buộc giám sát của con người đối với hệ thống AI trong các lĩnh vực rủi ro cao như y tế, tài chính, hạ tầng
- Trách nhiệm trong tai nạn xe tự lái → nhà sản xuất và tài xế; AI y tế được FDA phê duyệt → quyết định cuối cùng vẫn là bác sĩ; Flash Crash năm 2010 → chủ thể vận hành thuật toán là đối tượng chịu quản lý
- Mức độ tự động hóa càng cao thì cấu trúc trách nhiệm không mờ đi, mà ngược lại còn có xu hướng quy về phía con người rõ ràng hơn
Những năng lực lập trình viên cần có trong thời đại AI
① Năng lực dự đoán chi phí thay đổi dài hạn
- AI được tối ưu để tạo ra "mã chạy được" (tái hiện các mẫu xuất hiện thường xuyên nhất trong dữ liệu huấn luyện)
- Mã chạy được ngay lúc này và mã vẫn dễ bảo trì sau 6 tháng là hai tiêu chí hoàn toàn khác nhau
- Chi phí của một thiết kế tồi không phát sinh vào lúc viết mã, mà vào lúc cần thay đổi
- Trên LinkedIn ngày càng nhiều bài viết kiểu "làm bằng AI xong nhưng khó bảo trì nên phải tuyển lập trình viên", hoặc "không thể gắn thêm tính năng nên đành bỏ"
② Năng lực đánh giá mã từ nhiều góc độ
- Ngoài độ chính xác chức năng (có thể kiểm chứng bằng test), còn phải đồng thời cân nhắc chất lượng cấu trúc, hàm ý về hiệu năng và khía cạnh bảo mật
- Tốc độ sinh mã của AI càng nhanh thì sự cân bằng giữa tốc độ sản xuất và năng lực review càng dễ bị phá vỡ
- Trước đây khi con người tự viết, sản lượng mã có một giới hạn vật lý; còn AI có thể sinh ra hàng trăm dòng chỉ trong vài giây
- Nếu tiêu chuẩn review, cơ chế review song song và các cổng kiểm soát tự động không đủ mạnh, technical debt sẽ tích tụ nhanh hơn
- Lý do nhiều công ty không cảm nhận được năng suất tăng sau khi áp dụng AI: tốc độ tạo mã tăng lên, nhưng quá trình review mã do AI sinh ra lại trở thành nút thắt cổ chai
③ Năng lực trừu tượng hóa
- AI cũng có thể định nghĩa interface, tách class, tách module, và làm khá tốt về mặt hình thức
- Khác biệt mang tính quyết định: sự trừu tượng hóa của AI dựa trên trung bình thống kê, còn sự trừu tượng hóa của lập trình viên dày dạn là phán đoán trade-off trong điều kiện tài nguyên hữu hạn và tương lai bất định
- Điểm nguy hiểm của mã do AI sinh ra là: nhìn bề ngoài có vẻ rất ổn — file được chia hợp lý, naming theo đúng convention, pattern cũng quen thuộc
- Vấn đề chỉ lộ ra khi cần thay đổi: "Đến lúc muốn thêm một phương thức thanh toán mới mới nhận ra rằng cấu trúc 'trông có vẻ sạch sẽ' ấy buộc phải sửa đồng thời ở khắp nơi"
- Ví dụ frontend: AI có thể nhồi data fetching, state management và UI rendering vào một component khổng lồ; hoặc ngược lại, với một biểu đồ đơn giản lại dựng hẳn 3 custom hook + context provider
④ Năng lực biến tri thức ngầm thành tri thức tường minh
- Muốn ra lệnh chính xác cho AI, bạn phải biến trực giác kiểu "có gì đó không ổn" thành ngôn ngữ cụ thể như "hàm này đang mang hai trách nhiệm"
- Điều quan trọng không phải các kỹ thuật prompt hình thức như few-shot hay chain-of-thought, mà là khả năng xác định rõ cần tạo ra cái gì, ngữ cảnh nào là quan trọng, rồi truyền đạt điều đó
- Tuổi thọ của kỹ năng dùng công cụ: bị ràng buộc vào chu kỳ thay thế công cụ (
jQuery → React,Webpack → Vite) - Tuổi thọ của năng lực phán đoán thiết kế và diễn đạt tri thức ngầm: còn hiệu lực chừng nào độ phức tạp bản chất của phần mềm còn tồn tại
Sự cần thiết của việc thiết kế luyện tập có chủ đích
- Ai cũng nói "hãy tập trung vào thứ công cụ không làm được", nhưng nghịch lý là cơ hội để rèn luyện chính những thứ đó lại đang giảm đi
① Hai điểm không nên giao cho AI: thiết kế và review
- Thiết kế ở giai đoạn trước khi viết mã: nếu bạn xác định trước interface và ranh giới trách nhiệm trước khi gõ prompt, bạn sẽ có cơ sở để so sánh đầu ra của AI với quyết định thiết kế của chính mình
- Thói quen giao PR review cho AI, thấy không có vấn đề gì rồi bấm duyệt luôn = "ra sân trong giờ thể dục nhưng chỉ ngồi trên ghế rồi quay vào"
② Dành thời gian cố ý tự tay viết
- Cảm giác về thiết kế chỉ có khi bạn biết nỗi đau của việc triển khai. Nỗi đau chưa từng trải qua sẽ không biến thành cảm quan
- Với lập trình viên junior, review mã do AI sinh ra cũng giống như "bắt một người còn đang học lái xe đi đánh giá phán đoán của xe tự lái"
- Năng lực coding trong tương lai: không còn là công việc làm hằng ngày, mà là một hình thức rèn luyện để duy trì khả năng phán đoán (quá trình lấy bằng hành nghề reviewer)
③ Luyện tập diễn đạt bằng ngôn ngữ câu hỏi "vì sao"
- Nếu dừng ở "có gì đó lạ", đó chỉ là trực giác; nếu đi tới mức "hàm này đang mang hai trách nhiệm", đó mới là ngôn ngữ
- Đừng dừng lại ở chỗ mã do AI tạo ra chạy được, mà hãy có thói quen tự hỏi: "Vì sao lại chọn cấu trúc này?", "Nếu là cấu trúc khác thì trade-off sẽ là gì?"
Cuối cùng, bản chất vẫn không thay đổi
- Fred Brooks (1986): độ phức tạp ngẫu nhiên (giới hạn của công cụ) vs độ phức tạp bản chất (nằm trong chính vấn đề)
- Thứ AI giải quyết là độ phức tạp ngẫu nhiên — boilerplate, mẫu lặp lại, lỗi cú pháp
- Độ phức tạp bản chất (sự mơ hồ của yêu cầu kinh doanh, cân bằng giữa các mục tiêu thiết kế xung đột, tính bất định của thay đổi trong tương lai) sẽ không biến mất dù AI có tiến bộ đến đâu
- Chừng nào con người vẫn là chủ thể của phán đoán và trách nhiệm, bản chất của những năng lực cần cho việc phán đoán sẽ không thay đổi
- Mức độ tự động hóa sản xuất mã càng cao thì tỷ trọng của năng lực phán đoán để kiểm định thành phẩm lại càng được nhấn mạnh hơn
14 bình luận
Cảm ơn mọi người đã đưa ra những ý kiến rất hay!
Việc tôi nhắc đến "trách nhiệm" trong bài không phải vì con người mắc ít sai lầm hơn AI ở mọi mặt, mà vì hệ thống pháp lý và đạo đức của xã hội hiện đại hiện vẫn chỉ giả định con người (hoặc pháp nhân) là "chủ thể chịu trách nhiệm".
Như bạn gcback đã nói, nếu sự an toàn về mặt thống kê được chứng minh thì trong tương lai ngay cả hệ thống trách nhiệm cũng có thể thay đổi, nhưng ít nhất trong tương lai gần, tôi cho rằng tình thế tiến thoái lưỡng nan mang tính xã hội về việc "ai sẽ vào tù hoặc bồi thường cho tai nạn do AI gây ra" sẽ khó có thể theo kịp tốc độ phát triển của công nghệ..!
Tôi cũng nghĩ vậy. Đã đọc rất hay.
Liệu nước đang rút đi, hay đang dâng lên? “Năng lực mà lập trình viên được yêu cầu trong thời đại AI” à, chà... nếu lập trình viên vẫn tiếp tục tồn tại thì đúng là vậy nhỉ.
Từ góc độ thực tế sử dụng AI trong công việc, tôi rất đồng cảm với nhận định rằng phát triển bằng AI -> giám sát đầu ra của AI.
Ngoài ra, AI cũng đang hỗ trợ rất nhiều trong việc giải quyết độ phức tạp mang tính bản chất. [kiểm tra mâu thuẫn khi phân tích yêu cầu, kiểm tra trùng lặp, đặt câu hỏi về giá trị cốt lõi]
Cần có thêm nhiều người mù quáng tin vào AI hơn nữa.
Lý do là gì vậy?
Có lẽ đây cũng chỉ là giai đoạn quá độ.
Ngay cả trong số những huấn luyện viên bóng đá nổi tiếng, cũng có nhiều người không xuất thân từ cầu thủ.
Dù không phải là người xuất sắc nhất, tôi nghĩ anh ấy trở nên nổi tiếng vì mức độ hiểu biết vượt trội.
Nhưng nhắc đến bóng đá thì tôi lại nghĩ tới Chung Mong-gyu.
Đó là vì họ có đủ phẩm chất để làm huấn luyện viên bóng đá ngay cả khi chưa từng là tuyển thủ, và người làm huấn luyện viên chính là người có thể chịu trách nhiệm về kết quả trận đấu.
Đúng vậy, cũng có những huấn luyện viên không xuất thân là vận động viên.
Tuy nhiên, những huấn luyện viên như vậy không phải nổi bật vì họ không từng là vận động viên... mà có lẽ là vì dù không xuất thân từ giới vận động viên, họ vẫn sở hữu tầm nhìn vượt trên cả vận động viên. Trong lĩnh vực đó, thực tế có thể gọi họ là những "siêu nhân" cũng không quá lời.
Tôi cũng đồng ý.
Gần đây nhìn vào kiểu harness hay loop, có vẻ con người chỉ đưa ra spec, còn đến cả việc review hay QA thì AI cũng tự xử với nhau theo hướng đó.
Tôi đồng ý.
Cuối cùng, vì mức độ kiểm định và xác nhận cũng khó tránh khỏi việc AI sẽ vượt con người, nên có lẽ chi phí để AI chịu trách nhiệm cũng sẽ chỉ thấp hơn chi phí hiện nay khi con người chịu trách nhiệm.
Dù là con người hay AI, đây là cuộc chơi mà bên nào thống kê cho thấy ít mắc sai sót hơn thì sẽ thắng.
Dân chủ hóa việc làm đạo diễn à? Haha, làm đạo diễn là vì có tố chất, chứ không phải không có tố chất mà vẫn làm đạo diễn được.