aws-samples/sample-autonomous-cloud-coding-agents

Азбука

Автономные кодирующие агенты на AWS

[!ПРИМЕЧАНИЕ] ** Текущая версия ABCA остается доступной для использования и не обесценивается. Он находится в режиме обслуживания и будет продолжать получать обновления и исправления безопасности.

Команда инвестирует в следующую версию ABCA (V2), основанную на отзывах клиентов, извлеченных уроках и достижениях в отрасли. Мы разделяем это направление рано, чтобы сигнализировать о будущем переходе. ** В настоящее время миграция не требуется.

##Что такое АВС

ABCA (Autonomous Background Coding Agents on AWS) является образцом того, как может выглядеть платформа самоорганизующихся агентов фонового кодирования на AWS. Вы отправляете задачу кодирования (через Slack, Linear, Jira, CLI или webhook), уходите и возвращаетесь к готовому к просмотру PR. Агент клонирует репо, пишет код, запускает тесты и самостоятельно открывает PR в изолированной облачной среде. Никаких нянь, никаких сессий IDE, никаких задних и задних.

Почему это важно

** Возврат инженерного времени** — рутинная работа выполняется в фоновом режиме, в то время как люди сосредоточены на дизайне и решениях. Быстрый цикл — задачи выполняются 24/7, без очереди за календарём человека

[!NOTE] The current version of ABCA remains available for use and is not deprecated. It is in maintenance mode and will continue to receive updates and security fixes.

The team is investing in the next version of ABCA (V2), informed by customer feedback, lessons learned, and advances across the industry. We are sharing this direction early to signal a future transition. No migration is required at this time.

What is ABCA

ABCA (Autonomous Background Coding Agents on AWS) is a sample of what a self-hosted background coding agents platform might look like on AWS. You submit a coding task (via Slack, Linear, Jira, CLI, or webhook), walk away, and come back to a ready-to-review PR. The agent clones the repo, writes code, runs tests, and opens the PR autonomously in an isolated cloud environment. No babysitting, no IDE sessions, no back-and-forth.

Why it matters

• Reclaim engineer time — routine work runs in the background while humans focus on design and decisions
• Faster cycle time — tasks execute 24/7, no queue behind a human’s calendar
• Consistent quality — every run includes lint, tests, and policy checks by default
• Learns over time — memory system captures PR feedback and improves future runs
• Cost-controlled — per-task budgets, concurrency limits, and blast-radius enforcement built in

The Use Case

Users submit tasks through webhooks, CLI, Slack, Linear, Jira,… For each task, the orchestrator executes the blueprint: an isolated environment is provisioned, an agent clones the target GitHub repository, creates a branch, works on the task, and opens a pull request.

Key characteristics:

• Ephemeral environments — each task starts fresh, no in-process state carries over
• Asynchronous — no real-time conversation during execution
• Repository-scoped — each task targets a specific repo
• Outcome-measurable — the PR is either merged, revised, or rejected
• Fire and forget — submit, forget, review the outcome
• Learns over time — the more you use it, the more it self-improves

How it works

Each task follows a blueprint — a hybrid workflow that mixes deterministic steps (no LLM, predictable, cheap) with agentic steps (LLM-driven, flexible, expensive):

1. Admission — the orchestrator validates the request, checks concurrency limits, and queues the task if needed.
2. Context hydration — the platform gathers context: task description, GitHub issue body, repo-intrinsic knowledge (CLAUDE.md, README), and memory from past tasks on the same repo.