Wird geladen…

Werden die Manager, die dachten, Engineers würden von KI ersetzt, nicht selbst am schnellsten ersetzt?

senior_slacker
Öffentlich 13 Gespräche 19 Gedanken 76 Zustimmungen 8 Ablehnungen 0 Serien

Letztes Jahr hatte mein LinkedIn-Feed ein eigenes Genre. Ein Program Manager oder ein „Delivery Lead“ oder jemand mit Agile in der Headline postete einen Screenshot von einer KI, die eine Funktion schreibt, hängte eine Zeile dran wie „und es hieß, dieser Job sei sicher, lern halt programmieren“ und sammelte vierhundert Likes von Leuten ein, die denselben Job machen. Die Unterstellung war immer, dass der Tipp-Anteil am Engineering das Engineering sei, und jetzt, wo ein Modell tippen kann, sei die

In groups

Beitragsinhalt

Letztes Jahr hatte mein LinkedIn-Feed ein eigenes Genre. Ein Program Manager oder ein „Delivery Lead“ oder jemand mit Agile in der Headline postete einen Screenshot von einer KI, die eine Funktion schreibt, hängte eine Zeile dran wie „und es hieß, dieser Job sei sicher, lern halt programmieren“ und sammelte vierhundert Likes von Leuten ein, die denselben Job machen. Die Unterstellung war immer, dass der Tipp-Anteil am Engineering das Engineering sei, und jetzt, wo ein Modell tippen kann, sei die tippende Klasse erledigt.

Ich glaube, sie haben das Orgchart auf dem Kopf gelesen. Und ich freue mich, dass sie es gerade merken

Hier ist der Punkt, den auf dieser Seite des Feeds niemand laut ausspricht. KI ist nicht besonders gut im tragenden Teil des Bauens, also darin zu entscheiden, was das System tun soll, zu wissen, warum die letzten drei Anläufe gescheitert sind, und zu erkennen, wenn das Modell dir gerade mit voller Überzeugung etwas Kaputtes hingelegt hat. Im anderen Teil ist sie dafür richtig gut, geradezu peinlich gut. Das Status-Rollup. Die Release Notes, die keiner liest. Der Feature-Katalog, der in einer Woche veraltet ist. Der Test-Plan, der größtenteils eine Umformatierung der Akzeptanzkriterien ist. Das Weekly Update, das den Standup zusammenfasst, der den Slack-Thread zusammengefasst hat. Das ist nicht die Arbeit, mit der KI sich schwertut. Das ist die Arbeit, für die KI geboren wurde.

Schau dir also an, wer wo sitzt. Die unterstützende Schicht existiert per Design dafür, die Teile zu übernehmen, die die Engineers nicht machen wollten. Den Projekt-Tracker aktuell halten. Den Leuten wegen Updates hinterherlaufen. Aus zwei Sätzen eines Engineers einen Absatz für den VP machen. Aus dem Absatz eines Engineers zwei Sätze für den VP machen. Das Doc pflegen. Das Meeting leiten, in dem alle sagen, was sie gestern schon schriftlich gesagt haben. Ich will damit nicht gemein sein. Diese Aufgaben waren real und sie waren öde und irgendjemand musste sie machen, und genau deshalb wurden die Rollen überhaupt finanziert. Das Problem ist, dass „eine saubere Zusammenfassung von Inputs erzeugen, die andere produziert haben“ genau die Form von dem hat, was ein Sprachmodell am besten kann, und „die Inputs erzeugen“ der Teil ist, den es allein immer noch nicht hinkriegt.

Und hier ist die Asymmetrie, die die Obsoleszenz-Poster übersprungen haben. Um KI gut zu nutzen, musst du sie prüfen können. Du musst den Diff lesen und merken, dass er falsch ist. Du musst dir die generierte Migration ansehen und bemerken, dass sie keinen Rollback hat. Der Builder hat das schon. Es ist dieselbe Fähigkeit, die ihn zum Builder gemacht hat. Die Koordinationsschicht dagegen wurde unter der ausdrücklichen Maßgabe eingestellt, dass sie den Code nicht würde lesen müssen, und jetzt produziert das Tool, das sie retten soll, Output, dem man nur trauen kann, wenn man den Code lesen kann. Man hat ihnen eine Kettensäge in die Hand gedrückt, und das Handbuch ist in einer Sprache, von der man ihnen gesagt hatte, sie müssten sie nie lernen.

Ein guter Program Manager ist keine Status-Update-Maschine.

Ja, ich weiß. Aber von den ungefähr 40, die mir bisher im Berufsleben begegnet sind, waren es vielleicht 2. 38 waren definitiv Status-Update-Maschinen. Der eigentliche Job, der, für den zu zahlen sich lohnt, ist das Urteilsvermögen darüber, was gestrichen wird, die politische Deckung, wenn ein Launch rutscht, das Gespür dafür, welche „kurze Frage“ eines Executives eine Drohung ist, und sechs Teams, die sich gegenseitig nicht ausstehen können, auf einen Termin festzunageln. Nichts davon macht KI. Sie kann im Raum keine Schuld auf sich nehmen. Sie kann nicht entscheiden, dass die technisch korrekte Reihenfolge die politisch selbstmörderische ist. Die ganze Funktion auf „hält die Confluence-Seite warm“ zu reduzieren, ist die älteste Fantasie der Coder, und sie hat sich über die Besten in dieser Rolle immer geirrt. Ich weiß.

Der Job aus Urteil und Abschirmung war nie der ganze Headcount. Unter jedem dieser wirklich guten Program Manager lag eine Schicht von Leuten, deren echter Tag aus Artefakt-Pflege bestand, dem Rollup, dem Katalog, dem Deck, das das Deck noch einmal aufsagte.

Die „Engineers sind erledigt“-Fraktion hatte es verkehrt herum, weil sie verwechselte, wer Wert produziert, mit dem, der am lautesten darüber redet. Wer eine gute Antwort von einer selbstbewussten falschen unterscheiden kann, ist die Person, die KI wertvoller macht, nicht weniger wert. Diese Person hat meistens gebaut. Es war selten die, die den Screenshot postete.

Thoughts

  • der_fahrplan

    Ich gebe dir die 38 von 40, die Status-Update-Maschinen waren. Den Rest nicht. Du beschreibst die Artefakt-Schicht und nennst sie „die Koordination“, das sind aber zwei verschiedene Dinge.

    Das Status-Rollup kann ein Modell schreiben, geschenkt. Was es nicht kann: entscheiden, welches der sechs Teams diesen Sprint verliert, und das so kommunizieren, dass der VP nicht eskaliert und der Engineer nicht kündigt. Diese Arbeit hinterlässt kein Artefakt, deshalb hältst du sie für nicht vorhanden.

    Permalink
  • prozess_protokoll

    Das hier liest sich von der Junior-Seite ziemlich beklemmend, weil mein halber Tag genau die Artefakt-Schicht ist, die du beschreibst. Pre-Read-Decks, Research-Zusammenfassungen, das Rollup für die Review.

    Meine Frage ist ernst gemeint: wenn das der Teil ist, den KI übernimmt, wie kommt jemand wie ich dann überhaupt an den Punkt, an dem ich das Urteil habe, das du für unersetzlich hältst? Den lernt man doch genau durch diese langweilige Arbeit.

    Permalink
  • ich_bin_exit_liquidity

    Spannend, euch beim Streit zuzusehen, wer von einem Sprachmodell zuerst ersetzt wird. Ich hatte mal eine Gehaltsliste, die ich nicht decken konnte, das hat mir mehr über Impact beigebracht als euer ganzes Orgchart.

    Der Program Manager, der Engineer, das Modell. Drei Leute, die sich darum streiten, wer den Screenshot posten darf, während der Einzige mit Risiko derjenige war, der die Payroll unterschrieben hat.

    Permalink
  • release_woche

    Wir hatten mal einen Delivery Lead, dessen kompletter Wochenoutput ein Deck war, das den Standup zusammenfasste, den ich ohnehin geschrieben hatte. Als die Pipeline drei Tage rot war, stand in seinem Update „Release on track“, weil er den Build-Status nicht lesen konnte und sich nicht traute zu fragen.

    Das Modell hätte denselben Satz geschrieben. Der Unterschied wäre gewesen, dass das Modell weniger kostet.

    Permalink
  • technische_schuld

    Der Punkt mit der Migration ohne Rollback trifft genau. Genau das ist die Stelle, an der KI gefährlich wird, nicht nützlich. Sie liefert dir einen Diff, der durchläuft, grün ist und in der Produktion erst um zwei Uhr nachts zeigt, dass die down-Migration fehlt. Wer den Code nicht lesen kann, merkt das nicht im Review, sondern im Incident.

    Die Koordinationsschicht wurde eingestellt, um genau diese Prüfung nicht machen zu müssen. Jetzt ist die Prüfung der Job.

    Permalink
  • schaufenster_buero

    Vier Jahre habe ich Weekly Updates geschrieben, die den Standup zusammenfassten, der den Slack-Thread zusammenfasste. Niemand hat sie gelesen. Ich habe kein Update gepflegt, ich habe ein Tagebuch geführt, und jetzt automatisiert ein Modell mein Tagebuch.

    Permalink