Vài ngày nay, cộng đồng WordPress xôn xao về một phát biểu của Chris Reynolds — người đứng đầu Developer Relations tại Pantheon — tại WordCamp US 2026. Buổi nói chuyện có tên hơi buồn cười là Parenting Claude: Guardrails for AI Assisted Development, nhưng nội dung thì nghiêm túc bất thường: nếu bạn để AI viết code cho website WordPress mà không có rào chắn, sớm muộn nó cũng đưa secret key lên repo công khai hoặc gắn một hàm nào đó tự gọi API mỗi lần load trang.
Trong bài này, mình sẽ tóm tắt những ý chính từ buổi nói chuyện và phiên bản podcast WP Tavern số 233 phát hành ngày 10/9/2026, rồi đi thẳng vào phần thực hành: cách dựng một bộ guardrails tối thiểu cho dự án WordPress dùng AI coding — gồm project contract, pre-commit hook và reviewer agent. Tất cả đều làm được trong một buổi chiều, không cần hạ tầng phức tạp.
AI viết code WordPress nhanh hơn nhưng vì sao lại nguy hiểm hơn?
Vì AI như Claude hay GPT là mô hình không tất định (non-deterministic): cùng một prompt, hai lần chạy có thể ra hai đoạn code khác nhau. Chris Reynolds mô tả trải nghiệm của chính ông: AI cực kỳ mạnh trong việc dựng nhanh chức năng, nhưng cũng cực kỳ tự tin khi chèn những thứ bạn không hề yêu cầu — thư viện lỗi thời, hàm deprecated của WordPress, hoặc lệnh gọi network ngay trong loop. Rào chắn không phải để hạn chế AI, mà để bạn ngủ ngon.
Project contract là gì và vì sao plugin WordPress của bạn cần nó?
Project contract là một file quy tắc đặt ngay trong repo, buộc AI tuân theo trước khi viết bất kỳ dòng code nào. Nó khai báo chuẩn code, phiên bản PHP tối thiểu, hàm WordPress nào bị cấm, và checklist bắt buộc trước khi nộp code. Nhờ đó mọi phiên làm việc với AI đều xuất phát từ cùng một bộ luật, thay vì bạn nhắc lại yêu cầu từng lần rồi quên mất lần sau. Đây là ý tưởng trung tâm của buổi nói chuyện, và mình thấy nó đúng với cả team một người.
Làm thế nào dựng project contract cho dự án WordPress trong 30 phút?
Bạn tạo một file CLAUDE.md hoặc AGENTS.md ở thư mục gốc plugin, nội dung tối thiểu như sau:
# Project Contract
- PHP minimum: 8.0, khai báo strict_types=1.
- WordPress minimum: 6.5, dùng WP 7.x APIs.
- Cấm: eval(), base64_decode để chạy code, query trực tiếp $_GET.
- Mọi query phải dùng $wpdb->prepare() hoặc WP_Query.
- Escape đầu ra: esc_html(), esc_attr(), esc_url().
- Nonce + capability check cho mọi AJAX và form handler.
- Không gọi network trong init hay loop; phải qua wp_remote_get với caching.
- Không hardcode secret; đọc từ constant hoặc wp_options.
Guardrails không phải ý tưởng mới — trong bài bảo mật WordPress thời AI mình đã từng đề cập checklist WP-CLI của cựu trưởng nhóm security WordPress. Lần này đi sâu hơn một tầng: chặn lỗi từ lúc code mới được sinh ra.
Sau đó bạn tham chiếu file contract này trong prompt khởi đầu của mỗi phiên: “Đọc project contract trước khi sửa code”. Các công cụ coding hiện đại đều tự nộp file này vào ngữ cảnh nếu nó nằm ở thư mục gốc. Mẹo của mình: giữ contract ngắn dưới 50 dòng, AI tuân theo quy tắc ngắn tốt hơn nhiều so với văn bản dài.
Cấu hình pre-commit hook chặn AI chèn code nguy hiểm thế nào?
Pre-commit hook là lớp phòng thủ thứ hai chạy ngay khi bạn gõ git commit, bất kể code do người hay AI viết. Bạn cài package husky hoặc dùng thuần shell script tại .git/hooks/pre-commit:
#!/bin/bash
# Chặn pattern nguy hiểm AI hay sinh ra
PATTERNS='eval\(|base64_decode\(|\$_GET\['
if git diff --cached | grep -E "$PATTERNS"; then
echo "Phát hiện pattern nguy hiểm. Commit bị chặn."
exit 1
fi
# Chạy PHPCS với chuẩn WordPress
./vendor/bin/phpcs --standard=WordPress --extensions=php src/ || exit 1Đơn giản vậy thôi, nhưng nó đã chặn được phần lớn lỗi mà Chris nhắc đến trong podcast: code chạy được nhưng vi phạm chuẩn WordPress coding standards hoặc chứa hàm nguy hiểm. Bạn nhớ chmod +x .git/hooks/pre-commit để script có quyền chạy.
Reviewer agent kiểm tra code AI như thế nào?
Lớp thứ ba là một AI khác đóng vai reviewer. Cách làm của Chris Reynolds: sau khi AI coding xong, bạn mở phiên AI thứ hai với prompt kiểu “Bạn là senior WordPress engineer, rà soát diff theo checklist bảo mật: SQL injection, XSS, CSRF, broken access control, và đối chiếu với project contract”. Hai AI kiểm tra chéo nhau khiến xác suất lỗi sót giảm rõ rệt, vì reviewer không bị “cảm xúc” với code nó vừa viết. Bạn có để hai reviewer agent khác nhau lần lượt chạy, kết quả chênh nhau ở đâu thì đó chính là chỗ cần nhìn kỹ.
Developer WordPress có bị AI thay thế không?
Theo Chris, không phải bị thay thế mà là chuyển vai: developer trở thành người thiết kế quy tắc, rà soát và chịu trách nhiệm cuối cùng. Ông cũng lưu ý một rủi ro ít ai nhắc: thế hệ mới học code bằng AI có thể không từng viết vòng lặp thủ công, nên khi AI sai ở khái niệm nền tảng, họ không có khả năng phát hiện. Kỹ năng đọc code vì thế trở nên quý hơn kỹ năng gõ code — một điều mình hoàn toàn đồng ý sau vài tháng dùng AI cho dự án khách hàng.
Bắt đầu từ đâu nếu bạn quản trị website WordPress?
Nếu bạn không phải developer nhưng hay nhờ AI viết snippet cho file functions.php, mình đề xuất khởi động tối giản: tạo một file quy tắc 10 dòng (cấm eval, bắt buộc escape, phải có nonce), lưu cạnh workspace của bạn, và dán vào đầu mỗi lần hỏi AI. Chỉ riêng bước này đã loại bỏ được phần lớn snippet “chạy được nhưng hở”. Khi đã quen, bạn nâng cấp lên pre-commit hook như hướng dẫn trên. Guardrails không làm bạn chậm đi — nó giúp bạn dám để AI chạy nhanh.
