Lập trình viên trong thời đại AI: từ tạo mã sang kiểm soát tính phi định tính

baeba · 2026-06-22T10:32:20+09:00

Tóm tắt tổng quan Khi AI tự động hóa phần lớn việc viết mã, vai trò cốt lõi của lập trình viên đang chuyển từ trực tiếp triển khai sang thiết kế, xác minh và kiểm soát. Bản chất của lập trình viên không nằm ở việc gõ thật nhiều mã, mà ở khả năng lấp đầy chi tiết của các yêu cầu mơ hồ và trừu tượng hóa chúng thành dạng có thể tái sử dụng. Thay vì chỉ dẫn cho AI cách hiện thực chi tiết, cách hiệu quả hơn là đưa ra mục tiêu và bối cảnh rồi ủy quyền phán đoán. Công việc với AI nên được tách thành đặc tả, kiểm thử, triển khai, refactor và xác minh thay vì xử lý một lần, để nâng cao chất lượng. Vì đầu ra của AI mang tính phi định tính, cần có harness mang tính quyết định như kiểm thử, compiler, linter và các cổng xác minh. Trong tương lai, nhà phát triển có thể sẽ gần với vai trò kiến trúc sư hệ thống và kỹ sư harness kết nối các AI agent với hệ thống xác minh hơn là chỉ là người viết mã đơn thuần. Giới thiệu Bản sắc của lập trình viên bị AI lung lay Khi AI có thể tạo ra hàng trăm dòng mã chỉ bằng chỉ dẫn ngôn ngữ tự nhiên, tiêu chuẩn đánh giá năng lực phát triển truyền thống đang thay đổi. Trước đây, khả năng viết mã nhanh từ một editor trống được xem là năng lực cạnh tranh chính của lập trình viên. Hiện nay, khi AI cung cấp kiến thức và cách triển khai, những câu hỏi sau xuất hiện. Không trực tiếp viết mã thì có còn được xem là phát triển phần mềm không? Nếu AI xử lý các chi tiết triển khai, lập trình viên còn lại vai trò gì? Kiến thức khoa học máy tính truyền thống và lịch sử lập trình còn cần thiết ở hiện tại không? Bài viết giải thích vấn đề này xoay quanh các khái niệm chi tiết, trừu tượng hóa, tính phi định tính và harness. Ý nghĩa của lịch sử lập trình Kiến thức lập trình trong quá khứ không chỉ là danh sách kỹ thuật, mà là quá trình các lập trình viên thời đó giải quyết vấn đề và tạo ra các tầng trừu tượng mới. Mã máy, assembly, lập trình có cấu trúc, hướng đối tượng và framework đều là kết quả được tạo ra để che giấu độ phức tạp của tầng bên dưới. Dù không trực tiếp dùng các công nghệ cũ, việc hiểu lịch sử của chúng giúp nhận ra vai trò của lập trình viên đã lặp đi lặp lại thay đổi như thế nào. Nội dung chính 1. Nhà phát triển là người cụ thể hóa chi tiết Kế hoạch sản phẩm thường chỉ đưa ra mục tiêu và định hướng lớn, chứ không chỉ rõ mọi điều kiện cần thiết cho triển khai thực tế. Ví dụ, ngay cả một tính năng đơn giản như “chỉnh sửa nickname” cũng có các điều kiện chi tiết sau. Có cho phép chuỗi rỗng hay không Cách xử lý ký tự đặc biệt và emoji Xử lý lỗi mạng và độ trễ phản hồi Hành vi khi rời khỏi màn hình trong lúc đang chỉnh sửa Vị trí và cách thể hiện thông báo lỗi Công việc của lập trình viên là cụ thể hóa những khoảng trống này thành các quy tắc logic và xử lý ngoại lệ. Vì vậy, chuyên môn của lập trình viên không nằm ở việc đơn thuần hiện thực tính năng, mà ở khả năng chuyển đổi yêu cầu mơ hồ thành hành vi hệ thống hoàn chỉnh. 2. Trừu tượng hóa là quá trình che giấu những chi tiết đã được giải quyết Để giảm công việc lặp lại, nhà phát triển đóng gói những vấn đề đã giải quyết một lần thành hàm, module, thư viện, framework... Cốt lõi của trừu tượng hóa là như sau. Che giấu các hoạt động nội bộ lặp đi lặp lại. Chỉ phơi bày các chức năng cần thiết ra bên ngoài. Thiết lập ranh giới giữa phần có thể thay đổi và phần cần cố định. Khi các trừu tượng vững chắc được tích lũy, các tầng mới sẽ hình thành, và nhà phát triển ở tầng trên có thể làm việc mà không cần biết toàn bộ triển khai bên dưới. Môi trường phát triển hiện tại vận hành trên các tầng trừu tượng do thế hệ lập trình viên trước xây dựng. 3. Độ sâu cần thiết với nhà phát triển thay đổi theo vị trí Không phải mọi trừu tượng đều đã hoàn thiện. Những tầng có thể che giấu ổn định triển khai nội bộ có thể được xem là “trừu tượng đã hoàn tất”. Những tầng mà chi tiết nội bộ vẫn liên tục lộ ra dưới dạng vấn đề hiệu năng hay lỗi thì thuộc “trừu tượng đang diễn ra”. Cùng một công nghệ nhưng trạng thái sẽ khác nhau tùy vai trò của nhà phát triển. Với một web developer thông thường, browser là một tầng tương đối hoàn thiện. Với developer của browser engine, quá trình rendering là chi tiết cần trực tiếp xử lý. Độ sâu cần thiết với nhà phát triển không phải là biết mọi công nghệ, mà là mức độ đủ để nắm được các điểm rò rỉ và giới hạn của tầng mình phụ trách. 4. AI xuất hiện như một tầng trừu tượng mới AI thực hiện rất nhanh việc viết mã và triển khai lặp lại mà trước đây nhà phát triển phải tự làm. Vì vậy, AI bắt đầu hoạt động như một tầng mới trừu tượng hóa chính quá trình phát triển, vượt ra ngoài vai trò công cụ tăng năng suất đơn thuần. Tuy nhiên, việc AI tạo ra mã không có nghĩa là nó tự động giải quyết luôn việc diễn giải yêu cầu, thiết kế cấu trúc, xác minh chất lượng và trách nhiệm vận hành. Ngược lại, khi chi phí triển khai giảm xuống, tầm quan trọng của chi phí lắp ráp và xác minh mã được tạo ra lại tăng lên. 5. Chỉ dẫn quá chi tiết có thể giới hạn hiệu năng của AI Tác giả đã thử phát triển một side project về UI trợ năng chỉ bằng AI mà không tự gõ mã. Ban đầu, tác giả đưa cho AI phương pháp triển khai cụ thể, nhưng AI bị cố định vào phương pháp đó và liên tục thêm xử lý ngoại lệ. Kết quả là mã trở nên phức tạp, phát sinh nhiều tác dụng phụ, còn phương án chuẩn phù hợp hơn chỉ được áp dụng muộn hơn. Trường hợp này cho thấy phương pháp ban đầu do người dùng đưa ra có thể trở thành một anchor giới hạn khả năng phán đoán của AI. Thay vì chỉ dẫn quá mức về cách giải quyết và cấu trúc mã, cách hiệu quả hơn là cung cấp những điều sau. Bối cảnh và mục đích của vấn đề Ngữ cảnh của hệ thống hiện tại Kết quả bắt buộc phải đạt được Các ràng buộc không được phép thay đổi 6. Cần ủy quyền mục tiêu và bối cảnh hơn là chỉ dẫn Khi hiệu năng của AI tăng lên, cách ủy quyền theo mục tiêu có thể hiệu quả hơn việc trực tiếp chỉ định từng thủ tục chi tiết. Trong cách ủy quyền này, thay vì quyết định toàn bộ “triển khai như thế nào”, nhà phát triển truyền đạt rõ ràng “vì sao cần điều đó” và “cần đạt được điều gì”. Tuy nhiên, nếu trao quyền tự chủ hoàn toàn, AI có thể tập trung vào việc sửa mã hơn là ý định thực sự của người dùng. Vì vậy, cần giới hạn quy trình làm việc để AI trước tiên thực hiện các hành động sau. Phân tích ý định của yêu cầu Đặt câu hỏi về thông tin còn thiếu Đề xuất kế hoạch giải quyết Chỉ thực thi sau khi người dùng phê duyệt Điểm cốt lõi không phải là các lệnh cấm đơn thuần, mà là chỉ rõ đầu ra nào được phép ở giai đoạn hiện tại. 7. Mỗi lần làm việc chỉ nên chỉ định một đầu ra LLM có giới hạn về lượng đầu ra và phạm vi suy luận mà nó có thể xử lý trong một lần phản hồi. Nếu vừa yêu cầu viết test vừa triển khai cùng lúc, tài nguyên có thể dồn vào mục tiêu cuối là hoàn thiện mã, khiến chất lượng test giảm xuống. Tác giả tách công việc TDD như sau. /red: chỉ viết các test thất bại /green: viết phần triển khai tối thiểu để test pass /refactor: cải thiện cấu trúc mã trong khi vẫn giữ test Khi giới hạn đầu ra của từng bước về đúng một loại, có thể giảm tình trạng AI bỏ qua quy trình trung gian hoặc làm cho có lệ. Điều này cho thấy cốt lõi của thiết kế prompt không phải là giải thích dài dòng về hành vi, mà là định nghĩa kết quả cần được tạo ra trong một lần làm việc. 8. Tài liệu Markdown và skill trở thành loại mã mới Khi tách đặc tả, kiểm thử, triển khai, xác minh và commit thành các skill riêng biệt, có thể xây dựng pipeline như sau. Viết đặc tả Tạo test thất bại Triển khai tính năng Refactor Xác minh Commit Mỗi skill có đầu vào, đầu ra và điều kiện ràng buộc, nên hoạt động tương tự một hàm. Tài liệu Markdown ghi lại các skill và quy tắc không chỉ là tài liệu mô tả đơn thuần, mà còn đóng vai trò như quy tắc thực thi quyết định hành vi của AI. Trong quá trình này, cũng có thể áp dụng các nguyên tắc thiết kế phần mềm truyền thống. Nguyên tắc trách nhiệm đơn nhất: mỗi skill chỉ có một trách nhiệm Tính module hóa: tách kiến thức và quy tắc sang các file riêng Nguyên tắc đóng-mở: mở rộng bằng file tri thức bên ngoài mà không thay đổi skill cốt lõi Chỉ là nền tảng đã chuyển từ IDE sang tài liệu Markdown; việc phân rã và kết nối công việc vẫn là lập trình. 9. Rủi ro cốt lõi của lập trình với AI là tính phi định tính Chương trình truyền thống nhìn chung trả về cùng một đầu ra cho cùng một đầu vào. AI có thể tạo ra mã và phán đoán khác nhau ngay cả với cùng một yêu cầu. Khi AI thực hiện refactor quy mô lớn, dù chức năng có thể vẫn chạy, các vấn đề sau vẫn còn tồn tại. Rà soát tính chính xác của mã đã thay đổi Đánh giá xem phần mã bị xóa có thực sự không cần thiết hay không Khả năng phát sinh tác dụng phụ mới Trách nhiệm bảo trì và phát hành AI tăng tốc độ sinh mã, nhưng không tự động mang lại sự ổn định của kết quả và trách nhiệm đi kèm. Trong môi trường production, quan trọng hơn khả năng tạo sinh là khả năng kiểm soát phạm vi thay đổi và xác minh kết quả. 10. AI mạnh với những bài toán có trần thấp Những vấn đề AI xử lý dễ dàng phần lớn là các “bài toán được định nghĩa tốt”, nơi yêu cầu và cách giải đã được biết khá đầy đủ. Các vấn đề như vậy có thể được giải quyết bằng cách kết hợp các yếu tố trừu tượng đã hoàn thiện sẵn như thư viện, framework và pattern. AI có thế mạnh trong việc tổ hợp theo xác suất mã và các pattern giải quyết vấn đề mà nhân loại đã tích lũy. Ngược lại, các vấn đề độ khó cao sau đây vẫn cần thêm phán đoán của con người. Bài toán có yêu cầu chưa hoàn chỉnh Quy tắc domain phức tạp Tương tác trong hệ thống quy mô lớn Tình huống ngoại lệ của môi trường vận hành Vấn đề kết hợp giữa bảo mật, hiệu năng, tuân thủ quy định và trách nhiệm Giá trị của việc triển khai đơn thuần không hẳn biến mất, nhưng bản thân việc triển khai có thể dần trở thành lĩnh vực mà cả người dùng phổ thông cũng làm được. 11. Chi tiết mà nhà phát triển xử lý đang chuyển sang kiểm soát AI Trước đây, nhà phát triển viết mã mang tính quyết định để phòng vệ trước đầu vào người dùng và môi trường vận hành khó dự đoán. Trong thời đại AI, cần dùng AI phi định tính để tạo ra sản phẩm mang tính quyết định. Những chi tiết mà nhà phát triển phải xử lý đang chuyển sang các lĩnh vực sau. Thiết lập phạm vi công việc để AI không bị mắc kẹt vào mục tiêu sai Định nghĩa định dạng đầu vào và đầu ra theo từng bước Quản lý tài liệu bối cảnh và tri thức Giới hạn phạm vi của các thay đổi quy mô lớn Thiết kế quy trình khôi phục khi xảy ra lỗi Xác minh chất lượng và độ an toàn của kết quả Càng nhiều công việc triển khai đơn thuần được tự động hóa, công việc phát triển càng có thể nghiêng mạnh hơn về xử lý ngoại lệ và kiểm soát. 12. Kết quả của AI phải được xác minh bằng công cụ mang tính quyết định Chỉ dùng phương pháp để AI khác xác minh kết quả do AI tạo ra là chưa đủ để đảm bảo độ tin cậy. Để đánh giá đầu ra của hệ thống có đúng hay không, cần có tiêu chuẩn đáp án rõ ràng, tức một oracle. Nếu AI phi định tính cũng tự ý tạo ra cả tiêu chuẩn xác minh, nó có thể sửa sai kết quả đúng hoặc làm méo mó tiêu chuẩn kiểm chứng. Vì vậy, tiêu chuẩn xác minh cần được cấu thành bằng các công cụ mang tính quyết định nhiều nhất có thể. Compiler và type checker Kiểm thử tự động Linter và phân tích tĩnh Kiểm tra schema Tiêu chuẩn hiệu năng và bảo mật Quy trình phê duyệt và giới hạn phạm vi thay đổi Phán đoán của AI có thể dùng như công cụ hỗ trợ, nhưng việc pass cuối cùng cần gắn với các tiêu chuẩn có thể tái lập. 13. Harness trở thành hạ tầng cốt lõi của phát triển với AI Harness là thiết bị xác minh được bố trí theo từng bước để AI không tích lũy lỗi trong quá trình làm việc hoặc đi vượt khỏi phạm vi. Các thành phần chính gồm có. Pipeline tách riêng từng giai đoạn công việc Định dạng vào/ra cho từng bước Kiểm thử tự động và phân tích tĩnh Các cổng xác minh dừng lại khi thất bại Giới hạn file và phạm vi được phép thay đổi Quy trình phê duyệt và review của con người Harness ngăn lỗi nhỏ ở một bước bị khuếch đại ở các bước tiếp theo. Năng lực tận dụng AI có thể sẽ được đánh giá không phải chỉ bằng khả năng viết prompt tốt, mà bằng khả năng ràng buộc đầu ra khó đoán vào trong một hệ thống ổn định. Kết luận Nhà phát triển không biến mất, mà vai trò đang dịch chuyển AI đang nhanh chóng tự động hóa việc viết mã đơn thuần và triển khai lặp lại. Tuy nhiên, để tạo ra kết quả ở cấp độ sản phẩm, vẫn cần các vai trò sau. Định nghĩa vấn đề và mục tiêu Thiết kế cấu trúc hệ thống Tách riêng các giai đoạn công việc và đầu ra Điều phối luồng giữa các AI agent Xây dựng tiêu chuẩn xác minh và harness Chịu trách nhiệm cuối cùng cho kết quả vận hành Công việc của nhà phát triển nhiều khả năng sẽ thay đổi theo hướng giảm tỷ trọng trực tiếp gõ mã, và tăng tỷ trọng tổ chức, hệ thống hóa và kiểm soát mã do AI tạo ra. Viết prompt là một dạng lập trình mới Quá trình biến những chỉ dẫn dùng lặp lại thành skill và quy tắc rồi kết nối chúng bằng pipeline tương tự như thiết kế hàm và module. Tài liệu Markdown có thể hoạt động như một tầng mã mới định nghĩa bối cảnh, hành vi và định dạng đầu ra của AI. Nhà phát triển cần tài liệu hóa kinh nghiệm và các tiêu chuẩn phán đoán ngầm của mình, rồi trừu tượng hóa chúng thành dạng AI có thể tái sử dụng. Điều này không chỉ là trừu tượng hóa hệ thống hiện có, mà còn là trừu tượng hóa chính cách làm việc và quá trình phán đoán của nhà phát triển. Năng lực cốt lõi của nhà phát triển tương lai Khả năng định nghĩa chính xác vấn đề Khả năng ủy quyền công việc dựa trên mục tiêu và bối cảnh Khả năng phân rã công việc phức tạp thành các đầu ra nhỏ Khả năng cấu thành skill và agent thành pipeline Khả năng thiết kế tiêu chuẩn xác minh mang tính quyết định Khả năng xây dựng harness để kiểm soát rủi ro của kết quả phi định tính Độ sâu kỹ thuật để hiểu kết quả do AI tạo ra và chịu trách nhiệm cuối cùng Đánh giá tổng hợp AI không xóa bỏ bản chất của phát triển phần mềm, mà đang thay đổi tầng trừu tượng mà nhà phát triển phải xử lý. Nếu trước đây nhà phát triển xử lý chi tiết của mã và hệ thống, thì trong tương lai họ sẽ phải xử lý chi tiết phát sinh từ hành vi và đầu ra của AI. Chi phí tạo mã giảm xuống, nhưng tầm quan trọng của xác minh, lắp ráp, vận hành và kiểm soát có thể còn tăng mạnh hơn. Bản chất của lập trình viên không nằm ở việc gõ phím, mà ở khả năng phát hiện chi tiết, trừu tượng hóa chúng và cấu thành chúng thành một hệ thống đáng tin cậy.

(velog.io)

6 điểm bởi baeba 5 giờ trước | Chưa có bình luận nào. | Chia sẻ qua WhatsApp

Tóm tắt tổng quan

Khi AI tự động hóa phần lớn việc viết mã, vai trò cốt lõi của lập trình viên đang chuyển từ trực tiếp triển khai sang thiết kế, xác minh và kiểm soát.
Bản chất của lập trình viên không nằm ở việc gõ thật nhiều mã, mà ở khả năng lấp đầy chi tiết của các yêu cầu mơ hồ và trừu tượng hóa chúng thành dạng có thể tái sử dụng.
Thay vì chỉ dẫn cho AI cách hiện thực chi tiết, cách hiệu quả hơn là đưa ra mục tiêu và bối cảnh rồi ủy quyền phán đoán.
Công việc với AI nên được tách thành đặc tả, kiểm thử, triển khai, refactor và xác minh thay vì xử lý một lần, để nâng cao chất lượng.
Vì đầu ra của AI mang tính phi định tính, cần có harness mang tính quyết định như kiểm thử, compiler, linter và các cổng xác minh.
Trong tương lai, nhà phát triển có thể sẽ gần với vai trò kiến trúc sư hệ thống và kỹ sư harness kết nối các AI agent với hệ thống xác minh hơn là chỉ là người viết mã đơn thuần.

Giới thiệu

Bản sắc của lập trình viên bị AI lung lay

Khi AI có thể tạo ra hàng trăm dòng mã chỉ bằng chỉ dẫn ngôn ngữ tự nhiên, tiêu chuẩn đánh giá năng lực phát triển truyền thống đang thay đổi.
Trước đây, khả năng viết mã nhanh từ một editor trống được xem là năng lực cạnh tranh chính của lập trình viên.
Hiện nay, khi AI cung cấp kiến thức và cách triển khai, những câu hỏi sau xuất hiện.
- Không trực tiếp viết mã thì có còn được xem là phát triển phần mềm không?
- Nếu AI xử lý các chi tiết triển khai, lập trình viên còn lại vai trò gì?
- Kiến thức khoa học máy tính truyền thống và lịch sử lập trình còn cần thiết ở hiện tại không?
Bài viết giải thích vấn đề này xoay quanh các khái niệm chi tiết, trừu tượng hóa, tính phi định tính và harness.

Ý nghĩa của lịch sử lập trình

Kiến thức lập trình trong quá khứ không chỉ là danh sách kỹ thuật, mà là quá trình các lập trình viên thời đó giải quyết vấn đề và tạo ra các tầng trừu tượng mới.
Mã máy, assembly, lập trình có cấu trúc, hướng đối tượng và framework đều là kết quả được tạo ra để che giấu độ phức tạp của tầng bên dưới.
Dù không trực tiếp dùng các công nghệ cũ, việc hiểu lịch sử của chúng giúp nhận ra vai trò của lập trình viên đã lặp đi lặp lại thay đổi như thế nào.

Nội dung chính

1. Nhà phát triển là người cụ thể hóa chi tiết

Kế hoạch sản phẩm thường chỉ đưa ra mục tiêu và định hướng lớn, chứ không chỉ rõ mọi điều kiện cần thiết cho triển khai thực tế.
Ví dụ, ngay cả một tính năng đơn giản như “chỉnh sửa nickname” cũng có các điều kiện chi tiết sau.
- Có cho phép chuỗi rỗng hay không
- Cách xử lý ký tự đặc biệt và emoji
- Xử lý lỗi mạng và độ trễ phản hồi
- Hành vi khi rời khỏi màn hình trong lúc đang chỉnh sửa
- Vị trí và cách thể hiện thông báo lỗi
Công việc của lập trình viên là cụ thể hóa những khoảng trống này thành các quy tắc logic và xử lý ngoại lệ.
Vì vậy, chuyên môn của lập trình viên không nằm ở việc đơn thuần hiện thực tính năng, mà ở khả năng chuyển đổi yêu cầu mơ hồ thành hành vi hệ thống hoàn chỉnh.

2. Trừu tượng hóa là quá trình che giấu những chi tiết đã được giải quyết

Để giảm công việc lặp lại, nhà phát triển đóng gói những vấn đề đã giải quyết một lần thành hàm, module, thư viện, framework...
Cốt lõi của trừu tượng hóa là như sau.
- Che giấu các hoạt động nội bộ lặp đi lặp lại.
- Chỉ phơi bày các chức năng cần thiết ra bên ngoài.
- Thiết lập ranh giới giữa phần có thể thay đổi và phần cần cố định.
Khi các trừu tượng vững chắc được tích lũy, các tầng mới sẽ hình thành, và nhà phát triển ở tầng trên có thể làm việc mà không cần biết toàn bộ triển khai bên dưới.
Môi trường phát triển hiện tại vận hành trên các tầng trừu tượng do thế hệ lập trình viên trước xây dựng.

3. Độ sâu cần thiết với nhà phát triển thay đổi theo vị trí

Không phải mọi trừu tượng đều đã hoàn thiện.
Những tầng có thể che giấu ổn định triển khai nội bộ có thể được xem là “trừu tượng đã hoàn tất”.
Những tầng mà chi tiết nội bộ vẫn liên tục lộ ra dưới dạng vấn đề hiệu năng hay lỗi thì thuộc “trừu tượng đang diễn ra”.
Cùng một công nghệ nhưng trạng thái sẽ khác nhau tùy vai trò của nhà phát triển.
- Với một web developer thông thường, browser là một tầng tương đối hoàn thiện.
- Với developer của browser engine, quá trình rendering là chi tiết cần trực tiếp xử lý.
Độ sâu cần thiết với nhà phát triển không phải là biết mọi công nghệ, mà là mức độ đủ để nắm được các điểm rò rỉ và giới hạn của tầng mình phụ trách.

4. AI xuất hiện như một tầng trừu tượng mới

AI thực hiện rất nhanh việc viết mã và triển khai lặp lại mà trước đây nhà phát triển phải tự làm.
Vì vậy, AI bắt đầu hoạt động như một tầng mới trừu tượng hóa chính quá trình phát triển, vượt ra ngoài vai trò công cụ tăng năng suất đơn thuần.
Tuy nhiên, việc AI tạo ra mã không có nghĩa là nó tự động giải quyết luôn việc diễn giải yêu cầu, thiết kế cấu trúc, xác minh chất lượng và trách nhiệm vận hành.
Ngược lại, khi chi phí triển khai giảm xuống, tầm quan trọng của chi phí lắp ráp và xác minh mã được tạo ra lại tăng lên.

5. Chỉ dẫn quá chi tiết có thể giới hạn hiệu năng của AI

Tác giả đã thử phát triển một side project về UI trợ năng chỉ bằng AI mà không tự gõ mã.
Ban đầu, tác giả đưa cho AI phương pháp triển khai cụ thể, nhưng AI bị cố định vào phương pháp đó và liên tục thêm xử lý ngoại lệ.
Kết quả là mã trở nên phức tạp, phát sinh nhiều tác dụng phụ, còn phương án chuẩn phù hợp hơn chỉ được áp dụng muộn hơn.
Trường hợp này cho thấy phương pháp ban đầu do người dùng đưa ra có thể trở thành một anchor giới hạn khả năng phán đoán của AI.
Thay vì chỉ dẫn quá mức về cách giải quyết và cấu trúc mã, cách hiệu quả hơn là cung cấp những điều sau.
- Bối cảnh và mục đích của vấn đề
- Ngữ cảnh của hệ thống hiện tại
- Kết quả bắt buộc phải đạt được
- Các ràng buộc không được phép thay đổi

6. Cần ủy quyền mục tiêu và bối cảnh hơn là chỉ dẫn

Khi hiệu năng của AI tăng lên, cách ủy quyền theo mục tiêu có thể hiệu quả hơn việc trực tiếp chỉ định từng thủ tục chi tiết.
Trong cách ủy quyền này, thay vì quyết định toàn bộ “triển khai như thế nào”, nhà phát triển truyền đạt rõ ràng “vì sao cần điều đó” và “cần đạt được điều gì”.
Tuy nhiên, nếu trao quyền tự chủ hoàn toàn, AI có thể tập trung vào việc sửa mã hơn là ý định thực sự của người dùng.
Vì vậy, cần giới hạn quy trình làm việc để AI trước tiên thực hiện các hành động sau.
- Phân tích ý định của yêu cầu
- Đặt câu hỏi về thông tin còn thiếu
- Đề xuất kế hoạch giải quyết
- Chỉ thực thi sau khi người dùng phê duyệt
Điểm cốt lõi không phải là các lệnh cấm đơn thuần, mà là chỉ rõ đầu ra nào được phép ở giai đoạn hiện tại.

7. Mỗi lần làm việc chỉ nên chỉ định một đầu ra

LLM có giới hạn về lượng đầu ra và phạm vi suy luận mà nó có thể xử lý trong một lần phản hồi.
Nếu vừa yêu cầu viết test vừa triển khai cùng lúc, tài nguyên có thể dồn vào mục tiêu cuối là hoàn thiện mã, khiến chất lượng test giảm xuống.
Tác giả tách công việc TDD như sau.
- /red: chỉ viết các test thất bại
- /green: viết phần triển khai tối thiểu để test pass
- /refactor: cải thiện cấu trúc mã trong khi vẫn giữ test
Khi giới hạn đầu ra của từng bước về đúng một loại, có thể giảm tình trạng AI bỏ qua quy trình trung gian hoặc làm cho có lệ.
Điều này cho thấy cốt lõi của thiết kế prompt không phải là giải thích dài dòng về hành vi, mà là định nghĩa kết quả cần được tạo ra trong một lần làm việc.

8. Tài liệu Markdown và skill trở thành loại mã mới

Khi tách đặc tả, kiểm thử, triển khai, xác minh và commit thành các skill riêng biệt, có thể xây dựng pipeline như sau.
- Viết đặc tả
- Tạo test thất bại
- Triển khai tính năng
- Refactor
- Xác minh
- Commit
Mỗi skill có đầu vào, đầu ra và điều kiện ràng buộc, nên hoạt động tương tự một hàm.
Tài liệu Markdown ghi lại các skill và quy tắc không chỉ là tài liệu mô tả đơn thuần, mà còn đóng vai trò như quy tắc thực thi quyết định hành vi của AI.
Trong quá trình này, cũng có thể áp dụng các nguyên tắc thiết kế phần mềm truyền thống.
- Nguyên tắc trách nhiệm đơn nhất: mỗi skill chỉ có một trách nhiệm
- Tính module hóa: tách kiến thức và quy tắc sang các file riêng
- Nguyên tắc đóng-mở: mở rộng bằng file tri thức bên ngoài mà không thay đổi skill cốt lõi
Chỉ là nền tảng đã chuyển từ IDE sang tài liệu Markdown; việc phân rã và kết nối công việc vẫn là lập trình.

9. Rủi ro cốt lõi của lập trình với AI là tính phi định tính

Chương trình truyền thống nhìn chung trả về cùng một đầu ra cho cùng một đầu vào.
AI có thể tạo ra mã và phán đoán khác nhau ngay cả với cùng một yêu cầu.
Khi AI thực hiện refactor quy mô lớn, dù chức năng có thể vẫn chạy, các vấn đề sau vẫn còn tồn tại.
- Rà soát tính chính xác của mã đã thay đổi
- Đánh giá xem phần mã bị xóa có thực sự không cần thiết hay không
- Khả năng phát sinh tác dụng phụ mới
- Trách nhiệm bảo trì và phát hành
AI tăng tốc độ sinh mã, nhưng không tự động mang lại sự ổn định của kết quả và trách nhiệm đi kèm.
Trong môi trường production, quan trọng hơn khả năng tạo sinh là khả năng kiểm soát phạm vi thay đổi và xác minh kết quả.

10. AI mạnh với những bài toán có trần thấp

Những vấn đề AI xử lý dễ dàng phần lớn là các “bài toán được định nghĩa tốt”, nơi yêu cầu và cách giải đã được biết khá đầy đủ.
Các vấn đề như vậy có thể được giải quyết bằng cách kết hợp các yếu tố trừu tượng đã hoàn thiện sẵn như thư viện, framework và pattern.
AI có thế mạnh trong việc tổ hợp theo xác suất mã và các pattern giải quyết vấn đề mà nhân loại đã tích lũy.
Ngược lại, các vấn đề độ khó cao sau đây vẫn cần thêm phán đoán của con người.
- Bài toán có yêu cầu chưa hoàn chỉnh
- Quy tắc domain phức tạp
- Tương tác trong hệ thống quy mô lớn
- Tình huống ngoại lệ của môi trường vận hành
- Vấn đề kết hợp giữa bảo mật, hiệu năng, tuân thủ quy định và trách nhiệm
Giá trị của việc triển khai đơn thuần không hẳn biến mất, nhưng bản thân việc triển khai có thể dần trở thành lĩnh vực mà cả người dùng phổ thông cũng làm được.

11. Chi tiết mà nhà phát triển xử lý đang chuyển sang kiểm soát AI

Trước đây, nhà phát triển viết mã mang tính quyết định để phòng vệ trước đầu vào người dùng và môi trường vận hành khó dự đoán.
Trong thời đại AI, cần dùng AI phi định tính để tạo ra sản phẩm mang tính quyết định.
Những chi tiết mà nhà phát triển phải xử lý đang chuyển sang các lĩnh vực sau.
- Thiết lập phạm vi công việc để AI không bị mắc kẹt vào mục tiêu sai
- Định nghĩa định dạng đầu vào và đầu ra theo từng bước
- Quản lý tài liệu bối cảnh và tri thức
- Giới hạn phạm vi của các thay đổi quy mô lớn
- Thiết kế quy trình khôi phục khi xảy ra lỗi
- Xác minh chất lượng và độ an toàn của kết quả
Càng nhiều công việc triển khai đơn thuần được tự động hóa, công việc phát triển càng có thể nghiêng mạnh hơn về xử lý ngoại lệ và kiểm soát.

12. Kết quả của AI phải được xác minh bằng công cụ mang tính quyết định

Chỉ dùng phương pháp để AI khác xác minh kết quả do AI tạo ra là chưa đủ để đảm bảo độ tin cậy.
Để đánh giá đầu ra của hệ thống có đúng hay không, cần có tiêu chuẩn đáp án rõ ràng, tức một oracle.
Nếu AI phi định tính cũng tự ý tạo ra cả tiêu chuẩn xác minh, nó có thể sửa sai kết quả đúng hoặc làm méo mó tiêu chuẩn kiểm chứng.
Vì vậy, tiêu chuẩn xác minh cần được cấu thành bằng các công cụ mang tính quyết định nhiều nhất có thể.
- Compiler và type checker
- Kiểm thử tự động
- Linter và phân tích tĩnh
- Kiểm tra schema
- Tiêu chuẩn hiệu năng và bảo mật
- Quy trình phê duyệt và giới hạn phạm vi thay đổi
Phán đoán của AI có thể dùng như công cụ hỗ trợ, nhưng việc pass cuối cùng cần gắn với các tiêu chuẩn có thể tái lập.

13. Harness trở thành hạ tầng cốt lõi của phát triển với AI

Harness là thiết bị xác minh được bố trí theo từng bước để AI không tích lũy lỗi trong quá trình làm việc hoặc đi vượt khỏi phạm vi.
Các thành phần chính gồm có.
- Pipeline tách riêng từng giai đoạn công việc
- Định dạng vào/ra cho từng bước
- Kiểm thử tự động và phân tích tĩnh
- Các cổng xác minh dừng lại khi thất bại
- Giới hạn file và phạm vi được phép thay đổi
- Quy trình phê duyệt và review của con người
Harness ngăn lỗi nhỏ ở một bước bị khuếch đại ở các bước tiếp theo.
Năng lực tận dụng AI có thể sẽ được đánh giá không phải chỉ bằng khả năng viết prompt tốt, mà bằng khả năng ràng buộc đầu ra khó đoán vào trong một hệ thống ổn định.

Kết luận

Nhà phát triển không biến mất, mà vai trò đang dịch chuyển

AI đang nhanh chóng tự động hóa việc viết mã đơn thuần và triển khai lặp lại.
Tuy nhiên, để tạo ra kết quả ở cấp độ sản phẩm, vẫn cần các vai trò sau.
- Định nghĩa vấn đề và mục tiêu
- Thiết kế cấu trúc hệ thống
- Tách riêng các giai đoạn công việc và đầu ra
- Điều phối luồng giữa các AI agent
- Xây dựng tiêu chuẩn xác minh và harness
- Chịu trách nhiệm cuối cùng cho kết quả vận hành
Công việc của nhà phát triển nhiều khả năng sẽ thay đổi theo hướng giảm tỷ trọng trực tiếp gõ mã, và tăng tỷ trọng tổ chức, hệ thống hóa và kiểm soát mã do AI tạo ra.

Viết prompt là một dạng lập trình mới

Quá trình biến những chỉ dẫn dùng lặp lại thành skill và quy tắc rồi kết nối chúng bằng pipeline tương tự như thiết kế hàm và module.
Tài liệu Markdown có thể hoạt động như một tầng mã mới định nghĩa bối cảnh, hành vi và định dạng đầu ra của AI.
Nhà phát triển cần tài liệu hóa kinh nghiệm và các tiêu chuẩn phán đoán ngầm của mình, rồi trừu tượng hóa chúng thành dạng AI có thể tái sử dụng.
Điều này không chỉ là trừu tượng hóa hệ thống hiện có, mà còn là trừu tượng hóa chính cách làm việc và quá trình phán đoán của nhà phát triển.

Năng lực cốt lõi của nhà phát triển tương lai

Khả năng định nghĩa chính xác vấn đề
Khả năng ủy quyền công việc dựa trên mục tiêu và bối cảnh
Khả năng phân rã công việc phức tạp thành các đầu ra nhỏ
Khả năng cấu thành skill và agent thành pipeline
Khả năng thiết kế tiêu chuẩn xác minh mang tính quyết định
Khả năng xây dựng harness để kiểm soát rủi ro của kết quả phi định tính
Độ sâu kỹ thuật để hiểu kết quả do AI tạo ra và chịu trách nhiệm cuối cùng

Đánh giá tổng hợp

AI không xóa bỏ bản chất của phát triển phần mềm, mà đang thay đổi tầng trừu tượng mà nhà phát triển phải xử lý.
Nếu trước đây nhà phát triển xử lý chi tiết của mã và hệ thống, thì trong tương lai họ sẽ phải xử lý chi tiết phát sinh từ hành vi và đầu ra của AI.
Chi phí tạo mã giảm xuống, nhưng tầm quan trọng của xác minh, lắp ráp, vận hành và kiểm soát có thể còn tăng mạnh hơn.
Bản chất của lập trình viên không nằm ở việc gõ phím, mà ở khả năng phát hiện chi tiết, trừu tượng hóa chúng và cấu thành chúng thành một hệ thống đáng tin cậy.