Chương trình giảng dạy kỹ thuật AI mới của Stanford chuyển trọng tâm từ viết mã sang đánh giá

Mihail Eric, người giảng dạy môn The Modern Software Developer tại Stanford và dẫn dắt mảng AI tại Monaco, đã cập nhật chương trình giảng dạy của mình để giải quyết cách các kỹ sư phần mềm nên học tập trong kỷ nguyên thống trị bởi các agent lập trình. Trong một cuộc thảo luận gần đây với kênh YouTube AI Engineer, Eric đã phác họa cách các bài tập học thuật và quy trình làm việc chuyên nghiệp đang chuyển dịch từ việc viết mã sang đánh giá mã, quản lý môi trường agent và hiểu bối cảnh lịch sử trong các codebase.

Điều gì đã xảy ra

Cấu trúc của khóa học CS146S tại Stanford đã thay đổi đáng kể giữa lần tổ chức đầu tiên và thứ hai. Ban đầu, khóa học bao gồm chín bài tập và một dự án capstone, trong đó có một yêu cầu sinh viên chạy một AI reviewer trên repository và đánh giá phản hồi của nó. Tuy nhiên, Eric nhận thấy rằng sinh viên đã sử dụng rộng rãi các agent, thường hoàn thành các bài tập trước đó chỉ bằng một prompt duy nhất. Do đó, giáo trình hiện tại thay thế nhiều nhiệm vụ riêng lẻ đó bằng yêu cầu đóng góp cho các dự án mã nguồn mở, nơi các maintainer con người sẽ xem xét các patch của sinh viên.

Sự thay đổi này buộc sinh viên phải tham gia vào những thực tế xã hội và kỹ thuật của phát triển phần mềm vượt ra ngoài việc chỉ triển khai tính năng. Mặc dù một agent có thể tạo ra bản triển khai tính năng trong một buổi chiều, sinh viên vẫn phải xác định xem maintainer có muốn thay đổi đó hay không, hiểu lý do tại sao mã hiện tại hoạt động như vậy và dự đoán các lỗi tiềm ẩn. Quá trình này phản chiếu động lực học tập giữa kỹ sư junior và senior, nơi giá trị nằm ở cuộc trò chuyện và sự phê bình hơn là chỉ ở kết quả thô.

Tại Monaco, đội ngũ của Eric cũng áp dụng triết lý tương tự trong các thực hành kỹ thuật chuyên nghiệp. Họ đã đánh giá nhiều sản phẩm review code khác nhau và quyết định tiếp tục sử dụng Devin cho một số tác vụ nhất định. Tuy nhiên, họ nhận thấy rằng các workspace agent có sẵn trên thị trường không đáp ứng được nhu cầu của họ vì các agent chạy nền đòi hỏi những môi trường cụ thể để chạy sản phẩm, tái hiện lỗi và kiểm tra patch. Vì những chi tiết này phụ thuộc rất nhiều vào thiết lập đám mây đặc thù của Monaco, đội ngũ đã xây dựng hạ tầng workspace riêng, dẫn đến sự ra đời của một công cụ nội bộ tên là Hal.

Cách thức hoạt động

Hal đóng vai trò là giao diện thống nhất cho các vai trò khác nhau trong công ty, minh họa cách đầu ra của agent phải được điều chỉnh theo ý định của người dùng. Một kỹ sư có thể yêu cầu Hal điều tra một vấn đề production và tạo ra một pull request kèm bản sửa lỗi. Một nhân viên kinh doanh có thể hỏi cùng hệ thống đó về cách một tính năng sản phẩm hoạt động. Trong trường hợp đầu tiên, đầu ra là một thay đổi mã sẵn sàng để con người review; trong trường hợp thứ hai, đó là lời giải thích phù hợp cho việc giao tiếp với khách hàng. Sự khác biệt này nhấn mạnh rằng đầu ra debug thô chỉ hữu ích cho kỹ sư, trong khi các bên liên quan khác cần câu trả lời đã được tổng hợp.

Một thành phần quan trọng của quy trình làm việc này là giải quyết vấn đề "authority map" (bản đồ quyền hạn). Khi một agent đề xuất thay đổi, nó thường chỉ nhìn thấy trạng thái hiện tại của mã. Nó thiếu khả năng hiển thị về lý do tại sao những thay đổi tương tự đã bị từ chối sáu tháng trước hoặc những quyết định kiến trúc nào đã dẫn đến cách triển khai hiện tại. Để giải quyết điều này, các đội ngũ phải cung cấp cho agent quyền truy cập vào bối cảnh lịch sử, chẳng hạn như các cuộc thảo luận pull request trước đó và nhật ký quyết định. Nếu thiếu bối cảnh này, agent có thể lặp đi lặp lại đề xuất các giải pháp từng được coi là sai hoặc không mong muốn.

Eric cũng nêu bật các kỹ thuật nhằm cải thiện sự hiểu biết của con người về mã do AI tạo ra. Một phương pháp liên quan đến việc sử dụng các công cụ như kỹ năng explain-diff của Geoffrey Litt, biến đổi một thay đổi mã thành một hướng dẫn trực quan và kiểm tra nhà phát triển về các sửa đổi. Cách tiếp cận này đảm bảo rằng các kỹ sư không mù quáng merge mã do agent viết mà thay vào đó xác minh sự hiểu biết của họ về logic và các tác dụng phụ tiềm năng trước khi tích hợp.

Chi tiết chính

• Khóa học CS146S của Stanford hiện yêu cầu sinh viên đóng góp cho các dự án mã nguồn mở với sự review của maintainer con người thay vì hoàn thành các bài tập đánh giá AI riêng lẻ.
• Monaco đã xây dựng công cụ workspace agent riêng, Hal, vì các giải pháp hiện có không thể tái tạo đầy đủ môi trường đám mây đặc thù của họ để thử nghiệm và tái hiện lỗi.
• Hal tạo ra các đầu ra khác nhau dựa trên vai trò người dùng: pull request cho kỹ sư và văn bản giải thích cho nhân viên kinh doanh.
• Một nghiên cứu được trích dẫn trong cuộc thảo luận lưu ý rằng các đội ngũ có mức độ áp dụng AI cao đã merge nhiều hơn 98% pull request, nhưng thời gian review của họ tăng lên 91%.
• Các quy trình làm việc hiệu quả với agent đòi hỏi quyền truy cập vào một "authority map" bao gồm các quyết định lịch sử và lý do từ chối trước đó để ngăn chặn các đề xuất thừa hoặc sai.
• Các công cụ trực quan hóa diff và kiểm tra nhà phát triển về các thay đổi giúp giảm thiểu rủi ro merge mã do AI tạo ra mà chưa được hiểu rõ.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và lãnh đạo kỹ thuật, sự thay đổi này báo hiệu rằng sự thành thạo với các agent lập trình không còn chỉ là về prompt engineering. Nút thắt cổ chai đã chuyển từ việc viết mã sang việc review nó và cung cấp bối cảnh cần thiết để agent hoạt động đúng cách. Các đội ngũ không đầu tư vào môi trường agent tùy chỉnh hoặc cơ sở dữ liệu tri thức lịch sử có khả năng sẽ thấy tỷ lệ churn trong pull request tăng lên và chu kỳ review kéo dài hơn, khi các agent gặp khó khăn trong việc tuân thủ các mẫu kiến trúc đã được thiết lập.

Việc tăng thời gian review bất chấp tỷ lệ merge cao hơn cho thấy sự giám sát của con người vẫn cực kỳ quan trọng. Các kỹ sư phải phát triển những kỹ năng mới để kiểm toán hiệu quả các thay đổi do AI tạo ra, tập trung vào ý định, các trường hợp biên (edge cases) và tính nhất quán lịch sử. Điều này đòi hỏi một sự thay đổi văn hóa, nơi code review trở thành một quá trình điều tra sâu sắc hơn chứ không chỉ là một bước kiểm tra hời hợt, đảm bảo rằng tốc độ không làm tổn hại đến sự ổn định hoặc khả năng bảo trì của hệ thống.

Bạn có thể làm gì

• Thay thế các bài tập lập trình riêng lẻ bằng các nhiệm vụ yêu cầu đóng góp vào các dự án mã nguồn mở thực tế hoặc các codebase legacy nội bộ với quy trình review nghiêm ngặt bởi con người.
• Xây dựng hoặc cấu hình các workspace agent có khả năng tái tạo chính xác môi trường production của bạn để thử nghiệm và điều tra lỗi.
• Triển khai các công cụ trực quan hóa diff mã và kiểm tra nhà phát triển về các thay đổi để đảm bảo sự hiểu biết sâu sắc trước khi merge.
• Tạo một "authority map" bằng cách lập chỉ mục các bình luận pull request trước đó, tài liệu thiết kế và lý do từ chối để agent có thể truy cập.
• Điều chỉnh đầu ra của agent cho các vai trò cụ thể, đảm bảo kỹ sư nhận được mã có thể hành động trong khi các bên liên quan phi kỹ thuật nhận được lời giải thích rõ ràng.
• Theo dõi chặt chẽ các chỉ số pull request, đặc biệt là theo dõi thời gian review so với tỷ lệ merge để xác định nút thắt cổ chai trong các quy trình làm việc hỗ trợ bởi AI.