Review từng dòng code AI là một sai lầm

1. Ai cũng đã phát ngán với việc review code AI

Philipp Lackner mở đầu: theo anh (video đăng ngày 14/10/2026), ai cũng đã phát ngán với việc phải review quá nhiều code do AI viết. Chắc bạn cũng biết kiểu pull request (PR) mà vừa mở ra là biết ngay: "ok, lại thêm một PR do AI sinh ra". Lý do là giờ ai cũng code theo cách đó, và theo anh chuyện này cũng sẽ không thay đổi nữa. Nhưng nó mệt kinh khủng.

Anh kể cụ thể cái mệt đó gồm những gì: phải đọc qua hàng loạt doc comment dài dằng dặc, rồi những thay đổi trong chính các doc comment ấy, phải đọc từng implementation cụ thể của các test case, rồi lại thêm doc comment, đủ thứ khác nữa. Có quá nhiều thứ phải review. Và theo anh (video đăng ngày 14/10/2026), kể cả khi đó là code do người viết, thì chỉ riêng khối lượng code mới mà bạn phải review ngày nay cũng đã khiến toàn bộ công việc này kém thú vị đi rất nhiều.

Ít nhất là với anh (theo video đăng ngày 14/10/2026), việc phải review quá nhiều code là thứ chính lấy đi niềm vui trong công việc. Anh nói cũng có một phần là vì giờ mình tự suy nghĩ ít hơn một chút, không còn phải tự nghĩ ra nhiều lời giải nữa. Nhưng phần chính vẫn là tất cả những gì thuộc về việc review lại những thứ AI đã làm.

Ít nhất là anh và team của anh đã thay đổi hoàn toàn hướng đi trong cách xử lý review nội bộ (theo video đăng ngày 14/10/2026). Trước khi vào điều anh thật sự muốn nói trong video, anh đưa ra một lưu ý và disclaimer rất quan trọng.

2. Lưu ý trước: chuyện này dành cho phần mềm bình thường

Những gì anh nói tiếp theo áp dụng cho phần mềm trung bình, cho một app trung bình. Theo Philipp (video đăng ngày 14/10/2026), chắc chắn có những ngành và những phần mềm, như trong hàng không vũ trụ (aerospace) hay ngân hàng (banking), nơi việc review thủ công từng dòng vẫn là không thể tránh, và vẫn nên làm.

Lý do anh đưa ra (video đăng ngày 14/10/2026): trong một số ngành, quản trị rủi ro (risk management) được ưu tiên cao hơn nhiều so với chỉ riêng lượng code làm ra, cao hơn tiến độ. Còn điều anh nói ở đây thật sự chỉ dành cho phần mềm trung bình điển hình, nơi một con bug không quyết định chuyện hàng nghìn người dùng mất tiền hay đại loại thế.

3. Review từng dòng không scale được

Rốt cuộc, anh và team đi tới kết luận rằng review từng dòng (line-by-line review) không scale được (theo video đăng ngày 14/10/2026). Review, chẳng hạn, 5.000 dòng code mỗi ngày, vì lượng output bây giờ quá nhiều, thì quá mệt. Và theo anh, khi một việc gì đó làm bạn mệt, khi bạn đã phát ngán với nó, thì bạn cũng sẽ không làm nó tốt được. Anh khá chắc là bạn hiểu cảm giác này nếu bạn đang review những PR kiểu như thế.

Nhân tiện, anh nói PR đang mở trên màn hình vẫn còn là một PR khá modular: theo lời anh (video đăng ngày 14/10/2026), nó có khoảng 112 dòng thay đổi, tức dòng thêm vào. Nhưng ngày nay, những PR 300, 400 dòng lại có cảm giác là ngắn.

Trước thời AI, theo anh, mức đó về cơ bản là giới hạn của một PR còn chấp nhận được. Giờ thì mức chuẩn đó đã thay đổi. Nên rất có thể bạn cũng đang review những PR 1.000 dòng. Và theo Philipp (video đăng ngày 14/10/2026), ngày nay không thể nào review những PR như vậy cho tốt được.

4. AI fatigue: mệt thì review không kỹ

Lý do, theo Philipp (video đăng ngày 14/10/2026), là AI fatigue có thật. Nó thật sự rất mệt. Và khi một việc làm bạn mệt, bạn sẽ không làm nó tốt được. Anh bảo người xem hãy thật lòng: nhiều khả năng bạn sẽ không review một PR chi tiết như bạn từng làm ngày trước, cái thời PR nhỏ hơn, mọi thứ ít code hơn, toàn là code người viết. Còn bây giờ, bạn có cảm giác: thôi, mình chỉ lướt qua (skim) cái này thôi.

Thêm vào đó, theo anh (video đăng ngày 14/10/2026), việc này chán kinh khủng. Mà khi một việc chán kinh khủng, thì bạn cũng sẽ không làm nó tốt bằng lúc nó còn thú vị. Vậy là một mặt, bạn đầu tư rất nhiều thời gian cho những lượt review từng dòng; mặt khác, bạn lại không thu được bao nhiêu từ chúng. Và bạn bắt đầu ngày càng ghét công việc của mình hơn. Anh nghĩ mọi chuyện không nên như vậy.

5. Tăng tốc nằm ở review, không phải bỏ review

Điều anh và team vừa nhận ra (theo video đăng ngày 14/10/2026) là trong cả thế giới agentic development này, mức tăng tốc lớn nhất đến từ việc làm cho khâu review nhanh hơn. Anh nhấn mạnh: anh không nói bỏ review. Anh chỉ nói bỏ kiểu review từng dòng, nơi bạn đi qua từng dòng một trong PR, trong các file spec, trong tài liệu, trong code implementation thật. Theo anh, cách đó không scale.

Cả làn sóng AI này lẽ ra phải giúp chúng ta làm việc hiệu quả hơn. Nhưng theo Philipp (video đăng ngày 14/10/2026), nếu sau đó ta dành hết thời gian để đọc lại từng dòng, thì ta cũng chẳng thật sự hiệu quả hơn. Anh bảo người xem thử hình dung toàn bộ khâu code review biến mất: bạn sẽ làm được bao nhiêu? Bạn có thể đẩy thay đổi ra suốt cả ngày theo đúng nghĩa đen, và có lẽ công việc cũng sẽ lại thú vị hơn.

Anh nói rõ một lần nữa: anh không bảo làm thế. Anh không bảo bỏ toàn bộ review, cũng không bảo bỏ mọi khâu kiểm chứng (verification). Nhưng rốt cuộc, theo anh (video đăng ngày 14/10/2026), điều bạn cần làm là xây những hệ thống verification thật vững, "chống đạn" (bulletproof). Bạn cần tập trung hơn nhiều vào verification, vào việc đảm bảo và thật sự chứng minh được code chạy đúng mà không cần một lượt review thủ công. Và đó chính là thử thách.

6. Đầu tư vào hạ tầng verification

Vì vậy, theo Philipp (video đăng ngày 14/10/2026), bạn cần bỏ thời gian và đầu tư nó vào hạ tầng verification (verification infrastructure) của mình. Ví dụ, rất đáng công nếu bạn dành thời gian suy nghĩ xem nên viết những loại test case nào, thay vì phó mặc hoàn toàn cho AI. Lý do anh đưa ra: AI thích chỉ chứng minh rằng code của chính nó, cái implementation đã có sẵn, là đúng. Còn một bộ test (test suite) thật tốt và ổn định, mà ít nhất ở tầng high level do một người thiết kế (architect), thì theo anh sẽ sinh lời về sau.

Anh nói rõ anh đang nói tới một bộ test rất đầy đủ: unit test, integration test, end-to-end test. Bạn cần đo test coverage. Bạn cần phân tích code của mình, quét nó để tìm các vi phạm convention, bug, vấn đề. Anh cũng nêu một ví dụ mà anh không chắc bạn có làm được không: performance reporting, chẳng hạn quy định thời gian khởi động (startup time) phải dưới một số mili giây nhất định. Theo anh (video đăng ngày 14/10/2026), tất cả những thứ đó bạn đều đo được và thật sự đưa được vào workflow của mình, và tất cả đều độc lập với việc người review.

Theo anh, bạn thật sự muốn "tấn công" code, tấn công app của mình từ đủ mọi góc để xem chỗ nào sai. Nhìn chung, theo anh, bạn muốn để agent làm việc lâu hơn một chút, trong khi giảm tối đa thời gian bạn phải tự đi qua mọi thứ. Đổi lại, khi agent báo đã xong, khả năng nó thật sự xong và code ở trạng thái rất tốt cũng cao nhất có thể (theo Philipp, video đăng ngày 14/10/2026).

Anh không nói nó sẽ luôn hoàn hảo. Tất nhiên vẫn sẽ có những thay đổi bạn phải tự làm. Nhưng theo anh (video đăng ngày 14/10/2026), bạn có thể tối đa hoá khả năng đó. Rồi anh chuyển sang câu hỏi: vậy anh và team đã thật sự thay đổi quy trình review như thế nào?

7. Agentic review cho mọi dòng code, người review thì được phép lướt

Trước hết, theo Philipp (video đăng ngày 14/10/2026), với mọi dòng code được viết ra, luôn phải có một lượt agentic review: một loại agent nào đó, những agent chuyên biệt đi qua mọi thứ, tìm bug, tìm các vấn đề về hành vi (behavioral issue). Lý do anh đưa ra là rốt cuộc việc đó vẫn rẻ, vì không cần một người phải làm.

Anh cũng nói rõ anh không bảo bạn bỏ hẳn review pull request. Theo anh (video đăng ngày 14/10/2026), bạn vẫn nên review PR, vẫn nên làm việc với pull request, và vẫn nên giữ chúng modular. Nhưng lướt qua chúng là được, và anh coi đây là một tư duy (mindset) quan trọng cần có.

Theo anh, thỉnh thoảng có một con bug lọt qua chỗ này chỗ kia cũng không sao. Hồi người review thì chuyện đó cũng xảy ra: phần mềm của bạn hồi đó cũng có bug. Thay vào đó, theo Philipp (video đăng ngày 14/10/2026), bạn muốn tập trung nhiều hơn hẳn vào việc review đúng thứ.

8. Review đúng thứ: các quyết định ở tầng cao

Vậy đâu là những thứ đúng để review? Theo Philipp (video đăng ngày 14/10/2026), chắc chắn đó là các quyết định ở tầng cao. Anh liệt kê những câu hỏi mà anh và team đặt ra:

• PR này thay đổi architecture tổng thể như thế nào? (theo video đăng ngày 14/10/2026)
• Code có dễ mở rộng (extendable) không? (theo video đăng ngày 14/10/2026)
• Có quyết định quan trọng nào ở tầng system design không, loại thật sự làm nền móng cho mọi thứ được xây lên trên nó về sau? (theo video đăng ngày 14/10/2026)
• Có những class nào, và các class đó được nối (wire) với nhau ra sao? (theo video đăng ngày 14/10/2026)
• Các thực hành kiến trúc phổ biến có được đáp ứng không? (theo video đăng ngày 14/10/2026)
• Caching strategy được implement thế nào? (theo video đăng ngày 14/10/2026)
• Có tuân theo nguyên tắc single source of truth không? (theo video đăng ngày 14/10/2026)

Anh nói đó chỉ là vài ví dụ về những gì anh và team tập trung vào khi review (theo video đăng ngày 14/10/2026).

9. Phần vẫn phải đọc từng dòng: tiền, dữ liệu người dùng, bảo mật

Theo Philipp (video đăng ngày 14/10/2026), review từng dòng vẫn nên có, nhưng chỉ dành cho code chạm tới tiền, dữ liệu người dùng hoặc bảo mật. Anh đưa từng ví dụ:

• Các thuật toán mã hoá (cryptographic algorithm) mà bạn tự implement theo cách nào đó thì chắc chắn phải có người review từng dòng, rất cẩn thận (theo video đăng ngày 14/10/2026).
• Nếu có logic thanh toán (payment logic), chắc chắn phải review (theo video đăng ngày 14/10/2026).
• Nếu có logic liên quan tới những quy định (regulation) quan trọng mà công ty bạn phải tuân thủ, hãy review từng dòng (theo video đăng ngày 14/10/2026).
• Nếu có logic về dữ liệu người dùng, nơi dữ liệu người dùng được lưu, dữ liệu nhạy cảm như mật khẩu, email hay bất cứ thứ gì, hãy review từng dòng (theo video đăng ngày 14/10/2026).

Nhưng mọi thứ còn lại, theo anh (video đăng ngày 14/10/2026), bạn không cần review từng dòng.

10. Những thứ Philipp không review từng dòng nữa

Đặc biệt là các UI component chẳng hạn. Philipp nói anh không review UI component nữa (theo video đăng ngày 14/10/2026). Anh có các preview của mình, anh biết chúng trông ra sao, anh biết chúng có trông đúng như mong muốn hay không.

Anh cũng không review implementation của các test case nữa, tức là không xem nội dung bên trong từng test có thật sự hợp lý hay không (theo video đăng ngày 14/10/2026). Thứ anh review là có những loại test case nào, và các test case đó đã đủ chưa, có hợp lý không; còn một test được implement chính xác ra sao thì không.

Theo anh (video đăng ngày 14/10/2026), số lượng test case được viết ra bây giờ lớn tới mức, và thật ra phần lớn trong số đó khá chắc chắn, nhất là nếu bạn làm việc với skill, nếu bạn tự mình hiểu về testing và biết phải nhìn vào đâu.

Anh cũng không thật sự nhìn vào chi tiết implementation cụ thể của một thuật toán business logic nào đó, vì phần đó đã được test case bao phủ rất tốt (theo video đăng ngày 14/10/2026). Nói lại lần nữa, anh tập trung vào phía verification chứ không phải phía implementation.

Và đúng là có thể có một edge case lọt qua chỗ này chỗ kia. Nhưng theo Philipp (video đăng ngày 14/10/2026), một lần nữa, chuyện đó ổn với hầu hết trường hợp. Khi bạn phát hiện ra, bạn chỉ việc thêm một test case cho nó, sửa bug, rồi đi tiếp.

11. Chỉ lướt qua phần lớn PR, và framework verification riêng

Theo Philipp (video đăng ngày 14/10/2026), ít nhất 50, 60% những PR như vậy anh thật sự chỉ lướt qua. Anh nói việc đó hoàn toàn ổn, và nó chưa hề phản tác dụng với anh và team. Anh và team đã đầu tư rất nhiều vào hạ tầng verification, và thật ra đã tự xây một verification framework riêng cho Android development, tên là Prism.

Theo anh (video đăng ngày 14/10/2026), chỉ với những mẹo trong video này thôi, bạn cũng đã tăng tốc khâu review của mình được ít nhất 50, 60%. Và nhìn chung, việc có thêm khoảng 50, 60% thời gian để build, đó mới là thứ khiến bạn làm việc hiệu quả hơn với agent.

Nhưng theo anh (video đăng ngày 14/10/2026), riêng việc bạn bám vào agent không làm bạn nhanh hơn. Thứ làm bạn nhanh hơn là dùng chúng đúng cách, và chấp nhận rằng không phải dòng code nào cũng cần một người đọc nữa.

12. Codebase cho AI đọc, không phải cho người đọc

Philipp kể thêm (video đăng ngày 14/10/2026): anh cũng không còn sửa AI nữa khi có một tên biến anh không đồng ý, kiểu một cái tên đã đủ mô tả nhưng có thể mô tả rõ hơn chừng 10%. Anh không sửa. Anh chấp nhận nó.

Theo anh (video đăng ngày 14/10/2026), xu hướng đang dịch chuyển khỏi những codebase được tối ưu để con người hiểu và đọc qua, sang những codebase chỉ được tối ưu để AI hiểu và thay đổi. Dù chuyện đó có hay hay không, theo anh đó thật sự chỉ là xu hướng anh đang thấy mọi thứ đi tới.

Anh nói mình cũng có cảm xúc lẫn lộn về chuyện này, nhưng theo anh (video đăng ngày 14/10/2026), ta không thay đổi được những gì đang diễn ra. Ta phải chấp nhận nó. Ta phải thích nghi. Và đây là một khía cạnh quan trọng trong cách anh và team đang thích nghi với tất cả những xu hướng này.

Anh cảm ơn mọi người đã xem và chúc mọi người phần còn lại của tuần thật tuyệt.