How it works
From one message to merged pull requests.
Delta runs a fixed chain: Architect, Tech Lead, Implementation. You can gate each step, review every diff, and merge on your terms. Nothing about the flow is hidden.
The flow
Nine steps, in order
Steps 4 and 6 only happen when plan mode is on for that stage.
- 01
Describe the product
One message in plain language. What it does, who uses it, what has to be true. No brief, no template.
- 02
Answer three or four questions
Delta asks about the product, not the stack: real-time or not, retention, who owns which record. Each answer is a product tradeoff, and it is recorded in the design.
- 03
Architect
Project-wide system design. Which services exist, how they communicate synchronously or through events, and which one owns each data store.
- 04
Approve the architecture
With plan mode on, the architecture waits for you. Approve it, or reject it with feedback and let Delta propose again.
- 05
Tech Lead
A specification per service, written in parallel. Inputs, outputs, errors, data model, and the events it publishes or consumes.
- 06
Approve the specifications
The second optional gate. Read what each service promises before any code exists.
- 07
Implementation
Code per service against its specification, in the runtime chosen for the project. Each repository builds to one container.
- 08
Review in GitHub
Pull requests open in your organisation, grouped in a change set. Read the diffs, request changes, approve.
- 09
Merge, then deploy
Delta merges the change set once every PR is approved. You deploy the containers wherever you want.
Modes
Feature or Refactor
The mode sets the scope of a conversation. Feature starts from a product change and updates the design. Refactor is purely technical and stays inside it.
Feature
product drivenA new capability, a new integration, a changed contract, a new data store. Architecture, specification and implementation all run, and the design is updated before code. Technical constraints are optional here.
- Starts from a product change
- Updates the system design first
- One specification per impacted service
- Grouped change set across repositories
Refactor
implementation onlyA bug fix, a cleanup, a performance change, a language switch. Purely technical work that does not change the system itself, only how it is implemented.
- Stays inside the current design
- No architecture or contract change
- Delivered as a standalone bugfix PR
- Merged in GitHub when eligible
If the work changes what the product does, needs a new service or a changed contract, use Feature. If it only changes how something is implemented, use Refactor. Refactor does not update the system design, so edits that conflict with it may be altered by later Feature work.
Plan mode
Approve each step before it runs
Turn plan mode on during onboarding, then adjust it from the settings icon in chat. Each stage is independent.
Architecture
Approve the project-wide design before any specification is written.
Specification
Approve what each service promises before implementation starts.
Implementation
Approve the implementation plan before code is generated.
Plan approval permits execution. It is not a GitHub code approval. You still review the pull requests afterwards.
Sessions and change sets
Work stays grouped, and merges stay ordered
Sessions
A session keeps one conversation and its runs together. Start a new session for a separate task. Archived sessions are read-only.
Change sets
Feature work groups its pull requests into a change set. Multiple runs can refine it before it merges. Delta merges the group once every PR is approved.
Order matters
Check that an earlier change set is merged before expecting a new session to build on it. Switching sessions does not merge pending work.
Coordinated merging is not an atomic transaction across repositories. Manually merged pull requests are outside the rollback protection Delta applies to its own merges.
Before you start
A dedicated GitHub organisation
Delta creates repositories, so it needs an organisation it can write to. A personal account is not enough.
- A dedicated GitHub organisation, not a personal account. It keeps generated work separate from repositories you already care about.
- The Delta AI GitHub App installed on that organisation with access to all repositories, so it can create new ones deterministically.
- One installation linked to one Delta AI account. It is not shared across accounts.
- Each repository stays under 400 MB. Delta keeps repositories tight at every run.
Worked example
A Discord-like platform, from four messages
A real-time communication platform: communities, messaging, voice and video, friends, moderation. This is the conversation Delta has, shortened to the parts that change the design.
Services proposed
- api-gatewayREST, websockets
- authsessions, tokens
- communitieschannels, roles
- messaginghistory, fan-out
- mediavoice, video
- moderationflags, actions
- notificationspush, email
Data stores
- auth_dbowned by auth
- community_dbowned by communities
- message_dbowned by messaging
Events
- message.createdmessaging → moderation, notifications
- content.flaggedmoderation → notifications
Decisions written down
- Messaging owns message history and publishes message.created.
- Moderation consumes message.created and publishes content.flagged.
- Notifications consumes both events and owns no primary data.
- Media is separate from messaging so voice and video scale on their own.
- Auth owns sessions and tokens; every other service trusts its contract.
Review
Nothing merges without you.
Every change arrives as a pull request in your organisation. Read the diff, request changes, approve. For grouped change sets, approve rather than merge: Delta coordinates the merge once every PR is approved.
If a change set is waiting, the State tab shows why: required work still running, an approval missing at the current commit, a conflict, or a GitHub access problem.
Start with the free run.
First architecture and one full service. No card.