Ưu tiên Nghiên cứu trong 18 Tháng Tới: Hướng Đi Tiếp Theo của Mã hóa Tự động

Ưu tiên Nghiên cứu: 18 Tháng Tới của Mã hóa Tự động

Các trợ lý mã hóa được hỗ trợ bởi AI đang thay đổi cách phát triển phần mềm. Đến cuối năm 2025, các công cụ như GitHub Copilot và chatbot AI được hầu hết các nhà phát triển sử dụng hàng ngày, và ngay cả những người không chuyên về lập trình cũng có thể tạo mã nguyên mẫu với các câu lệnh đơn giản. CEO của Google lưu ý rằng xu hướng này – thường được gọi là “vibe coding” – đang làm cho việc lập trình dễ tiếp cận hơn đối với nhân viên không chuyên về kỹ thuật (www.itpro.com). Tuy nhiên, việc triển khai trong thực tế đã bộc lộ những lỗ hổng quan trọng. Mã do AI tạo ra thường chứa các lỗi tinh vi, không hoạt động trên các dự án phức tạp, và đặt ra các vấn đề về trách nhiệm giải trình và chính sách. Để chuyển từ các bản demo trong phòng thí nghiệm sang các hệ thống sản xuất đáng tin cậy, chúng ta cần nghiên cứu tập trung vào bốn lĩnh vực: độ tin cậy, lập kế hoạch dài hạn, khả năng kiểm chứng và quản trị kỹ thuật xã hội. Dưới đây, chúng tôi phác thảo các vấn đề mở chính và đề xuất các chương trình nghiên cứu, tiêu chuẩn đánh giá, và hợp tác để giải quyết chúng.

1. Độ tin cậy và Chất lượng Mã

Một vấn đề lớn là độ tin cậy cơ bản: mã do trợ lý AI viết vẫn chứa nhiều lỗi hơn đáng kể so với mã do con người viết. Ví dụ, một phân tích 470 yêu cầu kéo (pull request) trên GitHub cho thấy các PR do AI viết có khoảng gấp 1,7 lần số vấn đề so với các PR do con người viết (www.itpro.com). Trung bình các PR của AI gây ra ~10,8 vấn đề (lỗi logic, vấn đề đặt tên hoặc định dạng, lỗ hổng bảo mật, v.v.) so với ~6,5 đối với các PR của con người (www.itpro.com). Đáng chú ý, mã do AI tạo ra có “đuôi” các lỗi nghiêm trọng nặng hơn (lỗi logic và lỗ hổng bảo mật xuất hiện gần gấp đôi so với mã do con người viết) (www.itpro.com). Trong thực tế, các nhóm sử dụng công cụ AI đã báo cáo những điều bất ngờ: mã trông có vẻ đúng khi đứng riêng lẻ nhưng lại thất bại khi tích hợp hoặc chứa các lỗi tiềm ẩn. Thật vậy, một khảo sát toàn diện về các công cụ tạo mã nhận thấy rằng các tiêu chuẩn đánh giá hiện có không nắm bắt được các loại chế độ lỗi được thấy trong sản xuất – các lời gọi API ảo giác, đặt tên không nhất quán, hoặc các lỗi logic tinh vi lọt qua các kiểm thử đơn vị (doi.org). Tóm lại, AI có thể tạo ra các đoạn mã hoạt động, nhưng những đoạn mã đó thường chưa sẵn sàng để đưa vào sản xuất (doi.org).

Kinh nghiệm của nhà phát triển cũng phản ánh sự thiếu tin tưởng này. Một khảo sát lớn của SonarSource (được báo chí ngành đưa tin) cho thấy trong khi 72% kỹ sư sử dụng công cụ AI hàng ngày để viết tới 42% mã, thì một con số đáng kinh ngạc là 96% thừa nhận họ không hoàn toàn tin tưởng vào đầu ra của AI (www.itpro.com). Tuy nhiên, chưa đến một nửa số nhóm luôn xem xét mã do AI tạo ra trước khi cam kết (www.itpro.com). Khoảng cách này – sử dụng nhiều nhưng tin tưởng thấp – dẫn đến cái mà các chuyên gia gọi là “nợ kiểm chứng.” Nếu không có độ tin cậy tốt hơn, các tổ chức sẽ có nguy cơ đưa vào các lỗi khó bắt và nợ kỹ thuật mỗi khi họ áp dụng các lối tắt mã hóa bằng AI (www.itpro.com).

Chương trình Nghiên cứu: Chúng ta cần nghiên cứu hệ thống các mô hình lỗi trong mã AI và các phương pháp mới để giảm thiểu chúng. Các ý tưởng bao gồm chống AI tự động: tích hợp các trình phân tích tĩnh hoặc các mô hình thứ cấp quét đầu ra của AI để tìm kiếm các lỗi phổ biến (tương tự như một người đánh giá thứ hai). Các mục tiêu huấn luyện LLM tốt hơn có thể tập trung vào sự ổn định – ví dụ, huấn luyện trên các ví dụ mã có lỗi và mã sạch để dạy mô hình ưu tiên các giải pháp an toàn hơn. Các nhà nghiên cứu nên phân tích các loại mã nào (thuật toán, I/O, quan trọng về bảo mật) làm hỏng các heuristic nội bộ của AI, và phát triển các biện pháp phòng thủ chuyên biệt. Chẳng hạn, các nghiên cứu ban đầu đã chỉ ra rằng các công cụ AI lạm dụng các lối tắt rủi ro (mật khẩu được mã hóa cứng, vòng lặp không hiệu quả, v.v.) (www.businesswire.com) (www.infoworld.com). Chúng ta phải hệ thống hóa các chế độ lỗi này.

Các giải pháp giáo dục cũng có thể giúp ích: như hướng dẫn cộng đồng nhấn mạnh, công cụ AI chỉ có thể hỗ trợ – con người phải kiểm chứng (firefox-source-docs.mozilla.org) (chromium.googlesource.com). Để khuyến khích điều này, các công cụ tương lai có thể tự động tạo cảnh báo hoặc thậm chí từ chối xử lý các tác vụ mà không có sự chấp thuận của con người. Việc thiết lập tiêu chuẩn đánh giá nên thay đổi: vượt ra ngoài “mã này có biên dịch không” để đến “còn bao nhiêu vấn đề tinh vi còn lại.” Ví dụ, các mô hình AI đánh giá mã đang nổi lên để đo lường cụ thể hiệu suất phát hiện lỗi (docs.factory.ai). Một nỗ lực cộng đồng để tạo ra một bộ dữ liệu công khai về các thay đổi mã thực tế giữa AI và con người (với các lỗi được chú thích) – tương tự như nghiên cứu PR của CodeRabbit – sẽ cho phép các nhà nghiên cứu theo dõi tiến bộ về độ tin cậy.

2. Lập kế hoạch dài hạn và Bảo trì

Các công cụ tạo mã AI xuất sắc trong các tác vụ nhỏ, độc lập, nhưng các dự án lớn lại bộc lộ giới hạn của chúng. Phần mềm thực tế phát triển theo thời gian, với các yêu cầu thay đổi, nhiều tệp và các quyết định kiến trúc cần quản lý. Các khảo sát lưu ý rằng “việc tạo ra các hàm riêng lẻ chính xác khác biệt về mặt định tính so với việc duy trì các quyết định kiến trúc nhất quán trên một codebase lớn” (doi.org). Trong thực tế, ngay cả các mô hình tiên tiến nhất cũng gặp khó khăn với các tác vụ đa bước, đa tệp. Hai tiêu chuẩn đánh giá gần đây làm nổi bật khoảng cách này:

• RoadmapBench (Tháng 5 năm 2026) đánh giá các nâng cấp “dài hạn” trên các dự án mã nguồn mở thực tế. Mỗi tác vụ cung cấp cho tác nhân một phiên bản cơ sở của dự án và danh sách các tính năng cần triển khai, với khoảng 3.700 dòng được thay đổi trên hơn 50 tệp. Ngay cả Claude-Opus-4.7, một trong những mô hình mạnh nhất, chỉ giải quyết được ~39% tác vụ, và các mô hình khác xuống thấp tới 5% (papers.cool). Ngược lại, việc sửa lỗi một lần đơn giản cho thấy hiệu suất AI gần như hoàn hảo. Các tác giả của RoadmapBench kết luận rằng “phát triển phần mềm dài hạn vẫn là một vấn đề chưa được giải quyết phần lớn.” (papers.cool)

• SlopCodeBench (2026) kiểm tra việc phát triển lặp lại. Các tác nhân được giao một nhiệm vụ và tạo mã, sau đó qua 20 vòng, đặc tả nhiệm vụ thay đổi, buộc mã phải phát triển. Kết quả: mặc dù tất cả các phiên bản trung gian đều vượt qua các kiểm thử hiện có, nhưng các codebase do AI tạo ra trở nên dài dòng gấp 2,2 lần và khó bảo trì hơn nhiều so với mã được con người bảo trì (www.techradar.com). Trên thực tế, không có mô hình hàng đầu nào giải quyết được toàn bộ chuỗi: tỷ lệ thành công giảm xuống ~0,5% ở điểm kiểm tra cuối cùng. Điều này cho thấy các lỗi thiết kế nhỏ tích lũy dưới sự hỗ trợ của AI, cản trở các sửa đổi trong tương lai (www.techradar.com).

Những phát hiện này gợi ý nghiên cứu tập trung vào lập kế hoạch và phân tách. Các hệ thống AI không chỉ nên “viết mã” theo câu lệnh, mà còn phải lên kế hoạch các chiến lược đa bước. Một ý tưởng mới nổi là lập kế hoạch và thực thi: hãy để mô hình phác thảo thiết kế hoặc chuỗi các bước trước, sau đó tạo mã cho từng bước (crabtalk.ai). Trên thực tế, các phân tích về các tác nhân mã hóa (Claude Code, GitHub Copilot, v.v.) cho thấy việc tách biệt lập kế hoạch khỏi thực thi (và hiển thị kế hoạch cho người dùng) cải thiện đáng kể hiệu suất trên các tác vụ phức tạp (crabtalk.ai). Nghiên cứu nên phát triển các kiến trúc mới: ví dụ, các tác nhân lồng ghép nơi một LLM “quản lý” chia một vấn đề lớn thành các nhiệm vụ con cho các LLM “thợ”. Cơ chế bộ nhớ dài hạn cũng cần thiết: các mô hình tương lai nên nhớ mã được tạo ra trước đó trong một phiên làm việc ngay cả khi vượt quá cửa sổ ngữ cảnh.

Tiêu chuẩn đánh giá: Cộng đồng nên xác định các tiêu chuẩn đánh giá phản ánh công việc phát triển thực tế. Vượt ra ngoài RoadmapBench, chúng ta cần các tác vụ trải rộng nhiều ngôn ngữ và thách thức tích hợp (frontend/backend, cơ sở dữ liệu, v.v.). Các dự án nhóm mô phỏng sẽ kiểm tra cách AI và con người hợp tác qua các bản phát hành. Mượn ý tưởng từ kỹ thuật phần mềm, các tiêu chuẩn đánh giá có thể đo lường không chỉ tính đúng đắn mà còn khả năng bảo trì (dễ dàng thêm một tính năng mới đến mức nào?), hiệu suất (mã AI có bị suy giảm khi phát triển không?), và tích hợp (nó có phù hợp với các quy ước phong cách hiện có không?). Ví dụ, các tiêu chuẩn đánh giá có thể bắt đầu với một codebase hiện có và yêu cầu tác nhân triển khai một loạt yêu cầu tính năng hoặc tái cấu trúc, với các kiểm thử định kỳ. Trong 18 tháng tới, việc tạo ra các thách thức mở như vậy (có thể thông qua các cuộc thi học thuật-công nghiệp) sẽ định hướng nghiên cứu về mã hóa đa giai đoạn.

3. Khả năng kiểm chứng và Giao diện hình thức

Khi các trợ lý AI đảm nhận nhiều tác vụ quan trọng hơn, việc đảm bảo tính đúng đắn trở nên thiết yếu. Khả năng kiểm chứng có nghĩa là liên kết mã với các đặc tả chính xác hoặc bộ kiểm thử để chúng ta có thể tự tin rằng nó làm những gì chúng ta muốn. Trong kỹ thuật cổ điển, người ta viết một đặc tả hình thức hoặc các kiểm thử kỹ lưỡng trước khi mã hóa. Làm thế nào để chúng ta mang tư duy này vào mã hóa do AI điều khiển?

Một cơ hội là tạo mã “vòng lặp kín”. Nghiên cứu gần đây đề xuất rằng mã do AI tạo ra, docstring của nó và bất kỳ chú thích hình thức nào nên được kiểm tra tính nhất quán. Chẳng hạn, phương pháp Clover tự động tạo các đặc tả hình thức (sử dụng các ngôn ngữ như Dafny) cùng với mã, và sau đó sử dụng các công cụ chứng minh để loại bỏ các giải pháp không nhất quán (theory.stanford.edu). Trong các thử nghiệm ban đầu, điều này đã phát hiện tất cả các chương trình không chính xác trên một bộ dữ liệu cấp sách giáo khoa. Tương tự, AutoACSL sử dụng phân tích tĩnh để nhắc một LLM viết các hợp đồng hàm chính xác (điều kiện tiên quyết/hậu điều kiện) và sau đó kiểm chứng chúng bằng Frama-C (papers.cool). Bằng cách đưa lại các điều kiện không được thỏa mãn, nó đã cải thiện đáng kể tỷ lệ mã có thể chứng minh là đúng. Những ví dụ này cho thấy việc tích hợp các phương pháp hình thức ở bước tạo mã có thể biến một phỏng đoán AI không kiểm soát thành một chương trình đã được kiểm chứng.

Ngoài toán học hình thức, chúng ta cũng cần các giao diện tốt hơn giữa các đặc tả phi chính thức, kiểm thử và mã. Ngày nay, việc mô tả một hàm bằng tiếng Anh và hy vọng AI sẽ làm đúng là phổ biến. Nhưng chúng ta cũng nên yêu cầu AI tạo hoặc yêu cầu các trường hợp kiểm thử, chú thích kiểu và các nhận xét thiết kế. Ví dụ, một câu lệnh có thể yêu cầu mô hình trước tiên mô tả thuật toán hoặc bất biến bằng ngôn ngữ tự nhiên hoặc mã giả, và sau đó mới mã hóa nó. Hoặc chúng ta có thể sử dụng phát triển theo hợp đồng trước: viết các kiểm thử đơn vị (hoặc kiểm thử thuộc tính) mà AI phải thỏa mãn. Các bản phác thảo sơ bộ của những ý tưởng này đã cho thấy nhiều hứa hẹn: ngay cả việc tạo ra một vài kiểm thử dựa trên ví dụ cũng có thể hướng mô hình tránh xa các giải pháp tầm thường.

Tiêu chuẩn đánh giá: Các tiêu chuẩn đánh giá mới nên bao gồm các vấn đề kiểm tra hình thức. Ví dụ, chúng ta có thể thêm các tác vụ trong đó “tính đúng đắn” được kiểm chứng bằng trình chứng minh định lý hoặc trình kiểm tra ký hiệu, chứ không chỉ các kiểm thử đơn vị. Các bộ dữ liệu về các câu chuyện người dùng với các đặc tả LTL/TLA+ hoặc Alloy và mã tương ứng sẽ rất có giá trị. Trong giáo dục, các cuộc thi như thử thách kiểm tra mô hình TLA+ cho thấy việc đặc tả là khó khăn – một nghiên cứu đã phát hiện ra rằng các LLM hiện tại chỉ đạt được ~8% tính đúng đắn về mặt ngữ nghĩa trên các đặc tả TLA+ đơn giản (papers.cool). Các dự án mã nguồn mở có thể phát hành các ngôn ngữ đặc tả rộng rãi hơn (một loại bản khai mã hóa). Các định dạng chuẩn hóa (YAML, JSON) cho các đặc tả API hoặc lược đồ dữ liệu có thể được AI tận dụng để điều chỉnh mã với hành vi dự định.

4. Quản trị Kỹ thuật Xã hội và Niềm tin

Cuối cùng, mã hóa tự động đặt ra các vấn đề con người và chính sách. Ai chịu trách nhiệm về mã AI? Làm thế nào để chúng ta đảm bảo bảo mật, tuân thủ bản quyền và trách nhiệm giải trình? Một số tổ chức đã bắt đầu giải quyết vấn đề này, nhưng các câu hỏi mở vẫn còn.

Thực hành của nhà phát triển: Như đã đề cập, các khảo sát ngành cho thấy một khoảng cách niềm tin. Các nhà phát triển biết họ nên xem xét đầu ra của AI nhưng thường bỏ qua nếu thấy dễ hơn, dẫn đến rủi ro không được quản lý (www.itpro.com). Để đáp lại, các dự án lớn đã đặt ra các quy tắc rõ ràng. Chẳng hạn, OpenInfra Foundation chỉ cho phép hỗ trợ AI nếu các commit được gắn nhãn “Assisted-By:” hoặc “Generated-By:” (openinfra.org). Dự án Chromium của Google cũng yêu cầu các tác giả phải hiểu đầy đủ bất kỳ mã nào do AI gợi ý nếu không sẽ mất đặc quyền commit (chromium.googlesource.com). Chính sách của Mozilla Firefox thẳng thắn nêu rõ: “AI có thể hỗ trợ, nhưng trách nhiệm luôn thuộc về con người đứng sau sự thay đổi” (firefox-source-docs.mozilla.org). Ngay cả dự án NumPy cũng cảnh báo rằng bạn phải có khả năng giải thích bất kỳ mã nào được gửi, bất kể AI có viết nó hay không (numpy.org). Những chính sách này nhấn mạnh rằng các công cụ kỹ thuật đơn thuần là không đủ – chúng ta cũng cần quy trình làm việc và văn hóa rõ ràng.

Quy định và tiêu chuẩn: Trên quy mô rộng hơn, các chính phủ và cơ quan tiêu chuẩn đang bắt kịp. EU đang hoàn thiện Bộ Quy tắc Thực hành cho AI Mục đích Chung, sẽ yêu cầu các nhà cung cấp mô hình AI thực hiện các biện pháp minh bạch và an toàn (digital-strategy.ec.europa.eu). Mặc dù điều này không dành riêng cho mã hóa, nó báo hiệu sự giám sát chặt chẽ hơn về giấy phép dữ liệu huấn luyện và khả năng giải thích của mô hình – cả hai đều rất liên quan nếu trợ lý mã của bạn lấy từ mã có bản quyền. Tương tự, ISO và IEEE đã bắt đầu các tiêu chuẩn AI về quản trị và đạo đức, mặc dù chỉ một số ít trực tiếp đề cập đến việc tạo mã. Đạo luật AI (EU) và các hướng dẫn sắp tới của Hoa Kỳ có thể sẽ ảnh hưởng đến cách các công ty kiểm tra mã AI nội bộ.

Cần hợp tác: Khắc phục những lỗ hổng kỹ thuật xã hội này sẽ đòi hỏi những nỗ lực chung. Giới học thuật có thể nghiên cứu cách các công cụ AI ảnh hưởng đến năng suất của nhóm, phát hiện lỗ hổng và cấp phép; ngành công nghiệp có thể chia sẻ dữ liệu ẩn danh về các sự cố liên quan đến AI thực tế; các cơ quan tiêu chuẩn (như W3C, IEEE) có thể đưa các kịch bản mã hóa vào các hướng dẫn AI đạo đức. Ví dụ, các hội thảo có thể tập hợp các chuyên gia SAT-EL (đảm bảo phần mềm) với những người làm ML để định nghĩa các tiêu chí đánh giá về an toàn mã AI. Các hướng dẫn có thể phát triển thành các tiêu chuẩn (ví dụ: “IEEE 8201: Quy trình phần mềm hỗ trợ AI”), cung cấp cho các tổ chức một khuôn khổ chung. Trong 18 tháng tới, việc xây dựng sự đồng thuận về các thực hành tốt nhất – thông qua các báo cáo chuyên đề, hiệp hội, hoặc mẫu chính sách mã nguồn mở – sẽ giúp các nhóm áp dụng các công cụ này một cách có trách nhiệm.

5. Chương trình Nghiên cứu và Tiêu chuẩn đánh giá

Để tóm tắt, chúng tôi đề xuất các bước cụ thể sau đây cho cộng đồng nghiên cứu:

• Tiêu chuẩn đánh giá Tăng cường: Phát triển một bộ tiêu chuẩn đánh giá mô phỏng các dự án phần mềm thực tế. Ví dụ, các framework đa module (ứng dụng web, API, hệ thống nhúng) nơi AI phải triển khai các tính năng mới và sau đó duy trì chúng. Bao gồm các đặc tả thay đổi (mô phỏng các yêu cầu thay đổi). Đo lường không chỉ tỷ lệ kiểm thử thành công mà còn độ phức tạp của mã, khả năng đọc, các chỉ số bảo mật và khối lượng công việc đánh giá. Hợp tác với ngành để thu thập lịch sử sửa lỗi và yêu cầu tính năng thực tế làm nhiệm vụ đánh giá.

• Nghiên cứu Phân loại Lỗi: Phân loại một cách có hệ thống các loại lỗi mà AI gây ra. Báo cáo của CodeRabbit đã đưa ra một phân tích ban đầu (lỗi logic, vấn đề đặt tên, v.v.) (www.infoworld.com). Một nghiên cứu học thuật lớn hơn có thể thu thập dữ liệu PR và phân loại lỗi giữa AI và con người. Điều này sẽ định hướng các hàm mất mát mô hình mới (ví dụ: trọng số thêm cho bảo mật) và các trình phát hiện tự động (công cụ gắn cờ các mẫu lỗi điển hình của AI).

• Nghiên cứu Lập kế hoạch và Đa tác nhân: Khám phá các kiến trúc như tác nhân lập kế hoạch/thực thi. Nghiên cứu cách cung cấp cho các hệ thống AI một dạng bộ nhớ qua các phiên làm việc hoặc thực thi lập kế hoạch phân cấp. Hợp tác với các công trình hiện có trong AI tác nhân và robot học (tái sử dụng các phương pháp suy luận đa bước cho mã).

• Tích hợp Phương pháp Hình thức: Đầu tư vào các nghiên cứu như Clover và AutoACSL liên kết tổng hợp chương trình và chứng minh. Khuyến khích các nhà nghiên cứu phương pháp hình thức hợp tác với các nhóm NLP/ML. Chẳng hạn, các cuộc thi học thuật có thể kết hợp các trợ lý mã LLM với các trình chứng minh trên các nhiệm vụ chung. Tạo các cuộc thi cho các chứng minh do AI tạo ra hoặc suy luận hợp đồng.

• Khuôn khổ Quản trị: Các nghiên cứu khoa học xã hội về thực hành của nhóm và trách nhiệm pháp lý. Ví dụ, thực hiện các nghiên cứu về nhà phát triển: cung cấp cho các nhóm công cụ AI và quan sát cách họ đánh giá và gỡ lỗi. Nghiên cứu pháp lý về IP: như một blog lưu ý, “vấn đề bản quyền Copilot” (mã không có giấy phép) là một vấn đề mở (www.systemshardening.com). Các cơ quan tiêu chuẩn nên soạn thảo các hướng dẫn rõ ràng về cấp phép dữ liệu và ghi công cho mã AI.

• Công cụ và Giao diện: Cuối cùng, xây dựng các nguyên mẫu công cụ thể hiện các thực hành tốt nhất. Một ví dụ: một plugin IDE mã hóa AI tự động chạy phân tích tĩnh hoặc kiểm thử trên bất kỳ mã nào do AI tạo ra và cảnh báo người dùng. Hoặc một CLI gắn nhãn tất cả các phần được hỗ trợ bởi AI trong một codebase. Khuyến khích các dự án mã nguồn mở áp dụng huy hiệu “AI đã sử dụng” hoặc các quy ước thông điệp commit. Các tiêu chuẩn không chính thức này sau này có thể được chính thức hóa.

Bằng cách định nghĩa các tiêu chuẩn đánh giá cộng đồng và tổ chức các thử thách đa tổ chức (như một cuộc thi hackathon mã hóa AI để đạt được các mục tiêu bảo mật hoặc khả năng bảo trì nhất định), chúng ta có thể theo dõi tiến độ. Hãy nghĩ về nó như cách ImageNet đã thúc đẩy thị giác máy tính: chúng ta cần một “ImageNet cho mã” chung phản ánh sự phát triển thực tế. Những nỗ lực ban đầu (RoadmapBench, SlopCodeBench, Sigmabench (sigmabench.com)) chỉ ra con đường, nhưng tiếp theo chúng ta nên mở rộng chúng và làm cho chúng khả dụng rộng rãi.

6. Giao diện Hình thức: Đặc tả, Kiểm thử và Mã

Một cơ hội trung tâm là tích hợp chặt chẽ hơn các đặc tả và kiểm thử vào vòng lặp mã hóa. Trong phát triển truyền thống, một đặc tả mô tả những gì mã nên làm, và các kiểm thử kiểm tra nó. Các công cụ AI có thể giúp kết nối những điều này. Ví dụ, một thực hành đầy hứa hẹn là tạo mã theo đặc tả: viết một đặc tả (có thể phi chính thức) trước, sau đó nhắc AI mã hóa nó. Tốt hơn nữa, người ta có thể cùng phát triển đặc tả với AI. Chẳng hạn, hỏi trợ lý: “Tạo các kiểm thử đơn vị cho yêu cầu này,” sau đó “Sử dụng các kiểm thử đó để xác thực mã.” Điều này tạo ra một giao diện hình thức: đặc tả ngôn ngữ tự nhiên, các kiểm thử mà nó ngụ ý và mã tạo thành một tam giác chặt chẽ.

Ở phía nghiên cứu, người ta có thể định nghĩa một định dạng chuẩn cho các đặc tả (ví dụ: một lược đồ YAML hoặc JSON mô tả chức năng) và yêu cầu các hệ thống AI tiêu thụ nó. Các nỗ lực như TLA+, Alloy, hoặc các công cụ kiểu BDD (Cucumber) có thể được tích hợp: hãy tưởng tượng việc nói với AI, “vui lòng tạo mã thỏa mãn mô hình TLA+ này.” Mặc dù các LLM ngày nay không giỏi viết TLA+ từ đầu (papers.cool), việc kết hợp một đặc tả trừu tượng do con người viết với việc tạo mã tăng cường AI đáng để khám phá. Mục tiêu là làm cho các nhóm dễ dàng tạo ra một đặc tả có thể chạy được (ngay cả khi phi chính thức) mà AI tôn trọng. Các kiểm thử hình thức sau đó có thể được tự động tạo: nghiên cứu gần đây cho thấy các mô hình GPT có thể tạo ra các kiểm thử dựa trên thuộc tính dựa trên mô tả hành vi hàm.

Tham vọng hơn, chúng ta có thể tạo ra các mẫu đặc tả hình thức. Đối với triển khai đám mây hoặc mã quan trọng về bảo mật, hãy định nghĩa một mẫu (ví dụ: “Luồng xác thực người dùng” với các trường). AI điền vào mẫu và tạo mã; một trình xác thực kiểm tra hợp đồng. Bằng cách cung cấp các giao diện này, chúng ta biến mã hóa từ một hộp đen thành một quy trình có kiểm soát hơn. Các sáng kiến như AI Tools for TLA+ hoặc dịch LLM sang đặc tả (đang diễn ra trong một số nhóm nghiên cứu) là những ví dụ ban đầu. Trong thực tế, ngay cả việc áp dụng một phần (yêu cầu AI xuất ra nhận xét hoặc chữ ký kiểu) cũng có thể cải thiện tính đúng đắn.

Là một bước đầu tiên cho các nhà phát triển: hãy tích hợp các vòng lặp đặc tả-kiểm thử đơn giản ngay bây giờ. Chẳng hạn, nếu sử dụng ChatGPT, hãy bắt đầu phiên làm việc của bạn bằng cách viết “Chúng ta muốn một hàm làm X, hãy viết kiểm thử trước.” Sau đó yêu cầu nó tạo ra triển khai. Ngay cả khi không có các công cụ hình thức phức tạp, điều này cũng thực thi một kỷ luật trong đó AI luôn tạo ra mã kèm theo một kiểm tra. Theo thời gian, thói quen này có thể được chính thức hóa thành các tiêu chuẩn cho mã hóa AI.

7. Hợp tác: Học thuật, Công nghiệp & Tiêu chuẩn

Để đạt được những mục tiêu này đòi hỏi sự hợp tác rộng rãi:

• Giới học thuật có thể đóng góp bằng cách tạo và chia sẻ dữ liệu và tiêu chuẩn đánh giá, và bằng cách công bố các đánh giá nghiêm ngặt. Các trường đại học nên hợp tác với các công ty để có được các codebase thực tế để kiểm thử. Các phòng thí nghiệm nghiên cứu có thể tổ chức các thử thách mở (có giải thưởng) về các nhiệm vụ như chất lượng mã dài hạn hoặc tạo mã đã được kiểm chứng.

• Ngành công nghiệp phải cung cấp các vòng lặp phản hồi. Các công ty triển khai công cụ mã hóa AI nên chia sẻ ẩn danh số liệu thống kê lỗi, kinh nghiệm của người đóng góp và yêu cầu tính năng. Các công ty công nghệ cũng có thể tài trợ các hội thảo hoặc các chuyên đề “AI cho mã hóa” tại các hội nghị (như ICSE, FSE). Họ có thể công khai một phần chính sách của mình (như Google đã làm với chính sách AI của Chromium (chromium.googlesource.com)) để những người khác có thể học hỏi.

• Các cơ quan tiêu chuẩn (IEEE, ISO, W3C, v.v.) nên đưa mã hóa vào các tiêu chuẩn đạo đức và an toàn AI hiện có. Ví dụ, công việc đang diễn ra của ISO về quản trị AI (ISO/IEC 38507) và vòng đời AI (ISO/IEC 5338) có thể đề cập rõ ràng đến việc tạo mã. W3C có bản nháp Nguyên tắc Đạo đức cho Web ML (www.w3.org) – điều này có thể được mở rộng với một phần về việc sử dụng lập trình. Một “bộ quy tắc thực hành” nhẹ nhàng cho các nhóm phát triển dựa vào AI nên xuất hiện, giống như các tiêu chuẩn phát triển an toàn (ví dụ: OWASP) tồn tại cho bảo mật.

Tóm lại, con đường phía trước là kỹ thuật xã hội. Giống như các cộng đồng mã nguồn mở đã hình thành các tiêu chuẩn mã hóa và văn hóa đánh giá, lĩnh vực mã hóa AI đang nổi lên cần các chuẩn mực chung. Các lộ trình chung (ví dụ, các hiệp hội công nghiệp về an toàn mã AI) và sự minh bạch (công bố các tiêu chuẩn đánh giá và các trường hợp lỗi) sẽ đưa mọi người cùng trên một trang.

8. Ai hưởng lợi và Cách bắt đầu

Quan trọng hơn cả, mã hóa có hỗ trợ AI không chỉ dành cho các nhà phát triển chuyên nghiệp. Những công cụ này có thể dân chủ hóa lập trình. Người mới bắt đầu và các chuyên gia trong lĩnh vực có thể sử dụng AI để khởi động các dự án mà họ sẽ không bao giờ có thời gian để tự mã hóa bằng tay. Ví dụ, một nhà phân tích tiếp thị có thể yêu cầu AI viết một script báo cáo dữ liệu thay vì học Python từ đầu. Một nghệ sĩ có thể tạo nguyên mẫu giao diện người dùng ứng dụng bằng cách phác thảo một lời nhắc. Trong mỗi trường hợp, AI làm giảm rào cản sáng tạo.

Để bắt đầu với các công cụ này, hãy làm theo quy trình làm việc linh hoạt, lặp đi lặp lại mà các nhóm chuyên nghiệp sử dụng:

1. Xác định mục tiêu hoặc đặc tả rõ ràng. Bắt đầu bằng cách nêu rõ những gì bạn muốn một cách cụ thể. Điều này có thể là một mô tả tính năng bằng ngôn ngữ tự nhiên hoặc một bản phác thảo đơn giản các bước. Đối với các lập trình viên, ngay cả một danh sách các gạch đầu dòng hoặc câu chuyện người dùng cũng có thể được sử dụng.
2. Sử dụng trợ lý AI để soạn thảo mã. Chạy một công cụ mã hóa AI (nhiều công cụ có sẵn: chatbot trực tuyến hoặc tiện ích mở rộng IDE) và yêu cầu nó triển khai đặc tả. Ví dụ, bạn có thể gõ “Tạo một hàm Python đọc CSV và vẽ các điểm dữ liệu.” AI sẽ tạo ra một phiên bản đầu tiên.
3. Kiểm chứng và tinh chỉnh. Quan trọng nhất, hãy lấy đầu ra của AI và kiểm thử nó. Nếu là mã, hãy chạy nó trong môi trường của bạn. Viết hoặc tự động tạo một số kiểm thử đơn giản: nó có cho kết quả đúng trên các trường hợp cơ bản không? Nếu có điều gì đó thất bại (nó thường sẽ thất bại ở lần thử đầu tiên), hãy đưa phản hồi cho AI: ví dụ, làm nổi bật trường hợp thất bại và yêu cầu nó sửa mã. Nhiều công cụ cho phép nhắc nhở lặp đi lặp lại hoặc chỉnh sửa “đa lượt”.
4. Yêu cầu giải thích và tài liệu. Sử dụng AI để tạo docstring hoặc nhận xét sau khi hoàn thành. Điều này giúp bạn, người mã hóa (mới), hiểu được những gì đã được thực hiện. Bạn cũng có thể yêu cầu AI chỉ ra các vấn đề tiềm ẩn hoặc đề xuất cải tiến.
5. Tăng dần độ phức tạp. Sau khi các script đơn giản hoạt động, bạn có thể thử một dự án nhỏ (ví dụ: một ứng dụng danh sách việc cần làm, một pipeline phân tích dữ liệu). Chia dự án thành các phần: hỏi AI từng thành phần (lược đồ cơ sở dữ liệu, giao diện người dùng, logic nghiệp vụ) từng cái một. Coi nó như lập trình cặp đôi, nơi AI là đối tác cấp dưới của bạn.

Bước tiếp theo đầu tiên: Chọn một công cụ mã hóa AI thân thiện với người mới bắt đầu và thử một thử nghiệm nhỏ. Chẳng hạn, sử dụng một giao diện như GPT-4 (với khả năng mã hóa) hoặc một tiện ích mở rộng miễn phí trong trình soạn thảo mã của bạn. Giao cho nó một nhiệm vụ đơn giản (“sắp xếp một danh sách”, “tạo biểu đồ”, “trang web hello world”) và xem nó tạo ra gì. Sau đó đọc mã – ngay cả khi không có kinh nghiệm mã hóa, hãy nhìn vào cấu trúc. Chạy nó và ghi lại bất kỳ lỗi nào. Sau đó lặp lại: tinh chỉnh lời nhắc của bạn (có thể thêm chi tiết hoặc ràng buộc hơn) và tạo lại. Theo thời gian, bạn sẽ học cách giao tiếp hiệu quả với công cụ và cách hướng dẫn nó đến các giải pháp đúng đắn.

Người mã hóa mới nên ghi nhớ: AI là một trợ lý mạnh mẽ, không phải là một nhà tiên tri. Luôn kiểm tra công việc của nó, và sử dụng nó như một cơ hội học hỏi. Viết kiểm thử của riêng bạn cho mã của AI, chạy chúng và đặt các câu hỏi tiếp theo cho đến khi bạn tự tin. Thói quen “kiểm tra rồi tin tưởng” này là cách mọi người – dù là người mới hay chuyên gia – nên xây dựng an toàn với AI.

Kết luận

Sự trỗi dậy của các công cụ mã hóa tự động là một thời khắc mang tính bước ngoặt, nhưng để gặt hái đầy đủ lợi ích, chúng ta phải đối mặt với các vấn đề mở được tiết lộ qua các đợt triển khai ban đầu. Về độ tin cậy, chúng ta thấy rằng các trợ lý mã hóa mắc nhiều lỗi hơn con người, vì vậy nghiên cứu phải tập trung vào phát hiện lỗi và tạo mã mạnh mẽ. Về lập kế hoạch, chúng ta thấy các tác nhân gặp khó khăn trong các dự án dài, đa bước, vì vậy chúng ta cần các kiến trúc và tiêu chuẩn đánh giá mới cho các quy trình làm việc phức tạp. Về khả năng kiểm chứng, chúng ta nhận ra rằng chúng ta cần sự hỗ trợ đặc tả hình thức và kiểm thử được tích hợp vào chính quy trình mã hóa AI. Và về quản trị, các công ty và cơ quan quản lý đang gấp rút đặt ra các quy tắc để mã AI minh bạch, an toàn và có trách nhiệm giải trình.

Trong 18 tháng tới, tiến bộ trong mỗi lĩnh vực này sẽ rất cần thiết. Bằng cách xây dựng các tiêu chuẩn đánh giá nghiêm ngặt (từ các thách thức lập kế hoạch dự án đến việc kiểm tra các lỗi do AI gây ra), tích hợp các phương pháp hình thức vào các pipeline mã hóa AI và thúc đẩy hợp tác giữa các lĩnh vực, chúng ta có thể thu hẹp khoảng cách giữa các bản demo hào nhoáng và độ tin cậy trong thế giới thực. Tầm nhìn rõ ràng: một hệ sinh thái mã hóa AI nơi ngay cả người mới bắt đầu cũng có thể tạo phần mềm một cách an toàn, và nơi mã do AI tạo ra đáng tin cậy như mã do con người tạo ra. Đạt được tầm nhìn này sẽ đòi hỏi phải định hình cả công nghệ và các thực hành xung quanh nó. Với nghiên cứu tập trung và nỗ lực rộng lớn của cộng đồng, thế hệ công cụ AI tiếp theo thực sự có thể mở khóa mã hóa cho tất cả mọi người – bắt đầu từ hôm nay.

**`