Full-Stack Engineer
Sie liefern Features durchgängig aus. Der Agent schreibt den Code, Sie architektieren, spezifizieren, validieren und verantworten das Ergebnis. Sie bewegen sich schnell über den gesamten Stack, weil der Agent keine Stack-Vorlieben hat und Sie haben aufgehört, welche zu haben.
Die Arbeit
Sie liefern Features aus. Durchgängig heißt durchgängig: Datenschicht, API, Frontend, Tests, Deployment, Observability. Nicht, weil Sie alles persönlich machen, sondern weil Sie das Ergebnis verantworten und der Agent jene Schicht übernimmt, die die Arbeit gerade benötigt.
Im Alltag tun Sie folgendes:
- Features vollständig spezifizieren. Akzeptanzkriterien, Randfälle, Datenimplikationen, UX-Verhalten, Risikoklassifizierung, Validierungs-Gates. Die Spezifikation ist das Artefakt, mit dem der Agent ohne Echtzeitaufsicht ausführen kann.
- Klärungsdialoge mit dem Agenten vor der Ausführung führen. Sie beantworten die Fragen, die echte Mehrdeutigkeit auflösen, vertagen jene, die während der Umsetzung beantwortet werden sollten, und weisen jene zurück, die signalisieren, dass Ihre Spezifikation vage war.
- Auf Feature-Ebene architektieren. Datenmodell-Entscheidungen, API-Form, Komponentengrenzen, Abhängigkeitsauswahl: Ihre Entscheidungen, die Umsetzung übernimmt der Agent.
- Vom Agenten erzeugte PRs reviewen. Auf T2 zeilenweise. Auf T3 auf Diff- und Verhaltensebene. Sie suchen nach dem fehlenden Fall, der falschen Abstraktion, dem stillen Bruch, nicht nach Tippfehlern.
- An risikoabgestuften Gates validieren. Stichproben für umkehrbare Änderungen. Direkte Freigabe für unumkehrbare. Sie entwerfen die Gates für Ihre Features beim Spezifizieren.
- Rekalibrieren, wenn Stories stocken. Falsche Umsetzungen sind meist Symptome einer falschen Spezifikation oder eines falschen Kontexts. Sie diagnostizieren, spezifizieren neu und nehmen wieder auf, statt den Output des Agenten zu debuggen.
- Den Kontext der Codebasis pflegen. Geteilte Prompt-Vorlagen, Kontextdateien, Hausstil-Leitfäden, Szenario-Bibliotheken. Das sind erstklassige Artefakte, Sie tragen zu ihnen bei und nutzen sie.
- Observability für das Ausgelieferte verantworten. Telemetrie, Alarme, Fehlerbudgets. Sie entwerfen das in die Spezifikation hinein, der Agent setzt um, Sie verifizieren, dass das Signal echt ist.
- Mit benachbarten Engineers an stack-übergreifenden Entscheidungen paaren. Der Agent absorbiert vieles, was früher Spezialisten-Übergaben erforderte, aber menschliches Urteil bleibt im Paar besser.
Wie Erfolg aussieht
Konkrete Ergebnisse auf dieser Ebene:
- Durchsatz. Sie liefern Features in Tagen aus, nicht in Sprints. Stories werden (Spec, Implementierung, Review, Merge) für typische Arbeit in Stunden bis Tagen abgeschlossen.
- Qualität. Defekte in Produktion aus Ihren Features sind selten und tendieren nach unten. Der Agent-Reviewer fängt, was Sie manuell gefangen hätten, Ihre Interventionen fangen den Rest.
- Kostendisziplin. Token-Ausgaben pro gemergtem PR werden verfolgt. Kosten pro Ergebnis verbessern sich über die Zeit, nicht nur der absolute Durchsatz.
- Stack-übergreifende Arbeit. Sie liefern Features aus, die in derselben Woche Frontend, Backend und Infrastruktur berühren. Der Agent erledigt die jeweilige Schicht, Sie liefern das Urteil.
- Codebasis-Gesundheit. Refactoring findet statt, technische Schuld wird abgebaut, die Codebasis altert gut, statt zu erstarren.
Was nicht als Erfolg zählt: ausgelieferte Codezeilen, PR-Zähler, geloggte Stunden, Sprint-Velocity-Punkte, die nicht in Nutzerergebnisse übersetzen.
Was diese Arbeit interessant macht
Der interessante Teil der Arbeit ist nicht die Geschwindigkeit, sondern was bei dieser Geschwindigkeit möglich wird.
Sie liefern schneller aus, als Sie für möglich hielten. Was früher einen Sprint brauchte, braucht einen Tag. Das Feature, das Sie Dienstagvormittag spezifizierten, ist Mittwochnachmittag in Produktion. Die Rückkopplungsschleife mit dem Nutzer schließt sich innerhalb der Woche, und Sie spüren es.
Full-Stack wird selbstverständlich. Sie hören auf, Stack-Vorlieben zu haben, weil der Agent keine hat. Sie bewegen sich fließend zwischen Datenmodell-Entscheidungen, API-Design und UX-Verhalten, weil die Reibung des Kontextwechsels über den Stack hinweg gegen Null gefallen ist. Die Belohnung ist echte Bandbreite des Umfangs.
Sie entwerfen mehr und tippen weniger. Der Großteil Ihres Handwerks lebt jetzt in Spezifikations- und Architekturentscheidungen, nicht im Tippen. Für Engineers, die in die Arbeit kamen, weil sie den Entwurfsteil mehr liebten als den Tippteil, ist das eine Rückkehr.
Die schwierigen Probleme sind die befriedigenden. Einen weiteren CRUD-Endpoint zu verdrahten, dauert Minuten. Die Probleme, die für Sie bleiben, sind jene, die Urteil erfordern: eine State-Machine richtig hinbekommen, die Grenze zwischen zwei Domänen wählen, entscheiden, was zu testen und worauf zu vertrauen ist. Das sind die Probleme, die Senior-Engineering von Junior-Engineering unterscheiden, und sie sind der Großteil dessen, was übrig bleibt.
Sie kollaborieren mit einem anderen Agenten, nicht nur mit anderen Menschen. Mit einem fähigen Agenten zu arbeiten ist seine eigene Fähigkeit, anders als Pair Programming, anders als Soloarbeit. Die Klärungsdialoge sind für sich interessant. Die Rekalibrierungssitzungen sind für sich interessant.
Sie sehen Ihre Arbeit schnell in der Welt. Features in Produktion innerhalb von Stunden nach der Spezifikation bedeutet, dass Ihr Gefühl von Handlungsfähigkeit in der Rolle stärker ist als für die meisten Senior-Engineers seit Jahren. Die Verzögerung zwischen Gedanke und Wirkung hat sich komprimiert.
Was unter Umständen nicht reizt. Sie schreiben weniger Code per Hand. Der Flow-Zustand mit stundenlangem konzentriertem Coden tritt seltener auf, und wenn doch, tendiert er zu ungewöhnlichen Stellen (Rekalibrierungssitzungen, Infrastrukturarbeit, die der Agent noch nicht gut kann). Die Grenzen zwischen „Ihrer Arbeit" und der Arbeit des Agenten verschwimmen. Wenn Ihre Handwerksidentität im persönlichen Produzieren des Artefakts verwurzelt ist, muss diese Identität wandern. Manche Engineers finden eine tiefere Version der Befriedigung in der neuen Arbeit, manche nicht. Seien Sie ehrlich mit sich, welche Art Engineer Sie sind.
Wer in dieser Rolle gedeiht
Die wichtigsten Eignungen auf T3 unterscheiden sich von jenen, die Senior-Engineering vor KI definierten.
Sie denken, bevor Sie tippen. Tippgeschwindigkeit hat aufgehört zu zählen; Qualität des Denkens im Voraus zählt viel. Sie halten inne, um Randfälle vor dem Spezifizieren zu bedenken; Sie stürmen nicht per Mustererkennung los.
Sie schreiben klar. Spezifikationen sind zuerst Schreiben, dann Coden. Menschen, deren schriftliches Denken unscharf ist, schreiben unscharfe Spezifikationen und bekommen unscharfen Output.
Sie sind bequem damit, Ergebnisse zu verantworten, die Sie nicht persönlich produziert haben. Der Agent hat den Code geschrieben, Sie haben freigegeben, wenn er fehlschlägt, tragen Sie das. Menschen, die diese Verantwortung halten können, ohne den Agenten zu mikromanagen, gedeihen.
Sie kommen mit unsauberer Diagnose gut zurecht. Wenn eine Story stockt, liegt die Ursache meist in der Spezifikation oder im Kontext, nicht im Code. Die Detektivarbeit, herauszufinden, welche Annahme gebrochen ist, gehört jetzt zum Handwerk. Menschen, die das genießen, finden die Arbeit reich; Menschen, die saubere Probleme mit sauberen Antworten wollen, haben Mühe.
Sie haben Geschmack. Wenn der Agent drei plausible Implementierungen produziert, erkennen Sie, welche für diese Codebasis die richtige ist. Geschmack ist schwer zu interviewen und schwerer zu lehren, aber er ist der einzelne nachhaltigste Vorteil auf T3.
Sie kümmern sich um Systeme, nicht nur um Features. Features werden ausgeliefert und ausgeliefert und ausgeliefert. Die Engineers, die über die Zeit gedeihen, achten darauf, wie die Codebasis altert, welche Muster wiederkehren, was die nächste architektonische Entscheidung antizipieren muss.
Weniger essenziell als zuvor: rohe Coding-Geschwindigkeit, Algorithmen-Trivia, Sprachpedanterie, die Fähigkeit, fünf Dateien gleichzeitig im Kopf zu halten. Das waren die Marker des Senior-Engineerings vor KI. Sie helfen weiterhin. Sie unterscheiden die Rolle nicht mehr.
Fähigkeiten, die Sie entwickeln sollten
Die obigen Eignungen beschreiben die Disposition. Die folgenden Fähigkeiten bauen Sie aktiv auf.
Spezifikations-Engineering. Spezifikationen schreiben, die ein Agent durchgängig umsetzen kann. Akzeptanzkriterien, Randfälle, Risikoklassifizierung, Validierungs-Gates. Wie üben: Schreiben Sie die Spezifikation vor jedem Code, auch für kleine Aufgaben. Lesen Sie Ihre Spezifikationen einen Monat später noch einmal; jene, die schlecht gealtert sind, sind Ihr Lernstoff. Siehe Spezifikations-Leitfaden.
Reviewurteil auf Diff-Ebene. Agent-Output lesen, um den fehlenden Fall, die falsche Abstraktion, den stillen Bruch zu erkennen, ohne jede Zeile zu lesen. Wie üben: Prüfen Sie KI-erzeugte PRs Ihres Teams. Artikulieren Sie warum Sie zurückweisen würden. Verfolgen Sie die Einwände, die sich als falsch erwiesen; dort ist Ihr Urteil fehlkalibriert.
Diagnose: Rekalibrierung gegen Debugging. Wenn Arbeit stockt, wissen, ob das Problem in der Spezifikation, im Kontext oder in der Umsetzung liegt. Wie üben: Führen Sie ein kurzes Journal über festgefahrene Stories. Klassifizieren Sie jede Nachschau als Rekalibrierung (Spec- oder Kontextproblem) oder Debugging (Umsetzungsproblem). Verfolgen Sie, welche Interventionen tatsächlich entblockten.
Risikoklassifizierung. Umkehrbare von unumkehrbarer Arbeit unterscheiden und das richtige Validierungs-Gate zuweisen. Wie üben: Für jede Story, die Sie spezifizieren, die Gates explizit benennen. Begründen Sie warum. Anpassen, wenn Sie aus Fehlklassifizierungen lernen. Siehe KI-Ausführungsstandards.
Stack-übergreifendes Urteil. Solide Entscheidungen außerhalb Ihrer historischen Spezialität treffen. Konvergenz auf T3 bedeutet, dass ein Senior Engineer mit Backend-Hintergrund jetzt nutzergerichtete Features durchgängig verantworten kann. Wie üben: Lesen Sie PRs in angrenzenden Bereichen (Frontend, Infra, Data). Merken Sie, was Sie verwirrt, dort ist Ihre Lernfläche. Bilden Sie ein Paar mit der Person, deren Spezialität es früher war.
Handwerk des Klärungsdialogs. Produktive Frage und Antwort mit dem Agenten vor der Ausführung. Wissen, welche Fragen vollständig zu beantworten, welche zu vertagen, welche eine unscharfe Spezifikation signalisieren. Wie üben: Merken Sie sich die Fragen, die ein Agent vor der Umsetzung stellt. Kategorisieren Sie sie. Die Kategorisierung zeigt Ihnen, wo Ihre Spezifikationen Arbeit brauchen.
Kontextpflege. Die geteilten Prompt-Vorlagen, Kontextdateien und Szenario-Bibliotheken pflegen, aus denen die Agenten des Teams schöpfen. Wie üben: Eine Verbesserung pro Sprint beitragen. Die Artefakte verstärken sich, kleine Beiträge zählen.
Wählen Sie eine Fähigkeit, üben Sie sie zwei Wochen an echter Arbeit und merken Sie, wie sich Ihr Verhältnis zur Rolle verschiebt. Alle sieben gleichzeitig zu entwickeln, ist der häufigste Fehlermodus.
Wie sich das von der alten Senior-Engineer-Rolle unterscheidet
| Alter Senior Engineer (vor KI) | Senior Engineer (KI-nativ) |
|---|---|
| Schreibt komplexen Code selbst; reviewed den Code anderer | Schreibt Spezifikationen; reviewed Agent-Output an risikoabgestuften Gates |
| Spezialisiert auf Frontend oder Backend oder Infrastruktur | Operiert über den gesamten Stack, weil der Agent es tut |
| Verbringt 50 bis 70 Prozent der Zeit mit Coden | Verbringt unter 20 Prozent der Zeit mit Coden |
| Durchsatz begrenzt durch individuelle Fokuszeiten | Durchsatz begrenzt durch Spezifikationsqualität und Reviewurteil |
| Übergaben an Spezialisten für stack-übergreifende Arbeit | Paart mit Spezialisten für Urteil, liefert stack-übergreifend allein aus |
| Die besten Engineers sind die schnellsten und produktivsten Produzenten | Die besten Engineers sind die klarsten Spezifizierer und unterscheidungskräftigsten Reviewer |
| Tests zeilenweise von Menschen geschrieben | Testszenarien von Menschen spezifiziert, vom Agenten geschrieben, von Menschen gereviewed |
Die Rolle ist kein umbenannter „Senior". Der Alltag ist strukturell anders.
Welche Rollenentwicklungsmuster wirken
- Elevation (primär). Der Schwerpunkt der Rolle bewegt sich von Ausführung zu Spezifikation und Validierung. Wert wandert von Tippgeschwindigkeit zu Spezifikationsqualität und Reviewurteil.
- Konvergenz (sekundär). Grenzen zwischen Frontend, Backend und Infrastruktur verschwimmen. Ein Senior Engineer mit starkem Urteil kann den Agenten über den gesamten Stack lenken bei einem Feature, das früher die Koordination dreier Spezialisten erforderte.
- Emergenz (teilweise). Manche Verantwortungen sind tatsächlich neu: Klärungsdialoge mit Agenten, Rekalibrierungssitzungen, Beiträge zur Konfiguration des Agent-Reviewers.
Spezialisierung und Absorption wirken nicht wesentlich: die Rolle weitet sich, statt sich zu verengen, und schrumpft nicht oder verschwindet.
Verwandte Rollen im Katalog
Quellen und weiterführende Literatur
- Patel, N. (2026). From Tasks to Roles: How Agentic AI Reconfigures Occupational Structures.
- Stack Overflow (2025). Developer Survey: AI Tools.
- GitHub & Accenture (2024). Quantifying GitHub Copilot's Impact in the Enterprise.
- GitClear (2025). AI Assistant Code Quality Research.
- Aus diesem Rahmenwerk: Engineering-Skala – Sprosse 0 bis 5 und KI-Labor – Betriebseinheit.
← Zurück zu Rollen · Rollenentwicklungsmuster · Referenzrahmenwerk · Ihre Rolle transformieren · Spezifikations-Leitfaden · KI-Ausführungsstandards · Zuverlässigkeit entwickeln