In this article
Aider architect mode first proposes a solution, then asks an editor model to create file edits. It still edits files and can use the same model in both roles.
Aider’s architect workflow separates proposing a solution from translating that proposal into file edits. It is useful to evaluate when a local model explains an approach well but struggles to produce an acceptable patch format. The mode is still an editing workflow, so its name should not be mistaken for a discussion-only setting.
Distinguish ask, code and architect
The chat modes guide describes ask for discussion, code for direct edits and architect for a proposal followed by an editor request. A command applied to one message and a persistent active mode can have different scope. Read the active prompt rather than inferring the mode from an earlier message.
Use a discussion-only question to settle an ambiguous requirement before editing. Once the intended behavior is clear, select the editing workflow deliberately. This separates a misunderstanding of the task from a failure to express the approved change in the expected patch format.
Configure both model responsibilities
The main model acts as architect; the editor model translates its proposal into edit instructions. The documented --editor-model option selects the editor explicitly. Both roles can use the same model, although the workflow still performs separate requests.
For a local runtime, the Ollama integration guide identifies Aider-specific connection conventions, including the recommended ollama_chat/ model prefix. Confirm that each selected role resolves to an available model. An architect response does not prove the editor is installed, loaded or configured with a usable context.
Build a cross-file task with a visible invariant
Use a small repository with a parser and its caller. Ask for a clearer error result while preserving behavior for a valid input. The architect should identify both files and the invariant before the editor changes them.
Inspect the handoff: did the editor receive the proposed behavior and needed source, or only a vague summary? Then review the diff for unrelated changes. This example makes a lost requirement or a formatting failure visible without requiring a large codebase or trusting a model’s own success claim.
Include Git behavior in the exercise
The Aider Git guide describes automatic commits and treatment of preexisting dirty files. Start the experiment with a known repository state and inspect what is committed. Do not treat an automatically generated commit message as evidence that a patch is correct.
Run the relevant tests and compare the resulting diff to the agreed invariant. Keep the architect proposal and editor output distinct in the record. A later undo addresses repository changes under the documented workflow; it does not prove that every external effect of a command is reversible.
Compare complete work, including the handoff
Evaluate ordinary code mode and architect mode on the same bounded task with the same acceptance checks. Record the full interaction, response budgets and time through the completed edit. A better explanation without a usable patch is not a completed implementation.
Two requests can add latency and resource usage. Different local models may also compete for memory or require reloads. Choose the workflow that produces reviewed correct changes under the actual machine’s constraints, rather than assuming that assigning two role names creates an automatic quality or speed improvement.
Related reading
Reproducible inference stacks: preserving a GPU pilot’s result, Coding LLMs on 12GB VRAM: Budget Context and Headroom.