Zig dạy dân AI một bài về ship phần mềm đàng hoàng

Zig 0.16.0 vừa drop "Juicy Main" — và cái cách họ làm release notes khiến mình tự hỏi: sao ecosystem AI không học theo?

Mình vừa đọc release notes hay nhất năm — và nó không phải của OpenAI

Tối qua lúc 2 giờ sáng, thay vì đọc changelog của mấy model mới, mình lạc vào release notes của Zig 0.16.0. Một ngôn ngữ lập trình hệ thống, không liên quan gì đến LLM hay agent. Nhưng đọc xong, mình ngồi thừ ra nghĩ: "Ủa, sao mấy framework AI mình dùng hàng ngày không viết release notes được như vầy?"

Plot twist: bài học lớn nhất cho dân AI tuần này lại đến từ một ngôn ngữ compiled.

"Juicy Main" — khi dependency injection được thiết kế cho người dùng

Zig 0.16.0 giới thiệu một concept gọi là "Juicy Main". Hiểu nôm na: thay vì để hàm main() của bạn tự đi kiếm mọi thứ nó cần — allocator, logger, system resources — Zig cho phép bạn khai báo thẳng "tôi cần những thứ này", và runtime inject vào.

pub fn main(process: std.process.Init) void {
    // process.allocator, process.env, process.args...
    // tất cả sẵn sàng, không cần setup thủ công
}

Hình dung thế này: bạn đang xây một AI agent service. Entry point cần config, cần model client, cần logger, cần rate limiter. Kiểu truyền thống là nhét hết vào global state hoặc viết một đống boilerplate init. Zig chọn cách khác — khai báo đi, runtime lo.

Giả sử team bạn 5 người, mỗi người viết một service. Nếu không có convention rõ ràng về cách init dependencies, đến lúc integration sẽ thành mớ hỗn độn — service A dùng singleton, service B dùng env vars, service C hardcode path. Ai từng debug production lúc 3 giờ sáng vì một config sai thì hiểu cái cảm giác muốn đập bàn phím.

Cái giá của release notes "cho có"

Điều khiến mình ấn tượng không chỉ là tính năng mới, mà là cách Zig trình bày nó. Mỗi thay đổi đi kèm: lý do tại sao, ví dụ code trước/sau, và edge cases cần lưu ý. Simon Willison — người mà giới AI chắc không ai không biết — phải gọi đây là release notes "comprehensive, detailed" nhất mà ông thấy.

Giờ đặt cạnh thực tế mình gặp hàng tuần: một framework agent update minor version, changelog ghi đúng một dòng "fixed bugs and improved performance". Bạn upgrade, app sập. Lục GitHub issues mới phát hiện họ đổi API mà quên thông báo.

Nếu bạn từng theo dõi bài mình viết về chuyện demo ngon nhưng production sập, thì đây là một nguyên nhân thường bị bỏ qua: không phải code bạn tệ, mà là thông tin giữa upstream và downstream bị đứt gãy. Release notes tốt giống như hệ thống biển báo giao thông — thiếu nó, tai nạn là chuyện sớm muộn.

Khi cái bot CI/CD của bạn... âm thầm tắt thở

Câu chuyện thứ hai còn nhức đầu hơn. Simon Willison maintain một thư viện Python tên asgi-gzip, extract từ Starlette. Thư viện này có một GitHub Actions workflow chạy scheduled để check xem Starlette có fix gì mới cần port về không.

Vấn đề? Cái workflow đó âm thầm ngừng chạy. Không ai hay. Kết quả: Starlette đã fix lỗi nén SSE (Server-Sent Events) responses từ lâu, nhưng asgi-gzip vẫn chạy code cũ, compress nhầm text/event-stream. Đến khi Simon deploy tính năng SSE mới lên production — boom.

Ví dụ cụ thể cho dân AI: giả sử team bạn có pipeline ML với scheduled retraining job chạy hàng tuần. Job fail silent từ tháng trước vì một dependency thay đổi. Model cũ vẫn serve, metric nhìn ổn vì data chưa drift nhiều. Đến lúc cần model mới — "Ủa, sao nó không retrain từ bao giờ?"

Nói thẳng ra thì: scheduled automation mà không có health check giống xe chạy không có đèn báo dầu — đến lúc chết máy giữa đường mới biết.

Thử ngay chiều nay: audit "đèn báo" trong stack của bạn

Không cần đợi sập production. Ba việc làm được trong một buổi chiều:

1. Kiểm tra scheduled workflows

# Liệt kê recent runs của một workflow
gh run list --workflow=your-workflow-name --limit=5
# Nếu run cuối cùng đã quá lâu → red flag

Workflow nào không chạy trong 2 tuần trở lên mà không có lý do? Đó là "đèn engine" đang sáng.

2. Pin version + đọc changelog trước khi upgrade

Đừng pip install --upgrade bừa bãi. Đọc changelog diff giữa version hiện tại và version mới. Nếu changelog chỉ ghi "bug fixes" mà không nói rõ fix gì — đó là tín hiệu cần thêm integration test trước khi merge.

3. Thêm heartbeat cho critical scheduled jobs

Cách đơn giản nhất: cuối mỗi job, gửi một ping đến healthcheck service (Uptime Robot, healthchecks.io, hoặc đơn giản là post vào Slack channel). Không có ping = something went wrong. Mất 15 phút setup, tiết kiệm vô số đêm mất ngủ.

Cái bẫy "chạy ổn rồi đừng đụng"

Mình từng chứng kiến một team deploy RAG pipeline, dùng thư viện chunking open-source. Thư viện đó release version mới, sửa bug tokenization quan trọng — nhưng team pin version cũ vì triết lý "don't touch what works". Sáu tháng sau, cần hỗ trợ model mới, upgrade lên thì API đổi hoàn toàn, phải refactor cả pipeline. Thời gian "tiết kiệm" được từ việc không upgrade bay sạch trong hai sprint khẩn cấp.

Bài học: pin version là đúng, nhưng pin rồi quên thì còn nguy hiểm hơn không pin. Giống đậu xe rồi khóa cổng — tốt — nhưng quên kiểm tra xe có còn nổ máy không thì lúc cần chạy gấp lại đứng hình.

Một takeaway duy nhất

Zig 0.16.0 và cái bug asgi-gzip kể cùng một câu chuyện: phần mềm tốt không chỉ là code hay, mà là communication hay. Release notes rõ ràng, CI/CD có health check, dependency management có chiến lược — những thứ nghe không sexy chút nào lại là thứ giữ production sống qua đêm.

Lần tới trước khi hào hứng chạy theo model mới hay framework hot, hãy tự hỏi: "Cái scheduled job tuần trước của mình có còn chạy không?" Đôi khi câu trả lời sẽ khiến bạn mất ngủ — nhưng ít nhất là mất ngủ chủ động, chứ không phải bị dựng dậy bởi PagerDuty lúc 3 giờ sáng.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng