Agent Teams in Claude Code: From Task to Release

--- title: "Agent Teams in Claude Code: how I built a process from task to release" description: "Developer Sergey Ladygin has been using Claude Code Agent Teams for autonomous development for six months: 12 roles, 44 releases, 8 model versions without rewriting roles." tags: [claude-code, agent-teams, automation] ### ⚡ The Gist in 5 Seconds - Sergey Ladygin has spent six months developing a service without a team: Claude Code agents write the code, he sets tasks and accepts the results. - The Agent Teams feature in Claude Code is enabled with the experimental environment variable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. - The process is autonomous, but human control is preserved at two points: plan approval in /weekly and result acceptance in /implement. Without a response, the agent launches nothing and spends nothing. ### 🔍 What Was Found In March 2026, developer Sergey Ladygin began building a service for Scrum team retrospectives on a Go, Next.js, PostgreSQL, Docker stack. At first, he and Claude put together a lengthy spec and ran one task per session, but he couldn't keep up with reviewing the results: Claude produced code faster than the author could accept it. So he added QA and DevOps roles, and then built out a full pipeline. As of September 2026, the project repository contains: 14 role-based teams (12 roles) plus 3 subagents for tests, 73 architectural decisions (ADRs), 37 files with failure diagnoses, 331 test cases, 146 integration test files, 110 analyzed bugs, 6 weekly reports, 409 commits, 70 PRs, and 44 release tags. The median time from the first commit on a branch to merge is 3.9 hours. Roles are markdown files with prompts in the.claude/commands folder. The tech lead creates the team via Agent Teams and launches the others as teammates with tasks and dependencies. Key roles: weekly analyst, on-call for production, marketer and writer, tech lead, architect, backend and frontend, DevOps, QA, documentation, plus a planner, test generator, and test healer. The roles have strict prohibitions: the tech lead doesn't write code, QA doesn't fix bugs, frontend doesn't hardcode colors and spacing, and the healer doesn't ask questions. Teams are launched via scenarios: /weekly — once a week for metrics and planning, /implement — per task, /bugfix — for defects, /triage — triaging errors from Sentry, /marketing — copywriting and measuring impact. After the /weekly plan is approved, it automatically launches /implement, and several teams work on the project in parallel, each returning its own PR. ### 💡 Why It Matters The main takeaway is that the process rests on files in the repository, not on a specific model. Eight model versions were swapped over six months, and not a single role had to be rewritten. The roles are duplicated in formats for Codex: skills, agent configs, and a shared AGENTS.md. This means the scheme can be transferred between tools and models. For a solo developer, this approach removes the "me myself" bottleneck: agents not only write code but also test it in the browser, write tests, rebuild the environment, and maintain documentation. The developer retains control at key points: approving the plan and accepting the result. ### 🧩 Context The impetus for the experimen

🔗 Read on habr.com