TROISINH
Harness EngineeringFeedback Loops & Quality Gates

Linter Integration: Reject lỗi trước khi apply

Khám phá cách SWE-agent và Claude Code dùng linter để chặn lỗi syntax trước khi AI apply code. Quality gate kiểu mới cho AI engineering.

Định nghĩa

Linter Integration là việc nhúng công cụ kiểm tra tĩnh (static analysis) vào vòng đời của AI Agent, tự động từ chối (reject) các thay đổi chứa lỗi cú pháp, kiểu dữ liệu, hoặc vi phạm quy chuẩn code trước khi chúng được ghi vào hệ thống.

Giải thích chi tiết

Vấn đề: AI "mù" biên dịch

LLM sinh ra text. Dù nó viết code trông có vẻ hợp lý, nhưng không có cơ chế nội tại để biết liệu đoạn code đó có parse được không. Một dấu ngoặc thiếu, một import sai tên module, hoặc một biến undefined — agent hoàn toàn không nhận ra cho đến khi bạn chạy code và thấy crash.

Nếu hệ thống của bạn cho phép agent "write then verify", bạn đã để lỗi len lỏi vào codebase. Chi phí để rollback và context switch lúc này rất cao, đặc biệt khi agent đã chuyển sang file khác và mất context.

Nguyên lý "Shift Left" cho Agent

Trong software engineering truyền thống, chúng ta có quy tắc "shift left" — đẩy việc phát hiện lỗi về giai đoạn sớm nhất có thể. Với AI agent, triết lý của Hashimoto ở feedback-loop-design vẫn đúng: mỗi khi agent mắc lỗi, bạn xây dựng giải pháp để nó không bao giờ mắc lỗi đó nữa.

Linter Integration tạo ra một "cửa ngõ" (quality gate) giữa ý định (intent) và thực thi (execution). Agent được quyền "đề xuất" (propose) thay đổi, nhưng phải qua kiểm tra mới được "commit". Đây là biện pháp rẻ nhất để bắt lỗi — tính bằng millisecond và không cần môi trường runtime.

Kiến trúc tích hợp thực tế

Có hai pattern triển khai trong harness:

Pattern 1: Hook vào Tool Call Khi agent gọi tool edit_file hoặc write_file, harness không ghi file ngay. Thay vào đó:

  1. Tạo temporary copy hoặc diff
  2. Chạy linter (ESLint, Pylint, Ruff, TypeScript compiler)
  3. Nếu exit code = 0 → apply thật
  4. Nếu exit code ≠ 0 → reject, trả về stderr cho agent trong context window để sửa ngay

Pattern 2: Pre-apply Validation Layer Tách biệt hoàn toàn quyền write. Agent chỉ được phép trả về proposed_edits. Một layer riêng (có thể là script hoặc evaluator agent) chạy linter trên proposal trước khi trình diễn cho người dùng hoặc auto-apply. Đây là cách tiếp cận "defense in depth" — thậm chí nếu agent cố tình viết code sai, hệ thống vẫn chặn được.

Từ Reactive sang Proactive

Cách cũ: Agent chạy → test fail → agent sửa → chạy lại. Vòng lặp dài, tốn token, tốn thời gian, dễ mất context.

Cách mới: Agent chạy → linter chặn ngay → agent sửa trong cùng turn. Đây chính là friction reduction — giảm ma sát trong feedback loop. Khi error message từ linter được đưa vào context ngay lập tức, LLM có cơ hội "self-correct" mà không cần human intervene.

Ví dụ thực tế

SWE-agent: Linter reject trước khi apply

Trong paper của Princeton (2024), SWE-agent triển khai "linter precondition check". Trước mỗi lần gọi edit_file, hệ thống chạy linter trên nội dung mới. Nếu phát hiện lỗi syntax (ví dụ thiếu dấu ngoặc đơn trong Python hoặc import chưa tồn tại), edit bị từ chối ngay lập tức. Error message được đưa vào context window dạng: SyntaxError: unexpected EOF while parsing.

LLM nhìn thấy lỗi này và tự sửa trong turn tiếp theo, thay vì apply xong mới phát hiện crash. Kết quả: Giảm đáng kể số lần agent tạo ra commit bẩn, tránh tình trạng "death spiral" khi agent cố fix lỗi runtime mà không biết mình đã viết sai syntax từ đầu.

Claude Code: Background type checking

Khi bạn dùng Claude Code với codebase TypeScript, mỗi khi agent đề xuất sửa file .ts, hệ thống chạy tsc --noEmit ngầm. Nếu xuất hiện type error (ví dụ gán string cho biến khai báo number), Claude không thể "xác nhận" (confirm) thay đổi cho đến khi sửa xong.

Đây là dạng "soft gate" — vẫn cho phép người dùng override, nhưng mặc định là chặn. Điều này ngăn chặn việc AI tạo ra technical debt về type safety — một vấn đề cực kỳ tốn kém để sửa sau này.

Python Ruff trong Harness tự động

Một AI engineer xây dựng harness cho data pipeline: Agent sinh ra đoạn transform code Pandas. Trước khi write vào transforms.py, harness chạy ruff check --select E,W,Fmypy --strict.

Nếu fail → trả về JSON error cho agent: {"error": "Undefined name 'df_clean' at line 42", "suggestion": "Did you mean 'df_cleaned'?"}. Agent nhận được feedback ngay trong context và tự sửa lại, không cần human phải chạy lệnh rồi copy-paste error message vào chat.

Ứng dụng

Sinh viên và Junior Developer

Dùng Cursor hoặc GitHub Copilot với ESLint/Pylint cấu hình strict. AI suggest code nhưng bạn không bao giờ apply lỗi syntax vào project — editor sẽ chặn ngay. Đây là cách "học đúng" từ đầu: agent dạy bạn viết code sạch, không phải code chạy được là được. Bạn sẽ không bao giờ commit thiếu dấu chấm phẩy nữa.

Developer doanh nghiệp

Thiết lập "executable validation layer" trong internal AI tools. Mỗi PR do agent tạo ra phải qua pre-commit hooks: black --check, isort --check-only, flake8. Không chỉ để đẹp mà để đảm bảo agent không tạo ra technical debt vô tình trong codebase production. Đây là quality gate bắt buộc.

AI Engineer và Tech Lead

Thiết kế harness với phân quyền rõ ràng như tool-permission-design: Agent không có quyền write trực tiếp, chỉ có quyền propose. Linter chính là "gatekeeper" đầu tiên. Khi bạn chuyển sang multi-agent architecture, có thể tách thành "coder agent" và "linter agent" chuyên trách việc verify, tạo thành một hệ thống checks-and-balances.

So sánh: Linter Integration vs Post-hoc Validation

Tiêu chíLinter Integration (Shift Left)Post-hoc Testing (Traditional)
Thời điểm phát hiệnTrước khi applySau khi đã apply
Chi phíCực thấp (dưới 1 giây, không cần runtime)Cao (cần build, test suite, môi trường)
Phản hồiNgay trong context windowCó thể mất context, cần read file lại
Loại lỗi phát hiệnSyntax, Type, StyleLogic, Integration, Runtime
Tự động hóaCó thể auto-retry ngayThường cần human intervene

Kết luận: Linter Integration không thay thế testing, nhưng là quality gate rẻ nhất và nhanh nhất. Nó loại bỏ 80% lỗi "ngu ngốc" (silly mistakes) trước khi chúng trở thành bug thật sự. Trong kiến trúc harness, đây là tuyến phòng thủ thứ nhất — ngăn chặn lỗi khi còn rẻ, không để chúng đắt dần lên ở production.

Bài viết liên quan

Cùng cụm "Feedback Loops & Quality Gates"

Feedback Loop Design

Khi agent sai, hệ thống phản hồi thế nào? Xây dựng vòng lặp khép kín để agent tự cải thiện qua từng lần thử

Quality Gate Patterns

Không cho agent skip bước — thiết kế các cửa ngõ bắt buộc trong workflow để đảm bảo chất lượng

Evaluation & Scoring

Đánh giá output của agent bằng heuristic và automatic metrics thay vì chỉ dựa vào "cảm tính"

Frustration Detection

Regex thắng model call khi accuracy tương đương — phát hiện agent đang "bí" hoặc lặp vô hạn bằng pattern matching

Đọc tiếp

State & Session Management

Quản lý trạng thái và bộ nhớ phiên khi agent chạy qua nhiều turn — nền tảng cho hệ thống phức tạp

Multi-Agent Architecture

Tách biệt "agent viết code" và "agent kiểm tra" — xây dựng evaluator agent chuyên trách validation

On this page