Codex 5.5 sau 3 tuần dùng thật trong production — không hype, không anti-AI
3 tuần. Codebase ~280k LOC. Production thật, không demo, không toy project.
Bug thật, deadline thật, có một incident nhỏ do mình accept output hơi nhanh tay. Viết lại đây vì thấy phần lớn review AI tool trên mạng đang ở hai thái cực — hoặc hype quá, hoặc dismiss quá — và cả hai đều không giúp ích gì cho người đang phải quyết định có dùng không.
Bối cảnh
Fullstack 11 năm, stack chính là NestJS / React / PostgreSQL / Redis / AWS ECS. Codebase từ 2018, có phần legacy, có phần refactor dở dang, team khoảng 14 người. Không phải greenfield, không phải side project — là hệ thống đang chạy và có người dùng thật.
Mình dùng Codex 5.5 cho: debug production bug, refactor module auth cũ, thiết kế và review architecture, viết ADR, review PR trước khi gửi team.
Thay đổi lớn nhất: nó không chỉ generate code
Có 2 mode — mini cho task nhỏ nhanh, pro cho task phức tạp. Sự khác biệt rõ rệt hơn mình nghĩ ban đầu.
Nhưng điều mình không expect là nó hay hỏi ngược lại. Không phải kiểu hỏi cho có, mà hỏi đúng chỗ: traffic hiện tại bao nhiêu? Scale constraint là gì? Bottleneck có chắc ở đây không? Cái này làm workflow thay đổi hẳn — giống pair programming hơn là autocomplete.
Bug payment webhook tồn tại 2 tháng
Race condition trong webhook payment, 3 buổi debug trước đó không ra. Đưa vào Codex full module + log + context ECS multi-instance — khoảng 2 phút sau nó trace ra được và đề xuất distributed lock.
Nhưng điểm quan trọng: nó chỉ đúng vì mình đưa đủ context. Lần trước thử thiếu log, nó đoán sai — và đoán rất tự tin. Đó là điều cần nhớ.
Refactor auth từ 2019 — từ 2 sprint xuống còn 4 ngày
Module auth cũ: JWT đơn giản, không refresh rotation, session management thủ công. Estimate ban đầu là 2 sprint.
Codex đưa ra migration plan, risk breakdown, rollback strategy, rồi implement từng bước. Kết quả: 4 ngày, có refresh token rotation + revocation + audit log. Không phải "AI làm hết" — mình vẫn review từng bước, vẫn quyết định trade-off. Nhưng tốc độ khác hẳn.
Có một lần nó generate resolver GraphQL đúng logic nhưng sai naming convention của codebase — vì thiếu context về existing pattern. Sửa thêm khoảng 30 phút. Nhỏ, nhưng đủ để nhắc mình không được lười đưa context.
So sánh với Claude (Opus 4) — mình dùng song song
Không có tool nào thắng tuyệt đối.
Codex 5.5 mạnh hơn ở debug production issue, refactor lớn, multi-step execution, follow instruction chặt. Claude lại tốt hơn ở viết test sạch, documentation, giải thích code, và đặc biệt là nghĩ ra edge case.
Workflow hiện tại: Codex pro cho core logic + debug + refactor, Codex mini cho boilerplate + quick fix, Claude cho test + docs, và human vẫn phải review business logic + architecture — cái đó không delegate được.
Số liệu sau 3 tuần (ước lượng, không phải benchmark chính thức)
| Task | Trước | Sau |
|---|---|---|
| Debug medium bug | 3–6h | 1–2h |
| CRUD feature | 4–6h | 1.5–2.5h |
| PR review | 30–45m | 15–20m |
| Technical doc | 2–3h | 45–60m |
| Refactor module | 2–3 ngày | 0.5–1 ngày |
Phần thực hành — dùng thế nào để không phí thời gian
Đây là phần mình muốn viết nhất, vì hầu hết bài review AI coding dừng lại ở "hay/dở" mà không nói đến "dùng như thế nào".
1. Cách đưa context đúng
Prompt tốt không phải prompt dài. Mà là prompt có đúng thứ AI cần để không phải đoán.
Prompt tệ:
Fix race condition này
Prompt tốt:
NestJS webhook chạy trên 4 ECS instances.
Issue xảy ra khi provider retry trong <5s.
DB là PostgreSQL.
Không muốn dùng global transaction lock vì ảnh hưởng throughput.
Đã thử unique constraint nhưng fail ở edge case duplicate event.
Chỉ cần 5 dòng đó, output thay đổi hoàn toàn. Những thứ cần có trong context: system architecture, constraint production, existing pattern, what already tried, expected trade-off. Thiếu bất kỳ thứ nào, AI sẽ fill vào bằng assumption — và assumption của nó không nhất thiết khớp với reality của bạn.
2. Chia task cho mini vs pro
Không phải task nào cũng đáng dùng model mạnh. Dùng pro cho task quá nhỏ vừa tốn thời gian chờ, vừa lãng phí.
| Task | Mini | Pro |
|---|---|---|
| Rename / refactor nhỏ | ✅ | |
| Boilerplate, CRUD cơ bản | ✅ | |
| Quick fix rõ ràng | ✅ | |
| Production debug | ✅ | |
| Architecture design | ✅ | |
| Long reasoning / trade-off | ✅ | |
| ADR, docs phức tạp | ✅ | ✅ |
Rule ngắn gọn: nếu bạn có thể đoán được output trước khi hỏi → mini. Nếu bạn không chắc output trông như thế nào → pro.
3. Giảm hallucination
Đây là phần hầu hết bài review AI coding né không nói đến. Hallucination không phải lúc nào cũng lộ rõ — code nhìn đúng, chạy được, nhưng sai behavior ở edge case hoặc sai method signature của thư viện bạn đang dùng.
Checklist mình hay dùng:
- Paste existing interface/type vào context, đừng để AI tự suy
- Yêu cầu AI list assumption nó đang dùng ("list các assumption bạn đang assume")
- Hỏi "3 approach + trade-off" thay vì "best solution" — cái sau khiến AI chọn hộ bạn mà không giải thích tại sao
- Với external API / thư viện: luôn verify manually, đừng tin vào method name AI suggest nếu chưa check docs
- Với payment/auth: đặc biệt cẩn thận — hallucination ở đây không gây compile error, nó gây bug production
4. Xử lý context drift trong session dài
Sau khoảng 40–50 messages, Codex bắt đầu lệch — sai convention, bỏ qua constraint đã nói trước đó, đôi khi còn contradict chính nó. Đây là pain point thật, không phải lý thuyết.
Cách mình xử lý:
- Reset session theo milestone, không kéo một session quá dài
- Giữ một "architecture summary" ngắn (~10 dòng) và paste lại định kỳ khi session dài
- Dùng fixed structure cho mỗi prompt khi task phức tạp:
Context: [hệ thống đang làm gì]
Constraint: [giới hạn không được vi phạm]
What changed: [thay đổi gần nhất liên quan]
What failed: [đã thử gì, fail ở đâu]
What I want: [output cụ thể]
Cái structure này nhìn có vẻ dư thừa, nhưng nó là thứ giúp AI không "quên" context giữa chừng.
5. Review checklist trước khi merge AI-generated code
Với code thông thường mình review bình thường. Nhưng với auth và payment, mình có checklist riêng vì đây là chỗ hallucination gây hậu quả nặng nhất:
- Retry behavior: có idempotency không?
- Transaction boundary: đúng chưa, hay AI tự thêm/bỏ?
- Timeout: có handle không, hay chỉ happy path?
- Concurrency: có race condition mới nào không?
- Rollback path: nếu fail giữa chừng thì sao?
- Logging / auditability: đủ để debug production không?
Mình từng merge một đoạn code AI viết thiếu idempotency check trong webhook — provider retry, record duplicate, mất 2 giờ debug. Không catastrophic, nhưng đủ để học bài.
6. Dấu hiệu AI đang đi sai hướng
Cái này chỉ người dùng thật mới để ý. Khi thấy mấy dấu hiệu dưới đây, nên dừng lại và reset thay vì tiếp tục build trên output đó:
- Trả lời quá nhanh cho vấn đề phức tạp — thường là nó đang oversimplify
- Ignore constraint bạn đã nói rõ ràng trước đó
- Architecture đột nhiên inconsistent với phần trước trong cùng session
- Code "đẹp" nhưng không fit existing pattern của codebase
- Over-engineering bất thường — thêm abstraction layer không ai yêu cầu
Khi thấy mấy cái này, đừng tiếp tục prompt. Reset session, đưa lại context từ đầu.
Hạn chế thật sự
Business context: AI không biết tại sao cái legacy code kia lại tồn tại, constraint nội bộ nào không được document, hay decision history của team. Refactor mù theo suggestion của AI là rủi ro thật.
API hallucination: Code nhìn đúng, chạy được, nhưng sai method name hoặc sai behavior ở edge case. Đặc biệt nguy hiểm với payment và auth.
Context drift: Đã nói ở trên — thật, không phải lý thuyết.
Test coverage: Viết test ổn, nhưng hay thiếu concurrency issues, external service failure, fault injection. Phải tự bổ sung.
Điều mình rút ra sau 3 tuần
Không phải "AI giúp code nhanh hơn". Mà là: AI đẩy phần thinking lên trước, coding xuống sau. Bạn gõ ít hơn, nhưng phải hiểu vấn đề rõ hơn trước khi bắt đầu.
Và cái này mới là quan sát thật sự:
Dev giỏi + AI = multiplier. Dev yếu + AI = illusion of productivity.
Không phải để phán xét ai. Chỉ là thực tế mình quan sát được trong 3 tuần qua.
Anh em đang xử lý context drift trong session dài như thế nào? Có ai thử dùng system prompt cố định chưa — curious muốn biết workflow của người khác.
All Rights Reserved
