- Trái với quan niệm phổ biến rằng trí tuệ nhân tạo sẽ biến lập trình viên thành “người quản lý” hay “biên tập viên”, tác giả đề xuất cách tiếp cận “lập trình như một bác sĩ phẫu thuật” và nhấn mạnh việc tập trung vào những công việc cốt lõi
- Giống như bác sĩ phẫu thuật chỉ tập trung vào phần trọng yếu của ca mổ nhờ có đội ngũ hỗ trợ, lập trình viên có thể ủy thác các công việc phụ cho công cụ AI để chuyên tâm giải quyết các vấn đề bản chất
- Các công việc chính (ví dụ: tạo mẫu UI) vẫn do con người trực tiếp thực hiện, nhưng các tác vụ lặp lại như viết tài liệu, sửa lỗi và khám phá mã nguồn có thể để AI agent xử lý
- Bằng cách giao cho AI những công việc lặp đi lặp lại đơn giản, có thể ủy quyền phần việc nặng nhọc mà không phát sinh vấn đề phân tầng địa vị, đồng thời nhờ khả năng sẵn sàng 24/7, có thể giao việc cả vào đêm khuya hay giờ nghỉ trưa
- Cách làm này liên hệ với khái niệm “autonomy slider” của Andrej Karpathy, cho thấy chiến lược tận dụng AI cần thay đổi theo mức độ tự chủ của từng loại công việc
Lập trình như một bác sĩ phẫu thuật: khái niệm cốt lõi
- Phản đối dự đoán phổ biến rằng AI sẽ biến lập trình viên thành quản lý hoặc biên tập viên, tác giả đề xuất cách làm việc như một bác sĩ phẫu thuật (Surgeon)
- Bác sĩ phẫu thuật trực tiếp thực hiện ca mổ, nhưng nhờ đội ngũ hỗ trợ xử lý khâu chuẩn bị và các việc phụ để chỉ tập trung vào công việc cốt lõi đòi hỏi chuyên môn riêng
- Lập trình viên cũng có thể dùng AI như lực lượng hỗ trợ để tập trung vào các công việc sáng tạo cốt lõi
- Với vai trò người tạo mẫu UI, tác giả đặt mục tiêu dùng công cụ AI để dành 100% thời gian cho công việc có ý nghĩa
- Tối đa hóa năng suất bằng cách giao các công việc phụ mà AI có thể xử lý
Những công việc phụ có thể ủy thác cho AI
- Danh sách các tác vụ hỗ trợ mà AI hoàn toàn có thể đảm nhiệm
- Viết hướng dẫn liên quan đến codebase trước khi thực hiện các thay đổi lớn
- Tạo bản nháp mã “spike” cho những lần thử thay đổi quy mô lớn
- Sửa lỗi TypeScript hoặc bug có đặc tả rõ ràng
- Viết tài liệu cho tính năng đang được phát triển
- Những công việc này có thể chạy bất đồng bộ trong nền
- AI có thể làm việc vào giờ nghỉ trưa hoặc ban đêm, để hôm sau có thể xem lại ngay
- Nhờ vậy, giống như “một bác sĩ phẫu thuật bước vào phòng mổ đã sẵn sàng”, lập trình viên có thể tập trung vào phần lập trình cốt lõi khi mọi khâu chuẩn bị đã hoàn tất
Thanh trượt tự chủ (Mind the autonomy slider)
- Cách sử dụng AI có sự khác biệt lớn giữa công việc cốt lõi và công việc hỗ trợ
- Thiết kế và tạo mẫu cốt lõi vẫn do con người trực tiếp thực hiện, nơi vòng phản hồi nhanh và khả năng quan sát cao là rất quan trọng
- Ngược lại, với các công việc phụ, giao cho AI tự chủ trong thời gian dài sẽ hiệu quả hơn
- Tác giả ưu tiên Claude Code cho các phiên làm việc dài không giám sát, và gần đây là Codex CLI
- Sự khác biệt này tương tự với khái niệm “autonomy slider” của Andrej Karpathy
- Tùy theo mức độ tự chủ mà công cụ và cách tư duy cần thiết sẽ khác nhau, và việc nhầm lẫn chúng là điều nguy hiểm
AI và khái niệm “đội phẫu thuật phần mềm”
- Khái niệm “bác sĩ phẫu thuật phần mềm” là một ý tưởng cũ do Harlan Mills đề xuất trong cuốn "The Mythical Man-Month" của Fred Brooks năm 1975
- Cấu trúc xoay quanh một “chief programmer”, được hỗ trợ bởi “copilot” và nhân sự quản trị
- Trước đây các vai trò hỗ trợ này do con người đảm nhiệm, nhưng AI đang thay thế theo cách khả thi hơn về mặt kinh tế
- Tác giả cho rằng sự thay đổi này mang ý nghĩa nhiều hơn là chỉ cắt giảm chi phí
- Nó giúp giảm bớt vấn đề phân cấp địa vị (status hierarchy)
- Bằng cách giao cho AI phần grunt work lặp lại và nhàm chán, có thể giải quyết sự mất cân đối trong phân chia công việc trong nhóm
- Vì AI luôn sẵn sàng 24 giờ, nó còn có thể làm những công việc nghiên cứu ban đêm hoặc phân tích mã mà thực tập sinh con người không thể đảm nhận
Notion và sự mở rộng của cách “làm việc như bác sĩ phẫu thuật”
- Tác giả cho biết tại Notion, nơi mình đang làm việc, cách tiếp cận này đang được triển khai trong thực tế
- Ở cấp độ công ty, việc sử dụng các công cụ lập trình AI được hỗ trợ tích cực, và codebase cũng được thiết kế phù hợp với điều đó
- Hiệu quả tăng năng suất đặc biệt lớn với những lập trình viên mới tham gia vào codebase quy mô lớn
- Ở khía cạnh sản phẩm, Notion muốn mở rộng cách “làm việc như bác sĩ phẫu thuật” không chỉ cho lập trình viên mà cho mọi lao động tri thức
- Mục tiêu cốt lõi không phải là ủy thác công việc quan trọng, mà là xác định và giao đi những công việc phụ lặp lại, không quan trọng để giúp mọi người tập trung vào điều quan trọng nhất
7 bình luận
Có vẻ ý ở đây là hãy tập trung vào công việc thuộc phần cốt lõi, còn các công việc bên lề thì giao cho AI. Tôi khá đồng ý với điều này, và có vẻ những công việc không thuộc domain cốt lõi mà có thể được thay thế bằng một số SaaS, hoặc các công việc hành chính, thì hoàn toàn có thể được AI thay thế. Câu hỏi gây tranh cãi hơn có lẽ là liệu có thể thay thế công việc cốt lõi bằng AI hay không. Cuối cùng thì xu hướng sẽ tiếp tục nghiêng về phía nào cho ra kết quả tốt hơn. Nhìn vào việc giải các bài IOI hay LeetCode, đôi khi AI còn cho thấy năng lực lập trình vượt trội hơn con người rất nhiều. Việc dự đoán vội vàng có vẻ vượt quá khả năng của tôi, nên chắc phải tiếp tục quan sát thêm.
Phép ví này là một so sánh hoàn toàn sai lầm vì không nắm được bản chất.
Phẫu thuật là công việc không thể đảo ngược, còn lập trình là công việc có thể đảo ngược được (tức là có thể save and load).
Nếu phẫu thuật cũng có thể đảo ngược được thì bác sĩ phẫu thuật cũng sẽ giao cho cấp dưới biết mổ thực hiện, còn bản thân đứng phía sau làm thiết kế, review và quản lý sẽ hiệu quả hơn. Vì nếu có sai thì chỉ cần hoàn tác lại là xong.
Tôi đồng ý. Tương tự, tôi cũng nghĩ nhiều người hay nhầm lẫn kỹ nghệ phần mềm với kỹ nghệ trong ngành xây dựng.
Nếu thật sự muốn code như một "bác sĩ phẫu thuật", chẳng phải nên để chỉ những người tốt nghiệp ngành khoa học máy tính mới được lập trình sao. Nếu tăng chỉ tiêu khoa học máy tính thì các lập trình viên cũng nên đoàn kết rồi đình công một chút nữa......
Sao không có trợ lý lập trình viên chứ!?
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
Ý kiến trên Hacker News
Nếu một bác sĩ phẫu thuật mới vào nghề bắt đầu ca mổ với niềm tin rằng y tá hay bác sĩ gây mê sẽ ngăn sai sót giúp mình, họ có thể nhanh chóng khiến bệnh nhân tử vong
Việc cần có cả ê-kíp phẫu thuật không có nghĩa là đào tạo bác sĩ phẫu thuật chính là không cần thiết
Vấn đề là ở chỗ một bác sĩ phẫu thuật thiếu kinh nghiệm nghĩ rằng “y tá sẽ đưa dao mổ cho mình nên mình không cần học làm gì”
Nếu cuối cùng vẫn phải học bằng cách hy sinh bệnh nhân thì cứ làm vậy, nhưng nếu không thì trước hết phải vào trường y đã
Vì thế, xuyên suốt bài viết có cảm giác như đang thấy hiệu ứng Dunning-Kruger (thiên kiến nhận thức khi người thiếu năng lực lại đánh giá khả năng của mình cao hơn thực tế rất nhiều)
Tôi từ lâu đã cho rằng kỹ sư phần mềm nên đọc The Mythical Man-Month
Trong 25 năm gần đây, cách phát triển phần mềm đã thay đổi mạnh mẽ, như sự chuyển dịch từ waterfall sang agile
Nhưng khi làm phát triển dựa trên LLM (Codex, Claude Code, v.v.), lại có cảm giác như đang quay về mô hình phát triển kiểu thập niên 70~80
Bây giờ giống như ta có thể suy nghĩ về kiến trúc như thiết kế một nhà thờ lớn, còn phần triển khai chi tiết thì có thể ủy thác
Trong phẫu thuật, tại một thời điểm chỉ có một người thao tác, còn phần mềm thì nhiều người có thể cùng chạm vào đồng thời
Nó giống một đội thể thao hơn, và chúng ta mất thời gian để đạt độ hoàn thiện vì thiếu luyện tập hay huấn luyện
Nhờ vậy có thể tập trung vào thiết kế nhiều hơn là viết code
Trên thực tế, nếu xây một tòa nhà cao tầng thì phải để ý cả chất lượng thép và nguồn gốc bu-lông
Bỏ qua những thứ đó là nguy hiểm
Phép so sánh này sai cả theo nghĩa đen lẫn nghĩa bóng
Bác sĩ phẫu thuật không chỉ là người lao động trực tiếp mà còn là người quản lý toàn bộ ca mổ, và thực tế thì bác sĩ gây mê mới là người quan trọng nhất
Ngoài ra, chính khái niệm “lao động tay chân đơn giản (grunt work)” cũng đã là một cách nhìn sai
Thái độ xem bản thân là bác sĩ phẫu thuật còn người khác là nhân lực phụ trợ là một góc nhìn tự cho mình là trung tâm
Giống như khái niệm “Chief Programmer” của Brooks, lập trình viên chủ chốt có thể làm việc nhờ sự hỗ trợ của cả nhóm
Tác giả xem junior không phải là nhân lực cấp thấp đơn thuần mà là người được cố vấn
Đây không phải phép ví von hoàn hảo, nhưng thông điệp về công cụ lập trình AI vẫn đáng để tôn trọng
Họ còn lấy ví dụ lịch sử cho thấy từng có thể phẫu thuật mà không cần gây mê
Ví dụ như các giải thích framework ví lập trình viên với thợ mộc; ngoài đời, thợ lành nghề cũng không mài giũa hoàn hảo mọi chi tiết
Tôi thích phép ví von này nên định sẽ dùng về sau
Một phép ví von khác có thể là xưởng vẽ của các họa sĩ cổ điển
Rembrandt hay Rubens để học trò chuẩn bị canvas và tô một số phần, còn bậc thầy chỉ trực tiếp vẽ những phần cốt lõi
Trong khi đó, từ sau chủ nghĩa lãng mạn trở đi mới xuất hiện lý tưởng nghệ sĩ tự mình hoàn thành mọi thứ
Có lập trình viên muốn sáng tạo một mình như Turner, còn tôi muốn vẽ bức tranh lớn như Rembrandt và giao chi tiết cho AI hoặc junior
Chất lượng code phải tốt thì mới phản ứng nhanh với phản hồi từ người dùng được
Không chỉ là “code thật nhanh rồi xong”, mà điều quan trọng là cấu trúc giúp giảm chi phí thay đổi
Nếu cách tiếp cận kiểu Rembrandt dẫn đến code tốt thì không sao, nhưng hiện vẫn chưa có nhiều bằng chứng cho điều đó
Tôi cũng đã dùng Claude vài tháng và cảm thấy tự mình code vẫn hiệu quả hơn
Nhưng lần này khi nâng cấp một DB lớn từ MySQL 8 lên 9, tôi nhờ Claude tìm giúp các truy vấn có khả năng gây vấn đề, và đáng ngạc nhiên là phần lớn đều đúng
Nó không hoàn hảo, nhưng đã cắt giảm đáng kể thời gian debug
Tôi cảm thấy LLM có giá trị hơn nhiều ở vai trò chỉ ra các điểm rủi ro, hơn là trực tiếp viết code
Khi dán stack trace từ một codebase cũ vào, LLM có thể đưa ra hướng debug ban đầu
Khi sửa vấn đề hiệu năng, cũng có thể nhờ nó kiểm tra xem các đường đi trong code có cho cùng một kết quả hay không
Việc viết code hiện vẫn chỉ ở mức autocomplete, nhưng hiệu suất thì chắc chắn đã tăng lên
Tôi nhớ đến bài nói chuyện Software Faster của Dan North
Câu “phần mềm cũng như phẫu thuật, chỉ làm đúng mức tối thiểu cần thiết để giải quyết vấn đề” khiến tôi ấn tượng
Nhưng bài viết lần này lại khá xa với triết lý đó
Vì thế giờ tôi có cảm giác mình là một bác sĩ phẫu thuật thường xuyên phải cắt cụt
Có vẻ cấu trúc Chief Programmer Team đang thịnh hành trở lại
Lần này là dưới hình thức trong nhóm có thêm AI agent thay vì chỉ con người
Ý tưởng của Fred Brooks đang lại được chú ý
Nếu ghép một lập trình viên năng suất gấp 10 lần (10x-er) với một đội ngũ giỏi, có thể giảm thời gian lãng phí cho họp hành hay quản lý Jira
Đã trả lương cao thì nên dùng thời gian của họ theo cách tạo ra nhiều giá trị nhất có thể
Hiểu được phổ tự chủ, hay phổ ủy quyền, là chìa khóa để dùng tốt các công cụ lập trình AI
Các kỹ sư thường không quen với việc ủy quyền, nhưng các nhà sáng lập lại có xu hướng nắm được điều này nhanh hơn
Có ý kiến chỉ ra rằng với câu “bác sĩ phẫu thuật tập trung vào việc quan trọng”, trên thực tế mọi công việc hỗ trợ đều quan trọng như nhau
Cần khiêm tốn, tôn trọng sự hỗ trợ quanh mình, và cũng phải support họ theo cách tương xứng