Pi hay PiG: coding agent viết lại bằng Go có nhanh hơn?

1. PiG: Pi viết lại bằng Go, ai build và vì sao lõi nhỏ

Video mở đầu bằng một câu khẳng định: đây là Pi, coding agent tối giản chạy trong terminal, được build lại bằng Go thành một file 55 MB. Theo tác giả kênh DIY Smart Code, việc cài đặt mất khoảng 3 giây. Sau đó anh trỏ nó vào model Qwen chạy ngay trên card đồ hoạ của mình, và agent đã tự viết một chương trình Go nhỏ, tự làm hỏng build của chính nó, tự sửa, rồi đưa được test về trạng thái pass. Không cần Node, không cần tài khoản cloud nào. Công cụ này tên là PiG (Pi in Go).

Theo video đăng ngày 02/10/2026, bản phát hành công khai đầu tiên của PiG (v0.2.0, ngày 25/09 theo màn hình) mới ra được năm ngày. Người build PiG là Michael Kinsy, làm việc tại Hewlett Packard Enterprise (HPE). Cuối tháng 4, anh commit một bộ khung (scaffold) khoảng 5.900 dòng (màn hình ghi chính xác 5,903 dòng, lấy từ bài blog của anh trên trang HPE Developer): Pi được viết lại bằng Go, và theo chính lời Michael, Pi đã giúp viết phần đó. Tới cuối tháng 5, nó đã thành coding agent anh dùng hằng ngày. Còn bây giờ (tính đến ngày video đăng), dự án thuộc về cộng đồng, là open source, và được văn phòng open source của HPE tài trợ.

Một ngày trước khi video lên, bài đăng mới nhất của Michael công bố version 0.3, chỉ bốn ngày sau bản phát hành công khai đầu tiên, kèm theo một hình pixel-art cả một đàn lợn, con nào cũng đeo bảng tên. Theo video ngày 02/10/2026, repo của PiG có 339 star, còn bản thân Pi có hơn 110.000 star.

Pi cố tình giữ phần lõi (core) thật nhỏ, và PiG sao chép đúng thiết kế đó thay vì tự nghĩ lại từ đầu. Trang chủ liệt kê sáu thứ được để ra ngoài core: không có MCP dựng sẵn, không có sub-agent, không có hệ thống phân quyền (permission system), không có plan mode, không có to-do list, không có background shell. Bạn tự thêm những thứ đó dưới dạng extension, hoặc không thêm gì cả.

Mỗi bản phát hành của PiG được ghim (pin) vào đúng một version của Pi; tại thời điểm video là Pi 0.87.1. Repo còn công bố bảng điểm (scorecard) của riêng nó: 424 trên 564 file đã được port, tức khoảng 75%, và 407 file trong số đó được đối chiếu với hành vi thật của Pi bằng 617 kịch bản test chạy theo cặp. Khi PiG hành xử khác Pi, README coi đó hoặc là bug, hoặc là một điểm khác biệt đã được ghi lại trong tài liệu (documented divergence).

2. Vì sao phải port: benchmark của chính PiG và chỗ khoảng cách biến mất

Vậy port sang Go để làm gì? Tác giả để benchmark của chính dự án PiG trả lời. Theo số liệu dự án công bố, được dẫn lại trong video ngày 02/10/2026: lệnh hỏi version mất trung vị (median) 21,5 mili giây, so với 300 mili giây của Pi, và chỉ dùng khoảng một phần tư bộ nhớ. Một prompt gửi tới một model giả lập chạy local (local mock model) mất 29 mili giây, so với 440 mili giây của Pi.

Tác giả lưu ý điều kiện của các lần chạy đó: một máy Linux chỉ có một core, và dùng một bản build từ trước version 0.2. Dự án cũng tự nói rõ chỗ nào khoảng cách này khép lại. Khi bạn nạp extension viết bằng TypeScript, PiG khởi động gần như nhanh ngang Pi, dao động từ nhanh hơn 8% tới chậm hơn 19%, vì nó phải khởi động Node để chạy các extension đó. Binary lõi không bao giờ cần Node, nhưng extension TypeScript của bạn thì vẫn cần.

3. Cài trên WSL và chạy hoàn toàn local với Ollama

Tiếp theo là phần cài đặt, trên Ubuntu chạy trong WSL. Chỉ một dòng curl: nó tải bản phát hành về, kiểm tra với các checksum đã công bố, và từ chối cài nếu không khớp. Đây là dòng lệnh tác giả gõ trên màn hình:

curl -fsSL https://pi-in-go.dev/install.sh | sh

Sau đó lệnh pig version in ra cả hai con số: PiG 0.3 đang bám theo (tracking) Pi 0.87.1. File binary nặng 55 MB, và trên máy của tác giả, lệnh kiểm tra version trả kết quả trong 14 mili giây (số đo của anh, theo video ngày 02/10/2026). Windows cũng có một lệnh cài một dòng bằng PowerShell, nhưng hỗ trợ Windows vẫn đang được gắn nhãn Preview.

PiG có sẵn 41 provider dựng sẵn (built-in). Ollama không nằm trong số đó, nên để có một setup chạy hoàn toàn local, bạn viết một file JSON trỏ PiG tới server Ollama của mình. Docs Providers của PiG cũng nói như vậy: endpoint không có trong bảng, ví dụ một server Ollama, LM Studio hay vLLM chạy local, thì khai báo trong ~/.pig/agent/models.json. Đây là file của tác giả trên màn hình:

{
  "providers": {
    "ollama": {
      "baseUrl": "http://localhost:11434/v1",
      "api": "openai-completions",
      "apiKey": "ollama",
      "models": [
        {
          "id": "qwen3.6-32k:35b-a3b",
          "name": "Qwen 3.6 35B-A3B (local)",
          "reasoning": true,
          "thinkingLevelMap": { "minimal": "none", "low": "low", "medium": "medium", "high": "high" },
          "contextWindow": 32768,
          "maxTokens": 8192
        }
      ]
    }
  }
}

Trong file của anh, có hai thiết lập quan trọng hơn hẳn phần còn lại, và anh phát hiện ra cả hai bằng cách làm sai trước. Lần thử đầu tiên, anh để Qwen 3.6 dùng context 131.000 token mà bản cài Ollama của anh cấp mặc định, và 11% model bị tràn sang CPU. Mỗi lượt (turn) của agent mất 30 tới 50 giây. Anh tạo một bản sao của model với context giới hạn ở 32.000 token. Bản này nằm gọn hoàn toàn trong card 7900 XTX của anh, và mỗi lượt giảm xuống còn vài giây.

Thiết lập thứ hai là thinking. Qwen mặc định có suy luận (reasoning), và trong một lần chạy nó tiêu khoảng 14.000 token chỉ để lần theo các chuỗi ký tự trong đầu (mô tả video ghi con số 14.340 token). Ánh xạ mức thinking minimal của PiG sang mức none của Ollama sẽ tắt hẳn phần đó.

4. Bài test thật: một prompt, một folder trống, Qwen trên GPU nhà

Rồi tới bài test thật. Một folder trống và đúng một prompt. Tác giả khởi động PiG với model local và mức thinking minimal bằng lệnh hiện trên màn hình:

pig --model ollama/qwen3.6-32k:35b-a3b --thinking minimal

Yêu cầu anh đưa ra: build "pig say", tức kiểu chương trình cowsay nhưng với con lợn, thêm một file test, chạy test, rồi chạy chương trình. Phần tiếp theo là phiên làm việc thật, được tua nhanh.

Agent bắt đầu bằng việc liệt kê một home folder không tồn tại, rồi chạy pwd và tìm ra mình thật sự đang ở đâu. Nó viết ba file và chạy test. Tiếp theo là bảy lần chạy test và vet đều thất bại. Đầu tiên là một câu lệnh break nằm ngoài vòng lặp, sau đó là một lỗi lệch một (off by one) trong độ rộng của khung lời thoại (bubble width).

Rồi tới lỗi mà tác giả thích nhất. Con lợn ASCII mà agent vẽ ra có chứa dấu backtick, mà trong Go, một dấu backtick sẽ kết thúc một raw string. Thế là chính bức vẽ của nó làm hỏng compiler. Agent tìm ra các dấu đó bằng một script Python một dòng, vẽ lại con lợn không có backtick, và lần chạy thứ tám thì pass.

Tổng cộng chưa tới năm phút (màn hình ghi session 4:54), trên GPU của chính tác giả, không có gì rời khỏi máy. Con lợn trông giống một con cú đứng trên cà kheo hơn, nhưng vòng lặp thì chạy đúng: thấy lỗi, sửa file, chạy lại.

5. Extension viết bằng Go và Piglet: một agent thành một file

Quay lại terminal. Extension là nơi đặt những mảnh mà Pi cố ý bỏ ra ngoài, và trong PiG bạn có thể viết chúng bằng Go. Chỉ một lệnh là dựng sẵn (scaffold) được một extension: pig extension init, kèm một cái tên và ngôn ngữ. Trên màn hình, lệnh tác giả gõ là:

pig extension init ./oink --lang go

Bạn nhận được hai file (màn hình ghi: go.mod và extension.go). File Go đăng ký ba thứ: một tool mà model có thể gọi, một slash command cho bạn dùng, và một status line ở phần footer. Tác giả không sửa một dòng nào. Anh nạp nó bằng -e (pig -e ./oink), và footer hiện "oink loaded". Lệnh /oink in ra "hello from oink". Sau đó anh bảo Qwen gọi tool mới, và nó trả về "pong from oink".

Từ version 0.3, PiG cũng nạp được các package JavaScript của chính Pi. Vì vậy package MCP adapter viết cho Pi cũng chạy được ở đây, dù release notes nói rằng chưa phải package nào cũng đã được kiểm chứng (qualified).

Piglet tiến thêm một bước. Đó là một file YAML ngắn định nghĩa một agent: model, các extension, các tool và prompt. File của tác giả dài chín dòng: Qwen local cộng với extension oink. Lệnh pig piglet build biên dịch file đó thành một file thực thi riêng. Lần build đầu mất 26 giây, lần rebuild mất 6 giây. Kết quả là một file 55 MB tên pig-oink đã biết sẵn model và các tool của nó.

Có một điểm vướng. Muốn build binary thì cần checkout source code của PiG và có Go trong PATH. Nếu không có source, lệnh build dừng lại và đòi biến source root (trên màn hình là PIG_SOURCE_ROOT). Một khi chạy được, bạn có thể trao cho cả team một agent dưới dạng một file duy nhất, và ký (sign) file đó. Mỗi người vẫn phải tự mang quyền truy cập model của mình.

6. Những gì PiG chưa làm được, và nên cài Pi hay PiG

Tính đến video ngày 02/10/2026, PiG vẫn là một bản 0.x. Một phần tư số file của Pi chưa được port, Windows vẫn là bản preview, và các binary cho macOS chưa được notarize. Nó chạy với đúng quyền của bạn và không có sandbox nào, giống Pi, nên README khuyên dùng container hoặc VM khi bạn cần cách ly. Ngoài ra còn có một ping lúc cài đặt, có thể tắt (opt-out), chỉ gửi đi số version.

Và phía upstream đã đổi ngay đúng ngày PiG 0.3 ra mắt: theo video ngày 02/10/2026, Pi 0.99 thêm MCP dựng sẵn, trong khi PiG vẫn ghim ở 0.87. Theo chính lời tác giả PiG, bộ công cụ dùng để port các thay đổi từ upstream vẫn cần làm tay một phần.

Nếu bạn chỉ muốn một coding agent viết bằng Go, thì Crush của Charm đã có sẵn rồi. Điểm của PiG là tương thích với Pi, tới tận các extension của chính Pi. Còn về bài test của tác giả: bảy lần chạy thất bại trên một chương trình 50 dòng là do Qwen, không phải do PiG. Một điều cuối, lấy thẳng từ trang chủ của họ: cũng như Pi, PiG chơi được Doom dưới dạng một extension.

Kết luận của tác giả: hãy cài PiG nếu bạn viết Go, hoặc nếu bạn muốn trao cho team một agent dưới dạng một file, vì extension viết bằng Go và binary Piglet chính là những gì PiG thêm vào so với Pi. Đừng chuyển sang chỉ vì các con số khởi động nếu setup của bạn chạy trên extension TypeScript, vì ở đó khoảng cách gần như biến mất. Còn nếu bạn cần các tính năng upstream, như hỗ trợ MCP mới, ngay trong tuần chúng ra mắt, thì tạm thời cứ dùng Pi.

Video kết thúc bằng câu hỏi cho người xem: Pi trên Node, hay PiG dưới dạng một binary Go, bạn sẽ cài cái nào?