Tech Lead

Sie schreiben den Code nicht mehr. Sie schreiben die Spezifikationen, die Code entstehen lassen, und Sie validieren die Ergebnisse. Die Arbeit ist schneller, Ihre Reichweite ist größer, und Ihre Entscheidungen wiegen mehr.

Die Arbeit

Sie verantworten einen Ausschnitt des Produkts. Innerhalb dieses Ausschnitts entscheiden Sie, was gebaut wird, wie es gebaut wird und ob das Ausgelieferte korrekt ist. Sie sind verantwortlich für Ergebnisse, nicht für bestimmte Codezeilen.

Im Alltag tun Sie folgendes:

• Spezifikationen schreiben, die ein KI-Agent durchgängig ohne Echtzeitaufsicht umsetzen kann. Jede Spezifikation enthält Akzeptanzkriterien, Randfälle, Risikoklassifizierung und die zutreffenden Validierungs-Gates.
• Klärungsdialoge mit dem Agenten vor der Ausführung führen. Sie beantworten die Fragen, die echte Mehrdeutigkeit auflösen, vertagen die Fragen, die während der Umsetzung beantwortet werden sollten, und weisen die Fragen zurück, die eine unscharfe Spezifikation Ihrerseits signalisieren.
• Output an risikoabgestuften Gates validieren. Umkehrbare Arbeit läuft über den Agent-Reviewer mit Stichproben. Unumkehrbare Arbeit (Produktions-Deploys, Schemaänderungen, kundengerichtete Texte, Sicherheitsgrenzen) erfordert Ihre direkte Freigabe.
• Rekalibrierungssitzungen durchführen, wenn ein Feature stockt. Der Agent ist an eine strukturelle Grenze gestoßen, die Spezifikation hat eine Rahmenbedingung verfehlt oder der Kontext stimmt nicht. Sie diagnostizieren, was zutrifft, und bauen das Verständnis des Agenten gemeinsam mit dem Team wieder auf.
• Die Standards setzen für den Ausschnitt: was als vollständige Spezifikation zählt, wann eskaliert wird, wie der Agent-Reviewer konfiguriert ist, welche Muster Hausstil sind.
• Ihre Engineers mentorieren in Spezifikationsqualität, Reviewurteil und dem Unterschied zwischen Debugging und Rekalibrierung. Hier konzentriert sich das Handwerk der Rolle.
• Nahe am Nutzer bleiben. First-User-UX-Tests, Randfall-Sessions und qualitative Validierung führen Sie selbst durch, statt zu delegieren.
• Unumkehrbare Entscheidungen verantworten. Produktions-Deploys, Datenmigrationen, Lieferantenzusagen, architektonische Pivots. Der Agent erledigt die umkehrbare Arbeit, für den Rest unterschreiben Sie.

Wie Erfolg aussieht

Konkrete Ergebnisse auf dieser Ebene:

• Durchsatz. Ihr Ausschnitt liefert Features in Tagen aus, nicht in Sprints. Stories werden durchgängig (Spec, Implementierung, Review, Merge) für typische Arbeit in Stunden bis Tagen abgeschlossen.
• Qualität. Defekte in der Produktion pro Feature sind niedrig und tendieren nach unten. Der Agent-Reviewer fängt das meiste, was Sie manuell gefangen hätten.
• Kosten. Token-Ausgaben pro gemergtem PR werden verfolgt und sind sichtbar. Kosten pro Ergebnis verbessern sich über die Zeit, nicht nur der absolute Durchsatz.
• Teamfähigkeit. Andere Engineers in Ihrem Ausschnitt schreiben verwendbare Spezifikationen, ohne dass Sie jedes Wort prüfen. Rekalibrierungssitzungen erfordern nicht alle Ihre Moderation.
• Nutzergerichtete Ergebnisse. Features, die Sie ausliefern, treffen den tatsächlichen Bedarf des Nutzers beim ersten Release. Die Zahl der zurückgerollten oder wesentlich überarbeiteten Features ist niedrig.

Was auf dieser Ebene nicht als Erfolg zählt: ausgelieferte Codezeilen, PR-Zähler, geloggte Stunden, interne Velocity-Metriken, die nicht in Nutzerergebnisse übersetzen.

Was diese Arbeit interessant macht

Der interessante Teil der Arbeit ist nicht, was KI macht. Es ist, was menschlich bleibt.

Ihre Entscheidungen vervielfältigen sich. Eine gut geschriebene Spezifikation erzeugt Dutzende korrekter Outputs. Ein gut entworfenes Validierungs-Gate fängt eine ganze Fehlerklasse für immer. Ihre Reichweite ist nicht mehr durch Ihre Tippgeschwindigkeit oder Ihre Schlafstunden begrenzt.

Sie liefern schnell aus und sehen die Wirkung. 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.

Sie arbeiten auf der Ebene der Intention. Sie entscheiden, was existieren soll und warum. Sie verbringen keine drei Stunden damit, ein Formular zu verdrahten, das ein Junior in zwei Stunden hätte verdrahten können. Die Arbeit konzentriert sich auf die wirklich harten Teile des Engineerings: Systeme entwerfen, Fehlerverhalten antizipieren, Grenzen richtig setzen.

Die schwierigsten Probleme sind jetzt die interessantesten. Rekalibrierungsarbeit, also herauszufinden, warum ein kompetentes System verwirrt wurde, sitzt an der Schnittstelle von Engineering, Sprache und Psychologie. Es ist nicht „Debugging im großen Maßstab". Es ist näher am Unterrichten oder an Therapie. Wenn eine Story auf T3 feststeckt, liegt die Antwort selten im Code.

Sie verbringen mehr Zeit mit Menschen. Stakeholder, Designer, Nutzer, Ihr Team. Der Agent erledigt das Tippen, Sie führen die Gespräche, die das Tippen nützlich machen. Für Engineers, die teilweise in die Arbeit kamen, um Dinge zu bauen, die Menschen nutzen, ist das eine Rückkehr.

Sie verantworten Ergebnisse, die größer sind als das, was Sie allein hätten bauen können. Ihr Ausschnitt liefert mit dem Durchsatz eines 10-Personen-Teams im alten Modell aus. Die Verantwortung ist real und die Reichweite ist real.

Was unter Umständen nicht reizt. Sie schreiben weniger Codezeilen. Sie sehen weniger zeilenweises Handwerk in Produktion. Der Flow-Zustand mit stundenlangem konzentriertem Coden tritt seltener auf. Wenn Ihre Befriedigung hauptsächlich aus dem Produzieren des Artefakts kam, wird diese Befriedigung umziehen müssen; manche finden eine tiefere Version davon 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 denen, die Tech Leads in der vorherigen Ära definierten.

Sie können artikulieren, was Sie wollen. Spezifikationen sind zuerst Schreiben, dann Coden. Menschen, die in Worten und Bildern denken, nicht nur in Code, schreiben bessere Spezifikationen.

Sie denken, bevor Sie handeln. Tippgeschwindigkeit hat aufgehört zu zählen. Qualität des Denkens im Voraus hat angefangen, viel zu zählen. Menschen, die innehalten, um die richtigen Fragen zu stellen, bevor sie beginnen, übertreffen jene, die per Mustererkennung losstürzen.

Sie sind bequem damit, Ergebnisse zu verantworten, die Sie nicht persönlich produziert haben. Das ist eine echte Verschiebung. Der Agent hat den Code geschrieben, Sie haben freigegeben, wenn er fehlschlägt, tragen Sie das. Menschen, die diese Verantwortung halten können, ohne zusammenzuzucken und ohne den Agenten zu mikromanagen, gedeihen hier.

Sie kommen mit unsauberer Diagnose gut zurecht. Rekalibrierungsarbeit ist selten im unmittelbaren Sinne befriedigend. Der Agent hat etwas subtil falsch gemacht, Sie müssen herausfinden warum, die Antwort liegt meist in der Spezifikation oder im Kontext, und die Behebung liegt vorgelagert. Menschen, die diese Art Detektivarbeit mögen, kommen gut zurecht; Menschen, die saubere Probleme mit sauberen Antworten wollen, haben Mühe.

Sie können lehren. Jede Spezifikation ist ein Lehrartefakt. Jede Rekalibrierungssitzung ist eine Coaching-Sitzung. Jedes Code-Review ist ein Feedback-Austausch. Tech Leads, die früher „es einfach selbst machen" konnten, aber nie ganz die Qualität ihres Teams skalieren konnten, finden, dass diese Rolle belohnt, worin sie schon gut waren.

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.

Weniger essenziell als zuvor: rohe Coding-Geschwindigkeit, Algorithmen-Trivia, Sprachpedanterie, die Fähigkeit, im Kopf zwischen fünf Dateien zu wechseln. 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, wer Sie sind. Die folgenden Fähigkeiten bauen Sie aktiv auf. Keine davon ist geheimnisvoll. Alle erfordern bewusste Übung.

Spezifikations-Engineering. Spezifikationen schreiben, die ein Agent durchgängig ohne Echtzeitaufsicht umsetzen kann. Akzeptanzkriterien, Randfälle, Risikoklassifizierung, Validierungs-Gates: explizit, testbar, vollständig. Wie üben: Schreiben Sie die Spezifikation vor jedem Code, auch für kleine Aufgaben. Bilden Sie ein Paar mit jemandem, der gute Spezifikationen schreibt, und arbeiten Sie dessen Entwürfe rückwärts auf. 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. Wissen, was zu hinterfragen ist, ohne jede Zeile zu lesen. Den fehlenden Fall, die falsche Abstraktion, den stillen Bruch erkennen. Wie üben: Prüfen Sie KI-erzeugte PRs Ihres Teams. Artikulieren Sie warum Sie zurückweisen würden, nicht nur wo. Verfolgen Sie die Einwände, die sich als falsch erwiesen, dort ist Ihr Urteil fehlkalibriert.

Diagnose: Rekalibrierung gegen Debugging. Wenn eine Story stockt, wissen, ob das Problem in der Spezifikation, im Kontext oder in der Umsetzung liegt. Die falsche Diagnose kostet Tage. Wie üben: Führen Sie ein kurzes Journal über festgefahrene Stories. Klassifizieren Sie jede Nachschau als Rekalibrierung (Problem in Spec oder Kontext) oder Debugging (Problem in der Umsetzung). Verfolgen Sie, welche Interventionen tatsächlich entblockten. Das Muster zeigt sich.

Entwurf risikoabgestufter Validierung. Umkehrbare Arbeit von unumkehrbarer Arbeit trennen und jeder das richtige Validierungs-Gate zuweisen. Zu viel Gating bremst das Team; zu wenig liefert das Falsche aus. 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 Tech Lead mit Backend-Hintergrund jetzt nutzergerichtete Features durchgängig verantworten kann. Wie üben: Lesen Sie PRs in angrenzenden Bereichen (Frontend, Infra, Data). Kommentieren Sie noch nicht. Merken Sie, was Sie verwirrt, dort ist Ihre Lernfläche. Bilden Sie ein Paar mit der Person, deren Spezialität es früher war.

Lehren durch Schreiben. Jede Spezifikation ist auch Einarbeitungsmaterial. Jeder Eintrag im Rekalibrierungsjournal ist künftiges Training. Die Tech Leads, die die Qualität ihres Teams skalieren, sind jene, deren schriftliche Artefakte ohne ihre Anwesenheit wiederverwendbar sind. Wie üben: Schreiben Sie Spezifikationen so, als würde sie ein Junior-Engineer in sechs Monaten ohne jeden Kontext lesen. Wenn Ihre Spezifikationen Echtzeitklärung brauchen, um nützlich zu sein, sind sie nicht fertig.

Gewohnheiten unter den Fähigkeiten. Innehalten, bevor Sie handeln. Klärende Fragen stellen, bevor Sie annehmen. Begründungen dokumentieren, nicht nur Entscheidungen. Das sind keine Fähigkeiten zum Abhaken, das sind Disziplinen, die Sie pflegen. Die obigen Fähigkeiten verstärken sich nur, wenn diese Gewohnheiten intakt sind.

Wenn Sie in der alten Version der Rolle verankert sind, ist der ehrliche Einstieg: Wählen Sie eine dieser Fähigkeiten, üben Sie sie zwei Wochen an echter Arbeit und merken Sie, wie sich Ihr Verhältnis zur Rolle verändert. Alle sechs gleichzeitig entwickeln zu wollen, ist der häufigste Fehlermodus.

Wie sich das von der alten Tech-Lead-Rolle unterscheidet

Die Rolle ist kein umbenannter „Senior Engineer". Der Alltag ist strukturell anders. Durchsatz wird durch Spezifikationsqualität und Validierungsdesign begrenzt statt durch Teamgröße und Fokuszeiten; Standups und Rituale schrumpfen zugunsten asynchronen Spec-Reviews; die besten Engineers in der Rolle sind klare Spezifizierer und unterscheidungskräftige Reviewer, keine produktivsten Produzenten.

Welche Rollenentwicklungsmuster wirken

Drei der fünf Rollenentwicklungsmuster prägen diese Rolle.

• Elevation (primär). Die Verschiebung vom Produzieren von Code zum Spezifizieren und Validieren. Wert wandert von Ausführungstempo zu Spezifikationsqualität und Reviewurteil.
• Konvergenz (sekundär). Grenzen zwischen Frontend, Backend, Infrastruktur und QA verschwimmen. Ein Tech Lead mit starkem Urteil lenkt den Agenten über den gesamten Stack auf einem einzelnen Feature.
• Emergenz (teilweise). Manche Verantwortungen sind tatsächlich neu: den Agent-Reviewer konfigurieren, risikoabgestufte Validierungs-Gates entwerfen, Rekalibrierungssitzungen führen.

Spezialisierung und Absorption wirken nicht wesentlich: die Rolle weitet sich, statt sich zu verengen, und schrumpft nicht oder verschwindet.

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.
• GitClear (2025). AI Assistant Code Quality Research.
• Aus diesem Rahmenwerk: Engineering-Skala – Sprosse 0 bis 5.
• Aus diesem Rahmenwerk: KI-Labor – Betriebseinheit und Zuverlässigkeit entwickeln.

← Zurück zu Rollen · Rollenentwicklungsmuster · Referenzrahmenwerk · Ihre Rolle transformieren · Spezifikations-Leitfaden · KI-Ausführungsstandards