Software Engineering ist möglicherweise kein Beruf mehr fürs ganze Leben

• Mit AI ist klar, dass man für die Ausführung der jeweiligen Arbeit weniger dabei lernt – das ist jedoch kein Grund, AI abzulehnen
• Selbst wenn AI die Fähigkeiten von Engineers langfristig schwächt, ist ihr Einsatz unvermeidlich, wenn die kurzfristigen Produktivitätsvorteile groß genug sind
• So wie Bauarbeiter trotz der körperlichen Belastung schwere Dinge heben, muss man sich letztlich nach den inhärenten Anforderungen des Berufs richten
• Man kann zwar beim händischen Coden bleiben, aber so wie ein Zimmermann, der Elektrowerkzeuge ablehnt, keinen Job hat, dürfte ein Engineer, der AI verweigert, im Wettbewerb ins Hintertreffen geraten gegenüber Engineers, die AI annehmen
• Software Engineers könnten wie Profisportler zur ersten Generation mit begrenzter Karrieredauer werden, weshalb eine darauf abgestimmte Planung nötig ist

---

Der Einsatz von AI und die Karrieredauer von Software Engineers

• Es gibt keine starken Belege dafür, dass AI die allgemeine Intelligenz von Menschen senkt, aber wenn man Aufgaben mit AI erledigt, ist klar, dass man für genau diese Tätigkeiten weniger lernt
• Die Logik einiger Software Engineers, die meinen, man solle AI bei der Arbeit vermeiden, läuft ungefähr so
  • Wer AI nutzt, lernt im Arbeitsprozess weniger
  • Mit der Zeit verkümmern technische Fähigkeiten, wodurch man zu einem weniger effektiven Engineer wird
  • Daraus folgt die Schlussfolgerung, dass man AI bei der Arbeit nicht verwenden sollte
• Allerdings ist die zweite Annahme nicht sicher
  • Beim Wechsel von Assembler zu C wurden Programmierer in mancher Hinsicht weniger effektiv und in anderer Hinsicht effektiver
  • Der Übergang vom händischen Schreiben von Code zur Arbeit mit AI könnte ein noch größerer Wandel sein, weshalb sich das Ergebnis schwer eindeutig festlegen lässt
• Selbst wenn der Einsatz von AI Engineers langfristig weniger effektiv machen sollte, folgt daraus nicht automatisch, dass man AI nicht verwenden sollte
• Bis ungefähr 2024 war der beste Weg, Software Engineering zu lernen, selbst Software Engineering zu betreiben
  • Man konnte ein Coding-Hobby in eine lukrative Karriere verwandeln, und wer seine Arbeit mochte, wurde mit der Zeit immer besser
  • Das war weniger das unveränderliche Wesen des Software Engineerings als vielmehr ein glücklicher Zufall

Konflikt zwischen kurzfristiger Produktivität und langfristiger Fähigkeit

• Selbst wenn der Einsatz von AI langfristig die berufliche Leistungsfähigkeit oder das allgemeine Denkvermögen verschlechtert, kann es sein, dass Engineers AI einsetzen müssen, wenn der kurzfristige Nutzen groß genug ist
• Bauarbeiter müssen schwere Dinge heben, um effektiv arbeiten zu können, aber solche Tätigkeiten können langfristig Rücken und Gelenke verschleißen und sie mit der Zeit zu weniger leistungsfähigen Arbeitern machen
  • Bauarbeiter sagen nicht: „Ein guter Bauarbeiter hebt keine schweren Dinge“, sondern: „Man kann nichts machen, das ist die Arbeit.“
• Auf Baustellen gibt es Methoden wie Kräne, Schubkarren und Gabelstapler, um schwere Lasten zu vermeiden
  • Auch Software Engineers brauchen möglicherweise Methoden für mentale Vertiefung, aber ein vergleichbarer Ansatz wurde womöglich noch nicht gefunden
• Wenn AI Menschen tatsächlich weniger klug machen sollte, kann man weiter von Hand coden
  • Aber aus demselben Grund, aus dem es kaum Jobs für Zimmerleute gibt, die Elektrowerkzeuge ablehnen, könnte es schwierig werden, allein fürs händische Coden bezahlt zu werden
  • Wenn die Modelle gut genug sind, gerät man gegenüber Engineers ins Hintertreffen, die bereit sind, langfristige kognitive Fähigkeiten gegen eine kurzfristig lukrative Karriere einzutauschen
• Gewerkschaften könnten diesen Prozess theoretisch verlangsamen
  • In anderen Branchen haben sie Arbeitgeber schon dazu gebracht, einen Wettlauf nach unten zu bremsen
  • Für Gewerkschaften im Tech-Bereich bin ich jedoch pessimistisch, weil die Bezahlung hoch ist, von überall auf der Welt gearbeitet werden kann und Ersatzarbeitskräfte daher leicht verfügbar sind
• Die Karriere von Profisportlern dauert in der Regel höchstens etwa 15 Jahre, und bis etwa zur Mitte ihrer 30er können sie oft viel Geld verdienen, danach spielt der Körper nicht mehr mit
  • Eine heute häufig zu sehende tragische Figur ist der Profisportler, der glaubt, „die Show werde ewig weitergehen“, und sich nicht auf die Zeit nach dem Karriereende vorbereitet
  • Software Engineers könnten die erste Generation sein, die in derselben Lage ist – und wenn das so ist, wäre es klug, entsprechend zu planen

[GN⁺]

Hacker-News-Kommentare

• Ich führe dasselbe Gespräch mehrmals pro Woche: Jemand sagt: „AI wird Entwickler bedeutungslos machen“, und wenn ich frage, warum, lautet die Antwort: „Weil LLMs Code schreiben können.“
  Tatsächlich macht Code schreiben in meiner bezahlten Arbeit aber nur 2–5 % aus, heute eher noch weniger, und der Rest besteht darin, Dinge zu verstehen und dann die Fähigkeit anzuwenden, Lösungen zu strukturieren.
  Entwickler, die noch immer glauben, ihr Job bestehe aus Tippen von Code, könnten in Zukunft tatsächlich keine Arbeit mehr haben, und bei Unternehmern, die glauben, sie könnten wegen LLMs ohne Entwickler auskommen, wird das am Ende wohl die natürliche Selektion regeln.

  • Um 2000 herum wurde ich in einem meiner ersten Jobs mit einem erfahrenen Softwareingenieur gepaart, der seit Anfang der 1970er arbeitete, und ich war begeistert, von ihm zu lernen.
    Ungefähr am vierten Tag sagte er, er werde mir das beibringen, was seiner Karriere am meisten geholfen habe, und dann: „Nummeriere Lochkarten immer, damit du sie leicht wieder in die richtige Reihenfolge bringen kannst, wenn sie herunterfallen.“
    Ich war enttäuscht, weil die Zeit der Lochkarten damals schon lange vorbei war, aber er ergänzte: „Ich sagte, es hat mir geholfen, nicht dir. Software ändert sich ständig.“ Daran muss ich heutzutage oft denken.
  • Diese Antwort ist etwas zu geschniegelt. In Wirklichkeit geht der Großteil der Zeit für Codieren drauf, einschließlich Tippen, Umformulieren und noch einmal Umformulieren.
    Dazu kommt die Zeit, in der man mit dem Kopf gegen die Wand rennt, um umgeschriebenen Code an eine schlecht dokumentierte API anzupassen, bis er endlich läuft.
    Die Formulierung im ursprünglichen Kommentar lässt Software Engineering wie eine reine und edle Tätigkeit à la Mathematik wirken, aber in der Realität ist es eher wie bei einem Bohrarbeiter, der mit einem großen Hammer auf Metall einschlägt, um unter Zeitdruck einen Bohrstrang passend zu machen, obwohl der Plan nicht zur Wirklichkeit passt.
  • Es gibt Leute, bei denen „Code schreiben“ 2–5 % ausmacht, aber auch Leute, bei denen es 6–50 % sind.
    Auch das „Dinge verstehen und Lösungen strukturieren“ ist ein Bereich, auf den AI abzielt.
    Vielleicht bist du einfach in der glücklichen Lage, dass deine Beiträge anerkannt werden, oder du arbeitest in einer Branche bzw. Domäne, die in den Trainingsdaten kaum vorkommt, oder in einem Problemraum, der für AI zu komplex ist.
    Wer Jira-Tickets abarbeitet und CRUD-Webapps baut, läuft eher Gefahr, dass seine Existenzgrundlage oft verschwindet oder dass bei gleichem oder geringerem Gehalt mehr Output verlangt wird und man mit AI mithalten muss.
  • Mir gefällt die Formulierung „das wird die natürliche Selektion regeln“. Vorhersagen darüber, wie AI Software und alles darüber hinaus verändern wird, gibt es im Überfluss, aber ich frage mich inzwischen, wann das Reden aufhört und die Demonstration von Ergebnissen beginnt.
    Wenn es funktioniert, dann funktioniert es, die Methode verbreitet sich und wird schnell für alle zugänglich, und der Fortschritt geht weiter.
    Wenn nicht, dann zeigt sich das daran, dass echte Resultate ausbleiben, und „Ich beobachte das“ reicht dann nicht. Es muss eine Realität sein, die alle sehen und nutzen können, unausweichlich und nicht wegzudiskutieren.
  • Grundsätzlich stimme ich zu, aber die 2–5-%-Schätzung wirkt extrem niedrig. Wenn jemand sagte, die meisten Entwickler verbringen 25 %, vielleicht bis zu 40 % ihrer Zeit mit Code, fände ich das überzeugend, aber jemand mit nur 2 % ist sehr selten.
    Vielleicht in einem Großkonzern als beratender CTO auf allerhöchster Staff-Ebene, aber dann ist man ohnehin schon in einer sehr seltenen Position.

• Die polarisierte Reaktion auf AI scheint davon abzuhängen, durch welche Linse man schaut. Junior-Rollen verschwinden schnell, aber bei Senior-Rollen sind Erfahrung und Urteilsvermögen wichtiger denn je.
  Deshalb könnte Software Engineering für viele tatsächlich kein Beruf fürs ganze Leben mehr sein. Das ist ähnlich wie bei Elitesport: für die meisten kein realistischer Beruf, aber einige werden davon leben, und das müssen sie auch.

• Meine Erfahrung war das genaue Gegenteil. Sehr erfahrene Ingenieure, die die neuesten Tools tatsächlich einsetzen wollen, sind heute deutlich stärker als früher, auch in ihren Vierzigern und Fünfzigern.
  Einer der Gründe, warum traditionelle Programmierer mit der Zeit in der Praxis nachlassen, ist, dass wie im Schach Konzentration und tiefe Berechnung abnehmen. Ein älterer Schachspieler versteht Schach viel besser als ein 19-jähriges Genie, kann aber nicht mehr gleich schnell und lange rechnen, sodass Erfahrung am Ende von reiner Rechenleistung überholt wird.
  Claude Code und Codex nehmen diese Rechenlast ab, während all die durch Erfahrung aufgebauten Instinkte und die 2-Sekunden-„Intuition“ erhalten bleiben.
  Inzwischen ist es nicht nur ein fairer Wettbewerb geworden, sondern eher umgekehrt unfair. Ein Senior, der früher ein Team aus sechs Personen leitete, führt jetzt ein Agenten-Team und reviewt den Code wie früher. Manchmal ist es sogar leichter, Agenten in die richtige Richtung zu lenken als die Juniors im eigenen Umfeld.

  • Zum Glück gibt es für Softwareingenieure einen Architektenpfad, und dort wird tiefe Intuition oft belohnt, auch wenn sich die Art der Detailberechnung ständig ändert.
    Die dringende, aber noch unbeantwortete Frage ist allerdings, ob gute Architekten auch ohne die Schützengräben der Praxis entstehen können.
    LLMs machen ebenfalls etwas, das Intuition ähnelt, also muss man unterscheiden. Ein LLM ist eher das kollektive Unbewusste des Internets und klar etwas anderes als Vorlieben, die aus guten und schlechten Erfahrungen entstehen.
    Diese aufsteigende Intuition ist letztlich einfach „guter Geschmack“, und das kommt in jedem technischen Feld dem Kern der Senior-Rolle sehr nahe.
  • Wenn ein Senior die Arbeit von sechs Kollegen leisten kann, was passiert dann mit diesen Kollegen?
    Die Menschen, die in der Landwirtschaft durch den Traktor ersetzt wurden, konnten ihre Jobs nicht behalten. Warum sollte es diesmal anders sein?
  • Die Aussage „Ein Senior, der früher ein Team aus sechs Personen leitete, führt jetzt ein Agenten-Team“ bestätigt doch den Punkt des Autors.
    Das Sechserteam wird nicht mehr gebraucht und folglich aus dem Unternehmen entfernt.
    Software Engineering bleibt also für einige ein Beruf, aber die Zahl der Beschäftigten könnte um 85 % sinken.
  • Ich bin 43 und war nach 15 Jahren als Java/Swing-Entwickler sehr produktiv und kannte die Tools in- und auswendig.
    Aber diese Firma gibt es nicht mehr, und es dauert deutlich länger, zu lernen, wie man mit den neuen Tools effizient arbeitet, die ich heute nutze. Ich habe die Details der neuen Umgebung eben nicht zehn Jahre lang gelernt.
    Deshalb spart mir AI enorm viel Zeit dabei, die richtige Syntax herauszufinden und mir die Details eines Unit-Test-Frameworks zu merken. Wenn ich 1–3 Jahre dabei bleibe, werde ich wohl viel schneller und die Tools auch deutlich besser kennen.
  • Wir sollten aufhören zu anthropomorphisieren. Ein Agenten-Team gibt es nicht; es sind einfach Tools und Prozesse, die auf einem Computer laufen.
    Wenn dieser eine Senior Engineer verschwindet, bleibt nichts zurück. Ein Team aus sechs Menschen ist besser.

• Die Aussage „Wer AI nutzt, dessen technische Fähigkeiten verkümmern mit der Zeit und er wird dadurch zu einem weniger effektiven Ingenieur“ ist langfristig vermutlich weitgehend richtig, und das ist traurig.
  Beruflich betrachtet lassen sich Menschen grob in zwei Gruppen teilen: diejenigen, die mit AI ihr Schlussfolgern verstärken, und diejenigen, die mit AI ihr Schlussfolgern ersetzen. Um die erste Gruppe sorge ich mich nicht besonders, um die zweite schon.
  Meine Mutter ist Lehrerin an einer öffentlichen Highschool in den USA und klagt oft darüber, dass Schüler die „Google AI overview“ als absolute Wahrheitsquelle behandeln.
  Vielleicht ist das ein neues Phänomen ähnlich wie früher „Wikipedia darf man nicht zitieren“, aber sie hat das Gefühl, dass die Fähigkeit zum kritischen Denken bei den Schülern seit der Pandemie sichtbar abgenommen hat.
  Es gibt inzwischen ein oder zwei Generationen, die damit aufgewachsen sind, dass Influencer und anonyme Leute im Internet ihnen sagen, was sie mögen, nicht mögen und glauben sollen. Diese Menschen haben ihr Denken schon vor LLMs ausgelagert und wirken nicht darauf vorbereitet, produktiv mit Systemen zu interagieren, die so gestaltet sind, dass sie ihnen trotz fragwürdiger Qualität das Gefühl geben, genau das zu bekommen, was sie wollen.

  • Ich arbeite tatsächlich mit Leuten zusammen, die Lösungen generieren, ohne die Ergebnisse wirklich anzuschauen. Sie klicken sich kurz durch die App oder lassen ein paar Tests laufen, finden das Ergebnis okay und deployen dann.
    Überall im PR sieht man die Handschrift von Claude, und man kann ziemlich sicher davon ausgehen, dass kaum etwas geändert wurde. Das ist Gruppe A.
    Andererseits gibt es Kollegen, die ein Problem bis zum Ende durcharbeiten, Harnesses bauen, um Änderungen zu testen, Ergebnisse validieren, mehrere Lösungsansätze durchlaufen und daraus ein ideales Resultat synthetisieren, benchmarken, verfeinern, gründlich testen und im PR ein vernünftiges Validierungsverfahren liefern. Das ist Gruppe B.
    Das sind zwei völlig verschiedene Arten, AI zu nutzen. A scheint momentan noch irgendwie durchzukommen, aber B ist eine neue Version dessen, was in der gegebenen Zeit möglich ist, und definiert einen neuen Maßstab für Software Engineering, den man außerhalb außergewöhnlich professioneller Umgebungen bisher kaum gesehen hat.
    Ich glaube, Gruppe A wird ziemlich schnell aus der Branche gedrängt. LLMs ermöglichen erstaunlich effektives Arbeiten, wenn man bereit ist zu lernen. Diese Form von Strenge könnte zum Standard werden und vielleicht die einzige Art, auf die Menschen im Loop weiterhin ein nützlicher Bestandteil bleiben.
  • Auch viele Erwachsene in meinem Umfeld behandeln die Google AI overview inzwischen wie eine absolute Quelle.
  • Dazu ein kürzlich auf HN geposteter Beitrag: https://news.ycombinator.com/item?id=47913650

• Anekdotisch fühlt es sich so an, als hätte sich der US-amerikanische Markt für Software-Einstellungen Anfang dieses Jahres tatsächlich verändert. Es wirkt, als würden immer mehr Unternehmen eine Abwarte-Strategie verfolgen, um in den nächsten Jahren nicht zu stark in Humankapital zu überinvestieren.
  Die ohnehin schwachen Einstellungssignale scheinen inzwischen ganz verschwunden zu sein. Schaltet man eine Stelle aus, bekommt man über 500 mit LLMs geschriebene Bewerbungen und Anschreiben, die sich alle ähnlich lesen und anfühlen.
  Der Vergleich im Artikel mit Profisportlern wirkt etwas schief. Wenn man mit Muskeln Geld verdient, sind körperliche Altersprobleme offensichtlich, aber vergleicht man das mit Wissensberufen wie Jura oder Medizin, gibt es dort auch in den Vierzigern und Fünfzigern viele sehr fähige und scharfsinnige Praktiker.

  • Auch das ist nur anekdotisch, aber ich sehe, dass US-Unternehmen massiv in Indien und anderen Entwicklungsmärkten einstellen.
    Ich kenne Fälle von Leuten in diesen Ländern, die früher nie von Big-Tech-Recruitern kontaktiert wurden und jetzt täglich Nachrichten bekommen.
    Ich habe auch gelesen, dass das mit einer bestimmten US-Regelung zusammenhängt, die letztes Jahr ausgelaufen ist, aber ich bin Laie und weiß zu wenig, um über die Gründe zu sprechen.
  • Vor Ort fühlt es sich ehrlich gesagt nicht so an, als würde AI die Einstellungsnachfrage beeinflussen. Es ist nicht so, dass AI alles schreibt, was sich die Führung ausdenkt, und die Ingenieure untätig herumsitzen.
    Stattdessen fühlt es sich eher an, als stünde die Wirtschaft kurz vor dem Absturz oder befände sich zumindest in einer Achterbahnfahrt. Steuerliche Einstellungsanreize sind schwach, die Nullzinsära ist lange vorbei, und Recruiter werden von verrauschten Bewerbungen überrollt.
    Trotzdem sagen Vorgesetzte gern, es liege an AI. So klingt es, als hätten sie die Lage unter Kontrolle.
  • Ich glaube eher, dass Unternehmen während Corona zu viel eingestellt haben und wegen dieser Erfahrung plus eines unsicheren Marktes denselben Fehler nicht wiederholen wollen.

• Als Erklärung dafür, warum wegen AI alles schon gutgehen werde, lese ich ständig, man könne sich einfach „für andere Berufe umschulen lassen“, aber ich sehe nie, welche Berufe das sein sollen oder wer die Umschulung bezahlen soll.
  Ich habe weder das Geld noch die Zeit, wieder an die Uni zu gehen und eine neue Karriere von ganz unten zu beginnen.

  • Die Logik lautet: „So war es in der Vergangenheit doch immer.“
    Das stimmt, aber nur bis zu dem Moment, in dem es nicht mehr stimmt.
    Ein klassisches Beispiel dafür, wie spektakulär dieses Denken scheitern kann, ist die Malthus-Theorie. Die Theorie, dass Nahrungsmittel linear wachsen und die Bevölkerung exponentiell, sodass die Bevölkerung kollabieren müsse, war über die gesamte Geschichte hinweg bis zu Malthus’ Beobachtung tatsächlich zutreffend.
    Auf mechanischer Ebene übersieht die Logik „Wir haben immer andere Jobs gefunden“, dass das nur möglich war, weil Menschen der Automatisierung immer einen Intelligenzvorsprung voraus hatten.
    Selbst einfache menschliche Eingriffe am Fließband beruhten letztlich auf menschlichen Fähigkeiten zu feinen, fast unsichtbaren Anpassungen, zu denen Roboter nicht fähig waren.
    Wenn aber etwas AGI-Ähnliches tatsächlich funktioniert, dann hat menschliche Arbeit gegenüber der Automatisierung keinen Vorteil mehr, und es ist unklar, warum die frühere Logik „Automatisierung schafft mehr menschliche Jobs“ weiterhin gelten sollte.
  • So wie es diese Umschulung für qualifizierte Industriearbeiter, deren Jobs nach China ausgelagert wurden, nicht gab, wird es sie auch diesmal nicht geben.
    Der Staat wird nur gerade genug Sozialleistungen zahlen, um die Lage beherrschbar zu halten, und danach werden die Betroffenen kulturell dämonisiert, ähnlich wie Ludditen.
  • Solche Berufe gibt es nicht, und selbst wenn doch, würdest du die Kosten selbst tragen müssen. Unternehmen zahlen so etwas nur in extrem seltenen Fällen, wenn sie aus Wettbewerbsgründen wirklich dazu gezwungen sind.
  • Dasselbe gilt auch für Branchen, die durch Software zerstört wurden.
  • Es gibt keine Garantie, dass neue großartige Berufe entstehen. Die Leute scheinen das einfach vorauszusetzen.
    Natürlich wird es noch eine Zeit lang Arbeiten geben, die menschliche körperliche Arbeit erfordern, aber realistisch betrachtet werden viele physische Jobs in anderen Teilen der Welt billiger erledigt.
    Nicht exportierbare Tätigkeiten wie Klempner oder Kellnerinnen haben eine begrenzte Nachfrage. Man kann nicht 50 % der heutigen White-Collar-Arbeitskräfte in solche Berufe drücken und erwarten, dass sie alle leicht Arbeit oder ordentliche Löhne finden. Diese Nachfrage existiert nicht.
    Gleichzeitig werden auch „geringqualifizierte“ körperliche Jobs zunehmend automatisiert, während White-Collar-Jobs verschwinden. Self-Checkout reduziert Jobs im Einzelhandel, Robotaxis und Drohnenlieferungen verringern Jobs in Lieferung und Logistik, und Lagerroboter werden Lagerjobs verringern.
    Es scheint eine implizite Annahme zu geben, dass AI viele gut bezahlte Jobs schaffen werde, die menschliche Arbeitgeber brauchen und die zugleich nicht günstiger ins Ausland ausgelagert werden können. Aber was soll das überhaupt für ein gut bezahlter Beruf sein, der sowohl AI-sicher als auch outsourcing-sicher ist? Werden wir alle hochbezahlte Reinigungskräfte? Das ergibt keinen Sinn.
    Der Rat, sich heute zu Bauarbeitern oder Klempnern umschulen zu lassen, scheint anzunehmen, dass die Nachfrage nach solcher Arbeit unbegrenzt sei, aber das ist sie nicht. Selbst wenn die Nachfrage nach Bauarbeitern explodieren würde, bräuchte es Jahre, um Ausrüstung, Lieferketten und Infrastruktur dafür aufzubauen, dass Millionen Menschen ins Baugewerbe wechseln können.
    Das wahrscheinlichste Szenario ist, dass Menschen ihre Jobs verlieren und dann in endlosem Unterbietungswettbewerb um die begrenzten Stellen gefangen sind, die in der Binnenwirtschaft übrig bleiben. Der Rest wird ausgelagert oder von Robotern und AI erledigt.
    Der bessere Rat ist, sich auf diese Realität vorzubereiten. Man sollte nicht annehmen, dass der Staat einen schützt oder überhaupt schützen kann. Wenn sich Reichtum konzentriert, ist Korruption fast unvermeidlich, und Politiker haben auch Familien, um die sie sich kümmern.
    Man sollte das ernst nehmen. Selbst wenn ich mich irre, ist es besser, sich auf das Schlimmste vorzubereiten, als anzunehmen, dass am Ende alles gut wird und man sich einfach für einen neuen gut bezahlten Beruf umschulen kann.

• Meine Eltern waren beide Bauarbeiter. Dort weiß man, dass man nicht ewig schwere Dinge heben kann.
  Irgendwann hört man damit auf und wird Vorarbeiter oder Aufseher. Wenn man sich damit nicht anfreunden kann zu lernen, wie andere Menschen die Arbeit machen, die man früher selbst erledigt hat, geht der Körper irgendwann komplett kaputt, und das Ergebnis ist furchtbar.
  Das ist eine nüchterne Realität, aber es war in meiner Karriere auch eine wichtige Metapher, um Delegation zu verinnerlichen. Mit AI hat das schon etwas zu tun, aber ich finde nicht, dass es vollkommen sauber passt.

  • Erwähnenswert ist auch, dass schwere Dinge heben Menschen in vernünftigen Grenzen stärker macht, während die aktuelle Hypothese über AI-Nutzung eher das Gegenteil besagt.
  • Softwareentwickler sind weniger bloße Programmierer als vielmehr Architekten. Einen Architekten lässt man nicht schwere Lasten tragen, sondern die Nutzung dieser Lasten entwerfen.

• Ich wünschte, klug wirkende Leute würden aufhören, in Texten solche Abstraktionsanalogien zu benutzen. Das Schlüsselwort ist Determinismus.
  Jede Abstraktionsebene wie Elektrowerkzeuge oder C hat eine deterministische Ebene hinzugefügt, auf die man sich verlassen kann, und jedes Mal dasselbe Ergebnis geliefert, sodass man effizienter arbeiten konnte.
  LLMs beschreiben Programmierung in natürlicher Sprache, und die Ergebnisse sind bestenfalls variabel. Deshalb braucht man Agenten und versucht die Resultate per brute force durchzudrücken.
  Der echte Burggraben ist meiner Meinung nach weiterhin, jemand zu sein, der tatsächlich programmieren kann.

  • Das sagen die Leute zwar ständig, aber ich halte das für eine falsche Behauptung. LLMs sind nicht deterministisch, aber das ist völlig unerheblich.
    Man führt den LLM-Output nicht direkt aus, sondern lässt das LLM einmal ein Artefakt erzeugen und führt dieses Artefakt dann deterministisch aus.
    Die Spezifikation wird einmal in Code übersetzt, und wenn man die Spezifikation bearbeitet, kann der Code aktualisiert werden, aber man erstellt nicht jedes Mal das gesamte Programm neu. Warum sollte Determinismus dann wichtig sein?
  • Ich stimme zu, dass LLMs nicht unter jede Definition von Abstraktion fallen. Aber nicht alle, die LLMs als weitere Abstraktionsebene bezeichnen, verstehen es deshalb falsch. Sie verwenden den Begriff nur abstrakter.
    Wie hat zum Beispiel Mark Zuckerberg vor fünf Jahren Software gebaut?
    Er konnte wie ich einen Editor öffnen, aber seine Situation gab ihm eine andere Schnittstelle: menschliche Ressourcen. Statt mit einem Editor interagierte er mit diesen Menschen, und sie bauten die Software.
    Diese Schicht zwischen ihm und dem gebauten System ist, ob deterministisch oder nicht, eine Abstraktion.
    Heute haben wir eine breitere Befugnis, mehr Aufgaben zu delegieren als noch vor ein paar Jahren.
  • Sind die anderen Ebenen wirklich deterministisch? Weißt du mit Sicherheit, welches Objekt garbage collected wurde? Weißt du sicher, wie viele Zyklen diese Instruktion braucht?
  • LLMs müssen keine perfekte Zuverlässigkeit erreichen, um viele Aufgaben zu ersetzen. Es reicht, ein für die jeweilige Aufgabe passendes Gleichgewicht aus Zuverlässigkeit und Kosten zu erreichen. Das variiert je nach Aufgabe.
  • Ich verstehe den Punkt, aber auch das Wort Determinismus ist nicht ganz treffend. LLMs sind im Grunde deterministisch, weil sie als reine Funktion des Eingabetexts und der Netzwerkparameter Text ausgeben.
    Je nach Sicht auf den freien Willen könnte man effektiv auch behaupten, dass Menschen deterministisch sind.
    Das eigentliche Konzept hier ist, dass LLMs und Menschen opake Funktionen sind. Ihr Verhalten lässt sich nicht auf eine Folge logischer Schritte reduzieren, die man im Kopf verfolgen kann, es gibt keine Invarianten, die ihre Komplexität sauber in einige interpretierbare Zustände zerlegen, und Eingabe- und Ausgaberäume sind unstrukturiert, mehrdeutig, unvollständig spezifiziert und faktisch unendlich.
    Deshalb ist es nahezu unmöglich, sie mit denselben Strategien und Analysen zu verstehen oder zu synthetisieren, die man auf traditionelle Programme anwendet.
    Man kann optional Entropiequellen einführen und damit Nichtdeterminismus hinzufügen, aber nötig ist das nicht. Wenn alle LLM-Anbieter den Seed ihres Pseudozufallszahlengenerators auf einen festen Wert setzen würden, würden es vermutlich fast keine Leute bemerken.
    Es dürfte nicht viele Workflows geben, die davon abhängen, denselben Prompt mehrfach einzugeben und auf eine bestimmte statistische Verteilung der Ausgaben zu bauen. Eher bekommt man selbst dann gecachte Antworten, wenn man das gar nicht möchte.

• Wenn man unter Software Engineering versteht, in einem Texteditor Code Zeichen für Zeichen einzutippen, dann wird es tatsächlich schwerer werden, jemanden zu finden, der dafür bezahlt.
  Wenn man damit aber Software bauen meint, dann bauen wir heute mehr Software denn je, und auch die Definition dessen, was Software ist, ist vielfältiger als je zuvor. Daraus könnten sich viele unterschiedliche Karrieren aufspalten.

  • Wir erleben gerade etwas Ähnliches wie Bauingenieure beim Übergang vom Rechenschieber zum Taschenrechner oder Elektroingenieure beim Übergang vom manuellen Zeichnen von Schaltungen zu CAD-Tools.
    Das Interessante ist, dass sich auch Software Engineering weiterentwickeln muss. Prozesse und Werkzeuge müssen sich genauso weiterentwickeln wie in den vergangenen Jahrzehnten.
    Als ich 2004 mein Studium abschloss, lernten wir noch die Zeit der „Softwarekrise“, Wasserfallprozesse und die gerade beginnenden neuen „iterativen Methoden“.
    Wir lernten auch den Übergang von Spaghetti-Code zu strukturiertem Programmieren in Pascal/C und dann weiter zu objektorientierter Programmierung.
    Auch die Engineering-Methodik entwickelte sich weiter. Es gab das berüchtigte UML, formale Methoden wie die Z-Sprache zur formalen Verifikation und Maße für Softwarekomplexität wie ABC oder zyklomatische Komplexität.
    Heute, wo Computer den Großteil des Codes schreiben, sinkt der Wert heutiger Sprachen und Softwareentwicklungsprozesse. Programmiersprachen wurden für Menschen gemacht. Sonst hätten wir weiter in Assembler geschrieben.
    Jetzt müssen wir die Abstraktionen ändern, mit denen wir dem Computer unsere Absicht vermitteln und verifizieren, dass die endgültigen Anweisungen tatsächlich das tun, was wir wollten.
    Ich bin sehr gespannt auf diese neuen Abstraktionen. Vielleicht sehen wir in Software-Engineering-Berufen sogar wieder mehr echte technische Strenge, wenn die kleinen Details des Codings vollständig automatisiert werden.
  • Nehmen wir an, es gibt 2020 zwei konkurrierende Firmen, die jeweils 100 Programmierer beschäftigen. Wir wissen alle, wie solche Organisationen funktionieren. Sie hängen immer hinterher, jede neue Funktion erzeugt weitere mögliche künftige Funktionen, wir alle haben so gelebt, und im Großen und Ganzen ist es immer noch so.
    Nehmen wir weiter an, beide Firmen kommen 2026 zu dem Schluss, dass AI Entwickler um den Faktor 10 beschleunigt. Ich behaupte nicht, dass das Realität ist, es ist nur eine runde Zahl.
    Firma 1 entlässt 90 Programmierer und macht mit 10 Leuten dieselbe Arbeit.
    Firma 2 behält alle Programmierer, erledigt zehnmal so viel wie zuvor und stellt vielleicht sogar noch mehr ein.
    Wer gewinnt am Markt?
    Die Antwort lautet wie immer: „Kommt darauf an“, aber ich glaube, der Spielraum, in dem Firma 1 gewinnt, ist viel kleiner als bei Firma 2. Dafür bräuchte es eine sehr spezifische Kombination von Marktbedingungen; nicht unmöglich, aber es ist riskant, darauf zu wetten, dass man die Ausnahme ist.
    Während des Beschleunigungsschubs, in der Phase, in der sich die neue Realität noch nicht gesetzt hat, wirkt die Antwort von Firma 1 für den Controller oberflächlich attraktiv.
    Aber sobald in irgendeinem Markt nur ein einziges Unternehmen die Lösung von Firma 2 wählt und damit ausbricht, muss der Rest der Branche nachziehen, um überhaupt konkurrieren zu können.
    Mittel- bis langfristig ist es auch unwahrscheinlich, dass die Wertschöpfung, die ein einzelner Programmierer erzeugt und die sich im Gehalt abbilden lässt, sinkt.
  • Die Sorge ist, ob diese Arbeit am Bauen solcher Software überhaupt gut genug bezahlt wird, um mit explodierenden Lebenshaltungskosten mitzuhalten.
    Die Jobs, die durch frühere Automatisierung entstanden sind, waren meist schlechter bezahlt und boten weniger Autonomie.
  • Selbst wenn wir mehr Software bauen, lösen wir damit nichts, wenn diese Software größtenteils nur funktionale Doppelarbeit zu anderer Software ist.
    Anders gesagt: Jede Firma erfindet das Rad mehrfach neu. Es hat keinen Sinn, Softwareentwicklung um das Zehnfache zu steigern, wenn das einzig Neue darin besteht, dass sie mit einem neuen glänzenden Framework geschrieben wurde.
    Ich finde, wir sollten anfangen, den Großteil der Software abzuschaffen. Zurück zu den Grundlagen, schauen, was wirklich gebraucht wird, das besser machen und fertigstellen. Irgendwann sollte man ein Stück Software auch einmal zu Ende bringen.
  • Man kann software engineer durch secretary und creating software durch typing correspondence ersetzen, und die Aussage bleibt dieselbe.
    In einer Welt, in der AI Softwareprogrammierung und -design gelöst hat, sammelt sich der Wert bei Menschen mit anderer Domänenexpertise. Sie verfügen dann über die Macht von 1000 professionellen Entwicklern, während der Wert nicht bei Menschen mit redundanten Fähigkeiten bleibt, gegen die bessere, schnellere und billigere AI-Tools antreten.

• Wenn ich nichts übersehe, steckt hier ein offensichtlicher Logikfehler drin.
  Wenn man für Produktivitätsgewinne durch LLMs einen Kompetenzabbau in Kauf nehmen muss, dann sind nur wir Entwickler mit begrenzter Lebensdauer. Die nächste Generation wird diese Fähigkeiten gar nicht mehr durch Handarbeit aufgebaut haben und hat somit auch kein Skillset, das verkümmern könnte.
  Und ich schlage vor, die Analogie „Codegenerierung durch LLMs ist wie Maschinencode-Generierung durch Compiler“ öffentlich zu verbieten. Es ist ermüdend, dieselbe Idee immer wieder neu auszudiskutieren.

  • Warum genau ist die LLM-Compiler-Analogie falsch? Nur weil der LLM-Output nicht deterministisch ist?