/architect
Wechselt in den Architect-Modus, in dem ein Modell die Lösung plant und ein zweites Modell sie als konkrete Datei-Änderungen umsetzt.
Im Architect-Modus schickt Aider die Anfrage zuerst an das Hauptmodell (Architect), das einen Lösungsvorschlag macht. Anschließend schickt Aider diesen Vorschlag an ein separates Editor-Modell (einstellbar mit --editor-model), das daraus konkrete Datei-Edits erzeugt. Ohne angehängten Prompt wechselt /architect nur dauerhaft in diesen Modus, ohne eine Nachricht zu senden.
✅ WANN EINSETZEN?
Starkes Reasoning-Modell mit einem guten Editor-Modell kombinieren
/architect Refactor the payment module to use the new API — z.B. mit einem starken Reasoning-Modell als Architect und Sonnet oder GPT-4o als Editor-Modell
Demselben Modell zwei Durchgänge geben
/architect (ohne Prompt, um dauerhaft in den Modus zu wechseln) — das Modell bekommt einmal Zeit zum Planen, einmal zum Umsetzen, was laut Doku manchmal bessere Ergebnisse liefert als der direkte Code-Modus
⛔ WANN EHER NICHT?
Schnelle, einfache Änderung
Architect-Modus braucht zwei LLM-Anfragen statt einer, das kostet laut Doku mehr Zeit und Geld.
Besser: /code für direkte Änderungen ohne den Zwischenschritt nutzen
Nur diskutieren, nichts ändern
Architect-Modus ändert am Ende Dateien; wer nur Fragen klären will, braucht das nicht.
Besser: /ask nutzen, um den Ansatz zu besprechen, bevor überhaupt Code geändert wird
QUELLEN
- Aider Docs — In-chat commands ↗ aider.chat
- Aider Docs — Chat modes ↗ aider.chat