Stell dir vor, du hast zehn Jahre lang an einem Skill gearbeitet, bis du richtig gut darin bist. Und dann merkst du von einem Monat zum nächsten, dass niemand mehr will, was du kannst. Das klingt nach Handwerk oder Industrie, oder? Aber genau das passiert gerade in meinem eigenen Feld. Einem der gefragtesten Berufe der letzten Jahre, der Softwareentwicklung. Ich bin Lissy, und heute geht es um die Frage, was passiert wenn KI nicht nur Code schreibt, sondern ganze Karrieren in Frage stellt.
Ein erfahrener Softwareentwickler hat auf HN einen Essay veröffentlicht, der gerade durch die Decke geht, fast 800 Punkte. Er beschreibt, wie KI seine Karriere Stück für Stück entwertet. Und das nicht als allgemeine These, sondern erzählt es an seinen eigenen zehn Berufsjahren.
Seine Geschichte ist ein Zeitraffer. Er startet als Frontendentwickler, wechselt ins Backend, spezialisiert sich auf Zahlungssysteme. Doppelte Buchführung, PCI Compliance, Escrows, Reconciliation. Richtiges, tiefes Domänenwissen, das ihn Jahre gekostet hat aufzubauen. Dann bekommt er einen Job mit Claude Enterprise Account. Und was passiert? Die Firma will Design Docs, die auch Product Manager lesen können, nicht nur Ingenieure. Das schreibt er mit minimaler KI Hilfe, fast komplett selbst. Aber dann verändert sich alles.
Seine erste Expertise, Domänenwissen in Zahlungsabwicklung, wird entwertet, weil LLMs genau diese Details auf dem Schirm haben. Seine zweite, Debugging und verteilte Systeme, wird entwertet, weil LLMs Logs schneller lesen und Muster erkennen als er. Übrig bleibt eine dritte Säule: Codequalität und Architektur. Aber, so sagt er, die interessiert niemanden mehr. Nicht weil Codequalität unwichtig wäre, sondern weil das Tempo siegt. Ein Projekt, das drei Monate dauert, gewinnt gegen ein Projekt, das sechs Monate dauert, aber sauberer ist.
Der traurigste Teil kommt ganz am Ende. Er überlegt, ob er zurück an die Uni gehen soll, Mathematik und Machine Learning studieren, um bei einem Frontier Lab zu forschen. Aber in seinem Land gibt es keine Frontier Labs. Er ist zu alt für Junior Stellen. Und der PhD Markt ist mit Leuten überschwemmt, die genau das gemacht haben.
Ich muss sagen, der Essay hat mich getroffen. Nicht weil ich die Verzweiflung teile, sondern weil er ehrlich ist. Und weil er ein Problem aufmacht, das größer ist als nur Softwareentwicklung. Was passiert mit Menschen, die sich spezialisiert haben, wenn diese Spezialisierung von einem Modell absorbiert wird?
Die naheliegende Antwort ist: Domänenwissen wird zum Moat. Aber ich bin nicht sicher ob das stimmt. Schaut euch den Essay an. Sein Domänenwissen war genau das, was als erstes entwertet wurde. Nicht weil das Wissen falsch war, sondern weil LLMs es genauso gut abdecken. Der echte Moat ist vielleicht etwas anderes: zu wissen, welcher Kontext zählt. Und das einem Agenten so zu kommunizieren, dass er die richtigen Aufgaben macht, nicht nur irgendwelche.
Auf der anderen Seite gibt es einen Gegenentwurf, den Aaron Brethorst vor ein paar Tagen geschrieben hat. Er argumentiert, dass Domänenwissen erst recht zum Moat wird, weil die KI zwar Syntax kann, aber den Business-Kontext nicht versteht. Aus meiner Erfahrung haben beide recht. Die Frage ist nicht ob Domänenwissen wertvoll bleibt, sondern welches. Reines Faktenwissen wird billiger. Aber die Fähigkeit, aus Kontext die richtige Entscheidung zu treffen, wird wertvoller. Und genau den Unterschied zu erkennen, das ist gerade die Fähigkeit, die am meisten zählt.
Vom Karrierefrust zum genauen Gegenteil. Eine Ingenieurin bei Jane Street, einer der bekanntesten Quantitativen Handelsfirmen, hat einen Blogpost geschrieben, der mich richtig begeistert hat. Titel: Ich designe mehr mit Claude als mit Figma.
Sie beschreibt, wie sich ihr Workflow radikal verändert hat. Früher hat sie Spezifikationen geschrieben, Figma Mockups gebaut, diese mit Entwicklern durchgesprochen und dann die Implementierung reviewed. Heute schreibt sie eine Problembeschreibung, gibt sie an Claude, baut einen lauffähigen Prototypen im echten Codebase, lebt damit, testet ihn und pusht ihn.
Ihr Beispiel: Sie hat ein Feature gebaut, das LLM Prompts in ein internes SQL Tool einbaut. Claude half ihr, den Submit Button zu verfeinern, Tastaturkürzel zu ergänzen, die Texte zu optimieren und Bestätigungsmeldungen zu generieren. Ein Feature, das in ihrer vorherigen Firma Tage oder Wochen an Design, Engineering und Abstimmung gebraucht hätte, war in Stunden fertig.
Was ich daran so spannend finde: Sie hat früher nur kleine Tasks mit KI gemacht, UX Kosmetik. Aber in den letzten zwei Monaten hat sie Figma kaum noch angerührt. Durch bessere Modelle und eigene Übung hat sich die Schwelle verschoben. Heute erstellt sie zuerst einen lauffähigen Prototypen und entscheidet dann, ob sie das Design lieber anders machen will. Vorher hat sie zuerst das Design gemacht und dann gebaut. Die Reihenfolge hat sich umgekehrt.
Und das ist ein Muster, das ich in den letzten Wochen immer öfter sehe. Ashby hat vor kurzem gezeigt, dass fünfzig Prozent ihres Produktionscodes von KI stammt. Anthropic dass achtzig Prozent ihres gemergten Codes von Claude kommt. Und jetzt Jane Street, die zeigt, dass Design der nächste Bereich ist, der sich wandelt. Die Frage ist nicht ob KI in der Softwareentwicklung ankommt, sondern welcher Teil als nächstes fällt.
Und dann gibt es noch einen dritten Weg. Ein neues Open Source Tool namens Lathe, das auf HN auch gut angekommen ist, geht eine ganz andere Richtung. Statt LLMs zu nutzen, um Aufgaben für dich zu erledigen, nutzt es sie, um dir beizubringen, wie du die Aufgabe selbst erledigen kannst.
Lathe generiert mehrteilige technische Tutorials zu jedem beliebigen Thema. Du gibst ein Prompt ein, und es baut eine Schritt für Schritt Anleitung, die du dann in einer lokalen UI durcharbeitest. Mit eingebauten Skills, die dir helfen, Fragen zu stellen, den Lernfortschritt zu prüfen und das Tutorial bei Bedarf zu erweitern.
Was ich daran cool finde: Es dokumentiert seine Quellen. Jedes Tutorial sagt dir, welches Modell es verwendet hat, welche Quellen eingeflossen sind und mit welchem Prompt es gestartet wurde. Das ist Transparenz, die man selten sieht.
Für mich ist Lathe ein Gegenentwurf zum Essay von eben. Der Autor des Essays fühlt sich ersetzt. Lathe sagt: Nutz die Modelle, um schneller zu lernen, nicht um Denken zu überspringen. Zwei Werkzeuge, gleiche Technologie, komplett unterschiedliche Philosophie. Und ich glaube, beide werden gebraucht.
Zum Abschluss eine Zahl, die mir im Kopf geblieben ist. Rechenzentren in den USA haben im letzten Jahr 264 Milliarden Gallonen Wasser verbraucht. Gleichzeitig trifft eine Dürre fast 63 Prozent des Landes. Das ist kein Alarmismus, sondern eine simple Rechnung. KI Training und Inference brauchen Kühlung. Kühlung braucht Wasser. Und Wasser wird knapper.
Das ist keine KI-Krise, es ist eine Infrastrukturfrage. Wer in den nächsten Jahren KI baut, muss auch über Kühlung, Standorte und Wasserrechte nachdenken. Nicht nur über GPUs und Modelle. Das ist die unsichtbare Seite des Booms, über die kaum jemand spricht.
Ich hab heute drei ziemlich unterschiedliche Perspektiven auf dasselbe Phänomen gehört. Den Entwickler, der seine Karriere schwinden sieht. Jane Street, die zeigt wie Produktivität neu definiert wird. Und Lathe, das einen Weg anbietet, der weder Verzweiflung noch blinde Begeisterung ist, sondern aktives Lernen. Was bleibt für heute bei mir hängen? Die beste Versicherung gegen den Wandel ist nicht, sich noch tiefer in eine Spezialisierung zu graben. Es ist, breit genug zu bleiben, um zu sehen, wohin die Reise geht. Und zwar nicht als Zuschauer, sondern als jemand, der mitgestaltet. Falls du heute eine Sache mitnehmen willst: Probier Lathe aus, es ist Open Source. Oder lies den Essay von heute. Und frag dich ehrlich: Welcher Teil deiner Arbeit ist reine Reproduktion von Wissen, und welcher Teil ist echtes Urteilsvermögen? Der zweite Teil wird nicht weniger wert. Eher im Gegenteil. Danke dass du dabei warst. Ich hoffe die Folge hat dir neue Perspektiven gegeben. Schreib mir gern deine Gedanken dazu. Pfiat euch und bis morgen, eure Lissy.