Sieben große Chancen für Entwickler, mit KI Zeit zu sparen

Jetzt haben wir Fable 5, Codex 5.6 Sol und stärker werdende Open-Weight-Modelle. Keiner weiß, wie man sie am besten nutzt, aber alle probieren es inzwischen seit Jahren aus. Was machst du also, wenn niemand die Antworten hat, aber du einen Wegweiser brauchst? Für mich ist die Antwort klar:

1. Du hörst dir verschiedene Perspektiven an.
2. Du nimmst die Perspektiven, die sich für dich richtig anfühlen, und führst auf deren Basis Experimente durch.
3. Dann bildest du dir deine Meinung.

Das ist genau das, was ich allen Software-Teams empfehle: Redet miteinander, experimentiert und findet euren Weg. Das musstest du vor generativer KI schon machen, und nur weil die Stimmen derer lauter geworden sind, die dir erzählen wollen, dass sie wissen, was sie tun, bedeutet das nicht, dass das plötzlich stimmt.

Und obwohl meine beratende Tätigkeit besonders auf meinem Blog und in sozialen Kanälen im Rampenlicht steht, baue ich auch immer noch jeden Tag Software.

Deswegen sind hier die sieben Bereiche des Software Engineering, bei denen ich selbst in meiner täglichen Arbeit die größte Zeitersparnis bemerke:

1. Recherche

KI verarbeitet Informationen schneller als ich — vielleicht nicht immer zu 100 % korrekt, aber das schaffen wir Menschen ja auch nicht. Als ich mir damals in einem meiner ersten Projekte von Grund auf alle Best Practices zum Thema Backend-Authentifizierung aneignen musste, hat das Stunden gedauert — insbesondere auch deshalb, weil es kognitiv herausfordernd ist, früh zu erkennen, dass man falsch abgebogen ist. Dadurch kann man viel Zeit damit verlieren, in Sackgassen zu laufen.

Wenn ich dagegen heute herausfinden möchte, wie die Angular-Community Fehlerbehandlung in modernen Projekten löst, bekomme ich dank der KI ein breit gefächertes Bild aus verschiedenen Meinungen, die ich in so kurzer Zeit nicht hätte finden können. Besonders effektiv ist das, wenn ich die KI so anweise, dass sie mir keine Handlungsempfehlung geben soll, sodass ich mir ohne Bias den Weg aussuchen kann, der am besten zum Projekt passt und die richtige Balance zwischen Qualität und Geschwindigkeit liefert.

Drei Tipps für bessere KI-Recherchen:

1. Vermeide Framing und Bias: Gib dem Agenten nur so viel Kontext, dass er wertvolle Informationen von unbrauchbaren unterscheiden kann, dir die endgültige Entscheidung aber nicht abnimmt oder dich beeinflusst.
2. Verhindere, dass Werbung das Ergebnis manipuliert: Claude kann das meiner Erfahrung nach sehr gut; anderen Modellen muss man vielleicht eine explizite Anweisung geben. Ein Beispiel: Suche ich einen SaaS-Anbieter für ein Compliance-Thema, möchte ich nicht durch die Blogartikel der Anbieter beeinflusst werden, sondern möglichst von unabhängigen Vergleichen oder Community-Diskussionen auf Reddit.
3. Definiere das Output-Format: Das gilt insbesondere dann, wenn du die Ergebnisse der Recherche mit deinem Team teilen möchtest. Niemand liest sich gerne fünf A4-Seiten KI-Prosa durch. Erziehe den Agenten so, dass er sich kurz fasst, nicht ausschweift und Kerninformationen markiert und belegt.

2. Code Exploration

Für manche Konzepte oder Entscheidungen brauche ich einen tieferen Einblick in die Codebase, als ich ihn durch mein eigenes Wissen und vorhandene Dokumentation habe. Möchte ich zum Beispiel das Design einer API großflächig anpassen (und habe einen guten Grund für einen derart einschneidenden Umbau), möchte ich vielleicht eine Liste aller Endpunkte inkl. Anfrage- und Antwort-Datentypen in Tabellenform.

Im Jahr 2020 hätte ich damit einen Großteil eines Arbeitstags verbracht und dabei wahrscheinlich mehrfach hinterfragt, wie ich an diesen Punkt in meinem Leben gekommen bin. Im Jahr 2026 erhalte ich derartige Analysen in einer knappen Viertelstunde.

Drei Tipps für bessere Code Exploration:

1. Divide and Conquer: Code Exploration kann in großen Repositories oder bei komplexen Aufgaben schnell das Kontextfenster volllaufen lassen. Um das zu verhindern, lass den Agenten mehrere Subagents orchestrieren, die sich auf einen Teilbereich der Codebase oder der Aufgabe fokussieren können, sodass der Agent die Ergebnisse nur noch zusammenfügen muss. Wenn du mit Claude arbeitest, kannst du außerdem erwarten, dass Claude die Ergebnisse der Agents stichprobenartig kontrollieren wird.
2. Kontrolliere die Ergebnisse mit Stichproben: Lies die Ergebnisse durch und kontrolliere Aussagen oder Datenpunkte, die dich stutzig machen. Damit die Zeitersparnis nicht bei der Prüfung verloren geht, beurteile die Korrektheit anhand der „schwierigen“ Stellen und nicht anhand aller.
3. Kontrolliere die Ergebnisse anhand eines zweiten Agents: Nutze ein neues Kontextfenster, gib diesem neuen Agenten die Ergebnisse der Exploration und die ursprüngliche Aufgabe. Lass ihn alle Punkte durchgehen und sag ihm, dass du Zweifel daran hast, dass die Ergebnisse des ersten Agenten korrekt sind.

3. Library Debugging

Oh, wie ich manche Library über die Jahre zu hasslieben gelernt habe: Nicht nachvollziehbare Query-Optimierungen in NHibernate, die LINQ-Code nicht richtig übersetzen konnten. Ein Bug in Apples Foundation-SDK, durch den generisches JSON-Decoding manchmal eine iOS-App hat abstürzen lassen. Ein Quirk im Flutter-SDK, der ein gewisses Screen-Layout hat wirken lassen, als würde es gegen die Gesetze der Physik verstoßen.

Wir haben damals gescherzt, dass wir für manche Probleme bis in Bill Gates’ Büro dekompilieren mussten — und genau so hat es sich auch angefühlt. Diese Art des Debuggings erfordert eine hohe Frustrationstoleranz und viel Tool-Know-how, das einige Entwickler schlichtweg nicht haben. Zusätzlich sind manche dieser Fehler so obskur, dass auch auf Stack Overflow (RIP) oder Reddit niemand helfen konnte.

Auch hier kann ein KI-Agent viel Schmerz lindern oder verhindern; allein dadurch, dass er viel Library-Code ohnehin in seinen Trainingsdaten hat. Damit wird er zum stärksten Debugging-Tool, das ich in all den Jahren vermisst habe.

Drei Tipps für besseres Library Debugging mit KI:

1. Nutze die GitHub-Integration: Du kannst faktisch alle Agents mit GitHub verbinden, sodass sie dir aktuelle Issues zur Library durchsuchen und Lösungsansätze „direkt an der Quelle“ suchen können. Hier gilt, wie auch bei der Recherche aus Punkt (1): So viele Informationen in so kurzer Zeit durchsuchen zu können, ist ein Segen.
2. Nutze Context7: Wer Doku liest, ist klar im Vorteil. Auch wenn es oft hilft, den Code der Library zu lesen, verrät eine ordentliche Dokumentation häufig wertvolle Informationen darüber, wie eine Funktion eigentlich verwendet werden soll. Mit dem Context7-MCP werden diese Informationen über sehr viele Libraries für den Agenten zugänglich.
3. Lass den Agenten so weit gehen, wie du selbst nie gehen wolltest: Einen Fork der Library erstellen, nur um mal etwas auszuprobieren? Eine andere Library nur für diesen Fall hinzufügen und gucken, ob sie das besser macht? Die Library nachbauen und für die eigenen Zwecke vereinfachen und anpassen? Früher wäre das den Aufwand vielleicht nie wert gewesen, heute ist so ein Experiment ein Vormittagsprojekt und je nach Anwendungsfall vielleicht einen Versuch wert.

4. Code-Generierung

Der Klassiker. Manche Leute, zumeist auf LinkedIn, behaupten gerne mal, dass sie über das Wochenende Slack oder Notion nachgebaut haben. Die rapide Erzeugung von Code, insbesondere auf einem „leeren Blatt Papier“, ist das, womit uns Anthropic und OpenAI geangelt haben. Das leere Blatt Papier existiert jedoch fast nie in meinem Alltag als Engineer, weshalb ich selektiv bin und immer selektiver werde, wenn es darum geht, eine geeignete Aufgabe in einem bestehenden System an generative KI abzugeben.

Drei Szenarien, in denen Code-Generierung den größten Mehrwert bringt:

1. Kohärente Projekte: KI erweitert das, was bereits da ist. Wenn deine Codebase durchgehend Konventionen befolgt, befolgt die KI die Konventionen auch. Sagst du jedoch häufiger Sätze wie: „In dem Teil des Projekts wurde das sauber gemacht; in dem anderen da leider nicht.“, musst du das auch der KI sagen. In diesem Fall greift Kent Becks: Make the change simple, then make the simple change. Gleiche die Konventionen der Bereiche an, bevor du die KI von der Leine lässt.
2. Projekte, die Standards würdigen: Ein Backend, das sich an den REST-Standard hält, bedarf keiner weiteren Erklärung, wenn es darum geht, einen Endpunkt hinzuzufügen. Ein Backend, das „irgendwie REST nutzt, aber irgendwie nicht so richtig“, hat das Problem, dass man der KI das „Irgendwie“ erklären muss, damit auch sie vom Standard abweicht. Besser ist es, wenn man sich die Frage stellt, ob eine Abweichung von einem Industriestandard wirklich durch das Produkt gerechtfertigt ist. Meiner Erfahrung nach ist das eigentlich fast nie gegeben.
3. Unit- und Integration Testing: Auch hier sind kohärente Strukturen eine wichtige Grundvoraussetzung. Tests zu schreiben ist aufwändig und wird von vielen Engineers nicht gerne gemacht. Für die KI ist es ohnehin egal, ob sie Features oder Tests schreibt — Tests sind in Zeiten von Agents umso wichtiger, weil sie dir helfen, die Arbeit der KI zu verifizieren; ein Problem, das durch den erhöhten Output und die zusätzliche Review-Last immer größer wird.

5. Automatisierung

Wenn ich sechs Stunden brauche, um eine Aufgabe zu automatisieren, die mich einmal im Monat zehn Minuten kostet, lohnt sich die Automatisierung nicht. Gleichzeitig gab es in meiner Karriere unzählige Momente, in denen ich mir ein Script gewünscht habe, das ich einfach ausführen kann, statt eben diese zehn Minuten zum Beispiel per Hand Daten von A nach B zu kopieren.

Manchmal gehen Wünsche in Erfüllung: Mit dem richtigen Blick für Ineffizienz und der Disziplin, aus einer einfachen Automatisierung nicht das nächste interne SaaS mit eigenem Platz auf der Roadmap werden zu lassen, lassen sich dank KI viele unliebsame Aufgaben automatisieren. Sowohl komplexe Bash-Scripts, die einfach machen, was sie sollen, als auch Headless Agents (z. B. via claude -p) lassen die Herzen derer höher schlagen, die Ineffizienz ebenso sehr verabscheuen wie ich.

Drei Tipps, mit denen du deine KI zur Automatisierungsmaschine werden lässt:

1. Frage dich häufiger, ob man das automatisieren kann: Vor ein paar Jahren habe ich mir diese Frage selten gestellt, weil ich wusste, dass eine Automatisierung nicht wirtschaftlich sein würde (siehe den ersten Satz dieses Teils). Diese Schwelle ist gesunken und die Ergebnisse sind gut. Selbst die Erzeugung guter App-Store-Screenshots für eine App lässt sich gut automatisieren — ein Beispiel, bei dem ich damals noch gedacht hätte: „Wie soll das gehen?“
2. Versuche immer zuerst den One-Shot: Um das Risiko zu minimieren, dass du doch das nächste interne SaaS baust, beschränke deine Automatisierung immer zunächst auf einen Prompt. Wenn der nicht sitzt, kann das ein Indiz dafür sein, dass die Automatisierung doch aufwändiger ist, als du gehofft hattest. Behalte die Wirtschaftlichkeit im Blick.
3. Nutze Git auch für deine kleinen Helfer: Nur weil es eine private Hilfe ist, bedeutet es nicht, dass es nicht von Versionskontrolle profitiert. Eine kleine Erweiterung funktioniert nicht? Dann willst du auch hier den alten Stand wiederhaben. Ich musste das auf die harte Tour lernen.

6. CI/CD

CI/CD steht hier stellvertretend für alles, bei dem du die Korrektheit zwar gut feststellen kannst, das du aber nicht häufig selber schreibst und das sich daher jedes Mal extrem schwerfällig anfühlt. Für mich ist es eben CI/CD-Konfiguration: Häufig YAML-Syntax, reguläre Ausdrücke und geschachtelte Regeln und Bedingungen treffen auf langsame Validierungsmechanismen. Woher weiß ich, ob meine Konfiguration korrekt ist? Indem ich sie ausprobiere. Ein Build dauert sechs Minuten? Dann hol dir nochmal einen neuen Kaffee und such deine Lieblingsfolge Hell’s Kitchen raus, denn: Das kann dauern.

So gerne ich Gordon Ramsay auch dabei zusehe, jungen Köchinnen und Köchen neue Fähigkeiten zu vermitteln: Aus einer Tätigkeit, die sonst gerne einen halben Arbeitstag in Anspruch genommen hat, wird mit KI eine Aufgabe, die sich eben mit einem Handgriff (und einem Prompt) erledigen lässt. Warum? Im Gegensatz zu mir kennt die KI CI/CD-Konfiguration mehr oder weniger in- und auswendig, da sie sie einfach in ihren Trainingsdaten hat.

Drei Tipps, wie die KI deine blinden Flecken ausgleichen kann:

1. Erkenne an, dass ein Bereich deine Schwäche ist: Meiner Erfahrung nach muss man das erwähnen. Unterbewusst weißt du, in welchen Bereichen du nur wenig Erfahrung hast und welche Aufgaben dir schwerfallen. Du musst nicht in jeder Sprache, jedem Framework und jedem Winkel deines Unternehmens der Allstar sein. Das anzuerkennen erlaubt es dir, mehr Zeit mit den Aufgaben zu verbringen, in denen du der Allstar bist, und realistisch genug zu sein, um mit Hilfe der KI auch die unliebsamen Aufgaben effektiv erledigen zu können.
2. Lass dir ihre Arbeit erklären: Vorher war der Modus in etwa: Ausprobieren → Fehler googeln → Korrigieren → nächsten Fehler googeln → […] → froh sein, dass es vorbei ist. Nutze aus, dass diese Schleifen wegfallen und nimm dir die Zeit, Fragen zur Arbeit zu stellen, die die KI für dich erledigt hat — nicht zuletzt deshalb, weil es immer noch du bist, der für den Code verantwortlich ist.
3. Lass die KI dokumentieren, was passiert: Wahrscheinlich bist du nicht der Einzige im Team, der diese Aufgabe nur ungern übernimmt; sonst wäre sie wohl kaum bei dir gelandet. Damit die nächste Person nicht wieder rätseln muss, wie der Code funktioniert, lass ihn noch in der gleichen Session kurz dokumentieren. Sobald du es selbst anhand der Dokumentation verstehst, weißt du, dass sie sitzt.

7. Prototyping und User Testing

Rudimentäre Mock-ups haben nur einen begrenzten Nutzen. Je weniger technisches Know-how bei Nutzern vorhanden ist, desto weniger aussagekräftig ist Nutzerfeedback bei UX-Tests. Wenn wir es schaffen, dass das, was wir Nutzern vorab zeigen, weniger abstrakt ist und es sich stattdessen schon fast wie ein echtes Produkt oder Feature anfühlt, wird folglich auch das Feedback konkreter, das wir bekommen.

Produktnahe Prototypen waren immer mit viel Arbeit verbunden. In den Unternehmen, mit denen ich gearbeitet habe, war die Konsequenz häufig, dass UX-Tests nur selten oder gar nicht durchgeführt wurden. Heute ist das leichter: Mit klaren Anweisungen und guten Prompts kann KI Prototypen bauen, die sich echt anfühlen, und das in einer Zeit, die vor wenigen Jahren unvorstellbar gewesen wäre. Diese Prototypen können den Austausch zwischen Kunden und Produktteam stärken und verhindern, dass wir etwas bauen, das eigentlich niemand braucht.

Drei Tipps im Umgang mit KI-generierten Prototypen:

1. Kenne den Unterschied zwischen einem Prototypen und einem MVP: Ein Prototyp wird nicht weiterentwickelt. Er ist für Tests da und stellt nicht die erste Version eines neuen Produkts oder Features dar. Genau das macht ihn so reizvoll als Mittel, um frühes Nutzerfeedback einzuholen. Er ist nicht dazu da, um Teil deines Kernprodukts zu werden.
2. Integriere dein bestehendes Designsystem: Auch wenn es nur ein Prototyp ist: Deine bestehenden Kunden erwarten (meist unterbewusst), dass alles, was du ihnen zeigst, so aussieht wie das, wofür sie bereits bezahlen. Wenn dein Prototyp völlig anders aussieht, kann das den Eindruck schwächen, weil die meisten Menschen Veränderung nicht mögen und ein völlig anderes Look and Feel ein unterbewusster Hinweis darauf sein kann.
3. Konzentriere dich auf das Experiment, das du führen möchtest: Während der Generierung von Prototypen hat die KI meist Ideen für weitere Funktionen, die sich logisch anfühlen, und weil es so einfach ist, tendiert man dazu, die noch kurz mitzunehmen. Frage dich immer: „Ist diese zusätzliche Funktion relevant für mein User Testing? Zahlt das auf die Wette ein, die ich damit eingehe?“ Ist die Antwort Nein, nimm die Funktion nicht mit und merke sie dir allenfalls für später.

Schlussworte

Was mich fasziniert, ist, dass das hier eine Momentaufnahme ist: Nach Jahren voller Experimente und rasanter Entwicklungen in dem Bereich sind die oben genannten sieben Bereiche die, in denen ich aktuell die größte Zeitersparnis wahrnehme. In jedem Abschnitt hast du Bedingungen gelesen, die für den Erfolg in diesem Bereich in meinen Augen sehr wichtig sind.

Die Aussagen gelten jetzt und in meiner Wahrnehmung. Zwei Fragen stellen sich:

1. Was ist in der Zukunft (in einem halben Jahr, in einem Jahr, in fünf Jahren)? Schauen wir dann auf diese Momentaufnahme und geben zu, dass sich nicht viel geändert hat? Oder lachen wir und sagen: „Haha, guck mal, was man damals noch alles selbst machen musste“?
2. Wie sehr überschneidet sich meine Wahrnehmung mit der anderer Engineers? An der Antwort auf diese Frage arbeite ich kontinuierlich durch unzählige Gespräche und es scheint, als gäbe es einen gewissen Konsens zwischen mir und den besten Engineers, die ich kenne. Eine Randnotiz: Ich freue mich darauf, in etwas mehr als zwei Monaten (zum Zeitpunkt des Schreibens des Artikels) zu erfahren, was die Größen des Software Engineerings auf der GOTO in Kopenhagen dazu denken.

Und abschließend: Wie sind deine Erfahrungen? Hast du Impulse aus diesem Artikel mitgenommen, die du in deinen Arbeitsalltag übernehmen möchtest? Siehst du gewisse Punkte grundsätzlich anders? Hast du Ergänzungen? Ich freue mich immer über einen produktiven Austausch und möchte dich anregen, dich mit mir auf LinkedIn zu vernetzen. Ich freue mich auf dich!