Workflow Lập Trình với AI: Từ Ticket đến Commit

Hầu hết dev dùng AI coding assistant y hệt cách dùng Stack Overflow hồi trước: paste lỗi vào, lấy cái answer đầu tiên trông có vẻ ổn, chạy tiếp thôi.

Cách đó ổn — cho đến khi không ổn nữa. Kết quả là đống code mình không hiểu, bug không biết từ đâu ra, và cái cảm giác ngày càng rõ rằng mình không thực sự đang kiểm soát thứ mình đang ship.

Thật ra có cách làm việc với AI tốt hơn — mình vẫn là người quyết định, AI lo phần nặng. Đây là workflow mình đang dùng, từ ticket đến commit.

Tổng Quan Workflow

Bước 1: Tóm Tắt Ticket với Rovo

Trước khi mở VS Code, phải hiểu mình đang làm cái gì đã.

Jira ticket thì đủ kiểu — có cái rõ ràng, có cái viết như đố mò. Acceptance criteria dài dằng dặc, sub-task lồng nhau, comment từ năm stakeholder khác nhau — dễ mất 20 phút chỉ để hiểu xem "xong" nghĩa là gì.

Mình dùng Rovo (AI của Atlassian) ngay trong Jira để tóm tắt ticket:

Problem đang được giải quyết là gì?
Trong scope là gì, ngoài scope là gì?
Có constraint hay dependency nào không?
"Done" trông như thế nào?

Có một đoạn tóm tắt gọn là mình đã chủ động trước khi viết dòng code đầu tiên. Không còn ngồi đọc lại ticket ba lần mà vẫn không chắc nữa.

Bước 2: Mở Codebase và Verify với Claude

Giờ mới mở VS Code với Claude Chat (hoặc Claude Code trên terminal). Lấy cái summary từ Rovo rồi hỏi Claude xem có khớp với code thực tế không:

"Đây là mình hiểu về ticket: [paste summary]. Code hiện tại có đúng với context này không? Mình cần biết gì về những phần liên quan?"

Bước này giúp phát hiện hai thứ:

Summary của mình có thể sai. Ticket không phải lúc nào cũng khớp với code thật. Claude đọc code và chỉ ra chỗ lệch.
Mình có thể thiếu context. Có thể có module liên quan, pattern đang dùng, hoặc thay đổi gần đây ảnh hưởng đến cách làm.

Bước này chưa nhờ Claude giải quyết gì cả. Mình đang dùng AI để kiểm tra lại hiểu biết của mình trước khi đi tiếp.

Bước 3: Hỏi Claude về Những Gì Chưa Rõ

Đây là bước hầu hết dev bỏ qua, và cũng là nơi phần lớn bug bắt đầu.

Trước khi làm gì tiếp, hỏi Claude hết những thứ còn mơ hồ:

"Hàm processPayment thực ra làm gì khi amount bằng 0?"
"Tại sao service này dùng repository pattern ở đây nhưng lại dùng direct query ở chỗ kia?"
"Có lý do gì mà test không cover edge case này không?"

Đừng để chỗ nào mờ mà cứ đi tiếp. Nếu mình không hiểu, AI sẽ tự lấp vào — và mình không biết nó lấp đúng không.

Mục tiêu là đến lúc mình giải thích được problem cho đồng nghiệp mà không cần nhìn note. Đến đó mới nói chuyện về solution.

Bước 4: Hỏi Các Option Kèm Trade-off

Giờ mới nhờ Claude đề xuất các hướng làm — không phải chỉ một câu trả lời:

"Với context này, có những approach nào để giải quyết? Mỗi cái có trade-off gì?"

Thường các option xoay quanh:

Simplicity vs. flexibility — fix nhanh vs. solution dễ mở rộng sau
Performance vs. readability — code tối ưu nhưng khó đọc
Risk vs. scope — thay đổi ít nhất có thể vs. sửa tận gốc
Test coverage — dễ test đến đâu

Không nhờ Claude chọn. Mình đang để nó trải ra các lựa chọn để mình quyết. Quan trọng lắm — AI hay đề xuất cái phức tạp nhất về mặt kỹ thuật, không phải cái phù hợp nhất với team và deadline của mình.

Chọn xong thì giải thích lý do cho Claude biết để nó có context đúng trước khi implement.

Bước 5: Implement Từng Bước

Đã chọn được approach rồi, nhờ Claude làm từng phần, không phải cả đống một lúc:

"Mình chọn option 2. Bắt đầu với [phần cụ thể]. Show thay đổi và giải thích đang làm gì."

Đừng nhờ làm hết ngay từ đầu. Cứ từng phần:

Mỗi lần một function, một file, hoặc một logical unit
Xem xong mới sang phần tiếp
Hỏi luôn nếu có chỗ nào không rõ tại sao lại làm vậy

Cái bẫy hay gặp là nói "làm hết đi cho xong" — nhất là khi mình đã tự tin vào approach. Đừng. Change trải ra nhiều file một lúc rất khó review, rất dễ có bug mà không thấy.

Làm từng bước cũng giúp mình không bị mất phương hướng. Đây là pair programming thật sự, không phải ngồi nhìn code tự chạy ra.

Bước 6: Đọc Những Thay Đổi Claude Làm

Sau mỗi bước, đọc diff. Đọc thật sự.

Không phải lướt qua, không phải "trông có vẻ ổn" — đọc có chủ ý:

Hiểu từng dòng thay đổi làm gì
Kiểm tra có đúng với yêu cầu không
Chú ý thứ gì bất ngờ hoặc không khớp với quyết định trước
Chạy thử trong đầu với ít nhất một input

Chỗ nào không giải thích được thì hỏi Claude trước khi accept. "Tại sao làm thế này mà không làm X?" là câu hỏi hoàn toàn bình thường — và thường lộ ra edge case hay assumption quan trọng.

Đây là điểm phân biệt làm việc với AI và bị AI dắt mũi. Code đó vào codebase của mình, tên mình trên đó, và mình sẽ là người debug lúc 2 giờ sáng sáu tháng sau.

Bước 7: Review Lại Trước Khi Commit

Trước khi commit, nhìn lại toàn bộ thay đổi một lần — không chỉ cái mới nhất, mà tất cả cộng lại:

Nhìn tổng thể diff có hợp lý không?
Có dòng debug, console.log, hay code comment thừa nào không?
Có thứ gì thay đổi mà lẽ ra không nên thay đổi không?
Có khớp với acceptance criteria của ticket không?

Rồi nhờ Claude viết commit message:

"Dựa trên các thay đổi vừa làm, viết commit message ngắn gọn nói rõ thay đổi gì và tại sao."

Đọc lại. Sửa nếu cần. Đảm bảo nó đúng với thực tế, không chỉ là những gì mình kế hoạch ban đầu.

Chỉ commit khi mình ổn nếu senior engineer nhìn vào cái diff và message đó mà không biết gì trước.

Tại Sao Từng Bước Quan Trọng

Mỗi bước giải quyết một vấn đề cụ thể:

Bước	Tránh được gì
Tóm tắt ticket	Làm sai problem ngay từ đầu
Verify với Claude	Xây trên assumption sai
Hỏi về chỗ chưa rõ	Ship code mình không hiểu
Options kèm trade-off	Chọn solution không phù hợp
Implement từng bước	Mất kiểm soát change quá lớn
Đọc các thay đổi	Accept code không làm đúng như nghĩ
Review trước commit	Ship code cẩu thả, thiếu sót

Bỏ bước nào là đẩy risk về sau — vào code review, vào QA, vào production.

Tóm Lại

✅ Tóm tắt ticket trước — có mental model rõ trước khi code
✅ Verify với codebase thực tế, không chỉ tin vào ticket
✅ Hỏi đến khi giải thích được problem mà không cần nhìn note
✅ Lấy nhiều option kèm trade-off — mình chọn, không phải AI
✅ Implement từng phần, không làm cả đống một lúc
✅ Đọc từng dòng thay đổi trước khi accept — mình chịu trách nhiệm
✅ Review cuối trước commit: diff gọn, code sạch, message rõ

Nói Thêm Một Chút

AI coding assistant rất nhanh. Đó vừa là điểm hay vừa là cái bẫy.

Nó có thể đưa mình từ "mơ hồ về ticket" đến "200 dòng code" trong vài phút. Nếu mình chưa thực sự hiểu problem, cái nhanh đó chỉ giúp đến đích sai nhanh hơn thôi.

Workflow này chậm hơn kiểu cứ vibe với AI. Nó bắt mình phải suy nghĩ, hỏi, và kiểm tra từng bước. Nhưng kết quả là code mình hiểu, quyết định mình có thể giải thích, và commit mình tự tin.

AI là pair programmer tốt nhất mình từng có. Nhưng như mọi pair programmer, output tốt hay không phụ thuộc vào cuộc trò chuyện mình có với họ.

Nói chuyện tốt hơn thì code ra tốt hơn.