Acht Entwickleraufgaben: Was man an KI abgibt und was in Menschenhand bleibt

Lange Zeit lief es immer gleich ab. Eine Anforderung kam rein, der Editor ging auf, die Doku wurde durchsucht, Beispiele kopiert, Code geschrieben. Fehler tauchten auf, es wurde weiter gesucht, dann kamen Tests, dann Dokumentation, und viele Stunden später war das Feature fertig.

KI hat diesen Ablauf umgekrempelt. Beschreibt man ein Problem in normaler Sprache, liefert ein Assistent in Sekunden Code, Tests, Dokumentation, SQL-Abfragen, reguläre Ausdrücke, Refactoring-Ideen und Ansätze fürs Debugging. Eine Unterscheidung geht in der Debatte „KI ersetzt Entwickler“ allerdings meist unter: Code zu generieren ist noch kein Engineering.

Manche Teile der Softwarearbeit erledigt KI hervorragend, andere unzuverlässig. Als Faustregel taugt: Wiederkehrende Ausführung übernimmt die KI, für das Urteil bleiben Menschen verantwortlich. Daraus ergeben sich fünf Aufgaben, die man gut an KI abgeben kann, und drei, die stark von Menschen getragen sein sollten.

1. Boilerplate

Das ist vermutlich am leichtesten zu delegieren. Typisch sind CRUD-Endpunkte, Datenbankmodelle, UI-Komponenten und Formulare, API-Clients, Validierungsregeln, Konfigurationsdateien, Serializer, DTOs und grundlegende Fehlerbehandlung. Schwer ist davon nichts. Es wiederholt sich nur ständig.

Nehmen wir eine API zur Benutzerverwaltung. Von Hand bedeutet das eine lange Kette von Schichten:

User Model
    ↓
Schema
    ↓
Repository
    ↓
Service
    ↓
Controller
    ↓
Validation
    ↓
Tests

Das ist eine Menge Tipparbeit. Ein KI-Assistent kommt mit einer schlichten Beschreibung aus, etwa: ein FastAPI-Registrierungsendpunkt mit PostgreSQL, der die E-Mail prüft, das Passwort hasht, doppelte Benutzer verhindert und die ID des neuen Benutzers zurückgibt. Ein brauchbarer erster Entwurf steht fast sofort.

Es gibt aber einen großen Vorbehalt: Generierter Code wird nie blind übernommen. Authentifizierung, Autorisierung, Validierung, SQL-Abfragen, Fehlerbehandlung, Abhängigkeitsversionen, Sicherheit, Performance und Randfälle muss sich ein Mensch ansehen. Die KI liefert die erste Implementierung, für die endgültige ist der Entwickler zuständig.

Die Zeitrechnung ist verlockend. Eine Aufgabe, die von Hand 45 Minuten dauert, ergibt vielleicht in 2 Minuten eine erste Version, danach etwa 10 Minuten Review und Tests. Der Zeitgewinn ist nett, wichtiger ist aber, dass man seltener den Kontext wechselt. Niemand muss das eigentliche Problem liegen lassen, nur um weitere 30 Zeilen Gerüstcode zu tippen.

2. Unit-Tests

Tests sind das perfekte Beispiel für Hilfe, die keine Verantwortung abnimmt. Nehmen wir diese kleine Funktion:

def calculate_price(price, discount):
    return price - (price * discount / 100)

Ein Entwickler müsste an normale Rabatte denken, an null, an 100 %, negative Werte, ungültige Eingaben, Gleitkomma-Verhalten und unerwartete Typen. Statt die erste Testsuite selbst zu schreiben, bittet man einen Assistenten um pytest-Fälle für normale Werte, Grenzen, ungültige Eingaben und Randfälle. Zurück kommt etwa so etwas:

def test_no_discount():
    assert calculate_price(100, 0) == 100


def test_full_discount():
    assert calculate_price(100, 100) == 0


def test_half_discount():
    assert calculate_price(200, 50) == 100

Dann folgt das Review, und genau hier liegt die Gefahr. Von KI geschriebene Tests können in die Irre führen. Eine Suite kann 100 % Abdeckung erreichen und trotzdem miserabel sein, denn Abdeckung ist keine Korrektheit. Der Assistent beschreibt womöglich nur, was der aktuelle Code tut, und wenn dieser Code falsch ist, bestätigen die Tests das falsche Verhalten fröhlich.

Die eigentliche Frage lautet also: Welches Verhalten soll tatsächlich garantiert sein? Das ist der menschliche Teil. Die KI schreibt den eintönigen Testcode, der Entwickler entscheidet, was getestet werden muss.

3. Dokumentation

Doku ist wichtig, und mit einer leeren Seite anzufangen tut weh. Teams schieben sie mit dem Versprechen auf, sie später zu schreiben, und sechs Monate danach kann niemand mehr erklären, wie das System funktioniert.

Mit KI fällt der erste Entwurf viel leichter. Man gibt ihr Quellcode, API-Definitionen, Konfiguration, Architekturnotizen, ein vorhandenes README und Deployment-Anleitungen und bittet dann um ein README mit Installation, Umgebungsvariablen, lokaler Entwicklung, Datenbank-Setup, Endpunkten, Tests und Deployment. Heraus kommt ein strukturiertes Dokument, das ein Mensch prüft.

Besonders praktisch ist das für:

• README-Dateien, die erklären, wie man das Projekt startet
• API-Dokumentation mit Endpunkten sowie Request- und Response-Formaten
• Code-Kommentare zu verworrenen Stellen
• Changelogs, die Unterschiede zwischen Releases zusammenfassen
• interne Dokumente aus groben technischen Notizen
• Onboarding-Material, das Neuen hilft, ein Projekt zu verstehen

4. Regex, SQL und andere „Kann ich, Syntax vergessen“-Aufgaben

Das sind kleine Unterbrechungen, die KI aus dem Weg räumt. Das Ziel ist klar, nur die Syntax ist verschwommen. Es kann ein Regex sein, eine komplizierte SQL-Abfrage, ein Shell-Befehl, eine Git-Beschwörungsformel oder eine JavaScript-Methode. Statt sich durch zehn Seiten Doku zu kämpfen, beschreibt man den Bedarf, zum Beispiel: Finde Benutzer mit mindestens drei Käufen in den letzten 30 Tagen und gib ihre Gesamtausgaben zurück.

Der Assistent schreibt die Abfrage, ein Mensch prüft sie. Die KI liefert die Syntax, der Mensch kontrolliert die Logik.

Nehmen wir ein Schema mit diesen Tabellen:

users
orders
payments

Angenommen, gesucht sind die 10 Kunden mit den höchsten Zahlungen in den letzten 30 Tagen. Ein erster Entwurf der Abfrage kommt schnell, aber der Mensch prüft trotzdem Joins, doppelte Zeilen, NULL-Verhalten, Indizes, Datumsgrenzen, Zeitzonen, Aggregation und Performance. Eine Abfrage, die auf 1.000 Zeilen stimmt, kann auf 100 Millionen dahinkriechen, und der Assistent kennt die Produktionsumgebung nicht. Generiertes SQL ist ein Entwurf und nie automatisch produktionsreif.

5. Debugging

Beim Debugging spart KI womöglich am meisten Zeit. Teuer sind selten die tiefen Bugs. Oft ist die Ursache schlicht albern: eine nicht gesetzte Umgebungsvariable, eine abweichende Paketversion, ein falsch geschriebener Name, eine Race Condition, Einstellungen, die zwischen Umgebungen auseinanderlaufen, ein verirrtes null oder eine API-Antwort in unerwarteter Form. Schmerzhaft ist die Suche nach der Ursache, und dabei hilft KI gut.

Wer nur eine nackte Fehlermeldung wie diese einfügt, bekommt magere Ergebnisse:

TypeError: undefined is not a function

Kontext ändert alles. Nennen Sie Framework und Version, sagen Sie, welche Komponente den Fehler wirft und wann (etwa beim Absenden eines Formulars), fügen Sie den Komponentencode, den Stacktrace und das erwartete Verhalten bei und fragen Sie nach den wahrscheinlichsten Ursachen plus der kleinsten sicheren Korrektur.

Ein typischer Ablauf sieht so aus:

Error
   ↓
Collect Context
   ↓
Ask AI for Possible Causes
   ↓
Rank the Causes
   ↓
Test the Hypothesis
   ↓
Apply Fix
   ↓
Run Tests
   ↓
Verify

KI ersetzt den Debugging-Prozess nicht. Sie beschleunigt die Untersuchung, und das ist ein deutlich realistischeres Bild KI-gestützter Entwicklung.

Die drei Aufgaben, die in Menschenhand bleiben

Wenn KI Code, Tests, SQL und Doku schreiben kann, warum lässt man sie nicht alles machen? Weil Engineering mehr ist als Codegenerierung. Manche Entscheidungen verlangen Kontext, Urteilsvermögen, Verantwortung, Geschäftsverständnis, Erfahrung und Kommunikation, und in diesen Bereichen sollten Menschen eng eingebunden bleiben.

6. Systemarchitektur

Eine KI kann eine Architektur vorschlagen, das letzte Wort sollte aber nicht bei ihr liegen. Fragt man nach einem skalierbaren Design für eine E-Commerce-Plattform, sieht die Antwort wahrscheinlich so aus:

Frontend
   ↓
API Gateway
   ↓
Microservices
   ↓
Message Queue
   ↓
Databases
   ↓
Cache
   ↓
Monitoring

Das wirkt beeindruckend. Aber stellen Sie sich eine Firma mit drei Entwicklern, 10.000 Nutzern, kleinem Budget, einem Produkt und überschaubarem Traffic vor. Braucht sie 15 Microservices? Wohl kaum. Ein modularer Monolith könnte um ein Vielfaches einfacher sein.

Architektur heißt Abwägen. Microservices bringen unabhängiges Deployment, Isolation, Teamautonomie und unabhängige Skalierung, kosten aber operative Komplexität, Netzwerkaufwand, Aufwand für Observability und verteilte Ausfälle. Ein Monolith ist einfach, leicht zu deployen, angenehm in der lokalen Entwicklung und leichter zu debuggen, aber einzelne Teile lassen sich schwerer skalieren, die Codebasis wächst, und bei schlechtem Design schleicht sich Kopplung ein.

Eine KI kann das alles erklären. Was sie nicht von selbst weiß: welcher Kompromiss zu genau dieser Firma passt. Das ist Ingenieursurteil.

7. Produktentscheidungen

KI kann Optionen analysieren, die Roadmap sollte ihr aber nicht gehören. Angenommen, ein Startup kann eines von zwei Features bauen. Das erste dauert zwei Monate und könnte den Umsatz steigern. Das zweite dauert drei Tage und verbessert die Kundenbindung. Welches gewinnt?

Ein Assistent kann helfen, Entwicklungsaufwand, möglichen Effekt, Markttrends und Kundenfeedback abzuwägen. Die Entscheidung hängt aber vom Geschäft ab. Vielleicht ist die Finanzierung das kurzfristige Ziel. Vielleicht ist die Kundenbindung das größte Problem. Vielleicht hat ein Großkunde das erste Feature verlangt, oder die Konkurrenz hat es gerade ausgeliefert. Diesen Kontext hat die KI nicht, solange man ihn ihr nicht gibt.

Die schwächere Frage lautet „Was sollen wir bauen?“. Die stärkere: „Was sollen wir angesichts unserer Ziele, Kunden, Einschränkungen und Ressourcen als Nächstes bauen?“ Die zweite Frage braucht Kontext, und deshalb bleibt Produktdenken so wertvoll.

8. Kreative Problemlösung

Diesen Bereich sollte man am ehesten in Menschenhand lassen. Muster helfen bei bekannten Problemen, aber manche Engineering-Probleme sind wirklich neu: Die bestehende Architektur funktioniert nicht, Anforderungen widersprechen sich, die Performance ist seltsam schlecht, das Produkt hat ungewöhnliche Einschränkungen, oder die naheliegende Lösung erzeugt ein neues Problem. Genau da zählt Kreativität.

Fürs Brainstorming ist KI nützlich, solange sie das Denken nicht ersetzt. Eine gute Reihenfolge: nach fünf unkonventionellen Ansätzen fragen, dann nach den Schwächen jedes Ansatzes, dann nach der Annahme, die man gerade trifft, und dann danach, was passieren würde, wenn die naheliegende Lösung ausgeschlossen wäre. In dieser Rolle ist KI ein Denkpartner und nicht die Instanz, die entscheidet.

Vom Schreiber zum Reviewer

Das ist vielleicht die größte Verschiebung, die KI mit sich bringt. Früher verbrachten Entwickler einen Großteil ihrer Zeit mit dem Schreiben von Code. Heute lässt sich Code viel schneller generieren, die Gewichtung der Fähigkeiten ändert sich, und Reviews werden wichtiger. Die Fragen dabei:

• Ist es korrekt? Löst es das eigentliche Problem?
• Ist es sicher? Gibt es etwas, das ein Angreifer ausnutzen könnte?
• Ist es wartbar? Würde ein Kollege es in einem halben Jahr noch verstehen?
• Ist es effizient? Kommt es mit echten Produktionsdaten klar?
• Ist es getestet? Was passiert an den Rändern?
• Ist es kompatibel? Passt es zum Rest des Systems?
• Ist es nötig? Kommt Komplexität hinzu, die niemand braucht?

Die Zukunft gehört wohl nicht denen, die am meisten Code generieren. Sie gehört denen, die Code gut beurteilen.

Auch schlechte Entwickler werden schneller

KI kann die Produktivität steigern, aber auch das Tempo, in dem jemand schlechte Software produziert. Ohne Verständnis von Sicherheit, Architektur, Datenbanken, Netzwerken, Tests und Performance bekommt ein Entwickler sehr schnell eine Menge plausiblen, aber fehlerhaften Code. Das ist gefährlich.

Stellen Sie sich jemanden vor, der SQL nicht versteht und die KI um Datenbankabfragen bittet. Das Ergebnis funktioniert, bis zur Produktion:

100 users
   ↓
Works perfectly

100,000 users
   ↓
Slow

10,000,000 users
   ↓
Production incident

Die Wissenslücke hat nicht die KI geschaffen. Sie hat das Ergebnis nur schneller geliefert.

Ein anderes Skillset

Moderne Entwickler brauchen ein etwas breiteres Spektrum an Fähigkeiten. Programmieren allein ist nicht mehr das ganze Bild:

Programming

Besser sieht es so aus:

Programming
     +
System Design
     +
AI Collaboration
     +
Code Review
     +
Testing
     +
Security
     +
Product Thinking

KI ist ein weiteres Werkzeug im Engineering-Werkzeugkasten.

Ein realistischer Tag

Ein normaler Ablauf mit KI könnte so aussehen:

1. Erst die Aufgabe verstehen. Die Anforderung selbst lesen und nicht sofort an die KI weiterreichen, denn zuerst muss das Problem einen Sinn ergeben.
2. Nach Alternativen fragen. Das Problem beschreiben und drei Ansätze mit ihren Abwägungen anfordern. So tauchen oft Optionen auf, an die niemand gedacht hatte.
3. Entscheiden. Dieser Schritt bleibt menschlich. Es zählen Komplexität, Teamerfahrung, Performance, Kosten, Wartbarkeit und Sicherheit.
4. Boilerplate generieren. Jetzt können Modelle, Interfaces, API-Handler, Tests, Doku und Basiskomponenten vom Assistenten kommen, und hier entsteht die Zeitersparnis.
5. Review. Den generierten Code vollständig lesen, nicht nur die ersten Zeilen.
6. Testen. Unit-Tests, Integrationstests, manuelle Prüfungen und Randfälle durchlaufen lassen. Schlägt etwas fehl, den Fehler an die KI zurückgeben.

Die KI übernimmt das Tippen, das Denken bleibt beim Menschen.