Giáo dục và Đánh giá Lập trình viên trong Kỷ nguyên Agent

Giáo dục và Đánh giá Lập trình viên trong Kỷ nguyên Agent

Phân tích này phản ánh bối cảnh giáo dục và chứng nhận tính đến ngày 26 tháng 7 năm 2026.

Giới thiệu

Các tác nhân lập trình tự động (autonomous coding agents) đang thay đổi quá trình phát triển phần mềm từ một công việc tập trung vào viết mã thành một công việc tập trung vào xác định công việc, giao phó nhiệm vụ, giám sát thực thi và xem xét kết quả.

Các tác nhân lập trình hiện đại có thể kiểm tra kho lưu trữ, phát triển kế hoạch triển khai, sửa đổi nhiều tệp, chạy thử nghiệm, phản hồi lỗi và mở một pull request để người đánh giá kiểm tra. Tài liệu hiện tại của GitHub mô tả các quy trình làm việc trong đó lập trình viên giao vấn đề cho tác nhân, giám sát công việc của chúng, yêu cầu đánh giá mã, cung cấp phản hồi và chấp thuận hoặc từ chối kết quả. (docs.github.com)

Điều này đặt ra một câu hỏi khó cho giáo dục:

Nếu một sinh viên có thể yêu cầu một tác nhân tạo ra một chương trình hoạt động, thì sinh viên đó cần phải hiểu gì?

Câu trả lời không phải là từ bỏ các nguyên tắc cơ bản của lập trình. Mà là thay đổi mục đích sử dụng các nguyên tắc cơ bản đó.

Sinh viên vẫn cần hiểu cấu trúc dữ liệu, thuật toán, ngôn ngữ lập trình, thiết kế hệ thống, bảo mật, kiểm thử và gỡ lỗi. Tuy nhiên, họ ngày càng cần áp dụng kiến thức đó để:

• Phân rã các vấn đề mơ hồ thành các tác vụ có thể quản lý được
• Viết các đặc tả và tiêu chí chấp nhận chính xác
• Cung cấp ngữ cảnh hữu ích cho các tác nhân lập trình
• Đánh giá xem mã được tạo có chính xác và dễ bảo trì hay không
• Thiết kế các bài kiểm thử làm lộ ra các lỗi tiềm ẩn
• Xem xét các rủi ro về bảo mật, quyền riêng tư, hiệu suất và kiến trúc
• Phối hợp nhiều tác nhân hoặc công cụ mà không mất kiểm soát
• Giải thích và bảo vệ các quyết định kỹ thuật

Thế hệ giáo dục lập trình viên tiếp theo do đó sẽ đánh giá ít hơn khả năng tạo ra lượng lớn mã của sinh viên và tập trung nhiều hơn vào khả năng hiểu, chỉ đạo, xác minh và cải thiện các hệ thống phần mềm của sinh viên.

Sự thay đổi trọng tâm: Từ sản xuất mã sang phán đoán kỹ thuật

Các tác nhân lập trình không chỉ đơn thuần là tự động hoàn thành nhanh hơn

Các công cụ hỗ trợ lập trình truyền thống gợi ý một dòng, một hàm hoặc một khối mã nhỏ. Các tác nhân lập trình tự động hoạt động ở quy mô lớn hơn. Chúng có thể làm việc trên nhiều tệp, gọi các công cụ phát triển, thực thi các bài kiểm thử, kiểm tra tài liệu và tiếp tục qua nhiều bước.

Điều đó thay đổi đơn vị công việc. Quy trình làm việc của lập trình viên ngày càng trông giống như sau:

1. Hiểu vấn đề của người dùng hoặc doanh nghiệp.
2. Xác định hành vi mong muốn.
3. Chia công việc thành các tác vụ nhỏ hơn.
4. Giao một tác vụ thích hợp cho một tác nhân.
5. Kiểm tra kế hoạch của tác nhân.
6. Để tác nhân triển khai trong một môi trường được kiểm soát.
7. Chạy các bài kiểm thử và kiểm tra bảo mật.
8. Xem xét kết quả.
9. Yêu cầu thay đổi hoặc sửa đổi thiết kế.
10. Phê duyệt, hợp nhất và giám sát phần mềm.

Người bỏ qua các giai đoạn lập kế hoạch và xem xét vẫn có thể tạo ra mã, nhưng không thể tạo ra một sản phẩm đáng tin cậy.

Giới hạn của đầu ra mã thô

Việc sản xuất mã thô đang trở thành một thước đo năng lực yếu hơn vì một tác nhân có thể nhanh chóng tạo ra một lượng lớn mã có vẻ hợp lý. Đồng thời, các tác nhân vẫn tiếp tục gặp khó khăn với sự tiến hóa phần mềm dài hạn, các thay đổi đa tệp, các yêu cầu không rõ ràng và duy trì hành vi qua các sửa đổi lặp đi lặp lại. Một nghiên cứu đánh giá năm 2025 đã tìm thấy một khoảng cách đáng kể giữa hiệu suất của tác nhân trong việc giải quyết vấn đề cô lập và các tác vụ tiến hóa phần mềm phức tạp, dài hạn hơn. (arxiv.org)

Điều này tạo ra một sự phân biệt quan trọng trong giáo dục:

• Một sinh viên có thể tạo mã có thể không hiểu nó.
• Một sinh viên có thể giải thích, kiểm thử, thách thức và sửa chữa mã thể hiện năng lực sâu sắc hơn.

Mục tiêu giáo dục do đó nên trở thành phán đoán phần mềm đã được xác thực, chứ không chỉ đơn thuần là tạo mã thành công.

Cách các chương trình giảng dạy đang thích nghi

Các chương trình giảng dạy đại học đang hướng tới sự hiểu biết và xác minh

Báo cáo Computer Science Curricula 2023 của ACM, Institute of Electrical and Electronics Engineers Computer Society và Association for the Advancement of Artificial Intelligence đã dự đoán rằng trí tuệ nhân tạo tạo sinh sẽ thay đổi giáo dục lập trình. Hướng dẫn của báo cáo cho thấy sinh viên sẽ cần tập trung nhiều hơn vào việc đọc, hiểu, xác minh, chỉnh sửa, sửa đổi, thích ứng và kiểm thử mã. Báo cáo cũng xác định phân rã vấn đề là một lĩnh vực có khả năng trở nên quan trọng hơn. (csed.acm.org)

Cùng một hướng dẫn đưa ra một điểm quan trọng: ngay cả khi một tác nhân viết chương trình, con người vẫn chịu trách nhiệm xác định xem chương trình đó có đúng hay không. Điều này có nghĩa là giáo dục lập trình không thể bị rút gọn thành việc viết lời nhắc (prompts). Sinh viên cần đủ hiểu biết kỹ thuật để đánh giá đầu ra.

Báo cáo cũng dự đoán những thay đổi trong giáo dục kỹ thuật phần mềm, bao gồm việc sử dụng trí tuệ nhân tạo nhiều hơn cho việc tạo mã, gỡ lỗi, phân tích tĩnh và đánh giá mã. Việc sử dụng hiệu quả các công cụ này đòi hỏi kỹ năng thiết kế và hiểu mã mạnh hơn, chứ không phải yếu hơn. (csed.acm.org)

Kiểm định đang bắt đầu thưởng cho các kết quả kỹ thuật rộng hơn

Các tiêu chí kiểm định điện toán hiện tại từ Accreditation Board for Engineering and Technology đã nhấn mạnh:

• Phân tích các vấn đề điện toán phức tạp
• Thiết kế và đánh giá các giải pháp điện toán
• Giao tiếp chuyên nghiệp
• Trách nhiệm pháp lý và đạo đức
• Bảo mật và quyền riêng tư
• Tác động xã hội của điện toán
• Một dự án toàn diện hoặc thành phần trải nghiệm (abet.org)

Những kết quả này rất phù hợp với môi trường phát triển dựa trên tác nhân vì chúng đo lường khả năng phán đoán và trách nhiệm hơn là số lần gõ phím.

Tính đến ngày 26 tháng 7 năm 2026, các thay đổi được đề xuất của Accreditation Board for Engineering and Technology cho chu kỳ 2026–2027 bao gồm các tiêu chí chương trình trí tuệ nhân tạo bổ sung và yêu cầu sinh viên tốt nghiệp có khả năng áp dụng các lý thuyết, mô hình và kỹ thuật trí tuệ nhân tạo vào các vấn đề phức tạp. Các thay đổi được đề xuất vẫn đang chờ được thông qua cuối cùng và dự kiến sẽ có hiệu lực sau cuộc họp mùa thu năm 2026, với lần áp dụng đầu tiên trong chu kỳ đánh giá 2027–2028. (abet.org)

Hướng đi có khả năng xảy ra là rõ ràng: các chương trình sẽ cần chứng minh rằng sinh viên có thể xây dựng và đánh giá hệ thống, chứ không chỉ đơn thuần hoàn thành các bài tập lập trình riêng lẻ.

Các khóa học mới đang giảng dạy việc sử dụng tác nhân như một ngành kỹ thuật

Một số khóa học đại học gần đây minh họa cho mô hình đang nổi lên.

Khóa học năm 2025 của Đại học Maryland về việc sử dụng hiệu quả các trợ lý và tác nhân lập trình trí tuệ nhân tạo đã đề cập đến các công cụ có thể gọi hệ thống xây dựng, chạy thử nghiệm và sửa lỗi. Khóa học cũng đề cập đến khả năng bảo trì, kiến trúc, thiết kế giao diện lập trình ứng dụng (API), hiệu quả, khả năng mở rộng, bảo mật, tích hợp liên tục, đánh giá mã, tác nhân bất đồng bộ và đánh giá mã tự động. (cs.umd.edu)

Đại học Pennsylvania đã đề xuất một khóa học khoa học máy tính cấp năm hai tập trung vào phát triển phần mềm được điều khiển bằng trí tuệ nhân tạo. Các chủ đề được đề xuất bao gồm ủy quyền các tác vụ lập trình, thiết kế mô-đun, kiểm thử có thể mở rộng, quản lý rủi ro, khả năng tái sản xuất, cộng tác và đạo đức. (seas.upenn.edu)

Khóa học mùa thu 2026 của Đại học Michigan, Kỹ thuật Phần mềm Tác nhân Ứng dụng (Applied Agentic Software Engineering), thậm chí còn rõ ràng hơn. Khóa học được tổ chức thành ba giai đoạn:

1. Sử dụng các tác nhân lập trình hiệu quả
2. Xây dựng một tác nhân bằng cách sử dụng giao diện lập trình ứng dụng (API) mô hình ngôn ngữ lớn
3. Thiết kế, đánh giá và triển khai một trình điều phối tác nhân

Khóa học sử dụng các dự án, phòng thí nghiệm, trình diễn và kiểm tra thay vì các kỳ thi truyền thống. Khóa học nêu rõ rằng việc chấm điểm sẽ thưởng cho sự hiểu biết hơn là kết quả đầu ra và yêu cầu sinh viên giải thích lý do tại sao một tác nhân thất bại và cách sửa chữa hệ thống xung quanh. (eecs498-aase.github.io)

Đây là một thay đổi thiết kế đáng kể. Khóa học không dạy sinh viên tạo mã nhanh hơn. Nó dạy họ trở thành người giám sát kỹ thuật các hệ thống tạo mã.

Các Bootcamps Đang Thay Đổi Như Thế Nào

Các bootcamp đang thích nghi nhanh hơn nhiều chương trình truyền thống vì chương trình giảng dạy của họ gắn chặt với yêu cầu việc làm. Tuy nhiên, chất lượng thích nghi khác nhau.

Mô hình bootcamp trí tuệ nhân tạo chuyên sâu

Bootcamp Phát triển Phần mềm Trí tuệ Nhân tạo hiện tại của Le Wagon kết hợp phát triển full-stack với tích hợp trí tuệ nhân tạo. Chương trình giảng dạy đã công bố của nó bao gồm lập trình có sự hỗ trợ của trí tuệ nhân tạo, tích hợp mô hình ngôn ngữ lớn, triển khai sản xuất, tạo sinh tăng cường truy xuất và các tác nhân trí tuệ nhân tạo tự trị. (lewagon.com)

Mô hình này coi trí tuệ nhân tạo như một luồng chạy xuyên suốt chương trình hơn là một bài học tùy chọn duy nhất. Sinh viên được kỳ vọng sẽ học cả hai:

• Cách thức hoạt động của các hệ thống phần mềm thông thường
• Cách sử dụng các công cụ trí tuệ nhân tạo để xây dựng và vận hành các hệ thống đó

Sự kết hợp đó rất quan trọng. Một người học chỉ biết cách vận hành một tác nhân có thể không nhận ra một kiến trúc bị lỗi. Một người học chỉ biết lập trình thông thường có thể không được chuẩn bị cho các quy trình làm việc phát triển hiện đại.

Mô hình "thêm một đơn vị trí tuệ nhân tạo"

Bootcamp kỹ thuật phần mềm của Springboard duy trì nền tảng truyền thống về phát triển web, giao diện lập trình ứng dụng (API), phát triển front-end, phát triển back-end và các dự án full-stack, đồng thời thêm một đơn vị trí tuệ nhân tạo tập trung vào kỹ thuật prompt và cộng tác với các công cụ tạo sinh. (springboard.com)

Mô hình này hữu ích cho những người học cần có nền tảng lập trình vững chắc trước tiên. Nó cũng phản ánh một thực tế: nhiều sinh viên không nên bắt đầu bằng việc xây dựng các tác nhân tự động. Họ nên học cách phần mềm hoạt động, cách sử dụng kiểm soát phiên bản, cách đọc thông báo lỗi và cách kiểm thử một chương trình trước.

Điểm yếu là một mô-đun kỹ thuật prompt ngắn có thể trở nên quá nông cạn. Một chương trình giảng dạy nghiêm túc trong kỷ nguyên tác nhân nên dạy nhiều hơn cách yêu cầu mã. Nó nên dạy:

• Cách tạo tệp ngữ cảnh kho lưu trữ
• Cách viết đặc tả kỹ thuật
• Cách xác định ranh giới tác vụ
• Cách hạn chế quyền của tác nhân
• Cách kiểm tra kế hoạch của tác nhân
• Cách đánh giá các bài kiểm thử được tạo
• Cách phát hiện các vấn đề bảo mật
• Cách so sánh các thiết kế thay thế
• Cách ghi lại sự tham gia của tác nhân

Sinh viên bootcamp nên tìm kiếm điều gì

Các sinh viên tiềm năng nên hỏi liệu một chương trình có đánh giá những điều sau đây hay không:

• Sinh viên có thể giải thích mã mà họ không tự mình gõ không?
• Sinh viên có xem xét và sửa chữa đầu ra tác nhân bị lỗi không?
• Các bài kiểm thử, bảo mật và khả năng bảo trì có được chấm điểm không?
• Có buổi trình diễn trực tiếp hoặc bảo vệ kỹ thuật không?
• Sinh viên có duy trì lịch sử dự án được kiểm soát phiên bản không?
• Sinh viên có được dạy cách làm việc mà không cần tác nhân khi cần thiết không?
• Chương trình có dạy khám phá sản phẩm và phân tích yêu cầu không?
• Các kỹ năng cụ thể về công cụ có được cân bằng với các nguyên tắc kỹ thuật bền vững không?

Một chương trình quảng cáo "xây dựng một ứng dụng trong một tuần với trí tuệ nhân tạo" có thể rất tốt cho việc tạo mẫu nhanh, nhưng điều đó không giống với việc chuẩn bị cho ai đó trở thành kỹ sư phần mềm chuyên nghiệp.

Các Chứng Chỉ Đang Thích Nghi Như Thế Nào

Các nhà cung cấp chứng chỉ đang phát triển ba loại chứng chỉ rộng lớn.

Chứng chỉ kiến thức cụ thể về công cụ

Chứng chỉ GitHub Copilot của Microsoft đánh giá việc sử dụng có trách nhiệm, các tính năng của Copilot, kiến trúc dữ liệu, tạo ngữ cảnh và prompt, năng suất của nhà phát triển, quyền riêng tư, loại trừ nội dung và các biện pháp bảo vệ. Kỳ thi được giám sát, kéo dài một trăm phút và có thể chứa các thành phần tương tác. (learn.microsoft.com)

Chứng chỉ này công nhận kiến thức hữu ích tại nơi làm việc. Nó có thể cho thấy một người hiểu cách sử dụng một nền tảng phát triển cụ thể một cách có trách nhiệm.

Hạn chế của nó là nó gắn chặt với một sản phẩm. Một chuyên gia biết cách vận hành GitHub Copilot có thể vẫn thiếu khả năng phân rã một yêu cầu sản phẩm phức tạp, thách thức một lựa chọn kiến trúc hoặc xem xét một thay đổi nhạy cảm về bảo mật.

Chứng chỉ phát triển trí tuệ nhân tạo dựa trên nền tảng

Chứng chỉ AWS Certified Generative AI Developer – Professional có phạm vi rộng hơn. Hướng dẫn kỳ thi của nó bao gồm tích hợp mô hình nền tảng, quản lý dữ liệu, tuân thủ, triển khai, giải pháp trí tuệ nhân tạo tác nhân, bảo mật, quản trị, kiểm thử, khắc phục sự cố, giám sát và tối ưu hóa. (docs.aws.amazon.com)

Tuy nhiên, kỳ thi chủ yếu là trắc nghiệm nhiều lựa chọn và nhiều câu trả lời. Đây là một bài kiểm tra kiến thức đáng kể, nhưng nó không hoàn toàn chứng minh liệu một ứng viên có thể xây dựng, xem xét hoặc bảo vệ một hệ thống hoạt động hay không. (aws.amazon.com)

Điều này minh họa một vấn đề rộng lớn hơn: các kỳ thi kiến thức dễ mở rộng hơn các kỳ thi đánh giá hiệu suất. Các tổ chức chứng nhận có thể kiểm tra thuật ngữ và nguyên tắc thiết kế một cách hiệu quả, nhưng năng lực thực tế đòi hỏi một môi trường trong đó các ứng viên phải đưa ra quyết định và đối phó với thất bại.

Chứng chỉ dựa trên phòng thí nghiệm và dự án

Chứng chỉ Kỹ năng Ứng dụng của Microsoft cung cấp một mô hình hứa hẹn hơn. Chúng yêu cầu người học hoàn thành các nhiệm vụ tương tác phù hợp với công việc thực tế trong một bài đánh giá dựa trên phòng thí nghiệm. Microsoft định vị những chứng chỉ này là bằng chứng cho thấy một ứng viên có thể giải quyết các thách thức điện toán đám mây và trí tuệ nhân tạo thực tế chứ không chỉ đơn thuần là ghi nhớ thông tin. (learn.microsoft.com)

Chương trình Trí tuệ Nhân tạo Tác nhân (Agentic Artificial Intelligence Program) giáo dục điều hành của Đại học Carnegie Mellon kết hợp giảng dạy trực tiếp, phòng thí nghiệm có hướng dẫn, bài tập, quy trình làm việc đa tác nhân, đánh giá, các rào chắn bảo vệ (guardrails), ghi nhật ký, khả năng quan sát và một dự án tốt nghiệp. (execonline.cs.cmu.edu)

Các chương trình này không giống với chứng nhận chuyên nghiệp độc lập, nhưng chúng cho thấy hướng mà các chứng chỉ có thể sẽ đi theo:

• Các đánh giá thực tế ngắn hơn
• Môi trường phát triển bị giới hạn (sandboxed)
• Kho lưu trữ thực tế
• Các tác vụ đánh giá và khả năng quan sát
• Hệ thống tốt nghiệp
• Giải thích kỹ thuật bằng miệng hoặc ghi âm
• Bằng chứng về việc sử dụng công cụ có trách nhiệm

Các Kỹ Thuật Đánh Giá Đo Lường Sự Hiểu Biết

Chiến lược đánh giá tốt nhất không cấm tác nhân trong mọi bài tập. Nó sử dụng tác nhân ở những nơi chúng phản ánh thực tiễn chuyên nghiệp và dành một số hoạt động để đo lường sự hiểu biết độc lập.

1. Tài liệu đặc tả và phân rã

Trước khi viết mã, yêu cầu sinh viên nộp:

• Vấn đề của người dùng
• Các yêu cầu chức năng
• Các yêu cầu phi chức năng
• Các giả định
• Các ràng buộc
• Cấu trúc dữ liệu
• Giao diện
• Tiêu chí chấp nhận
• Phân rã tác vụ
• Các rủi ro đã biết

Tài liệu nên giải thích lý do tại sao vấn đề đã được chia thành các tác vụ cụ thể.

Điều này đo lường liệu sinh viên có hiểu vấn đề trước khi yêu cầu tác nhân triển khai nó hay không.

2. Các điểm kiểm tra kế hoạch của tác nhân

Yêu cầu sinh viên trình bày kế hoạch đề xuất của tác nhân trước khi bắt đầu triển khai. Sinh viên phải xác định:

• Những phần nào của kế hoạch là chấp nhận được
• Những phần nào chưa hoàn chỉnh
• Những giả định nào không an toàn
• Những tác vụ nào yêu cầu sự chấp thuận của con người
• Những bài kiểm thử nào nên được thêm vào

Điểm cuối cùng nên thưởng cho chất lượng phán đoán của sinh viên, chứ không phải độ dài kế hoạch của tác nhân.

3. Đánh giá kiểm tra mã

Cung cấp cho sinh viên một kho lưu trữ do tác nhân tạo ra có chứa các lỗi cố ý. Các lỗi có thể bao gồm:

• Xử lý trường hợp biên không chính xác
• Xác thực không an toàn
• Xử lý lỗi kém
• Các vấn đề hiệu suất tiềm ẩn
• Logic trùng lặp
• Giao diện không rõ ràng
• Các bài kiểm thử không đầy đủ
• Vi phạm quyền riêng tư
• Rủi ro phụ thuộc

Yêu cầu sinh viên đưa ra một bản đánh giá với mức độ nghiêm trọng, bằng chứng, các đề xuất sửa lỗi và các bài kiểm thử hồi quy.

Điều này gần hơn với công việc phần mềm chuyên nghiệp hơn là yêu cầu sinh viên tạo một ứng dụng nhỏ khác từ đầu.

4. Giải thích lại và bảo vệ bằng miệng

Một sinh viên nên có khả năng giải thích:

• Hệ thống làm gì
• Tại sao kiến trúc đó được chọn
• Những phần nào được tạo ra
• Những giả định nào mà tác nhân đã đưa ra
• Cách các bài kiểm thử chứng minh sự đúng đắn
• Điều gì vẫn có thể thất bại
• Những đánh đổi nào đã được chấp nhận

Một buổi bảo vệ miệng ngắn có thể được thực hiện riêng lẻ hoặc theo nhóm nhỏ. Nó không cần phải đáng sợ. Năm đến mười câu hỏi tập trung thường là đủ để tiết lộ liệu một sinh viên có hiểu bài nộp hay không.

5. Các tác vụ chuyển giao

Sau khi một sinh viên hoàn thành một dự án có sự hỗ trợ của tác nhân, hãy cung cấp một yêu cầu mới không thể giải quyết bằng cách chỉ lặp lại lời nhắc ban đầu.

Ví dụ:

• Thêm một nguồn dữ liệu mới
• Thay đổi mục tiêu hiệu suất
• Hỗ trợ định dạng đầu vào không mong muốn
• Xóa một phụ thuộc
• Thêm kiểm soát truy cập
• Giải thích một bài kiểm thử thất bại
• Tái cấu trúc một mô-đun mà không thay đổi hành vi của nó

Sinh viên có thể sử dụng tác nhân, nhưng phải giải thích kế hoạch, xác minh các thay đổi và bảo vệ kết quả.

Các tác vụ chuyển giao đo lường liệu sinh viên có học được một phương pháp tổng quát hay không thay vì ghi nhớ một tương tác thành công.

6. Thiết kế kiểm thử và kiểm thử đối kháng

Sinh viên nên được chấm điểm dựa trên chất lượng các bài kiểm thử của họ, không chỉ dựa trên việc mã được tạo có vượt qua các bài kiểm thử được cung cấp hay không.

Các yêu cầu hữu ích bao gồm:

• Viết các bài kiểm thử biên
• Tạo các bài kiểm thử tiêu cực
• Kiểm thử đầu vào không hợp lệ
• Kiểm thử phục hồi lỗi
• Kiểm tra các giả định về hiệu suất
• Sử dụng các bài kiểm thử dựa trên thuộc tính khi thích hợp
• Kiểm thử hành vi nhạy cảm về bảo mật
• Giải thích những gì còn chưa được kiểm thử

Câu hỏi cốt lõi không phải là “Mã có vượt qua không?” mà là “Sinh viên có biết những gì cần được kiểm thử không?”

7. Lịch sử phiên bản và danh mục quá trình

Một danh mục dự án có thể bao gồm:

• Đặc tả ban đầu
• Phân rã tác vụ
• Kế hoạch của tác nhân
• Các lời nhắc hoặc hướng dẫn chính
• Các commit
• Kết quả kiểm thử
• Bình luận đánh giá
• Các cách tiếp cận thất bại
• Thay đổi thiết kế
• Phản ánh cuối cùng

Một danh mục quá trình không nên trở thành yêu cầu phải nộp mọi dòng hội thoại riêng tư. Một hồ sơ đại diện thường hữu ích hơn một bản ghi chép khổng lồ.

Ví dụ, khóa học lập trình năm 2025 của Princeton cho phép sử dụng các công cụ trí tuệ nhân tạo tạo sinh nhưng yêu cầu sinh viên mô tả việc sử dụng chúng trong một tệp readme thông qua một bản tóm tắt đại diện thay vì một bản ghi chép đầy đủ. (cs.princeton.edu)

8. Đánh giá ngang hàng có cấu trúc

Đánh giá ngang hàng biến sinh viên từ những người chỉ tạo mã thành những người phê bình mã. Nghiên cứu ban đầu cho thấy đánh giá ngang hàng dựa trên tiêu chí có thể xấp xỉ đánh giá của giảng viên với độ chính xác vừa phải đồng thời phát triển tư duy đánh giá và sự tham gia. (arxiv.org)

Sinh viên nên được yêu cầu biện minh cho nhận xét của mình bằng bằng chứng. "Mã này tệ" không phải là một đánh giá. "Hàm này thực hiện một truy vấn cơ sở dữ liệu bên trong một vòng lặp, tạo ra một vấn đề hiệu suất có khả năng xảy ra khi tập hợp dữ liệu lớn lên" là một đánh giá.

9. Các vấn đề về prompt và đặc tả

Các bài toán Prompt (Prompt Problems) là các bài tập lập trình trong đó sinh viên viết các hướng dẫn bằng ngôn ngữ tự nhiên để khiến một hệ thống trí tuệ nhân tạo tạo ra mã đáp ứng một đặc tả. Phương pháp này dạy rõ ràng sinh viên cách truyền đạt các yêu cầu tính toán cho các hệ thống tạo mã. (arxiv.org)

Điều này có thể hữu ích, nhưng nó không nên là phương pháp đánh giá duy nhất. Một nghiên cứu năm 2026 liên quan đến hơn chín trăm sinh viên đã phát hiện ra rằng các lỗi phổ biến bao gồm việc bỏ sót các chi tiết quan trọng từ các prompt. Khi mã được tạo thất bại, sinh viên thường tập trung vào việc làm rõ ý định của họ hơn là theo dõi mã hoặc kiểm tra các trường hợp kiểm thử. (arxiv.org)

Do đó, việc nhắc lệnh có thể tiết lộ kỹ năng phân rã và giao tiếp, nhưng nó phải được kết hợp với việc đọc mã, kiểm thử, gỡ lỗi và xem xét.

Một cấu trúc đánh giá mẫu

Một dự án thực tế có thể sử dụng trọng số sau:

Cấu trúc này vẫn thưởng cho một sản phẩm hoạt động, nhưng nó ngăn cản sinh viên nhận được điểm cao chỉ vì một tác nhân đã tạo ra một codebase lớn.

Liêm Chính Học Thuật trong Các Bài Tập Có Sự Hỗ Trợ của Tác Nhân

Cấm hoàn toàn và sử dụng không hạn chế đều không phù hợp

Việc cấm hoàn toàn có thể phù hợp cho một đánh giá nền tảng cụ thể, đặc biệt khi mục tiêu học tập là thực hành lập trình độc lập. Tuy nhiên, một lệnh cấm phổ quát ngày càng khó thực thi và có thể ngăn cản sinh viên học các công cụ mà họ sẽ gặp trong công việc chuyên nghiệp.

Việc sử dụng không hạn chế cũng không phù hợp. Nếu sinh viên có thể nộp bài tập do tác nhân tạo ra mà không giải thích, việc đánh giá có thể đo lường quyền truy cập vào một công cụ hơn là việc học.

Cách tiếp cận mạnh mẽ nhất là chính sách rõ ràng, cấp độ bài tập.

Ba chế độ chính sách hữu ích

Chế độ một: Cấm tác nhân

Sử dụng chế độ này cho:

• Các kỳ thi
• Các bài luyện tập lập trình nền tảng
• Các buổi trình diễn gỡ lỗi cá nhân
• Các bài tập thuật toán cốt lõi
• Các đánh giá được thiết kế để đo lường khả năng nhớ hoặc triển khai không hỗ trợ

Khóa học Nguyên tắc Tính toán Mệnh lệnh (Principles of Imperative Computation) của Carnegie Mellon cấm các công cụ trí tuệ nhân tạo cho bất kỳ phần nào của công việc được chấm điểm, bao gồm tạo giải pháp, giải thích giải pháp, định dạng mã và tạo trường hợp kiểm thử. (cs.cmu.edu)

Chế độ hai: Hạn chế tác nhân

Sử dụng chế độ này khi sinh viên có thể yêu cầu:

• Giải thích khái niệm
• Hỗ trợ tài liệu
• Giải thích thông báo lỗi
• Làm rõ thư viện hoặc giao diện lập trình ứng dụng
• Động não
• Phê bình một thiết kế do sinh viên tạo ra
• Tái cấu trúc nhỏ

Các khóa học hệ thống của Carnegie Mellon cho phép các công cụ trí tuệ nhân tạo để hiểu giao diện lập trình ứng dụng, thư viện, framework, mã được cung cấp và thông báo lỗi, đồng thời cấm các yêu cầu giải pháp bài tập một phần hoặc hoàn chỉnh. (cs.cmu.edu)

Chế độ ba: Cho phép tác nhân kèm theo khai báo

Sử dụng chế độ này cho các dự án kỹ thuật phần mềm thực tế. Yêu cầu sinh viên khai báo:

• Những công cụ nào đã được sử dụng
• Những tác vụ nào đã được ủy quyền
• Mã được tạo có được sao chép, sửa đổi hay viết lại không
• Đầu ra được kiểm thử như thế nào
• Sinh viên đã học được gì
• Những phần nào của thiết kế vẫn thuộc trách nhiệm của sinh viên

Hướng dẫn liêm chính học thuật của Princeton nêu rõ rằng việc sử dụng trí tuệ nhân tạo được phép vẫn phải được khai báo và việc trình bày đầu ra được tạo ra như của riêng mình hoặc không khai báo việc sử dụng nó có thể cấu thành một vi phạm liêm chính. (scholarlyintegrity.princeton.edu)

Trường Giáo dục Sau đại học Harvard cũng cho phép các mục đích sử dụng như làm rõ, động não và khám phá, đồng thời cấm sinh viên nộp bài tập được tạo bằng trí tuệ nhân tạo như của riêng mình. Trường cũng yêu cầu tài liệu về việc sử dụng được phép và cảnh báo rằng sinh viên vẫn chịu trách nhiệm về độ chính xác, quyền riêng tư, bản quyền và thành kiến. (registrar.gse.harvard.edu)

Một tuyên bố công bố thực tế

Một khóa học có thể cung cấp một mẫu đơn giản:

Tôi đã sử dụng [tên công cụ] để [lập kế hoạch, gỡ lỗi, tạo mã, kiểm thử, tài liệu hoặc đánh giá]. Tôi đã ủy quyền [các tác vụ cụ thể]. Tôi đã xem xét và sửa đổi đầu ra, kiểm thử hệ thống kết quả, và vẫn chịu trách nhiệm về độ chính xác, bảo mật và tính nguyên bản của bài nộp.

Sinh viên không nên được yêu cầu công bố việc sửa lỗi chính tả thông thường giống như việc triển khai được ủy quyền. Các chính sách nên phân biệt giữa hỗ trợ nhỏ và đóng góp nhận thức hoặc kỹ thuật đáng kể.

Quyền riêng tư và tiếp cận công bằng

Các tổ chức nên cung cấp các công cụ đã được phê duyệt hoặc các lựa chọn thay thế. Sinh viên không nên bị yêu cầu tải lên các bài tập bí mật, thông tin cá nhân, nghiên cứu chưa được công bố hoặc mã độc quyền lên các hệ thống công cộng.

Hướng dẫn của UNESCO kêu gọi một cách tiếp cận lấy con người làm trung tâm nhằm giải quyết quyền riêng tư, an toàn, công bằng, hòa nhập và sự chuẩn bị của tổ chức. (unesco.org)

Các khóa học cũng nên xem xét những sinh viên không thể chi trả nhiều công cụ trả phí. Một khóa học công bằng có thể:

• Cung cấp một công cụ chung của tổ chức
• Cung cấp một giải pháp thay thế cục bộ hoặc mã nguồn mở
• Thiết kế các bài tập không phụ thuộc vào một nhà cung cấp duy nhất
• Chấm điểm khả năng lập luận hơn là quyền truy cập vào mô hình mạnh nhất
• Cho phép các con đường không có tác nhân cho mọi kết quả học tập thiết yếu

Các Phương Pháp Thực Tế để Kết Hợp Tác Nhân một cách Hiệu Quả

Sử dụng kho lưu trữ được kiểm soát

Cung cấp cho sinh viên một kho lưu trữ chứa:

• Một tệp readme rõ ràng
• Một codebase nhỏ nhưng thực tế
• Các bài kiểm thử tự động
• Một quy trình tích hợp liên tục
• Một danh sách các vấn đề đã biết
• Một hướng dẫn về phong cách
• Một danh sách kiểm tra bảo mật
• Một nhật ký thay đổi

Điều này làm cho việc sử dụng tác nhân có thể quan sát được và cung cấp cho sinh viên một cái gì đó thực tế hơn một bài tập lập trình trống rỗng.

Yêu cầu kế hoạch trước khi triển khai

Sinh viên không nên bắt đầu bằng việc yêu cầu một tác nhân "xây dựng toàn bộ ứng dụng." Yêu cầu một trình tự:

1. Yêu cầu tác nhân kiểm tra kho lưu trữ.
2. Yêu cầu một bản tóm tắt kiến trúc.
3. Hỏi về rủi ro và thông tin còn thiếu.
4. Viết kế hoạch tác vụ của sinh viên.
5. Phê duyệt một tác vụ triển khai nhỏ.
6. Xem xét các thay đổi kết quả.
7. Chạy kiểm thử trước khi tiếp tục.

Điều này dạy ủy quyền có kiểm soát thay vì ủy quyền mù quáng.

Sử dụng một nhóm tác nhân với vai trò rõ ràng

Một mô hình điều phối đơn giản có thể bao gồm:

• Người lập kế hoạch: đề xuất phân rã tác vụ
• Người triển khai: sửa đổi mã
• Người kiểm thử: tạo và chạy các bài kiểm thử
• Người đánh giá: tìm kiếm các lỗi và rủi ro
• Người đánh giá là con người: chấp thuận hoặc từ chối các thay đổi

Sinh viên nên học rằng việc thêm nhiều tác nhân không tự động cải thiện chất lượng. Nhiều tác nhân có thể tạo ra các hướng dẫn mâu thuẫn, công việc trùng lặp, tăng chi phí và trách nhiệm không rõ ràng.

Mục tiêu giáo dục không phải là xây dựng hệ thống đa tác nhân lớn nhất. Mà là chọn quy trình làm việc đơn giản nhất tạo ra kết quả đáng tin cậy.

Xây dựng các cổng chấp thuận của con người

Yêu cầu sự chấp thuận rõ ràng trước khi một tác nhân có thể:

• Thay đổi xác thực
• Sửa đổi lược đồ dữ liệu
• Thêm các phụ thuộc
• Truy cập hệ thống sản xuất
• Thay đổi cấu hình triển khai
• Xóa tệp
• Hợp nhất một pull request

Điều này dạy sinh viên rằng quyền tự chủ phải được giới hạn bởi các quyền và sự xem xét.

Chấm điểm các thất bại một cách có chủ đích

Các tác nhân mang tính giáo dục nhất khi chúng thất bại theo những cách cung cấp thông tin. Các giảng viên nên bao gồm:

• Các yêu cầu mơ hồ
• Các ràng buộc mâu thuẫn
• Các bài kiểm thử không đầy đủ
• Các hoạt động nhạy cảm về bảo mật
• Tài liệu gây hiểu lầm
• Các bài kiểm thử không ổn định (flaky tests)
• Giới hạn hiệu suất
• Một thay đổi có vẻ đúng nhưng làm hỏng một tính năng khác

Nhiệm vụ của sinh viên là chẩn đoán lỗi và cải thiện quy trình.

Khung Năng Lực cho Giai đoạn 2026 đến 2031

Khung này được thiết kế để vẫn hữu ích ngay cả khi các công cụ cụ thể thay đổi.

Lĩnh vực một: Nền tảng kỹ thuật và hiểu biết về mã

Một lập trình viên có năng lực có thể:

• Đọc mã không quen thuộc
• Giải thích luồng điều khiển và luồng dữ liệu
• Hiểu các giao diện và phụ thuộc
• Phân tích độ phức tạp thuật toán
• Sử dụng kiểm soát phiên bản
• Gỡ lỗi mà không phụ thuộc hoàn toàn vào tác nhân

Bằng chứng: giải thích mã, tác vụ gỡ lỗi thủ công, phê bình thiết kế và bài tập chuyển giao cá nhân.

Lĩnh vực hai: Xác định vấn đề và phân rã

Một lập trình viên có năng lực có thể:

• Làm rõ mục tiêu người dùng
• Xác định các ràng buộc và giả định
• Tách các yêu cầu thiết yếu khỏi các yêu cầu tùy chọn
• Chia công việc thành các tác vụ có thể kiểm thử độc lập
• Định nghĩa tiêu chí chấp nhận
• Nhận biết khi một tác vụ quá rộng để ủy quyền đáng tin cậy

Bằng chứng: đặc tả, biểu đồ tác vụ, sổ đăng ký rủi ro và giải thích các lựa chọn phân rã.

Lĩnh vực ba: Chỉ đạo tác nhân và kỹ thuật ngữ cảnh

Một lập trình viên có năng lực có thể:

• Cung cấp ngữ cảnh kho lưu trữ liên quan
• Đưa ra hướng dẫn chính xác
• Định nghĩa ranh giới và quyền hạn
• Chọn khi nào nên sử dụng tác nhân và khi nào không nên sử dụng
• So sánh các kế hoạch thay thế
• Khắc phục khi tác nhân đi theo diễn giải sai

Bằng chứng: các điểm kiểm tra kế hoạch, hồ sơ tương tác đại diện và một tác vụ sửa đổi trực tiếp.

Lĩnh vực bốn: Xác minh và đánh giá

Một lập trình viên có năng lực có thể:

• Kiểm tra mã được tạo
• Thiết kế các bài kiểm thử có ý nghĩa
• Xác định các giả định tiềm ẩn
• Xem xét rủi ro bảo mật và quyền riêng tư
• Đánh giá khả năng bảo trì
• Giải thích những gì các bài kiểm thử không chứng minh

Bằng chứng: đánh giá mã, kiểm thử đối kháng, bài tập tìm lỗi và bảo vệ bằng miệng.

Lĩnh vực năm: Điều phối và vận hành

Một lập trình viên có năng lực có thể:

• Phối hợp các công cụ lập kế hoạch, triển khai, kiểm thử và đánh giá
• Sử dụng các điểm kiểm tra và cổng chấp thuận của con người
• Theo dõi chi phí, thời gian và hành vi công cụ
• Duy trì các quy trình làm việc có thể tái sản xuất
• Quan sát các thất bại và cải thiện hệ thống
• Quyết định liệu nhiều tác nhân có tăng thêm giá trị hay không

Bằng chứng: quy trình điều phối hoạt động, nhật ký, báo cáo đánh giá và phân tích chi phí hoặc hiệu suất.

Lĩnh vực sáu: Thiết kế sản phẩm và hệ thống

Một lập trình viên có năng lực có thể:

• Chọn mức độ tự động hóa phù hợp
• Thiết kế các hệ thống mô-đã
• Cân bằng tốc độ, chất lượng, chi phí và rủi ro
• Kết nối các quyết định kỹ thuật với kết quả người dùng
• Nhận biết khi nào một giải pháp đơn giản không dùng tác nhân là tốt hơn

Bằng chứng: bản tóm tắt sản phẩm, hồ sơ quyết định kiến trúc, nguyên mẫu và trình diễn lấy người dùng làm trung tâm.

Lĩnh vực bảy: Thực hành chuyên nghiệp có trách nhiệm

Một lập trình viên có năng lực có thể:

• Công bố sự hỗ trợ của trí tuệ nhân tạo
• Bảo vệ thông tin riêng tư và độc quyền
• Tôn trọng bản quyền và nghĩa vụ cấp phép
• Xác định rủi ro thành kiến và độ tin cậy
• Truyền đạt sự không chắc chắn
• Chấp nhận trách nhiệm đối với hệ thống cuối cùng

Bằng chứng: tuyên bố công bố, đánh giá rủi ro, xem xét quyền riêng tư và trình bày chuyên nghiệp.

Các cấp độ thành thạo được đề xuất

Đến năm 2031, một chứng chỉ chuyên nghiệp nên thể hiện sự tiến bộ qua các cấp độ này thay vì chỉ đơn thuần xác nhận sự quen thuộc với một công cụ phần mềm cụ thể.

Khuyến Nghị Dành cho Các Bên Liên Quan Khác Nhau

Các trường Đại học

• Thêm các mô-đun kỹ thuật phần mềm có nhận thức về tác nhân vào các khóa học hiện có.
• Giữ vững các nguyên tắc lập trình và thuật toán cơ bản.
• Thay thế một số bài tập tạo mã bằng các tác vụ đánh giá và chuyển giao.
• Yêu cầu sinh viên giải thích và bảo vệ công việc quan trọng.
• Đào tạo giảng viên về các công cụ tác nhân, thiết kế đánh giá, quyền riêng tư và chính sách liêm chính.
• Xây dựng các kho lưu trữ dùng chung và môi trường thử nghiệm (sandbox).

Các Bootcamp

• Dạy phát triển thông thường và phát triển có sự hỗ trợ của tác nhân cùng nhau.
• Đưa kiểm thử, kiến trúc và bảo mật trở thành các phần trung tâm của chương trình giảng dạy.
• Yêu cầu các dự án danh mục đầu tư với hồ sơ quá trình.
• Thêm các buổi trình diễn kỹ thuật trực tiếp.
• Dạy khám phá sản phẩm và viết yêu cầu.
• Tránh hứa hẹn rằng chỉ cần nhắc lệnh (prompting) có thể tạo ra các kỹ sư sẵn sàng làm việc.

Các nhà cung cấp chứng chỉ

• Tăng cường sử dụng các đánh giá dựa trên phòng thí nghiệm.
• Bao gồm đánh giá mã, kiểm thử, gỡ lỗi và phân tích mối đe dọa.
• Sử dụng các kho lưu trữ thực tế thay vì các câu hỏi trắc nghiệm riêng lẻ.
• Kiểm tra khả năng phán đoán độc lập với công cụ.
• Thêm các giải thích miệng ngắn hoặc các buổi trình diễn được ghi lại.
• Làm mới nội dung thường xuyên mà không làm cho chứng chỉ phụ thuộc vào giao diện của một nhà cung cấp duy nhất.

Các Giảng viên

• Nêu rõ chính xác những gì được phép cho mỗi đánh giá.
• Thiết kế các bài tập xoay quanh kết quả học tập mong muốn.
• Cung cấp cho sinh viên các công cụ đã được phê duyệt hoặc các lựa chọn thay thế tương đương.
• Đánh giá quá trình, lập luận và xác minh.
• Sử dụng nhật ký làm bằng chứng, không phải là bằng chứng duy nhất.
• Tránh phụ thuộc vào phần mềm phát hiện trí tuệ nhân tạo làm cơ chế chính để đảm bảo liêm chính.

Người học và người tạo sản phẩm

• Học đủ lập trình thông thường để đọc và thách thức mã được tạo.
• Bắt đầu với một sản phẩm nhỏ thay vì một ứng dụng lớn, mơ hồ.
• Viết đặc tả trước khi mở một tác nhân.
• Ủy quyền từng vấn đề một.
• Xem xét mọi thay đổi và kiểm thử mọi giả định.
• Giữ một bản ghi các quyết định quan trọng.
• Coi tác nhân là một cộng tác viên cấp dưới nhanh nhẹn, chứ không phải là một chuyên gia không thể nghi ngờ.

Bước Tiếp Theo Đầu Tiên

Đối với một người bắt đầu hành trình tạo sản phẩm, bước đầu tiên hữu ích nhất là:

Chọn một vấn đề nhỏ của người dùng và viết một đặc tả một trang trước khi yêu cầu tác nhân viết mã.

Bao gồm:

• Người dùng là ai
• Vấn đề họ đang gặp phải
• Phiên bản đầu tiên phải làm gì
• Những gì nó không được làm
• Ba bài kiểm thử chấp nhận
• Một mối quan ngại quan trọng về bảo mật hoặc quyền riêng tư
• Ba tác vụ triển khai nhỏ

Sau đó, yêu cầu tác nhân xem xét đặc tả và xác định các yêu cầu còn thiếu, chứ không phải xây dựng toàn bộ sản phẩm.

Sau khi sửa đặc tả, chỉ ủy quyền tác vụ đầu tiên. Xem xét kế hoạch đề xuất, kiểm tra các thay đổi, chạy các bài kiểm thử và ghi lại những gì tác nhân đã làm sai.

Bài tập đơn lẻ đó dạy bài học quan trọng nhất của kỷ nguyên tác nhân: chất lượng của kết quả ít phụ thuộc vào lượng mã tác nhân có thể tạo ra mà phụ thuộc vào cách con người định nghĩa, giám sát và đánh giá công việc rõ ràng đến mức nào.

Kết luận

Giáo dục lập trình viên đang chuyển dịch sang một sự cân bằng mới.

Sinh viên vẫn sẽ cần viết mã, đặc biệt là khi học các khái niệm nền tảng. Nhưng năng lực chuyên môn sẽ ngày càng được thể hiện thông qua phân rã vấn đề, đặc tả, hiểu mã, đánh giá, kiểm thử, điều phối, phán đoán sản phẩm và sử dụng có trách nhiệm các hệ thống tự trị.

Các chương trình giảng dạy mạnh mẽ nhất sẽ không coi các tác nhân lập trình như máy gian lận hay gia sư thần kỳ. Chúng sẽ coi chúng như những công cụ kỹ thuật mạnh mẽ nhưng có thể mắc lỗi. Sinh viên sẽ học cách sử dụng chúng, cách hạn chế chúng, cách đánh giá đầu ra của chúng và cách chịu trách nhiệm về hệ thống cuối cùng.

Lập trình viên bền vững nhất trong năm năm tới sẽ không phải là người có thể tạo ra nhiều mã nhất bằng tay hoặc tạo ra lời nhắc dài nhất. Đó sẽ là người có thể biến một mục tiêu không rõ ràng thành một quy trình đáng tin cậy, hướng dẫn nhiều công cụ đạt được mục tiêu đó, phát hiện lỗi sớm và giải thích tại sao phần mềm tạo ra xứng đáng được tin cậy.