Feature Development
This is the day-to-day Software Factory workflow: from connecting your code to a merged pull request. It is the concrete version of the Software Factory AI model, and it splits into two halves: Dev turns a request into merged code, and DevOps keeps the running system healthy.
The workflow at a glance
Each step is summarized below.
1. Connect your code (and cloud)
- Connect GitHub (or GitLab), the account that owns your code.
- Add your repository, picking the repo and branch. ACE indexes it.
- Connect your AWS account (or GCP / Azure), only if your app runs in the cloud. These connections are read-only. ACE never changes your cloud account.
Connections are the gate for everything after. No repo means nothing to build on, and no cloud means no infrastructure features. See Connect a repository for the setup itself.
2. Map and synthesize: give the AI grounding
- Map code. ACE reads every connected repo and builds a map of files, languages, frameworks, and entry points. This is the one required step. The AI has nothing to reason from without it.
- Synthesize your codebase. ACE turns that map into a written architecture narrative and a relationship diagram. This narrative is auto-injected into every agent on every run, so the AI always knows how your system fits together.
- Discover and map your cloud infrastructure (cloud-hosted apps). ACE scans your connected cloud account, builds an inventory of what's actually running, and cross-references it with your code to produce an infrastructure map.
This whole step is the Learn Path pillar in action: the same mapping becomes readable Docs and the Agents' grounding.
3. Ship a feature from the board
Every piece of work is a card on the Development board. You create a card (or Chat files one for you), then dispatch it. Dispatching hands the card to the Software Factory, and the AI starts working immediately. See The Development Board for the columns, checkpoints, and review mechanics.
4. The inner loop: build and verify
Once dispatched, the AI runs the inner loop inside a private cloud sandbox:
- Plan. It breaks the feature into tasks (the subtasks you see under the card).
- Build. ACE writes the code, task by task.
- Verify and check in. At each milestone it stops and asks you: for approval, for an answer, or for a go/no-go. You approve to continue, request changes to send it back for rework, or reject to stop it.
Nothing touches your real repository during this loop. The code lives only in the sandbox until you approve shipping.
5. Open the Local Environment: see and touch what the AI built
The sandbox the AI worked in is not hidden from you. Local Environment opens that exact workspace in VS Code, right in your browser, the same live files the AI touched, not a copy.
- The sandbox runtime is Daytona. Opening a card's environment wakes (or restores) its Daytona sandbox and drops you into a full code-server IDE.
- You can read and modify the code by hand, and fire up the sandbox to test your software (run it, run its tests, poke at it) in the same environment the AI used.
- Sandbox states you'll see: Ready (hot now), Asleep (restored from a saved snapshot), Shipped (cloned from the card's branch), Empty (nothing saved yet).
This is the hands-on verification step. The AI builds and checks, and you can confirm it yourself before approving.
6. Approve, PR, AI analysis, merge
- Approve the feature. The human gate. Only now does the work leave the sandbox.
- Get a Pull Request. The finished code becomes a PR against your repository. (For work built from scratch, "Save & ship" creates the repo and pushes the sandbox first.)
- The AI analyzes the PR. ACE produces a code-review report. Approving and merging are blocked until that analysis has run at least once.
- Merge. You merge on the provider (with a strategy it allows), recorded in ACE. Merge is only clickable when analysis is done, there are no conflicts, and the provider says it's mergeable.
The pull request is the end of the loop, produced once everything is approved, not a step in the middle. See Pull Requests for the review page, the analysis gate, and the decision rules.
7. Deploy and hand off to Operations
A merge is not the end of the story. The code still has to go out, and Deployments tracks those runs as your pipelines report them. This is the connective tissue between the two halves of ACE: a merged change becomes something live to watch, and a failed run can flow straight back into the board as a fix. It is where Dev hands off to DevOps.
8. If your app is cloud-hosted: maintain the infrastructure too
Feature work doesn't stop at merge. Because ACE also mapped your cloud, the same platform lets you run and maintain the infrastructure your software lives on:
- Check logs and investigate what's happening in your services.
- Monitor health of your live resources.
- Analyze cost and ask the AI to find ways to reduce it.
- Review security posture on a recurring basis.
That ongoing side is its own pillar. See Operations.
The Dev / DevOps split
- Dev, steps 1 to 6: turning a request into merged code.
- The bridge, step 7: Deployments, where a merge becomes something live to watch.
- DevOps, step 8: keeping the running system healthy, cheap, and secure.
ACE covers both with the same Software Factory model: the AI does the work, a human approves what matters.