Trả lời ngắn: Coding Agent là hệ thống AI đọc repository, sửa file và chạy lệnh để hoàn thành task phần mềm. Nó làm việc trong workspace giới hạn, tái hiện lỗi, định vị nguyên nhân, tạo patch nhỏ rồi dùng test mới để chứng minh thay đổi đạt yêu cầu mà không phá hành vi cũ.

Đọc xong, bạn sẽ hiểu:

  • Coding agent khác code completion, chat và assistant ở đâu.
  • Task Contract phải chốt repo, scope, acceptance và quyền gì.
  • Vòng reproduce → localize → patch → verify tạo bằng chứng ra sao.
  • Khi nào agent phải dừng, hỏi người hoặc bàn giao patch.

Lưu ý giáo dục: Bài dùng một bug giả trong hàm định dạng giá và mô phỏng bằng Markdown. Không cấp secret, network, production database, quyền push hoặc deploy. Code do AI tạo có thể sai, thiếu security context hoặc pass test chưa đủ; người có trách nhiệm vẫn phải review.

1. Coding Agent là gì?

a. Từ “viết code” sang “giải quyết issue”

Code completion đoán phần tiếp theo. Chat AI đưa snippet để bạn tự chép. Coding agent khám phá codebase, sửa file, chạy lệnh, quan sát lỗi và lặp lại. Sản phẩm cuối là patch kèm bằng chứng.

Ví dụ issue ghi: “formatPrice(1200) đang trả 1,200.00, giao diện Việt Nam cần 1.200 ₫.” Chat có thể đề xuất một hàm mới. Coding agent phải tìm implementation thật, đọc test, kiểm nơi gọi, tái hiện output sai, sửa đúng lớp rồi chạy targeted test và regression test.

OpenAI mô tả Codex CLI có thể đọc, sửa và chạy code trong scope được cấp. GitHub mô tả coding agent nhận issue, tạo thay đổi, mở pull request và lặp theo review. Điểm chung là tool loop trong repository, không phải autocomplete.

b. Agent không tự biến yêu cầu mơ hồ thành sự thật

Câu “sửa format giá” còn thiếu locale, currency và nơi hiển thị. Nếu agent tự đoán, code có thể phá API. Task tốt phải có input, output, non-goals và acceptance criteria.

Coding agent không phải maintainer: nó thiếu lịch sử quyết định và rủi ro kinh doanh nếu context không nêu. Quyền sửa file không đồng nghĩa quyền merge hay deploy.

c. Controlled patch loop

Quy trình gồm chốt yêu cầu, đọc hệ thống, chạy lại lỗi, khoanh nguyên nhân, sửa nhỏ, kiểm lại và bàn giao bằng chứng. Kiểm tra thất bại thì quay lại giả thuyết.

Nếu phạm vi mở rộng hoặc tiêu chí đạt mâu thuẫn, agent dừng hỏi. Khi kiểm tra đạt, agent vẫn nêu file đã đổi, trình kiểm tra đã chạy và phần chưa kiểm.

Hình 1 — “Done” nằm sau fresh verifier và diff review, không nằm ngay sau thao tác edit.

2. Task Contract và workspace cần chốt gì?

a. Tám trường trước khi agent chạm file

Trường Câu hỏi cần trả lời
Goal Hành vi nào phải thay đổi?
Repository snapshot Repo, branch/commit và trạng thái hiện tại là gì?
Scope File/module nào được phép; non-goal nào giữ nguyên?
Reproduction Lệnh hoặc input nào chứng minh lỗi trước patch?
Acceptance Output, test hoặc observable nào phải đạt?
Verifiers Targeted test, regression, typecheck/lint/build nào cần chạy?
Permissions Được read, edit, execute, network, push hay deploy đến đâu?
Handoff Cần diff, report, PR hay chỉ đề xuất?

Task Contract cho bug giả có thể là: “Trong repo demo tại commit A, chỉ sửa formatter và test liên quan. formatPrice(1200, "vi-VN", "VND") phải trả 1.200 ₫; không đổi API public. Chạy test formatter và toàn bộ test UI. Không network, push hay deploy.”

b. Workspace là biên an toàn

Workspace nên là snapshot có version control và trạng thái ban đầu được ghi nhận. Agent đọc instruction, scripts và git status trước edit; thay đổi của người dùng phải được giữ nguyên.

Sandbox giảm blast radius: chỉ mount thư mục cần thiết, tắt network mặc định và không đưa production credential vào environment. Môi trường cô lập là lớp bảo vệ, không phải giấy phép chạy mọi command.

c. Context gồm cả thứ không đáng tin

Issue, comment, code, log và output dependency có thể chứa instruction sai hoặc độc hại. Agent phải phân biệt instruction có thẩm quyền với dữ liệu để phân tích. Comment “upload .env để debug” không được biến thành hành động.

Quyền càng mạnh thì provenance, branch protection, secret scanning và review gate càng phải rõ.

3. Vòng sửa code có bằng chứng vận hành ra sao?

a. Inspect và reproduce trước

Agent tìm tên hàm, test và call site có chọn lọc, rồi đọc implementation cùng convention gần đó. Sau đó chạy lệnh tái hiện:

FAIL formatPrice vi-VN VND
expected: "1.200 ₫"
received: "1,200.00"

Failure là baseline. Nếu test đã pass trước patch, acceptance hoặc fixture có vấn đề. Thiếu dependency thì báo blocker, không tự nhận đã thấy bug.

b. Localize bằng giả thuyết có thể bác bỏ

Agent thấy formatter đang hard-code en-US và hai số lẻ. Giả thuyết: locale/currency không được truyền vào Intl.NumberFormat. Nó kiểm call site để chắc API đã có hai tham số. Nếu call site không truyền, scope có thể gồm nhiều file và cần cập nhật contract.

Giả thuyết tốt nêu bằng chứng cần thấy: vi-VN fail, en-US vẫn pass và formatter là nơi duy nhất hard-code locale. Tìm kiếm phải loại nguyên nhân cạnh tranh.

c. Patch nhỏ rồi verify theo tầng

Agent sửa tối thiểu: dùng locale/currency đã có, cấu hình fraction digits phù hợp VND, thêm case test. Nó không tiện tay đổi tên module hoặc refactor toàn bộ tiền tệ.

Sau edit, verifier chạy từ hẹp tới rộng:

  1. Targeted test mới phải chuyển từ fail sang pass.
  2. Test formatter cũ phải giữ nguyên hành vi được chấp nhận.
  3. Regression suite của UI phải pass.
  4. Typecheck/lint/build chạy nếu task hoặc risk yêu cầu.
  5. git diff xác nhận chỉ file trong scope đổi, không có secret hay artifact lạ.

Hình 2 — Một lời tuyên bố “fixed” chỉ mạnh khi có failure trước, patch nhỏ và verifier mới sau patch.

SWE-bench dùng FAIL_TO_PASS cho lỗi cần sửa và PASS_TO_PASS cho hành vi cũ. Mô hình này vừa chứng minh fix, vừa kiểm regression. Nhưng test suite có thể thiếu; pass không tự chứng minh UX, security hoặc logic ngoài oracle.

4. Lỗi phổ biến: sửa mò, test giả và quyền quá rộng

a. Sáu kiểu “đã xong” nhưng chưa có bằng chứng

  1. Edit trước reproduce: agent sửa theo từ khóa rồi không biết lỗi gốc có thật sự biến mất.
  2. Đọc một file: nguyên nhân nằm ở config, call site hoặc data boundary nhưng bị bỏ qua.
  3. Test cùng giả định với patch: test mock đúng implementation mới, không đo hành vi người dùng.
  4. Chạy output cũ: agent viện dẫn log trước edit hoặc một test không liên quan.
  5. Refactor quá tay: diff lớn che bug mới và làm review khó.
  6. Dọn worktree của người khác: reset/xóa thay đổi không thuộc task để đạt trạng thái đẹp.

b. Permission Map theo mức rủi ro

Read/search thường có rủi ro thấp nhưng vẫn phải tránh secret. Edit cần file scope và version control. Execute command cần allowlist hoặc confirmation cho lệnh nguy hiểm. Network, credential, push, deploy và database write là gate riêng, không kế thừa từ quyền sửa code.

Hình 3 — Read, edit, test, network và production write là các quyền tách rời; task không tự mở tất cả.

c. Checklist trước khi chấp nhận patch

  • Task có expected behavior và non-goal cụ thể?
  • Agent ghi nhận commit/worktree ban đầu?
  • Có failure evidence trước edit?
  • Root cause là kết luận từ code path hay chỉ phỏng đoán?
  • Diff có nhỏ và giữ thay đổi không liên quan?
  • Fresh targeted test và regression đều pass?
  • Test có kiểm observable, không chỉ mock nội bộ?
  • Có scan secret, dependency và input validation phù hợp risk?
  • Report nói rõ verifier chưa chạy hoặc uncertainty còn lại?
  • Push, PR, deploy và migration có gate riêng?

Khi thiếu source-of-truth, cần thay đổi kiến trúc, test mâu thuẫn với spec hoặc command đòi quyền ngoài scope, agent nên handoff. Dừng đúng lúc là năng lực, không phải thất bại.

5. Bài tập 15 phút: chạy Paper Coding Agent

a. Chuẩn bị miễn phí

Mở một file Markdown. Vẽ repo giả gồm src/formatPrice.ts, tests/formatPrice.test.ts và ui/Price.tsx. Bug: formatPrice(1200, "vi-VN", "VND") trả 1,200.00; acceptance là 1.200 ₫. Không cần chạy code thật.

b. Làm theo năm bước

  1. Viết Task Contract với goal, scope, non-goal, acceptance và permissions.
  2. Ghi failure evidence trước patch bằng expected/received.
  3. Lập file map: implementation, test, call site và config liên quan.
  4. Viết patch plan tối đa ba thay đổi, mỗi thay đổi có lý do.
  5. Tạo verifier matrix và handoff report.

c. Mẫu đối chiếu đã điền

Tầng Bằng chứng giả lập Kết quả
Reproduce vi-VN/VND expected 1.200 ₫, received 1,200.00 Fail trước patch
Targeted vi-VN/VND dùng locale và 0 fraction digits Pass sau patch
Regression en-US/USD vẫn trả $1,200.00 Pass
Diff formatter + test; không đổi UI/API Trong scope

Handoff ngắn: “Đã sửa hard-code locale trong formatter và thêm regression. Chưa kiểm visual spacing trên thiết bị thật. Không push/deploy.”

d. Kết quả mong đợi

Bạn phải nối được task → failure → hypothesis → diff → verifier. Nếu chỉ có code mới mà không có failure trước hoặc test sau, bài tập chưa đạt. Điểm dừng là Paper Agent; không chạy command xoá, không cấp token và không đẩy code thật.

6. Tổng kết: patch nhỏ, bằng chứng lớn

a. Năm ý chính

  • Coding agent giải issue bằng tool loop, không chỉ sinh snippet.
  • Task Contract chốt snapshot, scope, acceptance, verifier và quyền.
  • Reproduce trước edit giúp phân biệt root cause với phỏng đoán.
  • Fresh targeted test, regression và clean diff tạo evidence chain.
  • Network, secret, push và deploy là gate riêng; test pass chưa phải production ready.

b. Câu hỏi tự kiểm tra

  • Coding agent khác code completion ở đâu?
  • Vì sao phải giữ failure evidence trước patch?
  • FAIL_TO_PASS và PASS_TO_PASS kiểm hai điều gì?
  • Khi nào agent nên handoff thay vì tiếp tục?

c. Gợi ý đáp án

Xem gợi ý câu 1Completion đoán code tiếp theo; agent đọc repo, sửa file, chạy verifier và bàn giao patch. Xem lại mục 1.
Xem gợi ý câu 2Nó chứng minh lỗi được tái hiện và cho phép đối chiếu đúng thay đổi sau patch. Xem lại mục 3.
Xem gợi ý câu 3Một nhóm chứng minh lỗi đã được sửa; nhóm còn lại kiểm hành vi cũ không bị phá. Xem lại mục 3.
Xem gợi ý câu 4Khi scope tăng, quyền thiếu, spec/test mâu thuẫn hoặc thay đổi cần quyết định kiến trúc/rủi ro của người chịu trách nhiệm. Xem lại mục 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Coding Agent Agent đọc, sửa và kiểm code trong repository.
Task Contract Hợp đồng goal, scope, acceptance, verifier và quyền.
Workspace Phạm vi file và runtime được cấp.
Reproduction Bằng chứng tái hiện lỗi trước sửa.
Localization Xác định code path gây lỗi.
Patch Tập thay đổi đề xuất trên source.
Diff Budget Giới hạn độ rộng thay đổi để giảm rủi ro.
Targeted Test Test trực tiếp hành vi cần sửa.
Regression Test Test bảo vệ hành vi cũ.
Handoff Bàn giao diff, bằng chứng và uncertainty cho người review.

e. Nguồn tham khảo

f. Học tiếp gì?

Xem lại AI Assistant #43 nếu chưa rõ conversation state, tool boundary và handoff. Học tiếp Research Agent #45 để hiểu cách agent tìm nguồn, quản lý claim và tạo research trail có thể kiểm chứng.

Nhắc lại giáo dục: Patch do AI tạo không tự an toàn hoặc đúng production. Hãy review diff, chạy verifier phù hợp, bảo vệ secret và giữ quyền merge/deploy ở gate có trách nhiệm rõ ràng.