31. Juli 2026
Entwicklung mit KI: Warum wir plötzlich sechs Aufgaben gleichzeitig lösen
KI schreibt Code schneller als wir. Der eigentliche Hebel ist aber das parallele Arbeiten an mehreren Aufgaben.
Transparenz
Alle Blogeinträge entstehen mit Hilfe von KI und werden von einem Menschen nachbearbeitet und geprüft.
Du schreibst eine Anforderung auf, übergibst sie an die KI und wartest auf Code. Das dauert im Alltag oft zwanzig Sekunden. In dieser Zeit sitzt du vor dem Bildschirm und tust absolut nichts (außer vielleicht den Mauszeiger im Kreis zu drehen). Wer diesen Prozess einmal umstellt, vervielfacht den eigenen Output, denn die wahre Bremse ist nicht die Codegenerierung, sondern der lineare Ablauf.
Die Planungsfalle bei einer einzelnen Aufgabe
Die KI schreibt Software deutlich schneller als ein Mensch. Die wahre Falle schnappt bei der Planung zu. Das passiert, wenn du dich auf kleine Funktionen versteifst. Das ist das Parkinsonsche Gesetz in Aktion. Arbeit dehnt sich genau auf die Zeit aus, die für sie zur Verfügung steht.
Mit der KI spinnst du einen simplen Entwurf plötzlich endlos weiter. Du fügst unzählige neue Ideen hinzu und blähst die Anforderungen extrem auf, weil dir das Werkzeug diese scheinbar kostenlosen Optionen reibungslos auf dem Silbertablett serviert. Plötzlich bekommt das kleine interne Hilfsskript eine komplett eigene Benutzerverwaltung. Eine winzige Detailänderung wächst dann unbemerkt zu einem ausufernden Projekt. Das kostet massiv Zeit.
Der Herd mit den sechs Töpfen
Betrachten wir das Problem wie einen erfahrenen Koch am Herd. Ein Meisterkoch fängt nicht an, statt eines simplen Gemüses noch eine absurd aufwendige Trüffelsauce zu kreieren, nur weil das Wasser für die Nudeln noch nicht sprudelt. Er stellt einfach sofort den nächsten Topf auf die heiße Platte. Hältst du deine Software-Anforderungen exakt so klein, gewinnst du tatsächlich die versprochene Zeit. Der absolute Schlüssel für extreme Entwicklungsgeschwindigkeit liegt schlicht im parallelen Arbeiten.
Die JavaScript-Runtime im Kopf
Genau genommen arbeitest du als Mensch in diesem Setup gar nicht parallel. Dein Gehirn funktioniert vielmehr exakt wie die JavaScript-Runtime: Es besitzt nur einen einzigen Haupt-Thread. Du kannst immer nur einen konkreten Gedanken zur selben Zeit fassen.
Wenn JavaScript einen langsamen Netzwerkaufruf startet, lässt es den Browser nicht einfrieren. Es lagert die Aufgabe aus und erhält sofort ein sogenanntes Promise zurück – ein digitales Versprechen auf eine spätere Antwort. Wie Asynchronität und Promises unter der Haube funktionieren, fasst dieser Golem-Artikel hervorragend zusammen.
Du bist in unserem Szenario dieser non-blocking Haupt-Thread. Du delegierst die rechenintensive Schreibarbeit an die externen Agenten. Während die Maschine im Hintergrund feilt und Tausende Zeilen generiert, blockierst du nicht.
Du wechselst einfach sofort den Kontext. Du machst das nächste Fenster auf und stößt direkt eine völlig andere Aufgabe an. Du holst dir schlicht dein nächstes Promise ab. Ein geübter Entwickler feuert auf diese Weise mühelos bis zu ein Dutzend Funktionen asynchron ab. (Ob das auf Dauer gesund ist, klären wir gleich.)
Plötzlich Teamleiter und Architekt
Selber Code tippen rückt bei dieser Arbeitsweise drastisch in den Hintergrund. Du nimmst stattdessen völlig neue Rollen ein. Du leistest die Arbeit eines Entwicklerteams und bist gleichzeitig Teamleiter, Senior Developer und Lead-Architect. Deine neue Hauptaufgabe ist es, all diese Ergebnisse effizient zusammenzuführen und die Software so flexibel zu halten, dass du sie später extrem sauber umbauen kannst.
In unseren eigenen Projekten spüren wir diese harte Belastung sehr deutlich. Das dauerhafte Steuern von sechs parallelen Aufgaben erfordert gewaltige geistige Kapazitäten. Morgens ist der Kopf noch frisch, da fliegen die fertigen Features nur so über den Bildschirm.
Spätestens am frühen Nachmittag reißt der Faden dann unweigerlich ab. Du verlierst den mentalen Kontext für die einzelnen Aufgaben, weil die Maschinen pausenlos nach neuen Entscheidungen verlangen. Ein gesunder Körper, viel Sport und vernünftige Ernährung sind plötzlich richtig harte Faktoren für den Erfolg im Projekt.
Genau in dieser schleichenden Erschöpfung lauert das absolute Risiko. Wenn deine Kraft am Nachmittag nachlässt, vertraust du der Maschine immer mehr und fragst nicht kritisch nach. Das ist der exakte Moment, in dem du aus purer Erschöpfung Code freigibst, den du am Morgen lachend gelöscht hättest. Am Ende des Tages arbeitest du vielleicht weniger Stunden am Stück, weil du mental schlicht erledigt bist. Der insgesamt erzeugte Output ist durch die drastische Parallelisierung am Ende trotzdem um ein Vielfaches größer.
Dieses Bild vom Koch mit den vielen Töpfen lässt sich direkt auf deinen lokalen Arbeitsplatz übertragen. In der Theorie klingt das Konzept nach einem simplen Fensterwechsel. In der Praxis ist es das nicht. Für deine lokale Entwicklungsumgebung bedeutet dieser enorme Schritt nämlich extrem harte, überaus greifbare Eingriffe in die genutzten Verzeichnisse und die angebundenen Datenbanken.
Das Prinzip der isolierten Arbeitsbereiche
Du behandelst deine parallelen Aufgaben wie ein echtes Team aus separaten menschlichen Entwicklern. Jeder virtuelle Entwickler werkelt fokussiert an seinem eigenen Feature in seinem völlig isolierten Branch. Du führst die fertigen Code-Ergebnisse am Ende ganz schrittweise über klassische Pull Requests zusammen.
Damit dieses Setup auf einem einzigen Rechner nicht sofort im absoluten Chaos endet, brauchst du zwingend strikt isolierte Arbeitsverzeichnisse. Ein normaler Wechsel des Branches via git checkout überschreibt rigoros alle Dateien in deinem aktuellen Arbeitsverzeichnis. Die Maschine verliert in genau diesem kritischen Moment ihren gesamten Dateikontext und liest fortan nur noch inkonsistente Fragmente aus. (Was sie natürlich nicht davon abhält, dir das kaputte Ergebnis anschließend extrem selbstbewusst zu präsentieren.)
Ein Git Worktree umgeht dieses Desaster elegant und zuverlässig. Er legt für jeden Branch ein sauberes, separates Verzeichnis physisch auf deiner lokalen Festplatte an. Du öffnest in jedem dieser Ordner einen eigenen Editorfenster-Kontext. Erst dann weist du der Maschine die Aufgabe zu.
git worktree add ../feature-a feature-a
git worktree add ../feature-b feature-bContainernetzwerke und Datenbanken trennen
Läuft dein System mit Docker, verschärft sich das Problem drastisch. Die gemeinsam genutzten Container für die Datenbank und die Applikation würden sich gegenseitig stören oder sogar zerstören. Wenn sechs parallele Branches zur exakt gleichen Zeit eine umfassende Datenbank-Migration starten, stürzt der MySQL-Service sofort ab. Eine klassische Datenbank verträgt viel, aber definitiv keine sechs parallelen Entwickler, die gleichzeitig ihre Grundmauer einreißen wollen. Sie nutzen dann ahnungslos denselben Container.
Deine lokale Umgebung muss deshalb für jeden erstellten Worktree ein völlig isoliertes Set an Containern bereitstellen. Du ordnest jedem Projekt eine dedizierte Umgebungsvariable wie COMPOSE_PROJECT_NAME und ein extrem isoliertes privates Netzwerk zu.
Was du jetzt tun solltest
- Git Worktrees lernen: Mach dich zunächst mit Git Worktrees vertraut. Überlege dann konkret, wie du deine eigene Arbeitsumgebung für parallele Prozesse umbaust.
- Langsam starten: Wage dich behutsam heran. Lass deinen Agenten erst einmal nur zwei Aufgaben in getrennten Worktrees parallel bearbeiten. Prüfe dabei genau, ob er dieses Setup sicher bedienen kann.
- Den Merge prüfen: Führe diese ersten parallelen Branches testweise zusammen. Überprüfe exakt, was passiert, wenn die getrennten Code-Ergebnisse am Ende wieder verschmelzen.
- Eigene Skills schreiben: Sobald du deinen reibungslosen Workflow für diese Art der Arbeit gefunden hast, gieße ihn in einen eigenen Skill. Das macht den Prozess für die Maschine reproduzierbar.
Wer diese Struktur im Hintergrund aufbaut und den Werkzeugen den genauen Ablauf erklärt, skaliert sich selbst auf eine völlig neue Ebene. Du wartest ab sofort nicht mehr. Du orchestrierst dein Projekt.