AI-Driven Development at Scale: Building a Firecracker MicroVM Platform with Autonomous Agents

atlassian · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Autonomous software development for secure execution infrastructure

Atlassian needed a secure Firecracker microVM execution platform for AI-agent infrastructure, but the required scheduler, autoscaler, node agents, ingress, persistence, and validation surface would normally be too large for a fast build.

Constraints:

Architecture

Atlassian used Rovo Dev agents as parallel engineering teammates to build Fireworks, a Kubernetes-based Firecracker microVM platform. Agents received repo configuration, dev environments, CI, PR workflows, and review subagents, while humans focused on architecture, risk, and rollout boundaries.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  rovo-dev-agents["Rovo Dev agents"]
  firecracker-microvm-orchestrator["Firecracker microVM orchestrator"]
  kubernetes-runtime["Kubernetes runtime"]
  dev-shards["Dev shards"]
  ci-pipeline["CI pipeline"]
  independent-review-subagents["Independent review subagents"]
  canary-production-rollout["Canary production rollout"]
  rovo-dev-agents --> dev-shards
  dev-shards --> ci-pipeline
  rovo-dev-agents --> independent-review-subagents
  rovo-dev-agents --> firecracker-microvm-orchestrator
  firecracker-microvm-orchestrator --> kubernetes-runtime
  firecracker-microvm-orchestrator --> canary-production-rollout
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
Rovo Dev agents Autonomous coding workers that implement Fireworks features, write tests, run CI, and iterate on failures. Firecracker microVM orchestrator, Dev shards, CI pipeline, Independent review subagents
Firecracker microVM orchestrator The secure execution engine that boots OCI workloads inside hardware-isolated Firecracker VMs on Kubernetes. Rovo Dev agents, Kubernetes runtime, Canary production rollout
Kubernetes runtime Runs the scheduler, autoscaler, node agents, ingress, persistence, and microVM control plane pieces. Firecracker microVM orchestrator, Dev shards
Dev shards Real environments where agents deploy, run e2e tests, and fix failures before review. Rovo Dev agents, Kubernetes runtime, CI pipeline
CI pipeline Runs lint, vet, tests, and Helm validation before PR review. Rovo Dev agents, Dev shards, Independent review subagents
Independent review subagents Adversarial reviewers spawned for larger PRs before human review. Rovo Dev agents, CI pipeline
Canary production rollout Limits external blast radius after fast internal validation. Firecracker microVM orchestrator

Data flow

Work starts with Rovo Dev agents operating in separate workspaces, deploying to dev shards, running e2e tests, reading CI failures, opening PRs, and using independent review agents before Fireworks reaches controlled production canaries.

“The agent writes tests, deploys to a dev shard, runs them, and loops on failures until they pass. The test suite is the primary proof that things work.”article, stated

Why this architecture

The architecture is built around autonomous verification because agents stall or produce unsafe work if they cannot test in a real environment and close their own failure loops.

“Just like you wouldn’t expect a human to ship working code without access to a real environment, your AI needs end-to-end access too. Give it the tools to verify its own work:”article, stated

Models used: Rovo Dev LLM agents

Scale

Alternatives considered (roads not taken)

Full human peer review before every dev deployment

Rejected because: The team kept human attention on architecture and risk while using dev deploys plus production canaries to keep validation fast without removing production safety.

“Progressive rollout: main deploys to dev without PRGB, so we can validate internally fast. Production gets canary deploys across multiple clusters.”article, stated

Agents limited to code generation only

Rejected because: Atlassian gave agents access to deployment, testing, PRs, CI, and ticket workflows because the source says agents need the whole SDLC, not just code generation.

“It needs to be involved in all parts of the SDLC, not just code generation”article, stated

Human reading of every implementation detail as the primary verification mode

Rejected because: The team leaned on black-box input/output validation when tests could comprehensively prove behavior.

“If you can comprehensively validate via inputs and outputs, you often don’t need to read the code and what it’s doing”article, stated

Patterns

eval-driven-development (quality)

Agents write e2e tests, deploy to real dev shards, run the tests, and loop on failures until the system behavior passes.

“The agent writes tests, deploys to a dev shard, runs them, and loops on failures until they pass. The test suite is the primary proof that things work.”article, stated

multi-agent-orchestration (development-workflow)

The main coding agent is paired with independent review subagents and golden-path workflow skills for end-to-end Fireworks changes.

“For review, have an adversarial persona subagent that spins up and reviews what the main agent has written.”article, stated

Tradeoffs

How much review latency to remove from internal validation.

Chose main deploying to dev without PRGB plus production canaries over waiting for full human peer review before every dev deployment.

Rationale: Fast internal validation lets agents and humans learn quickly, while production canaries keep the external blast radius controlled.

“Progressive rollout: main deploys to dev without PRGB, so we can validate internally fast. Production gets canary deploys across multiple clusters.”article, stated

Gotchas (what bit them)

Autonomous agents stall if they cannot verify their own work in a real environment.

Root cause: A code-generation agent without deployment, test, and CI feedback cannot close the implementation loop.

Resolution: Give agents dev-environment access, e2e tests, CI output, and PR workflows so they can fix failures before asking for human review.

“Just like you wouldn’t expect a human to ship working code without access to a real environment, your AI needs end-to-end access too. Give it the tools to verify its own work:”article, stated

Evaluation

The team used black-box behavior checks, e2e tests, CI gates, Helm validation, dev-shard deployment, and canary rollouts to validate agent-authored infrastructure code.

Metrics: 100ms boot behavior · migration preserves state · network policy enforcement · CI lint/vet/test/Helm validation

“Every PR runs lint, vet, tests, and Helm validation. The agent reads pipeline output and addresses failures before requesting review.”article, stated

Outcomes

Vendor-authored Atlassian engineering post; strong claims are self-reported but include concrete platform features.

“We’ve built a platform that will be the secure execution engine behind Atlassian’s AI agent infrastructure.”article, stated