Bài học từ Sự cố#

Sự cố này tiết lộ một sự thật cơ bản về AI coding agents: chúng cực kỳ giỏi làm theo hướng dẫn và cực kỳ tệ trong việc hiểu hậu quả.

Agent đã làm chính xác những gì được yêu cầu — gom policies. Nó không hiểu rằng một số policies đó tạo thành ranh giới bảo mật không nên vượt qua. Ba thất bại cụ thể:

1. Credentials overscoped — Sandbox có full IAM write access thay vì read-only có phạm vi
2. Trusted policy diff — Diff 200 dòng bị collapse mặc định; việc mở rộng quyền vô hình
3. Không có safety check policy — Không có xác minh pre-commit rằng thay đổi giữ nguyên ranh giới truy cập ban đầu

Cách Kiro Đã Sửa#

Sau sự cố, Kiro thêm một số tính năng bảo mật hiện là tiêu chuẩn:

1. Policy-aware sandboxing — MCP integrations liên quan đến hạ tầng (IAM, Terraform, CloudFormation) chạy trong restricted sandbox theo mặc định
2. Permission diff highlights — Khi PR thay đổi IAM/service roles, agent tự động highlight delta quyền trong mô tả PR
3. Guardrails configuration — .kiro/kiro.json chấp nhận deny rules tường minh

Thiết lập Guardrails#

Trong .kiro/kiro.json:

1
{
2
  "guardrails": {
3
    "deny": {
4
      "actions": [
5
        "grant_admin_access",
6
        "modify_network_security_groups",
7
        "delete_production_database"
8
      ],
9
      "resources": [
10
        "arn:aws:iam::*:role/production-*",
11
        "arn:aws:s3:::*-production"
12
      ],
13
      "patterns": [
14
        "AWS_SECRET_ACCESS_KEY",
15
        "DATABASE_URL_PRIMARY"
16
      ]
17
    },
18
    "requireApproval": {
19
      "files": ["**/Dockerfile", "**/docker-compose*.yml", "**/*-config/production.*"],
20
      "patterns": ["DELETE FROM", "DROP TABLE", "GRANT ALL"]
21
    }
22
  }
23
}

Cấu hình này bảo Kiro:

• Deny — Không bao giờ thực hiện các hành động này, chạm vào tài nguyên này, hoặc viết các pattern này
• Require approval — Đánh dấu các file/pattern này cần human review trước khi áp dụng

Danh sách deny tự động được kiểm tra ở ba giai đoạn: spec generation, task execution và PR creation. Nếu spec được tạo bao gồm hành động bị từ chối, Kiro từ chối trước khi code nào được viết.

Vệ Sinh Token và Credential#

Từ Day 3, chúng ta đã đề cập cơ bản (không hardcode token, read-only trước). Đây là hệ thống hoàn chỉnh:

Quy tắc quan trọng nhất: không bao giờ kết nối Kiro với AWS credentials production của bạn. Dùng staging/production-isolated sandbox. Autonomous agent chạy trong môi trường cloud riêng, nhưng nếu bạn cấu hình nó với full AWS access, khác biệt duy nhất giữa Kiro và một vụ rò rỉ bảo mật là khả năng review PR trước khi merge.

1. Steering File Là Single Source of Truth#

Steering file định nghĩa “hiến pháp” dự án của bạn. Mọi thành viên team và mọi AI agent đều tham chiếu nó. Hãy giữ nó:

• Trong version control — Track .kiro/steering.md trong git. Thay đổi cần qua PR review như bất kỳ thay đổi code nào.
• Review hàng quý — Khi dự án phát triển, cập nhật steering files phản ánh quyết định kiến trúc mới.
• Ngắn gọn nhưng cụ thể — Steering file 20 dòng tập trung vào các ràng buộc critical tốt hơn tuyên ngôn 200 dòng không ai đọc.

Steering files tốt tập trung vào: không nên làm gì, nên theo pattern nào, và cách xử lý bảo mật.

2. Spec Review Hoạt Động, Nếu Bạn Làm#

Giai đoạn spec generation (Day 2) bắt được nhiều bugs hơn code review. Các team đầu tư 5 phút review spec trước khi phê duyệt thấy:

• Ít hơn 40% PR iterations so với bỏ qua spec review
• Ít hơn 60% security escapes — edge cases được đánh dấu trước khi code tồn tại
• Task decomposition tốt hơn — component thiếu được phát hiện sớm

Điểm đau: rất dễ liếc spec và bấm approve. Đừng. Đọc acceptance criteria và edge cases. Đó là nơi bugs ẩn náu.

3. Giới Hạn Concurrent Autonomous Tasks#

Autonomous agent có thể chạy 10 task đồng thời (Day 4). Kinh nghiệm team gợi ý:

Chạy 10 task đồng thời không giám sát là cách bạn thức dậy với 10 PRs đều cần rework đáng kể. Bắt đầu với 3. Chỉ tăng khi bạn tin tưởng chất lượng output của agent.

4. Hooks: Bắt Đầu Nhỏ, Mở Rộng Sau#

Sai lầm phổ biến nhất với Kiro: tạo 15 hooks ngày đầu tiên. Mỗi hook đốt credits và có thể tạo noise.

Bắt đầu với ba hooks này:

1
on_commit: Quét secrets (không thể thương lượng)
2
on_save → "src/**/*.ts": Type-check (bắt lỗi sớm)
3
on_pr_open: Tạo mô tả PR (tiết kiệm thời gian)

Thêm hook khác chỉ khi có pain point cụ thể.

5. MCP: 3 Servers, Không Phải 5#

Kiro hỗ trợ đến 5 MCP server đồng thời. Dùng ít hơn:

• Bắt đầu với 1-2 — MCP servers liên quan nhất đến sprint hiện tại
• Không bao giờ quá 3 cho công việc hàng ngày — Nhiều server hơn = planning chậm hơn + token consumption cao hơn
• Dùng Powers khi có thể — Chúng đã được pre-tested và tối ưu cho Kiro

Thiết lập MCP phổ biến nhất: version control (GitHub/GitLab) + database (PostgreSQL/Supabase) + documentation (Context7/Notion).

6. Luôn Giữ Con Người Trong Vòng Lặp#

Per-task approval mode của Kiro không chỉ là checkbox. Cho bất kỳ thứ gì chạm production infrastructure, security configuration, hoặc database schema:

1. Review spec trước khi thực thi
2. Review diff trước khi merge
3. Chạy staging tests trước production

Autonomous agent là trợ lý async, không phải người ra quyết định tự động. Hãy đối xử với nó như junior developer đọc docs nhanh nhưng thiếu judgment.

Kiro vs Claude Code#

Kết luận: Claude Code tốt cho inline work — hỏi câu, nhận câu trả lời, tiếp tục. Kiro thắng cho dự án cần structured workflows, cross-repo changes và async execution. Nếu công việc chủ yếu là sửa file đơn lẻ và đặt câu hỏi, Claude Code rẻ hơn và nhanh hơn.

Kiro vs Cursor#

Kết luận: Tab completion và inline editing của Cursor tốt hơn đáng kể cho rapid iteration. Spec-driven mode của Kiro mạnh hơn cho complex features nhưng cần đầu tư upfront nhiều hơn. Cho prototyping, Cursor nhanh hơn. Cho production features với yêu cầu rõ ràng, Kiro tạo output đáng tin cậy hơn.

Kiro vs GitHub Copilot#

Kết luận: Copilot là lựa chọn giá phải chăng nhất cho developer cá nhân chủ yếu cần code completion và chat. Kiro nhắm vào vấn đề khác: team cần orchestrate AI xuyên repo, enforce standards và tự động hóa quality checks. Chúng không thực sự cạnh tranh — Copilot là autocomplete tốt hơn, Kiro là development environment tốt hơn.

Khi Nào Không Nên Dùng Kiro#

Thành thật:

1. Bạn là solo developer xây single-page apps — Quá đắt. Dùng Copilot hoặc Claude Code.
2. Team không code review — Safety model của Kiro dựa vào human review. Không có nó, bạn đang cho AI write access vào hạ tầng.
3. Bạn làm việc trong air-gapped environments — Kiro cần internet cho auth và updates. Claude Code có thể chạy offline trong terminal.
4. Dự án của bạn zero tests — Spec-driven workflow tạo test files, nhưng nếu không có test suite hiện tại để verify, bạn mất lợi ích chính của verification phase.
5. Bạn cần kiểm soát chi phí chi tiết — Credit model của Kiro dựa trên consumption. Nếu team chạy 50 hooks mỗi ngày, chi phí tăng nhanh. Copilot $39/tháng flat dễ dự đoán hơn.

Khi Nào Chắc Chắn Nên Dùng Kiro#

1. Bạn duy trì 10+ microservices — Cross-repo refactoring một mình justify chi phí
2. Team bạn struggle với code consistency — Steering file enforce standards xuyên tất cả PRs
3. Bạn đang migrate codebase lớn — Framework upgrades, library changes, cloud migrations
4. Security compliance bắt buộc — Guardrails, deny lists và per-file approval modes
5. Bạn muốn async development — Ủy thác công việc và review kết quả sau