Vom „KI das Coden beibringen“ zum „KI das Coden managen“: Wie ein Rollenwechsel deine Auftragskapazität verdoppelt
Vom „KI das Coden beibringen“ zum „KI das Coden managen“: Wie ein Rollenwechsel deine Auftragskapazität verdoppelt
RichardsonDu schreibst keinen Code – du führst ein „KI-Team“
Die meisten nutzen Coding Agents immer noch wie ein Tech Lead: Systemarchitektur selbst absegnen, Code Review Zeile für Zeile, jede KI-generierte Zeile persönlich prüfen, bevor sie committed wird. Qualität? Top. Der Preis? Du bist der größte Engpass in der gesamten Produktionslinie. Jede Entscheidung wartet auf dich, jedes Detail läuft über deinen Tisch – die Produktivität des Agents wird von deiner Aufmerksamkeit und deiner Zeit erstickt.
Die Indie-Entwickler, die wirklich Geld verdienen, haben längst einen entscheidenden Rollenwechsel vollzogen: vom TL zum EM. Klartext: Als TL starrst du auf jede Codezeile, als EM schaust du nur, ob das Ergebnis funktioniert. Der TL fragt „Ist dieser Code korrekt?”, der EM fragt „Hat das Feature die Abnahme bestanden?”. Klingt nach Nuance, ist aber der Unterschied zwischen „Output einer Person” und „Output eines Teams”.
Warum du jetzt loslassen kannst: Die Modelle haben den Kipppunkt überschritten
Loslassen setzt voraus, dass die Codequalität stimmt. Diese Voraussetzung ist dieses Jahr erfüllt: In den gängigen öffentlichen Benchmarks liegt die Trefferquote der Top-Modelle beim Coden über 80 Prozent – mit deutlichem Vorsprung gegenüber der Vorgängergeneration (die einzelnen Rankings und Scores bewerten die Anbieter unterschiedlich; schau selbst auf Artificial Analysis oder SWE-Bench nach den aktuellen Zahlen und glaub keiner Zweitquelle, auch mir nicht).
Was heißt das? KI-Code geht nach einer kurzen Verifizierung nicht mehr grob daneben. Der Grenznutzen deiner Zeilen-Reviews ist so niedrig, dass er sich nicht mehr lohnt. Wer weiter TL spielt, investiert seine teuerste Zeit in die billigste Qualitätskontrolle. Der Markt zahlt nicht für dein „unsicheres Gefühl” – Kunden zahlen für gelieferte Ergebnisse.
Weg 1: „Plan bestätigen + Ziel vorgeben” statt Zeilen-Überwachung
Wie setzt du das konkret um? Schritt eins: den Workflow ändern. Sobald du weißt, welches Feature gebaut werden soll, gehst du den technischen Plan einmal mit dem Agent durch. Plan bestätigt? Dann bekommt der Agent das Ziel samt Plan und führt aus – Code schreiben, automatisierte Tests laufen lassen, alles seins. Deine einzige Aufgabe: am Ende das Feature abnehmen, nicht den Code reviewen.
Hier eine Prompt-Vorlage zum direkten Kopieren:
1 | Ich will bauen: 【Feature-Beschreibung】. |
Für die Abnahme hältst du die Qualität mit einer Checkliste fest – ganz ohne Code zu lesen:
- Kernablauf einmal manuell durchklicken, Hauptpfad fehlerfrei
- Je einen Edge Case testen (leere Eingabe, extrem lange Eingabe, Netzwerk weg)
- Alle vom Agent ergänzten automatisierten Tests laufen grün
- Bei einem Bug nicht selbst in den Code steigen, sondern das Phänomen dem Agent beschreiben: reproduzieren, fixen, Test ergänzen lassen – dann erneut abnehmen
Der Kern dieser Methode: Du verlagerst die Verifikation nach vorn. Im TL-Modus prüfst du auf Code-Ebene – extrem teuer. Im EM-Modus prüfst du auf Feature-Ebene – ein paar Klicks, ein Durchlauf, wenige Minuten. Deine Zeit fließt im gesamten Zyklus nur in zwei Dinge: klar definieren, was gebaut wird, und bestätigen, dass es richtig gebaut wurde.
Weg 2: Tech-Auswahl von „Was kann ich?” zu „Was passt am besten?”
Der Rollenwechsel hat einen versteckten Bonus: Deine Technologiewahl wird nicht mehr von deinen eigenen Fähigkeiten gedeckelt. Im TL-Denken greifst du automatisch zum Stack, den du beherrschst – weil du Probleme selbst fixen kannst. Im EM-Denken bewertest du nur, welche Technologie für das Projekt optimal ist. Den Rest macht der Agent.
Ein Indie-Entwickler hat diesen Weg beschrieben (laut seinem Originalpost, nicht unabhängig verifiziert): Für eine Untertitel-Übersetzungs-App wählte er zunächst Electron, weil er Frontend kannte – die Performance blieb unbefriedigend. Also wechselte er auf den ihm völlig fremden nativen Stack Swift + AppKit, mit KI-Unterstützung ohne größere Reibung. Für sein nächstes Cross-Plattform-Produkt griff er direkt zu Rust, das er nie zuvor geschrieben hatte. Ob die Geschichte stimmt, musst du selbst beurteilen – aber die Logik dahinter kannst du heute Abend testen: Nimm einen Stack, den du nicht kennst, und lass den Agent mit dir ein 100-Zeilen-Tool bauen. Schau, ob es dich ausbremst. Klartext: Deine Kompetenzgrenze ist keine Ausrede mehr – bei der Tech-Wahl zählt nur noch, was optimal ist.
Weg 3: Iterationsgeschwindigkeit als Burggraben – plus eine ehrliche Rechnung
Läuft dieses Modell rund, schrumpft die Lieferzeit von Wochen auf Tage. Der Kunde äußert morgens einen Wunsch, nachmittags sieht er eine abnahmefähige Version. Die Konkurrenz liefert einmal pro Woche, du einmal pro Tag. Auf eBay Kleinanzeigen, Fiverr oder Upwork tummeln sich viele KI-Entwicklungs-Anbieter – aber die meisten stecken noch in der Phase „KI hilft mir beim Tippen”. Mit dem EM-Modus spielst du eine Liga höher.
Konzepte allein zahlen keine Miete, also die Rechnung (konservativ geschätzt, rechne mit deinen eigenen Preisen):
- Beispiel Auftrag „kleines Tool/Mini-App”, Auftragswert 1.400 €
- TL-Modus: ein Auftrag inkl. Nacharbeiten 5 Tage, bei Vollauslastung 4 Aufträge im Monat = 5.600 € Monatsumsatz
- EM-Modus: Planung + Abnahme 1,5 Tage, während der Agent arbeitet, nimmst du parallel den nächsten Auftrag an – effektiv 2 Tage pro Auftrag, 8–10 Aufträge im Monat = 11.000–14.000 €
- Kostenseite: KI-Abo maximal 200 €/Monat, Nacharbeitsquote dank Abnahme-Checkliste ca. 10 %, pro Auftrag einen halben Tag Puffer einplanen
Ergebnis: Derselbe Monat, über 5.000 € Differenz – und im EM-Modus ist dein Engpass das Auftragsvolumen, nicht deine Tippgeschwindigkeit. Schreib „Lieferung einer nutzbaren Version in 48 Stunden” direkt in dein Angebot. Das ist Differenzierung, die niemand kopieren kann.
Der einzige Engpass: Du weißt nicht, was du bauen willst
Das Modell hat eine echte Grenze: Sobald eine neue große Version oder Produktidee konzipiert werden muss, wird der Mensch wieder zum Engpass. Der Agent kann noch so stark sein – er führt nur Ziele aus, die du klar gedacht hast. Weißt du selbst nicht, was gebaut werden soll, produziert er keine einzige brauchbare Zeile.
Deshalb stellt der EM-Modus höhere Anforderungen an dich – nicht an technische Tiefe, sondern an Produkturteil. Du musst Zeit investieren, um zu verstehen, wonach Kunden auf eBay und Amazon suchen, welche Pain Points in Reddit-Threads und Newsletter-Kommentaren durchschlagen, welche Tool-Inhalte auf TikTok viral gehen. Die gesparte Code-Review-Zeit gehört komplett in „klar denken, was gebaut wird”. Das ist der Platz, an dem der Mensch in diesem Modell hingehört.
Leg heute los: Der Rollenwechsel in drei Schritten
Noch keinen Auftrag an Land gezogen? Dann denk nicht gleich an Kapazitätsverdopplung, sondern nimm den Einstieg über eine Stufe tiefer: Stell auf eBay Kleinanzeigen oder Fiverr ein Angebot „Individuelles KI-Tool nach Maß” für 300–500 € ein und durchlaufe mit den folgenden drei Schritten deinen ersten Auftrag. Damit hast du einen wiederverwendbaren Workflow und ein echtes Gefühl für Preise.
Schritt eins: Nimm ein kleines Projekt aus deinem Fundus und zwing dich, keine einzige Codedatei zu öffnen. Nur Plan schreiben, Ziel vorgeben, Feature abnehmen – einmal den kompletten EM-Workflow erleben und die Zeit stoppen. Das sind deine eigenen First-Hand-Daten, mehr wert als jede Fallstudie. Schritt zwei: „Bug zuerst dem Agent beschreiben, reproduzieren und fixen lassen” zur Muskelerinnerung machen – auf keinen Fall selbst in den Code springen. Schritt drei: Beim nächsten Projekt bewusst einen Stack wählen, den du nicht beherrschst, der aber am besten passt – und prüfen, ob die KI dich hinüberträgt.
Der Kipppunkt bei der KI-Coding-Fähigkeit ist überschritten. Die Dividende wandert gerade von „Leuten, die mit KI coden können” zu „Leuten, die KI-Teams führen können”. Such dir heute Abend ein Projekt und durchlaufe den EM-Workflow mit der Vorlage und Checkliste oben.
