OpenCode.io.vn
Quay lại Blog
22 tháng 5, 2026OpenCode Vietnam10 phút đọc

Building pi trong thời đại code slop: bài học cho developer dùng AI agent

Từ talk của Mario Zechner về pi: vì sao context phải thuộc về developer, agent dễ tạo code slop ra sao, và cách dùng AI coding agent mà vẫn giữ quyền kiểm soát kỹ thuật.

#pi#ai-coding#coding-agent#slop#developer-workflow#context#code-review

Building pi trong thời đại code slop: bài học cho developer dùng AI agent

AI coding agent đang làm developer nhanh hơn. Nhưng nhanh hơn không tự động đồng nghĩa với tốt hơn.

Trong talk về pi, Mario Zechner không chỉ giới thiệu một agent harness mới. Ông đưa ra một cảnh báo rất thực tế: nếu developer giao hết quyền quyết định cho agent, không đọc diff, không hiểu code, không kiểm soát context, thì agent sẽ giúp ta tạo ra một thứ còn nguy hiểm hơn bug đơn lẻ: một codebase phình to, khó hiểu, khó maintain.

Nói ngắn gọn: vấn đề không phải AI viết code. Vấn đề là con người merge code mình không hiểu.

Video gốc


pi là gì?

pi là một coding agent harness do Mario Zechner xây dựng.

Hiểu đơn giản, harness là cái khung để chạy coding agent, gồm:

  • vòng lặp gọi model
  • tool cho agent dùng
  • terminal UI
  • cách quản lý context
  • cách kết nối provider/model
  • cơ chế extension

Điểm khác biệt của pi không nằm ở việc nó có nhiều tính năng hơn mọi agent khác. Ngược lại, triết lý của nó là tối giản và dễ kiểm soát.

Mario muốn agent thích nghi với workflow của developer, không phải developer phải thích nghi với agent.


Nỗi đau thật: context không còn là của mình

Một trong những câu đáng nhớ nhất trong talk là:

“My context wasn’t my context.”

Context là toàn bộ thứ model nhìn thấy khi làm việc: system prompt, tool definition, lịch sử chat, output từ tool, error message, file, docs, test result và cả những reminder mà tool tự nhét vào.

Theo Mario, nhiều coding agent hiện tại làm quá nhiều thứ ngầm phía sau:

  • đổi system prompt sau mỗi release
  • sửa tool definition
  • tự inject reminder vào context
  • tự cắt bớt output từ tool
  • tự thêm lỗi LSP sau mỗi lần edit
  • tự quyết định workflow thay user

Các tính năng này có thể hữu ích với người mới, nhưng với developer muốn kiểm soát hệ thống, chúng tạo cảm giác khó đoán. Khi agent ra quyết định dựa trên context mà bạn không thấy rõ, bạn không còn thật sự biết agent đang làm việc với thông tin nào.

pi chọn hướng ngược lại: core nhỏ, prompt ngắn, ít magic, muốn thêm gì thì tự thêm bằng extension.


Tối giản không có nghĩa là yếu

Điểm thú vị của pi là nó không cố built-in mọi thứ.

Nó không nhất thiết có sẵn subagent, MCP, plan mode, workflow riêng của từng team, hay security policy đặc thù. Thay vào đó, pi cho phép viết extension bằng TypeScript.

Extension có thể:

  • thêm tool mới
  • thêm slash command
  • sửa cách tool chạy
  • thêm provider/model
  • thêm UI
  • lưu state
  • tùy chỉnh compaction/context
  • can thiệp sâu vào harness

Đây là triết lý gần với Unix, Neovim hoặc Arch Linux: core nhỏ, hiểu được, tự ghép workflow theo nhu cầu.

Với team kỹ thuật mạnh, đây là điểm rất hấp dẫn. Thay vì đợi vendor hỗ trợ đúng workflow của mình, team có thể tự build guardrail, command, sandbox hoặc integration riêng.


Nhưng có mâu thuẫn không?

Mario vừa cảnh báo agent tạo slop, vừa xây một agent cho phép tự viết extension. Nghe qua có vẻ mâu thuẫn.

Thực ra điểm khác biệt nằm ở chỗ nào được phép nhanhchỗ nào bắt buộc phải chậm.

Agent nên chạy nhanh trong vùng nhỏ:

  • task rõ scope
  • có docs hoặc ví dụ
  • có test/check
  • dễ review toàn bộ diff
  • sai thì bỏ được

Con người phải đi chậm ở vùng quan trọng:

  • quyết định kiến trúc
  • merge code
  • auth, payment, security
  • migration data
  • public API
  • deploy production

Nói cách khác: hãy bỏ bottleneck ở việc gõ code, nhưng giữ bottleneck ở review và quyết định kỹ thuật.

Agent tăng tốc tạo nháp. Con người vẫn phải chịu trách nhiệm chất lượng.


“Slop” trong code là gì?

Slop là output AI chất lượng thấp. Trong code, slop không nhất thiết là code không chạy. Nhiều khi nó chạy được, pass test, nhưng vẫn làm codebase xấu đi.

Slop thường có dạng:

  • thêm abstraction thừa
  • duplicate logic
  • fix cục bộ nhưng phá tổng thể
  • thêm backward compatibility không cần thiết
  • tạo nhiều layer kiểu enterprise mà không có nhu cầu thật
  • viết test không bắt được lỗi thật
  • làm codebase phình to đến mức không ai hiểu nữa

Điểm nguy hiểm là agent không mệt. Con người viết nhiều quá sẽ thấy đau, thấy rối, rồi dừng lại refactor. Agent thì không có cảm giác đó. Nếu bạn tiếp tục giao việc, nó tiếp tục thêm code.

Vấn đề không phải agent “ngu”. Vấn đề là agent không phải người sẽ maintain codebase đó 6 tháng sau.


Vì sao agent dễ làm codebase rối?

Có bốn lý do chính.

1. Agent tối ưu cục bộ

Agent thường sửa nơi gần nhất để hoàn thành task. Nhưng phần mềm là hệ thống. Một fix nhỏ có thể đúng ở file hiện tại nhưng sai với kiến trúc tổng thể.

2. Agent thiếu context dài hạn

Codebase lớn không thể nhét hết vào context. Agent chỉ thấy một lát cắt. Nếu lát cắt đó thiếu constraint quan trọng, nó sẽ tự đoán.

3. Agent chọn pattern phổ biến

Khi prompt mơ hồ, agent thường dùng pattern nó thấy nhiều trong dữ liệu huấn luyện. Pattern phổ biến không chắc là pattern đúng cho repo của bạn.

4. Agent không cảm nhận chi phí maintain

Developer thấy code khó maintain sẽ khó chịu. Cảm giác khó chịu đó là tín hiệu chất lượng. Agent không có tín hiệu này, nên nó có thể tiếp tục thêm code dù hướng đi đang xấu dần.


Spec càng chi tiết càng tốt?

Mario có một ý rất hay:

“A sufficiently detailed spec is a program.”

Spec đủ chi tiết thì gần như đã là chương trình.

Điều này không có nghĩa là không cần spec. Nó có nghĩa là đừng biến prompt thành tiểu thuyết để ép agent không còn quyền quyết định nào. Cách thực dụng hơn là giao task nhỏ, rõ ràng, có ranh giới và có kiểm chứng.

Task tốt trông như thế này:

Trong src/auth/session.ts, thêm check expired session.
Không đổi public API.
Thêm test cho expired token.
Chạy đúng test file đó.
Không sửa database schema.

Task xấu trông như thế này:

Làm auth system enterprise-grade hơn.

Task đầu tiên có scope, có điều cấm, có test. Task thứ hai mơ hồ đến mức agent có thể thêm role system, middleware, config, abstraction và backward compatibility mà chưa chắc giải quyết đúng vấn đề.


YOLO mode: nhanh nhưng không phải bảo mật

Một điểm gây tranh luận của pi là mặc định không hỏi approve mỗi lần agent chạy command.

Mario không tin popup approve lặp lại là bảo mật thật. Nếu tool hỏi quá nhiều, người dùng sẽ quen tay bấm đồng ý. Nó tạo cảm giác an toàn giả.

Nhưng YOLO cũng không tự nhiên an toàn. Nó chỉ có nghĩa là pi không áp một policy bảo mật nông cho mọi người. Team nào cần guardrail thì tự viết extension, sandbox hoặc rule phù hợp.

Nếu dùng agent nghiêm túc, đặc biệt trong repo thật, nên có tối thiểu:

  • sandbox hoặc container
  • chặn command nguy hiểm
  • không để secret quan trọng trong môi trường agent
  • review diff trước khi commit
  • không cho agent tự deploy production

YOLO phù hợp với người hiểu rủi ro và kiểm soát được môi trường. Nó không phù hợp để thả agent vào production rồi hy vọng mọi thứ ổn.


Bài học cho developer dùng OpenCode, Claude Code hay bất kỳ agent nào

Talk này không chỉ dành cho người quan tâm pi. Nó là lời nhắc cho tất cả developer đang dùng AI coding agent.

1. Task phải nhỏ đến mức review được

Nếu bạn không thể đọc toàn bộ diff, task đang quá lớn. Hãy chia nhỏ.

2. Luôn có check rõ ràng

Test, lint, build, reproduction, hoặc checklist thủ công. Nếu không biết đánh giá output, đừng giao agent tự quyết.

3. Không merge code mình không hiểu

Đây là luật quan trọng nhất. Agent có thể viết code, nhưng người merge phải hiểu code.

4. Critical code phải đọc từng dòng

Auth, payment, security, migration, deploy, public API: không review kiểu lướt.

5. Đừng build chỉ vì agent làm được

Agent làm feature rất rẻ. Nhưng feature thừa vẫn là nợ sản phẩm. Mỗi dòng code mới đều cần lý do tồn tại.

6. Giới hạn số agent chạy song song

Nhiều agent không làm team nhanh hơn nếu review không theo kịp. Khi review bottleneck bị vỡ, slop sẽ vào repo.

7. Kiểm soát context

Đưa đúng file, đúng constraint, đúng test, đúng mục tiêu. Đừng nhồi context bừa bãi và cũng đừng để tool tự quyết hoàn toàn context thay bạn.


Cách nghĩ đúng: agent là junior dev cực nhanh

Một hình ảnh dễ nhớ:

Agent nên giống một junior dev cực nhanh. Nó có thể làm nhiều việc, nhưng senior vẫn phải review và quyết định.

Junior giỏi có thể tạo ra bản nháp tốt, viết test, tìm bug, refactor nhỏ, đọc log, thử nhiều phương án. Nhưng bạn sẽ không để junior tự quyết kiến trúc, tự sửa payment, tự deploy production mà không review.

Với agent cũng vậy.

Agent càng nhanh, kỷ luật review càng quan trọng.


Kết luận

pi là một phản ứng thú vị trước làn sóng coding agent ngày càng nhiều magic. Nó không hứa sẽ tự động cứu developer khỏi code rác. Nó chỉ trao lại nhiều quyền kiểm soát hơn cho người dùng.

Thông điệp quan trọng của Mario không phải là “đừng dùng AI”.

Thông điệp là:

Đừng để AI quyết định thay bạn.

Và cũng không phải “agent không được viết code”.

Thông điệp đúng hơn là:

Đừng merge code agent viết nếu bạn không hiểu nó.

Trong thời đại AI agent, tốc độ gõ code không còn là lợi thế lớn nhất. Lợi thế thật sự là khả năng đặt constraint đúng, chia task nhỏ, kiểm soát context, review diff, và giữ chất lượng kiến trúc.

Agent có thể chạy nhanh. Quyết định kỹ thuật vẫn phải đi chậm.

Đọc tiếp

Một vài bài liên quan có thể bạn sẽ thích