Workflow thực tế khi dùng AI vào coding

Workflow hiệu quả không phải:

Mô tả yêu cầu → AI viết toàn bộ code → chạy được → merge.

Workflow thực tế nên là:

Yêu cầu rõ → AI đọc hệ thống → lập kế hoạch → tạo thay đổi nhỏ → chạy kiểm tra → AI tự review → người review → CI/PR.

Các coding agent hiện nay có thể đọc workspace, tìm kiếm bằng grep, sửa nhiều file, chạy terminal, compile và test theo vòng lặp. Tuy nhiên, công cụ chính thức vẫn khuyến cáo phải kiểm tra code sinh ra, chạy automated tests, static analysis và review bảo mật trước khi chấp nhận. (developers.google.com)

1. Ba cấp độ sử dụng AI

Cấp 1 — Autocomplete

Dùng cho:

Ví dụ:

! Calculate the Euclidean distance between two 3D points
real(real64) function distance_3d(a, b)

AI dự đoán phần còn lại.

Người dùng vẫn kiểm soát từng dòng.

Cấp 2 — Chat / pair programming

Dùng khi cần:

AI chưa nhất thiết tự sửa file. Nó đóng vai trò như một kỹ sư trao đổi cùng bạn.

Ví dụ:

Phân tích module này nhưng chưa sửa code.

Hãy cho biết:
1. Dữ liệu đi vào từ đâu.
2. Những biến nào có thể vượt giới hạn mảng.
3. Những procedure nào thiếu explicit interface.
4. Ba nguyên nhân có khả năng nhất gây SIGSEGV.
5. Cách kiểm chứng từng giả thuyết.

Cấp 3 — Coding agent

Dùng cho task nhiều bước:

Agent mode của các công cụ hiện tại hoạt động theo vòng lặp đại khái là:

Observe → Reason → Act → Read result → Adjust → Repeat

Agent thường sử dụng workspace, file reader, tìm kiếm, Git và terminal làm công cụ. Các thao tác ghi file hoặc thay đổi hệ thống thường có cơ chế xin phép; chế độ tự động chấp thuận cần được sử dụng thận trọng. (developers.google.com)

2. Workflow đầy đủ cho một task coding

Bước 0 — Chuẩn hóa repository cho AI

Trước khi giao task, repository nên có:

README.md
docs/
tests/
Makefile
.github/
    copilot-instructions.md
AGENTS.md

Trong file instruction nên ghi:

Ví dụ với môi trường của bạn:

# Project environment

- Language: Fortran 2008.
- Compiler: gfortran from MSYS2 UCRT64.
- Operating system: Windows.
- Editor: VS Code.
- Build system: GNU Make.

# Build commands

- Debug build: `make debug`
- Release build: `make build`
- Tests: `make test`

# Rules

- Do not modify public procedure signatures without approval.
- Do not suppress compiler warnings.
- Use `implicit none`.
- Do not add external dependencies without approval.
- Preserve existing numerical behavior.
- Never run destructive Git commands.
- Before editing, explain the root cause and proposed files.

Repository instruction files hiện được các công cụ dùng để cung cấp context lâu dài về cách hiểu, build, test và validate project. GitHub hỗ trợ repository-wide, path-specific và agent instruction files như .github/copilot-instructions.md hoặc AGENTS.md. (docs.github.com)

Bước 1 — Viết task dưới dạng ticket

Một task tốt cần ít nhất sáu phần:

1. Vấn đề hiện tại.
2. Kết quả mong muốn.
3. Cách tái hiện.
4. Acceptance criteria.
5. Phạm vi được phép sửa.
6. Phạm vi không được phép sửa.

Task kém

Fix lỗi game.

Task tốt

Khi người chơi chuyển từ map 2 sang map 3, chương trình đôi khi SIGSEGV.

Cách tái hiện:
1. Load save test/save_03.dat.
2. Chọn menu 2.
3. Di chuyển sang tọa độ 14, 8.
4. Chuyển map.

Kết quả mong muốn:
- Không SIGSEGV.
- Dữ liệu nhân vật được giữ nguyên.
- Không thay đổi định dạng save file.

Phạm vi:
- Được sửa map_transition.f90 và test liên quan.
- Không thay đổi public API của libseed00.
- Không refactor các module không liên quan.

Hoàn thành khi:
- Tái hiện được lỗi trước khi sửa.
- Test regression thất bại trước và thành công sau khi sửa.
- `make debug` và `make test` thành công.

Điểm quan trọng nhất là acceptance criteria phải kiểm chứng được bằng command hoặc test.

Bước 2 — Cho AI đọc nhưng chưa sửa

Đây là bước thường bị bỏ qua.

Prompt phù hợp:

Hãy phân tích task và repository ở chế độ read-only.

Chưa được sửa file.

Thực hiện:
1. Tìm entry point liên quan.
2. Lập call graph rút gọn.
3. Xác định file và procedure có khả năng liên quan.
4. Tìm test hiện có.
5. Tìm cách build và tái hiện lỗi.
6. Liệt kê các giả thuyết theo xác suất.
7. Đề xuất kế hoạch sửa nhỏ nhất.

Không được chạy command làm thay đổi repository.

Kết quả mong muốn không phải là code, mà là:

Task
 ├─ map_controller.f90
 │    └─ change_map()
 ├─ map_transition.f90
 │    └─ copy_player_state()
 └─ player_state.f90
      └─ inventory(:)

Bước này giúp tránh việc AI thấy một triệu chứng rồi sửa nhầm kiến trúc.

Bước 3 — Thiết lập baseline

Trước khi sửa, phải biết trạng thái ban đầu:

git status
git diff
make clean
make debug
make test

Đối với lỗi runtime Fortran, debug build có thể dùng:

gfortran \
  -g \
  -O0 \
  -Wall \
  -Wextra \
  -Wimplicit-interface \
  -fcheck=all \
  -fbacktrace \
  -ffpe-trap=invalid,zero,overflow

Baseline phải trả lời được:

Không có baseline thì sau khi AI sửa, bạn không biết lỗi mới do AI gây ra hay đã tồn tại sẵn.

Bước 4 — AI lập kế hoạch thay đổi

Kế hoạch tốt nên chỉ rõ:

File nào sẽ sửa.
Procedure nào sẽ sửa.
Vì sao cần sửa.
Test nào sẽ thêm.
Rủi ro regression.
Command xác nhận kết quả.

Ví dụ:

1. Thêm regression test tái hiện kích thước inventory bằng 0.
2. Sửa copy_player_state() để kiểm tra allocated().
3. Không thay đổi interface.
4. Chạy test riêng cho map transition.
5. Chạy toàn bộ make test.

Ở đây, người dùng cần kiểm tra:

Bước 5 — Viết test hoặc phương pháp kiểm chứng trước

Đối với bug:

Reproduce → Write regression test → Confirm test fails → Fix → Confirm test passes

Đối với feature:

Acceptance criteria → Test scenarios → Implementation → Verification

Bạn có thể yêu cầu:

Chỉ tạo regression test cho lỗi này.

Chưa sửa production code.

Sau khi tạo:
1. Chạy test.
2. Xác nhận test thất bại đúng vì lỗi đang điều tra.
3. Dừng lại và báo cáo kết quả.

Đây là một cách hạn chế AI “sửa lỗi” bằng cách thay đổi hành vi mong đợi hoặc làm test dễ qua hơn. GitHub cũng mô tả workflow TDD theo thứ tự: tạo failing tests, review tests, sau đó mới implement để làm test pass. (docs.github.com)

Bước 6 — Cho AI tạo patch nhỏ

Không nên yêu cầu:

Implement toàn bộ feature và refactor code cho sạch.

Nên yêu cầu:

Thực hiện bước 1 và 2 trong kế hoạch đã duyệt.

Ràng buộc:
- Chỉ sửa các file đã liệt kê.
- Không đổi public interface.
- Không format lại file ngoài vùng sửa.
- Không thêm dependency.
- Giữ diff nhỏ nhất có thể.
- Sau khi sửa, hiển thị git diff và giải thích từng thay đổi.

Một agent tốt nên làm vòng lặp:

Edit
  ↓
Compile
  ↓
Read error
  ↓
Correct
  ↓
Run focused test

Không nên ngay lập tức chạy toàn bộ test suite nếu focused test vẫn chưa qua.

Bước 7 — Verification nhiều lớp

Một thay đổi không được coi là hoàn thành chỉ vì compile thành công.

Lớp 1: Syntax và compile

make debug

Lớp 2: Test trực tiếp

./tests/test_map_transition.exe

Lớp 3: Regression suite

make test

Lớp 4: Static checks

Với Fortran:

gfortran -Wall -Wextra -Wimplicit-interface -fcheck=all

Có thể bổ sung:

Lớp 5: Kiểm tra diff

git diff --stat
git diff
git status

Phải kiểm tra:

Các hướng dẫn chính thức đề xuất chạy test và static analysis trước, sau đó kiểm tra intent, chất lượng code, dependency, bảo mật và các lỗi đặc trưng của code do AI tạo. (docs.github.com)

Bước 8 — Bắt AI tự review

Không nên dùng cùng một prompt:

Bạn đã làm đúng chưa?

Nó thường chỉ xác nhận lại quyết định cũ.

Nên tạo một context review riêng:

Hãy đóng vai reviewer chưa tham gia implementation.

Review diff hiện tại so với main.

Tập trung vào:
1. Logic sai.
2. Out-of-bounds.
3. allocated/deallocated state.
4. Integer overflow.
5. Race condition OpenMP.
6. Thay đổi hành vi ngoài acceptance criteria.
7. Test bị thiếu.
8. Code chỉ làm test pass nhưng không sửa root cause.

Không sửa code. Chỉ đưa ra findings, mức độ nghiêm trọng và bằng chứng.

Có điều kiện thì dùng một model khác để review:

Model A: implement
Model B: review
Human: quyết định

Model thứ hai không bảo đảm đúng, nhưng giúp giảm hiện tượng model tự bảo vệ phương án của chính nó.

Bước 9 — Người review diff

Người review không cần đọc mọi dòng với mức độ giống nhau. Nên ưu tiên:

  1. Public API và data structure.
  2. Memory allocation.
  3. Boundary conditions.
  4. Error handling.
  5. File I/O và persistence.
  6. Authentication, quyền truy cập, secret nếu có.
  7. Concurrency.
  8. Test assertions.
  9. Dependency mới.
  10. Những dòng AI nói “không thay đổi hành vi”.

Một nguyên tắc hữu ích:

Bạn không cần tự viết toàn bộ code, nhưng phải hiểu đủ để chịu trách nhiệm về code được merge.

Bước 10 — Commit và PR

AI có thể hỗ trợ:

PR nên có cấu trúc:

## Problem

## Root cause

## Changes

## Tests performed

## Risk and compatibility

## Files intentionally not changed

Sau đó CI chạy lại trong môi trường độc lập:

Build
Lint/static checks
Unit tests
Integration tests
System tests
Security scanning
Artifact generation

Cloud coding agent cũng thường làm việc trong một development environment riêng, nơi nó có thể khám phá code, sửa file và chạy test trước khi tạo PR. (docs.github.com)

3. Phân chia công việc giữa người và AI

Công việc AI nên làm Người phải kiểm soát
Tìm file liên quanChínhKiểm tra kết quả
Giải thích codeChínhXác nhận hiểu đúng domain
Sinh boilerplateChínhReview
Viết test ban đầuChínhKiểm tra test có đúng yêu cầu
Chọn kiến trúcTư vấnQuyết định
Thay đổi public APIĐề xuấtPhê duyệt
Chạy build/testChínhXem bằng chứng
Review diffHỗ trợChịu trách nhiệm cuối
Xử lý secret/quyềnKhông tự quyếtKiểm soát chặt
Merge productionKhông nên tự độngNgười hoặc policy CI

4. Workflow theo từng loại task

Sửa bug

Tái hiện
→ Thu thập log/backtrace
→ Xây giả thuyết
→ Viết regression test
→ Sửa nhỏ nhất
→ Test focused
→ Regression test
→ Review

Thêm feature

Requirement
→ Acceptance criteria
→ Thiết kế interface
→ Chia vertical slice
→ Test scenario
→ Implement từng slice
→ Integration test
→ PR

Refactor

Chứng minh hành vi hiện tại bằng test
→ Chọn một vùng nhỏ
→ Refactor không đổi behavior
→ Chạy test
→ So sánh performance
→ Tiếp tục vùng kế tiếp

Legacy code chưa có test

AI đọc và lập bản đồ
→ Characterization tests
→ Ghi nhận current behavior
→ Tạo seam/interface nhỏ
→ Sửa từng phần

Integration test / system test

Đọc API và data flow
→ Liệt kê actor và dependency
→ Xác định environment
→ Sinh scenario
→ Chuẩn bị test data
→ Chạy trên hệ thống thật hoặc gần thật
→ Thu thập log và side effect
→ Đối chiếu acceptance criteria

AI không nên biến integration test thành unit test có quá nhiều mock.

5. Hai vòng lặp nên dùng

Vòng lặp nhỏ — vài phút

Prompt nhỏ
→ Patch nhỏ
→ Compile
→ Focused test
→ Inspect diff

Vòng lặp lớn — một task

Ticket
→ Analysis
→ Plan
→ Tests
→ Implementation
→ Full verification
→ Review
→ PR

Phần lớn hiệu quả đến từ việc chạy nhiều vòng lặp nhỏ bên trong một vòng lặp lớn, thay vì giao toàn bộ task trong một prompt.

6. Mẫu prompt thực tế

Prompt phân tích

Đọc task và repository, nhưng chưa sửa file.

Hãy:
1. Tìm entry point và call path liên quan.
2. Xác định root cause có khả năng nhất.
3. Liệt kê bằng chứng từ code.
4. Đưa ra tối đa ba giả thuyết.
5. Đề xuất cách tái hiện và kiểm chứng.
6. Đề xuất patch nhỏ nhất.
7. Liệt kê test cần chạy.

Môi trường:
- Windows
- MSYS2 UCRT64
- gfortran
- GNU Make
- VS Code

Prompt implementation

Thực hiện kế hoạch đã thống nhất.

Ràng buộc:
- Chỉ sửa các file được phê duyệt.
- Không đổi public interface.
- Không thêm dependency.
- Không format lại code không liên quan.
- Giữ diff nhỏ nhất.
- Tạo regression test trước khi sửa production code.
- Chạy focused test sau mỗi thay đổi.
- Dừng nếu phát hiện giả thuyết root cause sai.

Prompt verification

Kiểm chứng thay đổi hiện tại.

Thực hiện:
1. Hiển thị git status.
2. Hiển thị git diff --stat.
3. Compile debug.
4. Chạy focused tests.
5. Chạy toàn bộ regression tests.
6. Kiểm tra warnings.
7. Review diff đối với out-of-bounds, allocation, I/O và regression.
8. Báo cáo command, exit code và kết quả thực tế.

Không che giấu test thất bại và không sửa test chỉ để làm test pass.

7. Những cách dùng AI thường thất bại

Giao task quá lớn

Hãy đọc repository và cải thiện toàn bộ kiến trúc.

Kết quả thường là:

Cho phép auto-approve mọi command

Agent có thể:

Các tài liệu agent mode cũng cảnh báo rằng agent có quyền dùng filesystem, terminal và các tool được cấu hình; những thao tác bên ngoài IDE có thể không có cơ chế undo. (developers.google.com)

Chỉ nhìn kết quả test do chính AI viết

AI có thể tạo test:

Để AI vừa thay requirement vừa sửa code

Khi test không qua, AI đôi khi sửa:

Expected result

thay vì sửa:

Implementation

Requirement và acceptance criteria nên được khóa trước khi implementation.

Merge một diff không hiểu

Đây là “AI-generated technical debt”: code có vẻ chạy nhưng không ai hiểu invariant, assumptions hoặc failure mode.

8. Workflow tôi khuyến nghị cho bạn

Với Fortran, MSYS2 UCRT64, Windows và VS Code:

1. Viết task rõ ràng trong issue hoặc task.md.
2. Cho AI đọc repository ở chế độ không sửa.
3. Yêu cầu call path và giả thuyết root cause.
4. Tự kiểm tra kế hoạch.
5. Tạo debug build có -fcheck=all và -fbacktrace.
6. Tái hiện lỗi trước khi sửa.
7. Cho AI viết regression test.
8. Cho AI sửa tối đa 1–3 file trong một vòng.
9. Chạy focused test.
10. Chạy make test.
11. Tạo session AI mới để review diff.
12. Bạn review các phần memory, array, interface và I/O.
13. Commit nhỏ.
14. Tạo PR và để CI kiểm chứng lại.
15. Ghi bài học mới vào AGENTS.md hoặc project instructions.

Công thức rút gọn:

AI đọc rộng
→ con người quyết định hẹp
→ AI sửa nhỏ
→ máy kiểm tra tự động
→ AI review bổ sung
→ con người chịu trách nhiệm cuối

Đây là workflow cân bằng nhất giữa tốc độ, chi phí token và độ tin cậy.