Vài năm trước, ý tưởng review nghiêm túc 15 dự án phần mềm cùng lúc nghe sẽ khá phi thực tế với tôi. Tôi không nói về việc mở 15 repository rồi nhìn lướt qua. Tôi nói về việc liên tục kiểm tra các dự án thật để tìm bug, giả định sai, vấn đề SEO, lỗi dịch, localization không nhất quán, thiếu test, regression và những đoạn code cũ không còn phù hợp với phần còn lại của hệ thống.
Giới hạn chưa bao giờ là tốc độ gõ. Đó là sự chú ý. Mỗi dự án có lịch sử, convention, edge case và những đoạn code trông có vẻ sai nhưng thực ra tồn tại có chủ đích. Một review cẩn thận cần đọc, tìm kiếm, so sánh, chạy check rồi mới quyết định điều gì thực sự nên thay đổi.
Codex đã thay đổi chi phí của phần công việc lặp lại này với tôi. Nó có thể thực hiện first pass qua repository, theo dõi reference, đọc các file liên quan, làm nổi bật pattern đáng ngờ, gợi ý test và giúp tôi điều tra những vùng trước đây phải mở thủ công từng file. Điều đó không tự động hóa quyết định cuối cùng. Nó làm phần tốn kém trước quyết định nhanh hơn rất nhiều.
Nguyên tắc quan trọng nhất tôi rút ra rất đơn giản: tôi không dùng Codex để loại mình khỏi review loop. Tôi dùng nó để mở rộng review loop của mình.
Nút thắt thật sự là sự lặp lại, không phải viết code
Khi duy trì một dự án, bạn có thể nhớ rất nhiều context. Với nhiều dự án, cách đó không scale. Những loại công việc giống nhau xuất hiện liên tục:
- tìm bug tương tự trong nhiều component;
- kiểm tra refactor có để lại call site cũ hay không;
- review test sau khi behavior thay đổi;
- tìm inconsistency trong metadata, logic ngôn ngữ, heading hoặc internal link;
- so sánh localization key và nội dung đã dịch;
- tìm error handling bị thiếu và edge case;
- kiểm tra thay đổi “nhỏ” có chạm nhiều file hơn dự kiến không;
- đọc những diff đơn giản riêng lẻ nhưng rất tốn thời gian khi cộng lại.
Không việc nào hào nhoáng. Tất cả đều quan trọng. Khi cùng một kiểu review phải lặp lại trên nhiều codebase, chi phí trở nên rất lớn.
Đây là nơi AI coding agent hữu ích nhất với tôi. Nó xử lý phần lặp lại của không gian tìm kiếm để tôi giữ sự chú ý cho judgment.
Tôi bắt đầu bằng inspect, không phải cho phép viết lại mọi thứ
Một trong những cách dễ nhất để có kết quả tệ là giao nhiệm vụ khổng lồ kiểu “review toàn bộ project và sửa mọi thứ”. Nghe hiệu quả, nhưng nó trộn discovery, ưu tiên, architecture, implementation và validation vào một task không kiểm soát.
Tôi có kết quả tốt hơn nhiều khi tách các giai đoạn.
inspect → explain findings → prioritize → change → validate → review diffĐầu tiên tôi muốn agent hiểu vùng liên quan và giải thích nó tìm thấy gì. Tôi cần path file cụ thể, code bị ảnh hưởng, lý do vì sao điều gì đó đáng ngờ và impact có thể có. Sau đó mới đến thay đổi.
Điều này quan trọng vì AI có thể sai với độ tự tin rất cao. Code trông dư thừa có thể tồn tại vì browser cũ, payment edge case, migration path hoặc business rule không thể hiểu từ một file. Inspect trước giúp tôi bắt giả định sai trước khi nó biến thành một diff khổng lồ.
Tôi coi finding là manh mối, không phải phán quyết
Một review Codex tốt không kết thúc bằng “tôi tìm thấy 17 vấn đề”. Con số gần như vô nghĩa nếu đứng một mình. Tôi cần evidence.
Với một finding thực sự actionable, tôi muốn biết:
- vấn đề ở đâu;
- vì sao nó là vấn đề;
- behavior nào có thể hỏng;
- kết luận đáng được tin đến mức nào;
- check nào có thể xác nhận hoặc bác bỏ;
- fix nhỏ nhất và an toàn là gì.
Điều này đặc biệt quan trọng với security, SEO và business logic. Agent có thể chỉ ra chỗ đáng điều tra, nhưng một lời giải thích nghe giống security report chưa phải vulnerability đã được chứng minh. Warning SEO không tự động là vấn đề ranking. Điều kiện lạ không tự động là dead code.
AI giảm chi phí tìm candidate. Verification vẫn quyết định cái gì là thật.
Validation loop khiến workflow đáng tin
Code generation là phần dễ thấy nhất của AI-assisted development, nhưng validation mới là thứ làm nó hữu ích ở production.
Sau thay đổi, tôi muốn codebase phản hồi. Tùy dự án, có thể bao gồm:
- TypeScript hoặc compiler/type checker khác;
- lint;
- unit và integration tests;
- build check;
- search có mục tiêu cho tên cũ hoặc call site;
- review thủ công final diff;
- xác minh thủ công behavior người dùng nhìn thấy.
Command cụ thể ít quan trọng hơn loop. Agent đưa ra giả định, repository trả evidence và quyết định tiếp theo dựa trên evidence đó.
Đó cũng là lý do tôi thích project strongly typed khi làm việc với AI. Tôi đã viết riêng về vì sao TypeScript hoạt động rất tốt với Codex trong software delivery thực tế: type biến nhiều giả định sai thành feedback tức thì có thể đọc bằng máy.
Một số loại review đặc biệt phù hợp với AI
Bug và regression
Agent có thể theo một value qua nhiều file, kiểm tra caller, so sánh implementation tương tự và tìm branch không nhất quán. Điều đó giúp thu hẹp nguồn của symptom. Tôi vẫn tái hiện hoặc xác minh behavior trước khi tin kết luận.
Test
AI hữu ích khi tìm behavior đã đổi nhưng test coverage chưa theo kịp, gợi ý edge case và giải thích test hiện tại thực sự bảo vệ gì. Nó cũng có thể phát hiện test chỉ xác minh implementation detail thay vì behavior thật.
SEO
Technical SEO có rất nhiều công việc consistency: metadata, language alternate, indexability, internal link, template, sitemap generation, redirect và quy ước từng page. Agent có thể so sánh các rule này trên codebase lớn nhanh hơn việc tôi tự mở từng route. Nhưng tôi luôn tách correctness kỹ thuật khỏi câu hỏi khó hơn: content có thực sự xứng đáng rank không?
Localization và bản dịch
Đây là một trong những vùng lặp lại nhất của sản phẩm đa ngôn ngữ. AI có thể so sánh key, tìm value thiếu, phát hiện ngôn ngữ sai, kiểm tra placeholder và chỉ ra locale lệch cấu trúc. Nhanh hơn rất nhiều so với đọc translation object lớn bằng tay, dù copy quan trọng vẫn cần human judgment.
Consistency sau refactor
Refactor lớn thường hỏng theo cách rất chán: một import cũ còn sót, một route vẫn dùng field name cũ, một test fixture giữ shape cũ. Repository-wide search kết hợp agent hiểu mục tiêu thay đổi rất hữu ích ở đây.
Làm việc song song chỉ hữu ích khi task độc lập
Rất hấp dẫn khi bật nhiều agent và để tất cả thay đổi mọi thứ cùng lúc. Throughput có thể tăng, nhưng conflict và giả định không tương thích cũng có thể nhân lên.
Tôi nhìn parallelism như bài toán coordination. Audit độc lập là candidate tốt: một project kiểm tra localization trong khi project khác review test, hoặc nhiều repository riêng biệt được inspect cùng lúc. Hai agent viết lại cùng architecture mà không có plan chung là chuyện khác.
Càng parallel, boundary càng quan trọng: project rõ, task rõ, definition of done rõ và result có thể review riêng.
Mục tiêu không phải tối đa số agent đang chạy. Mục tiêu là tối đa progress hữu ích và có thể verify.
Những thứ tôi không giao mù quáng
- Architecture decision: model có thể đề xuất option, nhưng trade-off dài hạn có thể phụ thuộc context ngoài repository.
- Security conclusion: finding cần verification, threat context và thường cần tool chuyên dụng.
- Business rule: code có thể nhất quán nội bộ nhưng vẫn triển khai sai behavior sản phẩm.
- Refactor phá hủy lớn: diff khổng lồ khó hiểu và dễ được approve cẩu thả.
- Production deployment: test pass không loại bỏ operational risk.
- Final review: tôi muốn biết điều gì thay đổi trước khi đặt tên mình vào đó.
Không phải AI vô dụng ở những vùng này, mà vì câu trả lời sai nhưng nghe hợp lý có thể rất đắt.
AI review không thay thế static analysis
Tôi cũng không coi Codex là thay thế cho compiler, linter, test, scanner hoặc monitoring. Những tool này có lợi thế AI không có: phạm vi hẹp, deterministic và repeatable.
Workflow mạnh nhất kết hợp chúng. Codex reasoning trên context và gợi ý chỗ cần nhìn. Static tool enforce rule chính xác. Test verify behavior. Log và monitoring cho thấy thực tế. Human review kết nối tất cả signal đó với product intent.
Không có những feedback system này, tôi sẽ tin AI ít hơn chứ không nhiều hơn.
Gain lớn nhất là phân bổ attention tốt hơn
Dễ nói “Codex tiết kiệm thời gian”, nhưng với tôi nó mô tả chưa đủ.
Resource hiếm trong software development không phải keystroke. Đó là high-quality attention. Trước AI coding agents, rất nhiều attention bị dùng cho discovery lặp lại: tìm cùng pattern, đọc file tương tự, theo reference, kiểm tra thay đổi đã lan tới mọi nơi chưa, rồi lặp audit ở repository khác.
Bây giờ tôi có thể delegate nhiều first-pass work hơn và giữ attention của mình cho những quyết định khó automate: finding có quan trọng không, fix có hợp architecture không, UX có tốt hơn không, risk có chấp nhận được không, tôi có thực sự muốn ship nó không?
Đó là lý do maintain và review nhiều project giờ có cảm giác khác. Tôi không review ít hơn. Trong nhiều trường hợp tôi review được nhiều hơn vì phần mechanical không dùng hết toàn bộ budget.
Workflow tôi tin tưởng
- Định nghĩa mục tiêu review hẹp. Bug, test, SEO, localization, refactor hoặc concern cụ thể khác.
- Cho agent inspect trước khi edit. Tôi muốn evidence và vị trí ảnh hưởng trước.
- Ưu tiên findings. Không phải vấn đề lý thuyết nào cũng đáng sửa code.
- Giữ thay đổi bounded. Diff nhỏ, coherent dễ validate hơn.
- Chạy machine checks. Typecheck, lint, test, build, search hoặc validation riêng của project.
- Đọc diff thủ công. Tìm rewrite không cần thiết, giả định sai, edge case thiếu và thay đổi ngoài scope.
- Verify behavior quan trọng. Đặc biệt users, tiền, security, SEO và production infrastructure.
- Sau đó mới sang project tiếp theo. Parallelism hữu ích nhưng uncertainty chưa giải quyết không nên lan truyền.
15 project không còn cảm giác như 15 lần lượng review
Codex không làm 15 project trở nên đơn giản và không bỏ responsibility khỏi tôi. Nó thay đổi mối quan hệ giữa scale và repetitive effort.
Tôi có thể yêu cầu first pass sâu hơn, consistency check rộng hơn, nhiều test idea hơn và audit systematic hơn mà không phải tự dành từng phút để search mỗi file. Sau đó tôi dùng attention tiết kiệm được cho những quyết định vẫn cần developer.
Đó là AI-assisted development tôi thấy có giá trị: không phải autopilot, không phải blind trust, không phải “generate code cho tới khi cái gì đó pass”. Đó là loop chặt hơn giữa inspection ở quy mô máy và judgment ở quy mô con người.
Với tôi, đó là leverage thật sự của Codex. Nó không loại bỏ review. Nó làm serious review khả thi ở scale trước đây khó duy trì hơn nhiều.