Cách tôi đang dùng AI để code: để ChatGPT nghĩ, để Codex làm
Tôi đang dùng AI theo một workflow khá đơn giản:
- Dùng ChatGPT + GitHub connector để đọc repo, docs, source code.
- Mọi thứ liên quan đến brainstorm, debate, phân tích hướng đi, audit kiến trúc thì làm trong ChatGPT.
- Khi mọi thứ đã rõ ràng, tôi yêu cầu ChatGPT generate một prompt thật chi tiết.
- Sau đó lấy prompt đó đưa cho Codex implement.
Nghe hơi vòng vo, nhưng với tôi đây là cách dùng AI tiết kiệm quota, tiết kiệm não, và quan trọng hơn: giảm khả năng AI tự bốc thuốc rồi bôi vào codebase như bôi dầu gió lên server production.
Vấn đề: AI code tốt, nhưng AI cũng rất thích “tự tin xạo”
AI coding agent bây giờ khá mạnh. Codex được OpenAI mô tả là coding agent cho software development, có thể giúp viết code, review, debug và làm việc qua nhiều interface như IDE, CLI, web/mobile hoặc CI/CD. OpenAI cũng từng giới thiệu Codex như một agent có thể viết feature, trả lời câu hỏi về codebase, fix bug và đề xuất pull request để review. Nguồn: OpenAI Codex, OpenAI Introducing Codex
Nhưng mạnh không có nghĩa là nên thả rông.
Cái nguy hiểm của AI không phải là nó ngu. Cái nguy hiểm là nhiều lúc nó ngu nhưng nói rất mượt. Nó có thể nhìn thiếu context, hiểu sai convention, đoán file path, tự tạo abstraction, tự rename, tự refactor nhẹ nhẹ, rồi cuối cùng để lại một đống code nhìn như có kiến trúc nhưng thật ra là nghĩa địa pattern.
Nói bậy bạ một chút: AI mà không có scope rõ thì giống junior uống 3 lon bò húc, đọc nửa bài Clean Architecture, xong đòi refactor cả monolith lúc 2 giờ sáng.
Không phải lúc nào cũng thảm họa. Nhưng đủ nhiều để tôi không muốn đánh bạc.
Vì sao tôi không brainstorm trực tiếp trong Codex?
Vì brainstorm rất tốn.
Tốn token, tốn quota, tốn context, tốn lượt qua lại. Một vấn đề kỹ thuật tử tế thường không chỉ là “implement A”. Nó sẽ có đủ thứ:
- Có nên làm không?
- Làm ở layer nào?
- Có đụng architecture hiện tại không?
- Có conflict với convention cũ không?
- Cần test kiểu gì?
- Có cần update docs không?
- Có over-engineering không?
- Có đang chữa cháy bằng design pattern không?
Nếu ném hết mớ này cho Codex rồi ngồi chat qua lại trong đó, thì Codex vừa phải làm architect, vừa làm reviewer, vừa làm dev, vừa làm thầy bói. Kết quả có thể vẫn chạy, nhưng chi phí context và rủi ro tự suy diễn tăng lên.
Với tôi, Codex nên là người thi công. Còn phần cãi nhau, bóc tách vấn đề, chửi nhẹ architecture, lật đi lật lại design thì để ChatGPT xử lý trước.
Workflow hiện tại của tôi
Tôi chia AI thành hai vai:
ChatGPT = nơi suy nghĩ, debate, audit, chốt solution.
Codex = nơi implement theo prompt đã rõ.
Quy trình thường là:
- Tôi mở project tương ứng trong ChatGPT.
- ChatGPT đã có project instruction riêng cho repo hoặc nhóm repo đó.
- Tôi dùng GitHub connector để ChatGPT đọc source/docs nếu cần.
- Tôi hỏi, phản biện, bắt nó audit, so sánh, đề xuất hướng làm.
- Khi solution đã rõ, tôi yêu cầu nó generate prompt cho Codex.
- Prompt đó phải mô tả rõ scope, context, rule, file cần kiểm tra, test cần chạy, report cần trả về.
- Codex nhận prompt và implement.
- Codex phải inspect source thật trước khi sửa, không được làm mù theo prompt.
Điểm quan trọng nhất nằm ở bước cuối: prompt không phải chân lý tuyệt đối; source thật mới là chân lý.
ChatGPT có thể đọc repo qua GitHub connector. Theo tài liệu OpenAI, GitHub connector cho phép ChatGPT lấy dữ liệu từ repository như code, README và docs để phân tích dựa trên codebase. Nguồn: OpenAI Help – Connecting GitHub to ChatGPT
Nhưng dù vậy, tôi vẫn bắt Codex kiểm tra lại source thật. Vì repo có thể đổi. Branch có thể lệch. File có thể khác. Prompt có thể đúng về ý tưởng nhưng sai về implementation detail.
AI cũng như con người thôi: nghe briefing xong vẫn phải mở source ra xem. Không ai được phép phẫu thuật production chỉ vì “nghe kể bệnh nhân đau bụng”.
Vai trò của ChatGPT Projects
Tôi cũng dùng ChatGPT Projects để define instruction riêng cho từng project.
Ví dụ một project có thể có rule riêng:
- Architecture flow phải là Request → Controller → FormRequest → Service → Repository → Model.
- Không để business logic trong controller.
- Không hard-code domain value nếu có thể dùng enum/const.
- Feature test không mock internal service bừa bãi.
- Codex gặp unclear/conflict/missing thì phải stop hỏi, không tự assume.
- Implement xong phải report file changed, what/why/how, test result.
Theo OpenAI, Projects trong ChatGPT giúp gom chats, files và instructions vào một chỗ để giữ context ổn định hơn cho ongoing work. Nguồn: OpenAI Help – Projects in ChatGPT
Cái này khá hợp với coding project. Vì mỗi repo thường có luật riêng. Nếu cứ nhắc lại từ đầu mỗi lần thì vừa mệt vừa dễ sót.
Nói hơi bẩn một chút: không có project instruction thì mỗi lần chat giống như hẹn hò lại từ đầu với một người mất trí nhớ. Lần nào cũng phải giới thiệu: “anh là ai, repo này là gì, architecture nhà mình không chơi fat controller nhé em”. Rất mất hứng.
Vì sao cách này tiết kiệm quota?
Vì phần tốn nhất không phải lúc AI gõ code.
Phần tốn nhất là lúc mình chưa biết rõ mình muốn gì.
Đó là giai đoạn:
- nghĩ hướng A hay B;
- đập bỏ hay update nhẹ;
- dùng adapter hay strategy;
- test feature hay unit;
- có cần docs không;
- có conflict với standard cũ không;
- có đang over-engineering không.
Giai đoạn này mà đem vào Codex thì phí. Codex nên nhận việc khi việc đã rõ. Còn nếu việc chưa rõ, tôi dùng ChatGPT để debate trước.
Với tôi, đây là chia việc:
- ChatGPT: nghĩ, debate, phản biện, audit, viết prompt.
- Codex: inspect source, implement, chạy test, report.
Cái này không đảm bảo đúng tuyệt đối. Nhưng nó giúp tôi kiểm soát workflow tốt hơn.
Prompt cho Codex phải đủ cứng
Tôi không thích prompt kiểu:
Implement logging service.
Prompt như vậy quá mơ hồ. AI gặp prompt này rất dễ tự thiết kế cả cái vũ trụ logging, xong cuối cùng cái mình cần chỉ là thay console adapter bằng Pino.
Prompt tôi muốn thường phải có cấu trúc kiểu:
# Task
Implement exactly this feature...
# Current context
This repo currently has...
# Scope
Do:
- ...
- ...
Do not:
- ...
- ...
# Required source inspection
- Inspect the actual source code first.
- Follow existing code style, structure, architecture, lints, tests.
- Treat this prompt as guidance, not absolute source truth.
- If the prompt conflicts with the actual codebase, stop and report the conflict.
- If anything is unclear, missing, or confusing, stop and ask. Do not assume.
# Implementation requirements
...
# Tests / validation
...
# Final report
Report:
- Files changed
- What changed
- Why changed
- How it was validated
- Remaining risks or notes
Đây không phải màu mè. Đây là hợp đồng thi công.
Không có hợp đồng thì AI rất dễ “tiện tay sửa thêm”. Mà “tiện tay sửa thêm” trong codebase thật đôi khi giống như đi cắt tóc mà thợ tiện tay cạo luôn lông mày.
Điểm tôi thấy quan trọng nhất: không để AI tự assume
Rule lớn nhất của tôi:
Nếu unclear, conflict, missing context, hoặc prompt không khớp source thật: dừng lại và hỏi. Không tự suy diễn.
AI tự suy diễn là nguồn gốc của rất nhiều bug khó chịu.
Nó thấy thiếu class thì tự tạo class.
Nó thấy naming khác thì tự đổi naming.
Nó thấy test fail thì sửa test cho pass thay vì sửa code.
Nó thấy architecture chưa rõ thì tự chọn architecture.
Và vì AI viết rất nhanh, một assumption sai có thể nhân bản thành 10 file sai trước khi mình kịp chớp mắt.
Cho nên với tôi, AI được phép không biết. AI được phép dừng. AI được phép hỏi. Nhưng AI không được phép giả vờ biết rồi âm thầm quyết định.
Workflow này không phải chân lý
Tôi không nói cách này là đúng cho tất cả mọi người.
Nếu task nhỏ, repo đơn giản, hoặc codebase không quan trọng, có thể ném thẳng cho Codex làm luôn cũng được.
Nếu người dùng không thích debate, không cần kiểm soát architecture, hoặc chỉ cần prototype nhanh, workflow này có thể hơi nặng.
Nhưng với tôi, khi làm repo thật, package thật, standard thật, CI/CD thật, thì tôi không muốn AI vừa nghĩ vừa làm vừa tự phê duyệt chính nó.
Nghe hơi giống một thằng dev tự review PR của mình lúc 3 giờ sáng và comment: “LGTM”.
Không ổn.
Cách tôi nhìn nó
Tôi xem ChatGPT như phòng họp kỹ thuật.
Ở đó tôi debate, audit, hỏi ngược, chốt design, xác định scope, ép nó chỉ ra risk, bắt nó viết prompt rõ ràng.
Tôi xem Codex như người cầm task đã chốt để implement.
Codex vẫn được quyền đọc source, phát hiện conflict, và báo lại. Nhưng Codex không nên là nơi tôi bắt đầu cuộc tranh luận “nên làm thế nào”.
Tách như vậy giúp tôi:
- giảm quota coding agent;
- giảm loop không cần thiết;
- giảm AI hallucination;
- giữ architecture nhất quán hơn;
- có prompt implementation rõ ràng hơn;
- dễ review lại quyết định trước khi code bị sửa.
Kết luận
Cách tôi đang dùng AI hiện tại có thể tóm gọn như sau:
ChatGPT = brainstorm, debate, audit, solution design
GitHub connector = đọc repo/source/docs để có context thật
ChatGPT Projects = giữ instruction riêng cho từng project
Codex = implement sau khi scope đã rõ
Prompt = hợp đồng thi công
Source code thật = chân lý cuối cùng
Với tôi, đây là cách dùng AI khá thực tế.
Không thần thánh hóa AI. Không coi AI là senior architect toàn năng. Cũng không coi AI là autocomplete ngu.
Nó là một bộ công cụ. Nếu chia việc đúng, nó rất mạnh. Nếu thả rông, nó vẫn mạnh — mạnh theo kiểu cầm máy cưa chạy trong phòng khách.
Và tôi thì không muốn ngày mai mở repo ra thấy AI đã “giúp” mình refactor nửa hệ thống chỉ vì một prompt thiếu scope.
Đời đã đủ bug rồi. Không cần nuôi thêm bug có văn phong tự tin.
