Auf dem dunklen Bildschirm blinkt der Cursor. Ein Junior-Entwickler formuliert eine Anforderung, löscht sie wieder, ergänzt einen Sonderfall und zeigt dem Coding-Agenten, welcher Teil des bestehenden Systems nicht beschädigt werden darf. Wenige Minuten später sind mehrere Dateien geändert. Nach dem ersten Lauf prüft ein zweites Modell den Diff.
Das ist längst kein exotischer Versuch mehr. Viele Juniors verbringen heute weniger Zeit mit dem eigentlichen Tippen als mit der Frage, was sie beauftragen, wie sie generierten Code lesen und wo eine fast richtige Lösung scheitert. Das Tempo ist beeindruckend. Gleichzeitig wächst die Sorge: Was lohnt es sich noch zu lernen, wenn das Werkzeug in Minuten liefert, wofür früher ein Arbeitstag nötig war?
„Lerne die Grundlagen“ bleibt richtig, beantwortet diese Frage aber nicht vollständig. Nur die neuesten Tools zu beherrschen, ist erst recht keine tragfähige Strategie. Sinnvoller ist es, die Grundlagen zu behalten, aber ihre Reihenfolge und den Nachweis des eigenen Könnens zu verändern.
Weniger Tipparbeit heißt nicht weniger Entscheidungen
Der klassische Einstieg lebte von Wiederholung. Einen kleinen Endpoint bauen, einen Bug beheben, eine Migration schreiben und dabei das Framework kennenlernen. KI liefert heute oft einen kompletten ersten Entwurf, bevor das mentale Modell des Juniors fertig ist.
Genau dort entsteht die Lücke. Laufender Code ist nicht automatisch verstandener Code. Der Happy Path kann funktionieren, während eine Zahlung doppelt ausgeführt wird, ein Token im Log landet oder ein wiederholter Request den Zustand beschädigt.
In der Stack Overflow Developer Survey 2025 misstrauten mehr Befragte der Genauigkeit von KI-Ausgaben, als ihr vertrauten. Besonders häufig genannt wurde die Antwort, die beinahe stimmt, aber eben nicht ganz. 45% empfanden das Debugging von KI-generiertem Code als zeitaufwendiger.
Das spricht nicht gegen KI. Es zeigt, dass Erzeugungsgeschwindigkeit und Verantwortung an unterschiedlichen Stellen liegen. Gefährlich wird es, wenn ein Junior Änderungen übernimmt, die sich nach Ende der Agentensitzung nicht mehr erklären lassen.
Grundlagen bekommen eine unmittelbare Aufgabe
Datenstrukturen, Netzwerke, Datenbanken und Betriebssysteme bleiben wichtig. Neu ist vor allem, wofür dieses Wissen im Alltag gebraucht wird.
Fügt ein Agent beispielsweise einen Cache ein, sollte das Review mindestens drei Fragen beantworten:
- Bleibt das System ohne Cache korrekt?
- Welches Ereignis macht einen Eintrag ungültig?
- Gibt es bei einer Störung einen Weg zurück zur maßgeblichen Datenquelle?
Das sind keine Prompt-Tricks. Sie entstehen aus dem Verständnis von Zustand und Fehlern. Niemand muss jeden HTTP-Header auswendig kennen. Ein Junior sollte aber verfolgen können, wohin Zugangsdaten weitergegeben werden. SQL muss nicht immer von Hand entstehen; ein schlechter Ausführungsplan sollte unter realen Daten trotzdem auffallen.
Grundlagen sind damit weniger Prüfungsstoff als Messinstrumente für plausibel klingende Fehler.
Verantwortung beginnt nicht erst mit dem Senior-Titel
In derselben Umfrage wollte die große Mehrheit KI weder Deployment und Monitoring noch die Projektplanung überlassen. Ab diesem Punkt zählt nicht nur, ob eine Änderung funktioniert. Entscheidend ist, wer sie stoppt, erklärt und zurücknimmt, wenn sie scheitert.
Ein Junior muss keine unternehmensweite Architektur entwerfen. Die Grenze der eigenen kleinen Funktion sollte jedoch klar sein: Woher kommt die Eingabe? Welcher Zustand ändert sich? Was bleibt nach einem Fehler übrig? Wer darf den Vorgang erneut ausführen?
Auch ein Portfolio wirkt anders, wenn es diese Verantwortung zeigt.
| Sinnvolle Spur | Was sie erkennen lässt |
|---|---|
| Erste Anforderung und Grund der Änderung | Problemabgrenzung |
| Verworfene KI-Vorschläge | Technisches Urteil |
| Reproduzierbarer Fehler | Debugging-Disziplin |
| Tests und Betriebslogs | Verifikation |
| Rücksetz- oder Wiederanlaufplan | Verantwortung im Fehlerfall |
Das ist keine Rechtfertigung für KI-Nutzung. Es ist der Nachweis, dass die Entscheidung bei einem Menschen blieb.
Schneller wirken und früher fertig sein sind zwei Dinge
KI fühlt sich schnell an, weil das erste sichtbare Ergebnis früh erscheint. Der gesamte Arbeitsaufwand kann trotzdem steigen.
METR untersuchte erfahrene Open-Source-Entwickler, die in ihnen vertrauten Repositories mit KI-Werkzeugen von Anfang 2025 arbeiteten. Die Teilnehmer erwarteten eine Beschleunigung. Gemessen benötigten sie im Durchschnitt 19% mehr Zeit.
Diese Zahl lässt sich weder pauschal auf Juniors noch auf aktuelle Modelle übertragen. Untersucht wurden erfahrene Maintainer, bestimmte Repositories und inzwischen veränderte Werkzeuge. Der engere Hinweis bleibt dennoch wertvoll: Review, Korrektur und Rollback gehören zur Zeitmessung. Zeilen pro Minute sind dafür eine schlechte Kennzahl.
Zwölf Wochen, die belastbare Spuren hinterlassen
Ein kleines System reicht aus: Anmeldung, persistente Daten, eine externe API und eine einfache Verwaltungsansicht. Es geht nicht um ein Startup, sondern darum, einen begrenzten Ausschnitt bis zum Betrieb zu verantworten.
Woche 1–3: Mit KI bauen, jede Änderung lesen. Für jede geänderte Datei wird in einem Satz festgehalten, wozu sie dient. Was sich nicht erklären lässt, wird nicht übernommen.
Woche 4–6: Fehler absichtlich auslösen. Verzögerte Verbindungen, falsche Eingaben, doppelte Requests und abgelaufene Zugangsdaten zeigen, ob das Verständnis über den Happy Path hinausgeht. Erst die Ursache im Log eingrenzen, dann den Agenten nach einer Lösung fragen.
Woche 7–9: Betriebsspuren ergänzen. Wichtige Anfragen erhalten Logs, jeder gefundene Fehler einen Regressionstest und jede riskante Änderung einen Weg zurück zur letzten funktionierenden Version.
Woche 10–12: Übergabe testen. Ein anderer Mensch sollte das System anhand des README starten, die wichtigste Abwägung verstehen und die verbleibende Grenze erkennen können. Fehlt ein Kollege, hilft ein Tag Abstand und ein Test mit dem eigenen zukünftigen Ich.
Vier Zeilen pro Woche genügen:
- Das Problem dieser Woche
- Angenommene und verworfene Vorschläge des Agenten
- Ein tatsächlich beobachteter Fehler
- Der erste Prüfpunkt beim nächsten Mal
Dieses Protokoll überlebt den nächsten Modellnamen.
Zeitweise ohne Agent arbeiten
Niemand muss alles wieder von Hand bauen. Eine kurze Phase ohne KI zeigt aber, wo das eigene Verständnis endet. Den Datenfluss skizzieren, bevor der Chat geöffnet wird. Testfälle notieren, bevor Code angefordert wird. Einen Fehler in eigenen Worten beschreiben, bevor ein Modell die Diagnose übernimmt.
Mit eingeschalteter KI darf das Werkzeug dagegen konsequent genutzt werden: für Wiederholungen, den Einstieg in unbekannte Bibliotheken und zusätzliche Testideen. Die wichtige Grenze verläuft nicht zwischen KI und Nicht-KI, sondern zwischen delegierter und überprüfter Arbeit.
Wo Junior-Entwickler weiterhin gebraucht werden
Auch wenn KI Code schreibt, muss jemand das Problem definieren, Frust beim Nutzer erkennen, einen gefährlichen Release stoppen und eine Entscheidung erklären. Diese Aufgaben sind nicht exklusiv für Seniors reserviert.
Junior-Entwickler müssen keinen Tippwettbewerb gegen einen Agenten gewinnen. Sie sollten lernen, verdächtige Ergebnisse zu erkennen, Belege zu prüfen und eine kleine Funktion in einen Zustand zu bringen, den andere betreiben können. Wer aus dem Backend kommt, kann KI auf diesem Systemverständnis aufbauen. Im Frontend geht es darum, Unsicherheit sichtbar und beherrschbar zu machen.
Toolnamen und Rollenbezeichnungen werden sich weiter ändern. Probleme einzugrenzen, ihren Kontext zu verstehen und Verantwortung für das Ergebnis zu übernehmen, lässt sich deutlich schwerer automatisieren. Dort lohnt sich die Investition.
