Software Engineer
Sie lernen das Handwerk in einer Welt, in der der Agent den Code schreibt und der Mensch die Spezifikationen schreibt. Der Job ist nicht, was er vor drei Jahren war, und Sie lernen nicht den Engineer zu werden, den es vor drei Jahren gab.
Die Arbeit
Sie tragen zu Features in einem Team bei. Der Agent übernimmt einen großen Teil der Codeproduktion auf Zeilenebene; Sie übernehmen die Arbeit, die der Agent schlecht macht, die Arbeit, die Urteilsvermögen erfordert, das Sie noch aufbauen, und die Arbeit, die der Teamprozess auf dieser Ebene von Ihnen erwartet. Sie lernen zwei Handwerke gleichzeitig: das Engineering selbst und das KI-native Betriebsmodell, das das Engineering trägt.
Im Alltag tun Sie folgendes:
- Spezifizierte Features umsetzen. Ein Senior FSE oder Tech Lead schreibt die Spezifikation, Sie kollaborieren mit dem Agenten an der Umsetzung, validieren den Output gegen die Spezifikation und bringen die Arbeit zu einem merge-fähigen PR.
- Eigene Spezifikationen für kleineren Umfang schreiben. Bugfixes, kleine Verbesserungen, internes Tooling: Sie spezifizieren zuerst, der Agent setzt um, Sie validieren. Spezifikationspraxis beginnt früh.
- Agent-Output kritisch lesen. Auch wenn der Agent funktionierenden Code produziert, fragen Sie: Ist das, wie diese Codebasis es geschrieben haben will? Passt es zu den Mustern des Teams? Das Lesen ist die Lehre.
- Mit dem Agenten über Klärungsdialoge paaren. Bevor der Agent ausführt, bringt er Fragen vor; Sie beantworten jene, die Sie können, und eskalieren jene, die Sie nicht können.
- Feedback zu Ihren Spezifikationen und Ihren PRs annehmen. Von Senior FSEs, Tech Leads, dem Agent-Reviewer. Jede Rückmeldung ist eine Lektion, das Team investiert in Ihr Handwerk.
- An risikoabgestuften Gates validieren. Routinearbeit läuft über den Agent-Reviewer, mit Ihnen als zweitem Augenpaar. Alles Unumkehrbare, Kundengerichtete oder über Ihre aktuelle Ebene Hinausgehende eskaliert an einen Senior FSE oder Tech Lead.
- Kontext pflegen. Dokumentation, Runbooks, die geteilten Prompts und Szenario-Bibliotheken des Teams. Dazu beizutragen, ist Teil des Aufbaus Ihres Urteils.
- Bei Rekalibrierungssitzungen auftauchen. Wenn der Agent stockt, kommt das Team zusammen. Sie nehmen teil, Sie beobachten, wie Senior Engineers diagnostizieren, das Beobachten lehrt Sie.
Wie Erfolg aussieht
Konkrete Ergebnisse auf dieser Ebene:
- Wachsender Durchsatz. Stories, die Sie durchgängig übernehmen, werden in vorhersagbarer Kadenz ausgeliefert. Ihr Durchsatz wächst Quartal über Quartal, während Ihre Spezifikationen schärfer werden.
- PR-Qualität. Der Agent-Reviewer markiert mit der Zeit weniger Ihrer PRs. Feedback von Senior Engineers verdichtet sich zu Unabhängigkeit.
- Aufkommendes Spec-Schreiben. Sie beginnen, Spezifikationen zu schreiben, die ein Agent durchgängig umsetzen kann. Manche benötigen noch einen Senior-Durchgang; der Anteil verschiebt sich über Monate zu selbsttragend.
- Bewusstsein für Rekalibrierung. Wenn eine Story stockt, können Sie artikulieren, ob das Problem in der Spezifikation, im Kontext oder in der Umsetzung liegt. Auch wenn Sie eskalieren, bringen Sie eine Hypothese mit.
- Intuition für die Codebasis. Sie beginnen zu wissen, welche Abstraktion diese Codebasis will, welchen Mustern zu folgen ist, was Hausstil bedeutet. Geschmack entsteht.
Was nicht als Erfolg zählt: geschriebene Codezeilen, PR-Zähler allein, geloggte Stunden, an alten Junior-Engineer-Metriken festzuhalten, die nicht in dieses Betriebsmodell übersetzen.
Was diese Arbeit interessant macht
Sie lernen das Handwerk des Engineerings, während es neu erfunden wird. Das ist selten und wertvoll.
Sie haben keine alten Gewohnheiten zu verlernen. Senior Engineers, die zu KI-nativer Arbeit wechseln, müssen über Jahre aufgebaute Muskelerinnerung aufgeben. Sie nicht. Die spezifikations-erste, agent-kollaborative Arbeitsweise ist Ihr Normal, das ist ein Vorteil, kein Mangel.
Ihr Einfluss steigt schneller an. Ein Junior Engineer in der alten Welt verbrachte die ersten 6 bis 12 Monate hauptsächlich mit dem Produzieren einfachen Codes. Auf T2 in einem KI-nativen Team können Sie innerhalb von Monaten bedeutsame Features spezifizieren und ausliefern. Die Rückkopplungsschleife von Ihrem Beitrag zum ausgelieferten Wert ist viel kürzer.
Das Team lehrt Sie, absichtlich. Spezifikationen, die Sie erhalten, sind auch Lehrmaterial. PR-Feedback ist strukturiert. Rekalibrierungssitzungen sind öffentliches Lernen. Die Lehre ist real, und sichtbarer als die Feuertaufe-Junior-Erfahrung der alten Ära.
Sie bauen früh stack-übergreifend. Da der Agent absorbiert, was früher tiefe Spezialarbeit war (Frontend-Layout, Backend-Verdrahtung, Infrastrukturkonfiguration), können Sie früh in Ihrer Karriere über den Stack hinweg beitragen. Die Breite kommt schneller.
Sie lernen, vor dem Tippen zu denken. Das ist die nachhaltigste Karrierefähigkeit in jeder Ära, und Ihre Rolle konzentriert sich darauf. Menschen, die früh lernen, gut zu spezifizieren, übertreffen jene, die die Fähigkeit erst später aufbauen.
Sie sehen Senior-Urteilsvermögen aus der Nähe. Spec-Dialoge, Code-Reviews, Rekalibrierungssitzungen: das sind die Momente, in denen Senior Engineers offenbaren, wie sie denken. Die Nähe ist echte Lehre.
Was unter Umständen nicht reizt. Wenn Sie die Rolle für die Erfahrung langer konzentrierter Coding-Sitzungen wollten, also funktionalen Code Zeile für Zeile von Null an zu produzieren, wird diese Arbeit weitgehend absorbiert. Junior Engineers, die in das Feld kamen, weil sie den Akt des Codens lieben, finden KI-native Arbeit manchmal weniger praktisch als erwartet. Manche entwickeln das neue Handwerk und finden es befriedigender als das alte, manche nicht. Die alte Junior-Erfahrung, Handwerk langsam durch Volumen geschriebenen Codes aufzubauen, ist weitgehend vorbei. Sie bauen es durch Volumen gelesener Spezifikationen, geschriebener Spezifikationen und beobachteter Rekalibrierungen auf.
Wer in dieser Rolle gedeiht
Die wichtigsten Eignungen sind Lern-, Urteilsentwicklungs- und Schreibeignungen, und sie wirken früher in Ihrer Karriere als bisher.
Sie stellen gute Fragen. Die Fähigkeit, die Ihr Wachstum auf dieser Ebene am stärksten vorhersagt, ist die Qualität der Fragen, die Sie stellen: zu Spezifikationen, zu Codebasen, zum Output des Agenten, zu Ihrer eigenen Entwurfsarbeit. Menschen, die per Mustererkennung handeln und schweigen, lernen langsamer als jene, die fragen.
Sie lesen unersättlich. Spezifikationen, PRs, Codebasen, Agent-Output, die Standards des Rahmenwerks. Engineering auf T2 und höher ist meist ein Lesejob, das Schreiben folgt aus dem Lesen.
Sie kommen mit dem Anfängerdasein souverän zurecht. Sie wissen nicht alles, das sollen Sie auch nicht. Menschen, die das halten können, ohne Sicherheit zu performen, lernen schneller als jene, die so tun.
Sie schreiben klar. Spezifikationen, PR-Beschreibungen, Designnotizen. Engineers, die auf dieser Ebene klar schreiben können, steigen schneller auf als jene, die es nicht können, unabhängig von Code-Cleverness.
Sie nehmen Feedback gut an. Senior Engineers und der Agent-Reviewer geben Ihnen ständig Feedback. Menschen, die es ohne Abwehr aufnehmen können, verdichten sich viel schneller als jene, die abwehrend werden.
Sie sind neugierig auf die Fehlermodi des Agenten. Warum hat der Agent das falsch gemacht? Warum hat die Spezifikation diesen Randfall übersehen? Warum hat die Rekalibrierungssitzung das Ergebnis verändert? Neugier auf das System macht Sie darin gut.
Sie bauen Geduld mit unsauberer Diagnose auf. Rekalibrierung gegen Debugging gegen Spec-Lücke ist auch für Seniors schwer zu unterscheiden. Sie werden es früh nicht richtig hinbekommen; Sie bauen das Urteil über die Zeit auf.
Weniger essenziell als zuvor: rohe Tippgeschwindigkeit, Tiefe in einer einzelnen Programmiersprache, Algorithmen-Trivia, die Fähigkeit, sich stundenlang durch CRUD-Arbeit zu kämpfen. Das war die Lehre des Junior Engineers. Es ist nicht länger das Unterscheidungsmerkmal.
Fähigkeiten, die Sie entwickeln sollten
Die Eignungen beschreiben die Disposition. Die folgenden Fähigkeiten bauen Sie aktiv auf.
Spec-Lesen. Verstehen, was eine Spezifikation fragt, was nicht, und was mehrdeutig ist. Wie üben: Vor der Umsetzung einer Spezifikation einen Absatz schreiben, der zusammenfasst, was Sie bauen werden und was noch unklar ist. Mit der Intention des Spec-Autors vergleichen.
Spec-Schreiben (klein anfangen). Bugfixes, kleine Verbesserungen, internes Tooling: zuerst die Spezifikation schreiben. Wie üben: Für jede Aufgabe, die Sie übernehmen, eine Spezifikation entwerfen, auch wenn niemand danach fragt. Mit einem Senior FSE prüfen, verfeinern. Den Muskel aufbauen.
Diff-Lesen. Vom Agenten produzierten Code kritisch lesen. Wie üben: Bevor Sie einen Agent-PR genehmigen, den Sie übernommen haben, artikulieren, warum jeder bedeutsame Block korrekt oder inkorrekt ist. Verfolgen, wann Sie etwas übersehen haben, das Muster ist Ihr Lernstoff.
Navigation im Klärungsdialog. Die Vor-Ausführungs-Fragen des Agenten produktiv beantworten. Wie üben: Merken Sie sich die Fragen, die Sie überspringen oder durchwinken. Die übersprungenen sind meist dort, wo die Umsetzung schiefgeht.
Rekalibrierung beobachten. Lernen, wie Senior Engineers Stockungen diagnostizieren. Wie üben: Jede Rekalibrierungssitzung besuchen, die Sie können. Notizen machen, was die Diagnose ausgelöst hat. Die Muster sammeln sich zu Ihrer eigenen Diagnosefähigkeit.
Codebasis-Intuition aufbauen. Verstehen, was diese Codebasis will. Wie üben: Vor jeder nicht trivialen Änderung drei ähnliche Muster in der Codebasis lesen. Die Konventionen merken. Sich daran anpassen.
Bessere Fragen stellen. Die einzelne Fähigkeit, die das Wachstum im Engineering am stärksten beschleunigt. Wie üben: Bevor Sie eine Frage stellen, die Frage aufschreiben. Sie zurücklesen. Ist sie klar? Ist sie beantwortbar? Zeigt sie, was Sie schon versucht haben? Vor dem Fragen umschreiben.
Beitrag zum Kontext. Zu geteilten Prompts, Szenario-Bibliotheken, Runbooks beitragen. Wie üben: Ein kleiner Beitrag pro Sprint. Auch ein einziger Randfall, der zur Szenario-Bibliothek des Teams hinzugefügt wird, verstärkt sich.
Wählen Sie die Fähigkeit, die zu Ihrem jüngsten Stockungsmoment passt. Üben Sie sie zwei Wochen an echter Arbeit.
Wie sich das von der alten Junior- oder Mid-Software-Engineer-Rolle unterscheidet
| Alter Junior Engineer (vor KI) | Software Engineer (KI-nativ) |
|---|---|
| Verbringt den meisten Tag damit, Code per Hand zu schreiben | Verbringt den meisten Tag damit, Spezifikationen zu lesen, Agent-Output zu reviewen und Spezifizieren zu lernen |
| Lernt, indem er über Monate viele Zeilen einfachen Codes schreibt | Lernt, indem er Spezifikationen liest, Reviews beobachtet und an Rekalibrierungen teilnimmt |
| Erste 12 Monate sind meist CRUD und Bugfixes für triviale Probleme | Erste 12 Monate enthalten bedeutsame Feature-Beiträge, weil der Agent die triviale Schicht übernimmt |
| Senior Engineers sind knappe Zeit; Paaren ist selten | Paaren geschieht über Spezifikationen, PR-Reviews und Rekalibrierungssitzungen; Senior-Urteil ist zugänglicher |
| Karrierepfad: Junior zu Mid zu Senior, langsamer Anstieg | Karrierepfad: ähnlicher Verlauf, aber mit schnellerem Anstieg auf bedeutsamen Beitrag; T2.5 und T3 sind früher erreichbar |
| Die besten Junior Engineers sind die produktivsten | Die besten Junior Engineers sind die klarsten Leser und Schreiber |
Die Rolle ist kein „alter Junior-Entwickler mit KI-Werkzeugen". Es ist eine andere Lehre, und das Handwerk, das Sie aufbauen, ist anders.
Welche Rollenentwicklungsmuster wirken
- Elevation (primär, aber von anderem Ausgangspunkt). Wie beim Senior FSE verschiebt sich Ihre Arbeit von Ausführung zu Spezifikation und Validierung, aber Sie lernen beide Handwerke gleichzeitig, statt von einem zum anderen überzugehen.
- Konvergenz (sekundär). Wie Senior Engineers operieren Sie früher über den Stack hinweg als alte Juniors, weil der Agent die jeweilige Schicht übernimmt.
- Emergenz (teilweise). Manche der Lehrrituale (Klärungsdialog-Praxis, Rekalibrierungs-Beobachten, Feedback-Schleifen mit dem Agent-Reviewer) sind tatsächlich neue Wege, das Handwerk zu lernen.
Spezialisierung und Absorption wirken auf Ihre Rolle selbst nicht wesentlich, obwohl Absorption auf das alte Arbeitsmuster des Junior-Entwicklers (Volumen trivialen Codeschreibens) zutrifft, das die Lehre nicht mehr definiert.
Verwandte Rollen im Katalog
Quellen und weiterführende Literatur
- Stack Overflow (2025). Developer Survey: AI Tools section. Enthält Daten zur KI-Werkzeugnutzung durch Junior- und Mid-Engineers.
- GitHub & Accenture (2024). Quantifying GitHub Copilot's Impact.
- GitClear (2025). AI Assistant Code Quality Research. Die Daten zur Qualitätsverschlechterung, wenn der Kompetenzfortschritt nicht Schritt hält.
- Aus diesem Rahmenwerk: Spezifikations-Leitfaden, Zuverlässigkeit entwickeln und Kompetenz-Stufenplan.
← Zurück zu Rollen · Rollenentwicklungsmuster · Referenzrahmenwerk · Ihre Rolle transformieren · Spezifikations-Leitfaden