Skip to content
Book demo
Back to Blog

Accelerating large engineering projects with Cosmos

Jun 18, 2026Last updated: Jun 19, 2026
Akshay Utture
Akshay Utture
Accelerating large engineering projects with Cosmos

TL;DR. Agents can now write code, review PRs, and investigate incidents. The next bottleneck is the large project itself: the design, decomposition, and coordination work that happens around the PRs.

We built Project Builder, a Cosmos expert that turns a high-level objective into a markdown or HTML design doc in the Cosmos VFS (shared Virtual File System),gets it reviewed by humans, and then orchestrates worker agents to drive the implementation to merge. Since deploying it, we have shipped complex projects like new platform capabilities and migrations to a production system, in days.

Software engineering has transformed over the last few years. Agents write the code. Code review is driven by agent teams that pull humans in only for judgment calls. Even incident investigation runs ahead of the on-call engineer. Each automation removed a bottleneck and exposed the next one.

For us, the next one was large engineering projects. Building a new feature, standing up a new service, a large scale migration, or rolling out a platform capability rarely stalls because someone can't write the code. It stalls in everything around the code: understanding the existing system, settling the design, deciding what to build in what order, and keeping the work aligned with the original objective as it progresses. Here is how we automated that layer. Let's dig in.

Why large projects are still hard

Most engineering organizations adopting AI today are optimized around individual changes: an engineer picks up a ticket, writes code, opens a PR, ships. Large projects don't fit that shape. Before implementation can begin, someone has to answer the hard questions: which systems change, what the architecture should look like, what the rollout plan is, what depends on what. For experienced engineers this is weeks or months of work: reading the codebase, writing the design, socializing it, and then coordinating execution until the feature lands.

AI-native workflows make this gap more visible, not less. When agents can produce a PR in minutes, a project that still takes weeks of human planning and coordination is bottlenecked entirely on the planning and coordination. That was the work we wanted to hand to an expert.

Introducing Project Builder

Project Builder is a Cosmos expert that takes a large feature from a short feature description to a shipped feature. It produces the design with a human-in-the-loop and orchestrates the implementation using tickets and the PR Author expert (introduced earlier).

A horizontal workflow diagram titled "Augment's Project Builder workflow on Cosmos." On the left, an input box reads "A short feature description or an image/mockup," which feeds into the Project Builder container labeled "Orchestrates the end-to-end delivery." Inside, the flow moves through Design (product and architecture as a Markdown doc in the VFS, grounded in the codebase) and Publish (a design PR on GitHub or a shareable HTML page for review). The path then forks into two branches. The one-shot branch goes to a single PR Author worker that implements the full design as one PR, fixes CI, and responds to comments. The ticketed branch goes to Orchestrate (ordered tickets in Linear or Jira, one PR per unit in dependency order) and then to a stack of PR Author workers producing one PR per unit. Both branches converge on Notify, which pings the team on Slack when PRs are ready, leading to the final "Shipped Feature" output. Two supporting elements sit below: a Project DRI who iterates on design and architecture in a human-in-the-loop step back into Design, and Code Review experts that accelerate PR reviews feeding into the worker stack.

Augment's Project Builder on Cosmos, from a one-line feature description to a shipped feature, with two delivery paths: a one-shot single PR or a ticketed run that splits work into one PR per unit.

Design: Project Builder writes the design doc first. This is the first part of the workflow. It starts with a short feature description or mockup, and produces a detailed design doc that is grounded in the real codebase (across a single or multiple repos). The Project DRI (human-in-the-loop) goes back and forth on various design details until they are satisfied with all the design choices. The design doc covers both, the product side: problem, goals, non-goals, success criteria, and the technical side: the proposed approach, the architecture, the affected components and files, alternatives considered, rollout and feature-flagging strategy, and testing plan.

The key insight is that for complex projects, the most important artifact is a high-quality design doc with all design decisions vetted by a human. Once we have that, agents today are very good implementing it end-to-end (even for complex projects).

This is the same shift we made in code review: humans move from reading code line-by-line to being decision-makers, applied one level up the stack.

Publish (for Design Review): As usual, we want the design reviewed by collaborators and stakeholders before going forward with implementation. The Project Builder offers two recommended choices here, a GitHub PR or HTML doc in the VFS. Both options are friendly for agents to access (without any additional integrations/MCPs) and edit.

  • Markdown in a GitHub PR: Is better for text-heavy documents, and has the advantage that all comments can be auto-addressed by a PR Author expert managing the PR.
  • HTML doc in the VFS: This offers a richer surface for architecture diagrams and polished formatting. The image below shows an example.

We don’t recommend other surfaces because they are not agent friendly. This slows down the process and prevents future agents from having easy access to it. However, if you must use Notion or Confluence, you can set up the corresponding MCP, and the agent can interact with design documents there as well.

Orchestration: Once the design is approved, Project Builder orchestrates its implementation. The orchestration step has two options: one-shot and ticketed; we describe them in the next section.

Notify: Finally, the Project Builder keeps updating humans on a Slack channel whenever a new PR is ready-for-review and needs their input. This is especially important for the ticketing flow.

How we run it at Augment

After design approval, Project Builder supports two ship paths: break the design into ordered, dependency-aware tickets with one PR per unit, or hand the entire design to a single worker and ship it as one PR. At Augment, we prefer to one-shot if possible. A single worker holding the whole approved design produces a more coherent change than several workers stitching together partial context.

The resulting PRs are large, often thousands of lines, and that's fine: the design was already thoroughly reviewed by a human, our Code Review experts analyze the full diff for correctness within minutes, including checking whether the code matches the design doc. "Small PRs" was always a workaround for human review bandwidth; with that bottleneck removed, we stopped paying the coordination tax of splitting. We still split when deploy safety genuinely requires it, such as migrations with intermediate states, or if a project involves changes across multiple repos.

However, you don't have to one-shot on day one. The same expert supports a ticketed path: it breaks the approved design into ordered work units, files them in Linear or Jira with dependency relations, and orchestrates one PR per unit in dependency order. Teams with audit requirements, mixed human-and-agent execution, or staged rollouts often start there: same design-first workflow, same expert, and move toward larger units as trust in design review grows.

Did it work?

Project Builder enables shipping large features and migrations at AI speed at Augment. Below are examples of large scale projects at Augment built using Project Builders; all of them modified production systems with thousands of active users and caused no outages/incidents.

It is important to remember that the rapid time to project completion doesn’t come solely from using the Project Builder expert. You need to use it in conjunction with other experts in the Cosmos ecosystem (primarily PR Author and code review experts (our build loop) that help move the feature fast through the other stages of the SDLC.

ProjectTotal New Lines of CodeEngineersTime to Production Rollout
New Feature: Cosmos GitLab Integration23,9622.516 days
Migration: Chat Interface migrated to server-driven streaming16,4741.514 days
New Feature: Cosmos Spaces5,47615 days

One could measure the mean time-to-completion before/after Cosmos, but comparing the three old large projects before Cosmos to three new projects after Cosmos is meaningless because the of the high variability in project complexity.

How you can adopt this

If your projects stall in planning and coordination rather than implementation, the goal isn't just "faster coding." It's a project system that scales: agents draft the design, humans review it, and worker agents drive the implementation to merge.

You can set up the Project Builder on Augment's Cosmos Platform in 10 minutes. Just prompt the platform's Cosmos Advisor Expert saying "Set up a Project Builder expert for me"; it will configure the expert and help you customize it to your repos and workflow. Augment uses GitHub/Linear/Slack internally, but the Cosmos Advisor will guide you through swapping out those integrations for a different stack like GitLab/JIRA/Teams.

Project Builder joins the experts already running our SDLC on Cosmos: code review experts that merge PRs at the rate agents generate them, and incident response experts that keep on-call load low by investigating alerts before a human arrives. With large projects automated from design doc to shipped feature, the unit of engineering work is no longer the PR, it's the project.

[ Coming up next ]

The New Code Review Workflow for AI-Native Engineering Teams

See how leading teams keep code review fast and rigorous as AI writes more of the code.

Save your seat
Thu, Jul 9 // 9:45 AM PDT

Written by

Akshay Utture

Akshay Utture

Akshay Utture builds intelligent agents that make software development faster, safer, and more reliable. At Augment Code, he leads the engineering behind the company’s AI Code Review agent, bringing research-grade program analysis and modern GenAI techniques together to automate one of the most time-consuming parts of the SDLC. Before Augment, Akshay spent several years at Uber advancing automated code review and repair systems, and conducted research across AWS’s Automated Reasoning Group, Google’s Android Static Analysis team, and UCLA. His work sits at the intersection of AI, software engineering, and programming-language theory.

Get Started

Give your codebase the agents it deserves

Install Augment to get started. Works with codebases of any size, from side projects to enterprise monorepos.