Tôi muốn nói về một con số mà tôi cứ nghĩ mãi: 1.300 pull request mỗi tuần. Đó là những gì team kỹ thuật nội bộ của Stripe đang tạo ra với các agent code tự trị của họ, được gọi là “Minions.” Không phải bản nháp. Không phải gợi ý. Những pull request sẵn sàng cho production xuất phát từ các tin nhắn Slack, báo cáo lỗi và yêu cầu tính năng — được xử lý bởi LLM sử dụng blueprint và CI/CD pipeline, với code review của con người là cổng cuối cùng.

Đây là sự chuyển đổi mà tôi đã theo dõi trong ba năm qua. Nó không còn là lý thuyết nữa. Kỷ nguyên AI agentic đang diễn ra bên trong các tổ chức kỹ thuật production ngay lúc này.

”Agentic” Thực Sự Có Nghĩa Gì Trong Production

Thuật ngữ này bị dùng khá tùy tiện. Đây là định nghĩa tôi sử dụng: một agent là hệ thống AI có thể thực hiện các chuỗi hành động, sử dụng công cụ và điều chỉnh hành vi dựa trên kết quả trung gian — mà không cần con người ở trong vòng lặp mỗi bước.

Sự tiến triển trông như thế này:

1. Chatbot: Bạn hỏi một câu hỏi, nó trả lời một lần
2. Copilot: Nó gợi ý completions hoặc đoạn code ngắn inline
3. Assistant với tools: Nó có thể gọi API, tìm kiếm, viết file — nhưng từng tác vụ một
4. Agent: Nó phân tách mục tiêu thành các subtask, thực thi chúng qua nhiều hệ thống, xử lý thất bại và trình bày kết quả cuối cùng

Hầu hết các team kỹ thuật hiện đang ở đâu đó giữa bước 2 và 3. Stripe đang ở bước 4, ở quy mô lớn.

Minions của Stripe: 1.300 PR/Tuần Thực Sự Cần Gì

Thách thức kỹ thuật không phải là LLM — mà là mọi thứ xung quanh nó. Từ những gì đã được mô tả công khai, hệ thống Minion của Stripe hoạt động như thế này:

Tiếp nhận tác vụ: Một tin nhắn Slack hoặc báo cáo lỗi đến. Hệ thống phân loại nó, xác định xem nó có thể tự động hóa không và định tuyến đến agent.

Thực thi blueprint: Các agent tuân theo “blueprint” — playbook có cấu trúc cho các loại tác vụ phổ biến (sửa loại lỗi này, thêm loại test này, implement loại endpoint này). Đây về cơ bản là system prompt với context chuyên biệt về conventions codebase của Stripe.

Sử dụng công cụ: Các agent đọc code, viết code, chạy test, kiểm tra kết quả CI. Chúng lặp lại — nếu test thất bại, chúng sửa và thử lại.

Code review của con người: PR cuối cùng đi qua code review bình thường. Con người không chỉ đạo agent trong quá trình thực thi; họ xác nhận output.

# Cấu trúc khái niệm của vòng lặp agent code
async def minion_agent(task_description: str, codebase_context: dict):
    plan = await llm.plan_task(task_description, codebase_context)

    for step in plan.steps:
        result = await execute_tool(step.tool, step.params)

        if step.requires_verification:
            test_result = await run_tests(result.changed_files)
            if not test_result.passed:
                # Agent thử lại với context lỗi
                result = await llm.fix_error(test_result.error, result)

    pr = await create_pull_request(result.changes, plan.description)
    return pr  # Con người review từ đây

Nhận định then chốt: các agent có giá trị nhất khi không gian tác vụ được xác định rõ ràng nhưng việc thực thi thì tẻ nhạt. Sửa một loại lỗi đã biết, thêm test vào một pattern hiện có, cập nhật các lệnh gọi API khi một dependency thay đổi — đây chính xác là các loại công việc làm tốn kệ của các senior engineer.

Responses API của OpenAI: Hạ Tầng Cho Agents

Trong khi Stripe tự xây dựng, OpenAI đang cố gắng cung cấp cho mọi người hạ tầng để xây dựng các hệ thống tương tự. Việc mở rộng Responses API gần đây có ý nghĩa quan trọng với developers:

Shell tool: Các agent bây giờ có thể thực thi lệnh shell trong môi trường sandbox. Điều này có nghĩa là một agent code không chỉ viết code mà còn thực sự chạy nó, xem output và lặp lại.

Vòng lặp thực thi agent tích hợp: Thay vì bạn quản lý chu kỳ tool-call/response/tool-call, API xử lý nó. Bạn định nghĩa các công cụ có sẵn và model chạy cho đến khi có câu trả lời cuối cùng — hoặc đạt giới hạn đã cấu hình.

Workspace container được host: File system liên tục cho các lần chạy agent. Agent có thể viết file, đọc lại, cài package, compile code — tất cả trong sandbox được quản lý.

Context compaction: Các agent chạy lâu tạo ra context dài. API bây giờ xử lý compaction tự động, giữ chi phí có thể quản lý được mà không mất lịch sử quan trọng.

Agent skills có thể tái sử dụng: Các khả năng được xây dựng sẵn (tìm kiếm web, thực thi code, file I/O) mà bạn kết hợp thay vì implement.

from openai import OpenAI

client = OpenAI()

# Mới: API xử lý vòng lặp tool cho bạn
response = client.responses.create(
    model="gpt-5.4",
    tools=[
        {"type": "shell"},           # Có thể thực thi lệnh
        {"type": "file_system"},     # Workspace liên tục
        {"type": "web_search"}       # Thông tin trực tiếp
    ],
    instructions="Bạn là senior code reviewer. Phân tích PR diff được cung cấp và tạo review.",
    input="<NỘI_DUNG_PR_DIFF>",
    max_turns=10  # Số lần lặp tối đa
)

print(response.output)  # Câu trả lời cuối cùng sau khi dùng tool

Điều này quan trọng vì rào cản lớn nhất để xây dựng agent không phải là model — mà là plumbing. Quản lý các vòng lặp tool call, xử lý retry, đối phó với giới hạn context — đây là các vấn đề kỹ thuật thực sự khó. Responses API trừu tượng hóa hầu hết chúng.

AWS Strands Labs: Chiến Lược Open-Source

Amazon Web Services đi theo hướng khác với Strands Labs — một tổ chức GitHub mới cho các dự án thử nghiệm liên quan đến agent. Điều này định vị AWS là người đóng góp vào hệ sinh thái agent open-source thay vì chỉ là cloud host.

Góc độ chiến lược: nếu bạn đang thử nghiệm với các dự án Strands Labs và chúng hoạt động tốt, bạn có khả năng triển khai trên hạ tầng AWS. Đây là phiên bản developer relations của cloud provider thông qua tooling.

Với các team đã sử dụng AWS Bedrock và Lambda, điều này tạo ra một con đường thú vị:

# Pattern agent theo kiểu Strands Labs khái niệm
import boto3
from strands import Agent, Tool

@Tool
def query_database(sql: str) -> str:
    """Thực thi truy vấn database chỉ đọc"""
    # Implementation của bạn
    pass

@Tool
def analyze_logs(service_name: str, hours: int) -> str:
    """Kéo và phân tích CloudWatch logs"""
    # Implementation của bạn
    pass

agent = Agent(
    model="anthropic.claude-sonnet-4-6-v1",
    tools=[query_database, analyze_logs],
    system_prompt="Bạn là chuyên gia phân tích hạ tầng. Chẩn đoán vấn đề được báo cáo."
)

result = agent.run("Độ trễ production tăng đột biến 3 giờ trước. Tìm nguyên nhân gốc rễ.")

Sức hút: bạn định nghĩa tools như các function Python, framework xử lý orchestration, và bạn chạy nó trên hạ tầng AWS mà bạn đã vận hành.

Điều Engineering Leaders Cần Rút Ra

Ba quan sát cụ thể từ việc theo dõi không gian này chặt chẽ:

1. Vấn đề đánh giá bây giờ là quan trọng nhất. Khi các agent tạo ra 1.300 PR mỗi tuần, làm sao bạn biết chúng tốt? Code review của con người giúp ích nhưng không mở rộng vô hạn. Các team cần pipeline đánh giá tự động — không chỉ là test suite mà còn kiểm tra ngữ nghĩa, quét bảo mật và tuân thủ phong cách có thể phát hiện vấn đề trước khi code review của con người.

2. Chất lượng blueprint quyết định chất lượng agent. LLM không biết các conventions codebase của bạn trừ khi bạn cho nó biết. Các team thấy kết quả tốt nhất từ coding agent đầu tư nhiều vào việc viết các playbook chi tiết, có cấu trúc — về cơ bản là tài liệu mà con người cũng được hưởng lợi. Đây là đòn bẩy: một blueprint được viết tốt cho phép hàng trăm implementation tự động.

3. Cổng code review của con người không thể là bóng cao su. Khi các agent trở nên có khả năng hơn và tạo ra nhiều output hơn, cám dỗ là review PR nhanh hơn. Đây là chế độ thất bại. Duy trì hoặc tăng sự nghiêm ngặt trong review; khối lượng nên được xử lý bởi tooling tốt hơn (AI-assisted review, automated checks) không phải bằng cách cắt góc.

Con Đường Thực Tế Tiến Về Phía Trước

Nếu bạn muốn giới thiệu khả năng agentic cho team kỹ thuật của mình trong năm 2026, đây là cách tôi sẽ xếp thứ tự:

Tháng 1-2: Tự động hóa một tác vụ duy nhất, tần suất cao, được xác định rõ ràng. Tạo test là lý tưởng — bạn có tiêu chí đúng đắn rõ ràng (test pass), giá trị rõ ràng (coverage tăng) và rủi ro có giới hạn (test không tự triển khai lên production).

Tháng 3-4: Mở rộng sang hỗ trợ code review. Không thay thế, mà tăng cường — một agent phát hiện các vấn đề tiềm năng trước khi code review của con người. Điều này xây dựng sự tin tưởng vào output của agent với rủi ro thấp.

Tháng 5-6: Giới thiệu việc tạo PR có giới hạn cho các loại tác vụ được hiểu rõ. Bắt đầu với cập nhật dependency, sửa lỗi đánh máy hoặc thay đổi tài liệu. Đo lường tỷ lệ sửa đổi (phần trăm PR agent cần thay đổi đáng kể trước khi merge).

Tháng 7+: Mở rộng sang các tác vụ phức tạp hơn dựa trên dữ liệu từ các giai đoạn trước. Lúc này bạn hiểu các chế độ lỗi của agent và có tooling đánh giá để phát hiện chúng.

Kết quả của Stripe — 1.300 PR mỗi tuần — không xảy ra chỉ qua đêm. Đó là output của nhiều năm lặp lại về định nghĩa tác vụ, chất lượng blueprint, tích hợp tool và đánh giá. Các tổ chức bắt đầu xây dựng những khả năng này ngay bây giờ sẽ có lợi thế đáng kể khi tooling trưởng thành hơn.

Bắt đầu với một tác vụ. Làm cho nó hoạt động tốt. Sau đó mở rộng.