99,9% đã đủ tốt hay chưa?

Hãy tưởng tượng bạn đang ở trong một căn phòng có 70 người, có người cược với bạn rằng: “Ở đây có ít nhất hai người trùng ngày sinh.”

Bạn cược có hay không? Thắng được 1 tỷ, thua bị “cắt trym”.

Hãy thử chọn trước khi biết đáp án.

Birthday Paradox

Trò này dựa trên nghịch lý ngày sinh. Một năm có mấy trăm ngày, trong phòng mới có 70 người. Nghe thì có vẻ khó trùng lắm.

Chỗ dễ nhầm là ta hay nghĩ xem có ai trùng sinh nhật với mình không. Nhưng ở đây chỉ cần hai người bất kỳ trùng nhau là được. Không nhất thiết phải có bạn trong đó.

Theo nguyên lý Dirichlet, cứ đưa vào phòng nhiều người hơn số ngày sinh có thể có thì chắc chắn sẽ trùng. Nhưng chưa cần đông đến thế, xác suất trùng đã rất cao rồi.

Thử tính ngược lại: để cả 70 người không ai trùng ngày sinh, mỗi người bước vào phải sinh đúng một ngày mà những người trước chưa dùng tới. Càng đông, việc này càng khó.

Để tính cho gọn, giả sử ngày sinh của mỗi người độc lập và rơi đều vào 366 ngày. Người đầu chọn ngày nào cũng được. Người thứ hai còn 365 ngày, người thứ ba còn 364 ngày. Cứ thế, nếu chưa ai trùng nhau thì người thứ 70 còn 297 ngày.

Nhân lại là ra xác suất cả phòng không có ai trùng ngày sinh:

P(không trùng) = 1 × (365/366) × (364/366) × … × (297/366) ≈ 0,0858%

Lấy 100% - 0,0858% = 99,9142%, đó là xác suất bạn thắng khi chọn “có”. Thậm chí với 50 người, xác suất thắng đã rất cao:

Với xác suất này, tôi đoán nhiều người sẽ liều lấy 1 tỷ. Nhưng 99,9% vẫn chưa phải 100%. Lỡ rơi đúng vào phần còn lại thì cũng không thể xin tính lại vì “xác suất thấp quá”.

Muốn chắc chắn thì phải đợi đủ 367 người. Vì còn ngày 29/2 nữa, nên có tới 366 ngày sinh có thể xuất hiện. Đến người thứ 367 mới hết chỗ để tránh nhau.

Từ 70 lên 367, ta phải đưa thêm gần 300 người vào phòng chỉ để loại bỏ chưa tới 0,1% khả năng thua còn lại. Phần còn thiếu thì nhỏ, nhưng để làm cho đủ lại chẳng nhẹ nhàng.

Đó là sự khác biệt giữa đủ tự tin để hành động và đủ điều kiện để kết luận chắc chắn.

Nếu đây là ngày phát hành

Giờ thay căn phòng bằng một sản phẩm sắp ra mắt. Người dùng đăng ký được, làm xong việc họ cần làm, dữ liệu lưu đúng chỗ. Những lỗi nghiêm trọng đã xử lý. Nhìn chung là chạy ổn.

Chỉ còn vài việc: một số trường hợp biên chưa thử, thông báo lỗi còn khó hiểu, luồng khôi phục cần kiểm tra lại, tài liệu vận hành chưa viết xong.

Đến đây thì câu quen thuộc xuất hiện: hay cứ ra mắt trước rồi tính tiếp?

Tôi tạm gọi đó là mốc “70”: đã có đủ cơ sở để cho một nhóm người dùng vào dùng thử, theo dõi và xử lý nếu có vấn đề. Còn “367” là làm xong và kiểm tra hết những gì mình đã hứa cho phiên bản này. Mượn con số để nói chuyện thôi, chứ phần mềm không có công thức chạy đủ bao nhiêu test là hết bug.

Nhưng cái danh sách “còn vài việc” ấy phải đọc kỹ. Thiếu một bộ lọc nâng cao mà chưa ai đòi thì có thể để sau. Chưa kiểm tra xem tài khoản A có đọc được dữ liệu của tài khoản B không thì phải làm trước đã. Giao diện đẹp đến mấy cũng không giải quyết được chuyện đó.

Cùng được gọi là “chưa hoàn thiện”, nhưng hậu quả khác nhau khá xa.

Tôi từng chọn hoàn thành hơn hoàn hảo

Năm 2017, tôi viết bài Hoàn thành thì tốt hơn là hoàn hảo , kể chuyện loay hoay với công cụ và quy trình mới trong khi một website vẫn đang chờ được làm xong.

Đến giờ tôi vẫn thấy câu ấy đúng. Một sản phẩm nằm mãi trên máy của lập trình viên có thể ngày càng đẹp, code ngày càng sạch, nhưng vẫn chưa biết có ai cần dùng không.

Có những chuyện phải đưa ra ngoài mới biết: người dùng có hiểu không, có quay lại không, cái tính năng mình dành cả tuần để làm có ai buồn bấm vào không. Ngồi viết thêm code không trả lời được những câu ấy.

Trước khi có các công cụ AI như bây giờ, chọn dừng ở “70” cũng dễ hiểu. Để tới “367”, vẫn phải có người ngồi viết test, tạo dữ liệu lỗi, thử từng quyền truy cập, tập triển khai lại và ghi cách khôi phục. Đội thì nhỏ, việc thì nhiều. Muốn làm kỹ hơn là một chuyện, có đủ thời gian và tiền để làm hay không lại là chuyện khác.

Vậy nên ra mắt sớm có thể là một lựa chọn hợp lý. Phạm vi nhỏ, nhóm dùng thử rõ ràng, có theo dõi và có đường quay lui. Chỉ cần nhớ rằng những việc để sau vẫn còn đó. Bấm deploy không tự đánh dấu xong chúng trong backlog.

Điều tôi muốn xem lại hôm nay là chi phí của việc đi tiếp. Chúng ta đã có thêm công cụ, vậy có cần dừng đúng chỗ ngày xưa vẫn dừng không?

AI có thể làm đoạn đường còn lại rẻ hơn

Nói đến AI viết phần mềm, người ta hay khoe làm demo nhanh thế nào. Bao nhiêu phút có giao diện, có API, có database, có link để gửi cho bạn bè xem.

Tôi lại muốn dùng nó nhiều hơn ở đoạn sau đó. Đọc lại yêu cầu, tìm chỗ làm thiếu, viết test, thử dữ liệu bẩn, chạy luồng lỗi, sửa xong rồi chạy lại. Toàn việc ít có gì để chụp màn hình khoe, nhưng bỏ qua thì người dùng sẽ tìm ra hộ.

Ví dụ, có một lỗi vừa sửa xong. Tôi muốn agent viết test tái hiện nó, kiểm tra rằng bản cũ thất bại và bản sửa chạy đúng. Có một luồng phân quyền, tôi muốn thử cả tài khoản được phép lẫn tài khoản không được phép. Có một bước ghi dữ liệu, tôi muốn biết chuyện gì xảy ra nếu mất kết nối giữa chừng.

Những việc này vẫn cần người xác định thế nào là đúng. Nhưng phần tạo dữ liệu, viết và chạy kiểm thử, sửa rồi thử lại có thể giao cho agent làm trong môi trường đã chuẩn bị. Người kỹ sư vẫn phải xem kết quả, chỉ là không nhất thiết tự gõ từng dòng.

Anthropic cũng mô tả cách làm gần như vậy: chia yêu cầu thành những phần kiểm tra được, làm từng phần, lưu lại trạng thái và kiểm tra hành vi thực tế. Giao một yêu cầu lớn, mơ hồ thì agent vẫn có thể báo xong quá sớm. Đọc đến đoạn này chắc nhiều người dùng AI thấy quen. Effective harnesses for long-running agents

Rẻ hơn bao nhiêu còn tùy dự án. Thời gian review, sửa yêu cầu và kiểm tra lại vẫn phải tính. Nhưng nếu trước đây mất nhiều ngày làm tay, còn bây giờ agent có thể gánh một phần đáng kể, thì lý do “thôi để sau, làm lâu lắm” cũng nên được xem lại.

Công cụ đã khác rồi, chi phí để làm nốt có thể cũng khác.

Muốn tới 367, trước hết phải biết mình đang đếm gì

Giao cho AI một câu “làm cho hoàn hảo đi” thì có khi nó sửa đến lúc hết tiền vẫn chưa xong. Luôn còn một tính năng để thêm, một thư viện để thay, một lớp trừu tượng để viết lại. Backlog khá giỏi trong việc tự sinh sản.

Muốn tới “367”, trước hết phải chốt xem phiên bản này hứa làm những gì.

Ví dụ, tôi chỉ cần một công cụ nhập danh sách công việc từ file CSV UTF-8. Các cột đã quy định sẵn, số dòng có giới hạn. Chưa cần hỗ trợ file Excel, đồng bộ hai chiều hay tự đoán mọi kiểu ngày tháng trên đời.

Ít tính năng như vậy, nhưng những việc đã nhận làm thì cần làm cho đến nơi:

• File đúng thì nhập đúng dữ liệu, vào đúng tài khoản.
• File thiếu cột hoặc sai dữ liệu thì báo rõ để người dùng sửa.
• Bấm gửi lại cùng một yêu cầu thì không tự dưng có hai bản dữ liệu.
• File quá lớn, mất kết nối hoặc ghi dữ liệu thất bại thì có cách xử lý rõ ràng, không để lại một nửa kết quả rồi coi như xong.

Tôi quyết định các quy tắc đó trước. Sau đó mới giao AI viết phần còn thiếu, tạo dữ liệu để thử và chạy kiểm tra từng điều. Kết quả phải xem được, chạy lại được.

Một phiên bản ít tính năng vẫn có thể hoàn thành trọn vẹn lời hứa của nó. Đó là “367” mà tôi muốn nói tới: hứa ít lại cho rõ, rồi làm đủ những gì đã hứa.

Tất nhiên, như vậy chưa chứng minh được cả hệ thống không còn lỗi nào. Nhưng ít nhất ta biết đã kiểm tra những gì, thay vì thấy demo chạy được một lần rồi gọi luôn là production.

Có thể tiến xa hơn cả việc sinh thêm test

Khi yêu cầu của phần mềm được mô tả bằng ngôn ngữ toán học, AI còn có thể giúp chứng minh rằng phần mềm làm đúng những yêu cầu đó.

Trong một nghiên cứu đưa lên arXiv tháng 7/2026, AI được giao viết các chứng minh toán học để kiểm tra tính đúng đắn của phần mềm. Viết xong, AI phải đưa chứng minh đó qua một công cụ chuyên dụng để kiểm tra lại. Nhóm tác giả báo cáo AI đã giải được toàn bộ các bài toán chứng minh trong thử nghiệm của họ. Kết quả ấy chưa có nghĩa là đưa phần mềm nào cho AI cũng chứng minh được nó hết lỗi. Harnessing Code Agents for Automatic Software Verification

Phần tôi thấy đáng quan tâm là: AI đưa ra lời giải, còn việc lời giải có đúng hay không phải qua một bộ kiểm tra. Nó không được tự chấm điểm cho mình.

Phần lớn ứng dụng không cần đưa toàn bộ code vào công cụ chứng minh toán học. Nhưng cách nghĩ này vẫn dùng được: nói rõ điều gì phải đúng, chọn cách kiểm tra đủ độc lập, rồi để AI làm phần việc tốn công.

AI viết code rồi tự khen code của mình chưa đưa ta tới 367. Vẫn phải chạy, phải kiểm tra, và phải có người chịu trách nhiệm với kết quả.

Vậy khi nào nên dừng ở 70?

Tôi vẫn sẽ ra mắt sớm nếu điều cần biết nhất chỉ có người dùng thật mới trả lời được.

Chưa biết có ai cần tính năng này mà ngồi đánh bóng thêm mấy tuần thì chưa chắc đã khôn hơn. Một bản beta nhỏ, giới hạn rõ và đủ điều kiện vận hành có thể cho ta biết nhiều hơn.

Có AI cũng không có nghĩa là ý tưởng nào vừa nghĩ ra cũng phải nhét vào phiên bản đầu. Nó làm nhanh hơn, nhưng người quyết định có nên làm vẫn là mình.

Còn nếu phần thiếu đã rõ, biết cách kiểm tra và nằm trong những gì đã hứa với người dùng, tôi sẽ tính lại xem làm nốt có tốn như mình nghĩ không. Có khi với công cụ hiện tại, thêm một vòng làm việc là xong phần trước đây phải để sang tháng sau.

Trước khi bấm deploy, tôi muốn trả lời ba câu:

1. Phần còn lại cần người dùng trả lời, hay chỉ cần mình ngồi xuống làm cho xong?
2. Để nó sang phiên bản sau thì ai chịu hậu quả, và có khôi phục được không?
3. Với công cụ hiện có, làm nốt và kiểm tra lại thực sự tốn bao nhiêu công?

Trả lời xong, có thể tôi vẫn ra mắt ở 70. Cũng có thể tôi làm tiếp. Nhưng ít nhất đó là quyết định dựa trên tình hình hiện tại, chứ không phải vì lần trước cũng làm thế.

Đừng dùng năng suất mới với tiêu chuẩn dừng cũ

Tôi vẫn muốn ra mắt sớm để biết mình có đang làm thứ người ta cần không. Tôi cũng muốn những gì đã hứa thì làm cho tử tế. Có AI, tôi nghĩ mình có thêm cơ hội làm được cả hai, nếu dành một phần thời gian tiết kiệm được cho kiểm tra và hoàn thiện.

Thu nhỏ phạm vi phát hành. Giữ đầy đủ trách nhiệm với phạm vi đó. Dùng AI để làm nốt những việc trước đây mình thường phải để sau.

Ra mắt ở 70 vẫn có thể đúng. Nhưng nếu AI đã giúp mốc 367 của phiên bản này trở nên khả thi, “đủ tốt rồi” cần một lý do tốt hơn việc ta đã quen dừng ở đó.

Trên đời này chẳng có gì hoàn hảo, phần mềm cũng vậy. Ta chỉ có thể hướng tới nó, và AI giúp ta có cơ hội đến gần hơn. Hoàn thành vẫn tốt hơn hoàn hảo. Chỉ là bây giờ, chúng ta có thêm công cụ để làm cho cái “hoàn thành” ấy tốt hơn trước.