# Ambient AI Development **TLDR:** ACEM (Automatic Code Evolution Management) is a GitHub App that turns labeled issues into pull requests, asynchronously. Add `acem-design` to an issue, step away, come back to an implementation plan. Add `acem-implement`, come back to working code. No IDE. No active prompting. Anyone on the team can kick off work. **Full disclosure: I built ACEM.** ## The Assumption Every AI Coding Tool Makes Copilot, Cursor, Windsurf, Claude Code. Every major AI coding tool is built on one premise: an engineer is sitting in front of their editor, actively prompting. This is a synchronous model. The AI is a pair programmer. Fast, impressive, and genuinely useful. It also requires you to be there. Most engineering time is not spent writing code. It is spent in meetings, reviewing PRs, answering Slack messages, waiting for CI, and unblocking other people. The time with hands on keyboard writing new code is a fraction of the workday. Synchronous AI tools optimize that fraction. ACEM is a different category. ## What Pair Programming Gets Wrong AI pair programming is a local optimization. It makes the thing you were already doing faster, in the moment you were already doing it. The real bottleneck in software development is not typing speed. It is coordination. You cannot start a feature at 3pm when a meeting runs until 4. You cannot review a PR and write new code at the same time. You cannot send a spec to an engineer at midnight and have an implementation by morning. These are not speed problems. No amount of autocomplete solves them. ## What is Ambient Async AI Code Generation? Ambient async AI code generation means development work happens in the background, triggered by intent, without requiring an active operator present. ACEM does this through GitHub labels. It runs as a background processor, watches your repositories for labeled issues, and creates pull requests. You initiate the work by adding a label. ACEM handles execution while you are in a meeting, at lunch, or asleep. The interface is two labels: ```yaml acem-design → PR with a markdown implementation plan acem-implement → PR with actual code changes ``` Use both in sequence for complex features. Skip straight to `acem-implement` for quick fixes and prototypes. ## Introducing ACEM ACEM installs as a GitHub App. No IDE extension, no CLI, no configuration files. Grant it access to your repositories, write an issue, add a label. ACEM reads your entire codebase before writing anything. It analyzes project structure, existing patterns, naming conventions, and dependencies. The output fits what is already in the repo, not a generic template. Setup takes under 5 minutes. See the [quickstart guide](https://redbeardlab.gitbook.io/acem/documentation/getting-started/quickstart). ## Key Capabilities ### Async by Design Add a label to an issue and step away. A pull request will be waiting when you return. ACEM processes issues in cycles with configurable rate limits (defaults: 3 new PRs per cycle, 10 per day). These limits prevent your team from being buried in AI-generated PRs while you are still reviewing the previous batch. This is what separates ACEM from every other AI coding tool: the engineer does not need to be present when the code is written. Work happens between human interactions, not during them. ### Design Before Code The recommended workflow starts with a design: ``` Issue → acem-design → Design PR → review → merge → acem-implement → Implement PR → review → merge ``` The design PR contains a single markdown file, `ACEM_DESIGN_{issue_number}.md`, with a detailed implementation plan. Which files to create, which to modify, the approach, and the reasoning. You see exactly what will be built before a line of code is written. This is where you catch scope problems, architectural mismatches, and missing requirements before they become merge conflicts. Design runs also consume fewer tokens than full implementations. Generate a design first to estimate cost before committing to implementation. See the full [workflow documentation](https://redbeardlab.gitbook.io/acem/documentation/concepts/workflow). ### Iteration via Review Comments Leave a review comment on any ACEM PR (design or implementation) and ACEM reads it, then pushes an update to the same branch on the next cycle. ```markdown Can we use Redis for token storage instead of the database? Switching to Redis gives us automatic expiration with TTL and better read performance under load. Updated. ``` No new prompts. No re-running anything. The iteration loop is the GitHub review workflow you already use. ### Non-Engineers Can Initiate Work Anyone who can write a GitHub issue and add a label can trigger ACEM. A product manager writes a detailed spec and adds `acem-design`. An implementation plan is ready before the next engineering sync. A founder drafts three features at midnight. Draft PRs are waiting by morning. A designer describes a UI change and creates a starting point for an engineer to review. Engineers remain responsible for the final merge. The quality gate does not move. What changes is who can initiate work and when. Engineering becomes less of a creation bottleneck and more of a review function. \[VISUAL: Diagram showing two swimlanes: "Non-engineers" (write issue, add label, review design) and "Engineers" (review PR, leave comments, merge)] ## Getting Started 1. [Install the ACEM GitHub App](https://redbeardlab.gitbook.io/acem/documentation/getting-started/quickstart) 2. Select which repositories ACEM can access 3. Create a GitHub issue describing what you want to build 4. Add the `acem-design` label 5. Wait for the next processing cycle 6. ACEM comments on the issue with a link to the design PR That is the entire setup. No configuration files, no new toolchain. ACEM lives entirely inside GitHub. For a complete example from feature request to merged PR, see [Your first feature](https://redbeardlab.gitbook.io/acem/documentation/getting-started/first-feature). ## Pricing Pricing based on tokens consumed via MiniMax M2.5: | | Input | Output | | ------------ | ------------------- | ------------------- | | MiniMax M2.5 | $0.40 per 1M tokens | $1.50 per 1M tokens | You pay for what you use. Generate a design first to estimate token consumption before committing to a full implementation. A VM sandbox is included with your subscription for code generation and testing. ## FAQ ### What is ACEM? ACEM (Automatic Code Evolution Management) is a GitHub App that generates pull requests from labeled issues. It reads your codebase, produces implementation plans and code changes, and iterates based on your review comments. The entire workflow runs asynchronously through GitHub. No IDE required. ### How does ACEM differ from Copilot or Cursor? Copilot and Cursor are synchronous tools. They assist an engineer who is actively writing code in an IDE. ACEM is async. Add a label to a GitHub issue, step away, and come back to a pull request. No engineer needs to be present while the code is generated. ### Can non-engineers use ACEM? Yes. Anyone who can create a GitHub issue and add labels can trigger ACEM. Product managers, designers, and founders can initiate design and implementation work. Engineers review the output and approve before anything merges. ### What if the generated code is wrong? Leave review comments on the PR and ACEM revises on the next cycle. For a completely fresh start, close the PR without merging while keeping the label on the issue. ACEM will generate a new implementation on the next cycle. You can also edit the code manually after the PR is created. ### Does ACEM generate tests? Yes. The implementation agent generates tests for new functionality by default. Specify testing requirements in the issue for more precise coverage. See the [best practices guide](https://redbeardlab.gitbook.io/acem/documentation/guides/best-practices) for examples on writing effective issues. *** [**Get started with ACEM →**](https://redbeardlab.gitbook.io/acem/documentation/getting-started/quickstart)