Building a Fully Autonomous Development Agent

The Capstone Scenario

Everything in this track has been building toward a question: what does a real autonomous development agent look like when you assemble the tools together? This lesson works through a concrete example — a nightly code health agent — and shows how each layer from Routines to Dynamic Workflows to /goal fits into the design.

The agent's job: every night, audit the codebase for quality regressions introduced since the last run, attempt to fix them automatically, and open a draft PR with its findings and any fixes it made. No human runs it. No human reviews intermediate steps. A human reviews the PR in the morning and decides whether to merge.

This is not a toy example. It's the pattern behind real production automation at organizations running Claude Code at scale.

Stage 1: The Cloud Routine

The outermost layer is a cloud Routine with a schedule trigger. It runs every night at 2am, on Anthropic's infrastructure, whether or not your machine is on.

The Routine's prompt is the high-level directive: "Audit all files changed in the last 24 hours for code quality regressions — unused variables, missing error handling, type safety issues, and test coverage gaps. Fix anything you can fix safely. Open a draft PR with your findings and changes."

Key Routine settings:

• Repository: the main repo, starting from the default branch
• Branch permissions: Claude creates claude/nightly-health-YYYY-MM-DD branches automatically; no unrestricted push needed
• Connectors: GitHub connector for PR creation; remove any connectors the agent doesn't need
• Environment: Default (Trusted network access) is sufficient for most codebases

Stage 2: The Dynamic Workflow Audit

Inside the Routine's session, the first action is discovery: which files changed in the last 24 hours? That's a single git log command. But auditing each of those files for quality issues is parallelizable work that can easily exceed the context window for large repositories.

Claude writes and launches a Dynamic Workflow from within the Routine session:

ultracode: audit every file from the git log output for quality regressions, working on each file in parallel and cross-verifying each finding

The workflow script fans out one audit agent per changed file, uses a pipeline to run them concurrently up to 16 at a time, and runs adversarial verification — a second agent reviewing each finding before it's reported. Findings that don't survive verification are filtered out. The workflow returns a structured list of verified issues to the Routine session.

This stage illustrates why Dynamic Workflows belong inside Routines for large-scale work: the Routine handles scheduling; the Workflow handles the scale of the actual task.

Stage 3: /goal-Driven Fixes

With a list of verified issues in hand, the Routine session now needs to fix what it can. This is where /goal enters the design:

/goal every finding from the audit report is either fixed and verified by running the test suite, or marked as \"requires human review\" with an explanation

Claude works through the issues one by one. After each batch of fixes, the evaluator checks whether all findings are in one of the two acceptable states. If not, Claude keeps working. When the condition is met, the goal clears and Claude moves to the final stage: opening the PR.

The /goal condition here is intentionally permissive about the "requires human review" category. An autonomous agent that tries to fix everything will make mistakes on ambiguous issues. Building an escape hatch into the goal condition — marking issues it can't safely fix rather than attempting them — produces more reliable and trustworthy output.

Permissioning the System

Permission design for an autonomous system like this requires more care than for an interactive session. The key decisions:

Use auto mode, not bypassPermissions. The Routine runs in auto mode by default (Routines have no permission mode picker). The classifier provides a meaningful safety layer. If the classifier blocks something — writing to an unexpected path, attempting to push to a protected branch — that's a signal worth investigating, not an obstacle to bypass.

Configure trusted infrastructure explicitly. Add your repository, CI endpoints, and internal package registry to autoMode.environment in your managed settings. This eliminates false positives from the classifier while keeping meaningful blocks in place for truly external operations.

Keep bypassPermissions off production. Even for automation you fully trust, bypassPermissions has no classifier. One injected payload in a file the agent reads during an audit could cause unintended actions. Auto mode's classifier catches this class of risk; bypassPermissions does not.

The PR is the human checkpoint by design. A draft PR, not a merged one. The agent's job ends at "open a PR for human review." Merging requires a human decision. This boundary is architectural, not just a safety preference — it defines what "fully autonomous" actually means in a production context: autonomous up to the point where human judgment matters most.

The Engineering Model

Looking at the full system — Routine → Dynamic Workflow → /goal → PR — you're not looking at a series of prompts. You're looking at a system with inputs (last 24 hours of git history), processing stages (audit, fix), quality controls (adversarial verification, /goal completion condition), failure handling (mark-as-requires-review), and a defined output artifact (draft PR).

This is what Boris Cherny's statement means in practice. "I don't prompt Claude anymore. I write loops that prompt Claude." The loops in this system are the Dynamic Workflow's pipeline, the /goal turn loop, and the nightly Routine schedule. Claude is the executor. You are the system designer.

The skills this track has built — choosing the right permission mode, writing verifiable /goal conditions, designing workflow scripts with adversarial verification, composing Routines with the right triggers and connectors — are system design skills applied to AI infrastructure. They scale in a way that individual prompting never can.

The system you've designed here is not the ceiling. It's the floor. Add a Channels integration so the Routine triggers immediately on new PRs, not just nightly. Add a /loop in the morning session to watch the draft PR for review comments and address them. Add a second Dynamic Workflow that runs only on security-relevant files with deeper analysis. Each addition is a design decision with a clear rationale, not a prompt to write.

That's the difference between working with Claude and building with Claude. This track has given you the tools. The rest is engineering.