LLMs untergraben meine Karriere als Software Engineer, und ich weiß nicht, was ich tun soll

• LLM-basierte Entwicklungstools greifen inzwischen in alles ein – von Design-Dokumenten über Implementierungspläne bis hin zu Code und Debugging – und schwächen damit die Differenzierung, die auf 10 Jahren Spezialisierung im Payment- und Finanz-Backend beruhte
• Domain-Wissen im Finanz- und Payment-Bereich war bislang ein Wettbewerbsvorteil, gestützt auf Erfahrung mit PCI-Compliance, Double-Entry-Ledgers, Escrows, Reconciliation, Payment Lifecycles und Bank-Transfer-Idempotenz; der erste Schock kam, als Modelle begannen, die Verknüpfungen in Systemarchitekturen zu erfassen
• Mit Claude Code, Codex, MCP und DataDog MCP weitet sich die Automatisierung des Debuggings aus; manche Bugs lassen sich allein mit Stack Traces und Sentry-Kontext beheben, später sogar 90 % der Bugs in verteilten Systemen in einem einzigen Durchlauf
• Auch die verbleibenden Felder Codequalität und Architektur werden auf „taste“ reduziert; der Trend geht dahin, statt für Menschen gut lesbarer A- und B-Codebases eher C- und D-Codebases zu akzeptieren, mit denen LLMs arbeiten können
• Um die langfristige Beschäftigungsfähigkeit zu sichern, müsste man seine Spezialisierung in Bereiche verlagern, in denen LLMs nicht so leicht gut werden; ein Wechsel in die Forschung ist jedoch durch Wohnort, Konkurrenz im Bewerbungsprozess, familiäre Umstände und die Möglichkeit von RSI eingeschränkt

---

Hintergrund meiner Laufbahn

• Ich bin Software Engineer mit 10 Jahren Berufserfahrung. Angefangen habe ich im Web-Frontend, weil Debugging dort leichter war, bin später aber ins Backend gewechselt
• Durch Zufall landete ich in der Softwareentwicklung für Finanzen, Buchhaltung und Zahlungsabwicklung und erlebte dabei ein hohes Maß an Autonomie in enger, offener Zusammenarbeit mit Product Managern und anderen Stakeholdern
• Ich habe Domain-Wissen zu PCI-Compliance, Double-Entry-Ledgers, Escrows, Reconciliation, Payment Lifecycles und Bank-Transfer-Idempotenz aufgebaut
• Die Karrierestrategie, Domain-Experte zu werden, war eine klare Entscheidung, um sich in einem Bereich zu differenzieren, in dem der Bedarf an Domain-Experten zu steigen schien

Die erste Säule beginnt zu bröckeln: domainspezifisches Wissen

• Im vergangenen Jahr wechselte ich zu einem Unternehmen aus dem Finanzbereich; meine früheren Firmen hatten zwar starke Payment- und Finanzanteile, waren aber keine rein auf Finanzen ausgerichteten Unternehmen
• Das neue Unternehmen setzte vollständig auf AI und stellte vom ersten Tag an ChatGPT- und Claude-Enterprise-Konten bereit; AI sollte ausdrücklich für Recherche, Exploration und Coding genutzt werden
  • Unter der Bedingung, dass jede einzelne Zeile Code für die Produktion persönlich geprüft und verantwortet werden muss
• Mein erstes Projekt war die Überarbeitung eines chaotischen Legacy-Systems für Online-Payments – eine Aufgabe, die ich wegen meiner bisherigen Erfahrung bekam
• Die vor dem Coding geschriebenen Design Docs mussten sowohl für Engineers als auch für Product Manager lesbar sein und erforderten eher eine Architekturperspektive als eine tief technische Analyse
• Die ersten Design Docs schrieb ich mit minimaler AI-Hilfe; damals nannte ich LLMs noch „stochastic parrots“, eine Sichtweise, die ich heute nicht mehr teile
• Das Feedback meines Managers war, dass ich Code zwar in gutem Tempo liefere, aber zu lange für Design Docs brauche und mehr AI einsetzen solle
• Die Modelle waren damals noch nicht so gut wie heute, aber bereits ausreichend, um Schreiben und Entscheidungsfindung deutlich zu beschleunigen
• Das war der Moment, in dem das Wissen an Wert verlor, das ich über Jahre zu Implementierungs-Trade-offs, der Funktionsweise von Acquiring und der Strukturierung von Idempotenz zur Vermeidung doppelter Abbuchungen aufgebaut hatte
  • Die Modelle brauchten zwar weiterhin Steuerung, konnten aber bereits die Verknüpfungen dafür erfassen, wie ein System strukturiert werden sollte – und genau das ist der schwierigste Teil, der sich sonst erst nach Jahren praktischer Arbeit im Kopf formt
• Da es im Web viele erklärende Artikel, technische Dokumentation und Blogposts über die Anwendung technischer Werkzeuge auf Domains gibt, liegt nahe, dass Modelle so etwas als Trainingsdaten aufnehmen können
• Ich hoffte weiterhin, dass Debugging der Bereich bleiben würde, in dem Menschen herausragen, und dass Erfahrung mit Race Conditions in Produktion und dem Debugging verteilter Systeme meine langfristige Beschäftigungsfähigkeit sichern würde

Die zweite Säule beginnt zu bröckeln: Debugging und verteilte Systeme

• Nachdem LLMs gut darin geworden waren, Dokumentation und Implementierungspläne zu unterstützen, wurden sie auch gut im Schreiben von Code; mit dem Hype um Claude Code in der zweiten Hälfte von 2025 und dem Auftauchen von Codex verstärkte sich dieser Trend
• Schon davor nutzte ich LLMs täglich zum Schreiben von Unit-Tests, vertraute ihnen aber noch nicht genug, um ganze Implementierungen zu überlassen
• Mehr AI beim Schreiben von Code einzusetzen war der natürliche nächste Schritt, und da ich Deployments in Produktion und zufriedene Nutzer fast so sehr mochte wie das Coding selbst, war das ein akzeptabler Tausch
• LLMs wurden zwar gut im Schreiben von Code, konnten aber das Chaos, das Modelle oder Menschen hinterlassen hatten, noch nicht debuggen; dadurch blieb meine Rolle größer als bloß Roboter zu orchestrieren
• Mit MCP, agentischen Workflows und dem Erscheinen von Claude 4.5 begann jedoch auch die Debugging-Säule zu wanken
• Claude 4.5 löste etwa 60 % der Bugs allein mit einem Stack Trace und etwas Kontext; in den meisten Fällen reichte bereits ein Sentry-Link mit aktiviertem Sentry MCP
  • Manchmal erzeugte es plausibel klingende, aber völlig falsche Lösungen
• Ab diesem Punkt hörte ich auf, der Maschine zu misstrauen, und erlebte, wie Claude Code Bugs auf Anhieb löste, für die ich früher einen ganzen Tag Debugging gebraucht hätte
• Später, mit 4.6, 4.7, GPT 5.5, Opus 4.8 und dem Erscheinen von DataDog MCP, kam der Punkt, an dem die CLI Bugs in verteilten Systemen in einem Schuss beheben konnte
  • Darunter Bugs, die ich früher nicht hatte lösen können, Bugs, für die zwei Tage Vollzeit-Debugging nötig gewesen wären, und Bugs in verteilten Systemen mit schwacher Distributed Observability
  • Seltsame Race Conditions, unerwartete Corner Cases, Probleme mit Third-Party-Integrationen, undocumented API-Edge-Cases – 90 % dieser Bugs wurden in einem einzigen Durchlauf gelöst
• Es braucht zwar weiterhin jemanden, der den Code prüft und die Roboter steuert, also bin ich noch beschäftigt, aber ich bin zu einem austauschbaren Standard-Engineer geworden
• Meine Spezialisierung in Finanzen und Payments, meine Debugging-Intuition und mein Wissen über verteilte Systeme wurden zu Wissen, das andere Senior Engineers per Prompt aus LLMs heraussteuern können
• Entgegen der bisherigen Lehre, dass sowohl Generalisten als auch Spezialisten ihren Platz haben, bewegt sich der Markt dahin, alle zu Generalisten zu machen
  • Wenn alle zu Generalisten werden und die Nachfrage nicht mitzieht, fällt der Preis von Generalisten – und die Nachfrage sinkt bereits

Die dritte Säule ist noch nicht eingestürzt: Codequalität und Architektur

• Die verbleibende Säule sind Codequalität und Softwarearchitektur, ein Bereich, der heute oft auf das Wort „taste“ reduziert wird
• Während meiner gesamten Laufbahn habe ich Refactoring geliebt, guten Code wichtig gefunden und in Sprints immer wieder Zeit dafür ausgehandelt
• Ich habe es immer geschätzt, bei Themen wie DDD, Hexagonal und Clean Architecture über Trade-offs und die Struktur von Codebases zu diskutieren
• Agenten sind sehr schlechte Werkzeuge, wenn es darum geht, eine Codebase in geordnetem Zustand zu halten
  • Ohne Steuerung entstehen schnell Probleme mit zirkulären Abhängigkeiten
  • Sie fügen duplizierten Code hinzu, setzen unnötige Kommentare ein, vermischen pure Funktionen mit Side Effects und ignorieren SOLID-Prinzipien
• Diese Fähigkeit müsste eigentlich der Bereich sein, der die Beschäftigungsfähigkeit von Menschen schützt, doch die Branche reduziert ihn auf „taste“ und bewegt sich in eine Welt, in der die Bedeutung sauber organisierter Codebases sinkt
• Menschen müssen Agenten weiterhin so steuern, dass keine Spaghetti-Codebases mit Graphen zirkulärer Abhängigkeiten entstehen
• Eine F-Codebase, in der bei jeder Reparatur etwas anderes kaputtgeht, will weiterhin niemand; C- oder D-Codebases gelten inzwischen aber als akzeptabel
• A- oder B-Codebases werden nicht mehr gebraucht, weil Codebases zunehmend so gebaut werden, dass LLMs mit ihnen arbeiten können, nicht damit Menschen sie gut lesen können
• Wenn Source Code jetzt eher für Maschinen als für Menschen geschrieben wird, ist es auch möglich, sich in Richtung Maschine zu orientieren
• Auch Wissen über Codequalität und Architektur verliert an Wert, und die Zeit für Bücher, praktische Übung, Diskussionen mit Engineers und das Schreiben von ADRs wird nutzlos

Was soll ich jetzt tun?

• Kurzfristig glaube ich, dass ich meinen Job behalten werde – zumindest im aktuellen Unternehmen –, aber die langfristige Perspektive ist unsicher
• Langfristig verlieren die Dinge, in die ich 10 Jahre investiert habe – mit nicht beruflicher Erfahrung sogar noch mehr –, zunehmend an Wert
• Auch die letzte Säule meiner Spezialisierung ist auf „taste“ reduziert worden
• Vor etwa acht Monaten gab es im aktuellen Unternehmen Entlassungen – laut Firma nicht im Zusammenhang mit AI – und hervorragende ehemalige Kolleginnen und Kollegen suchen noch immer Arbeit
  • Viele von ihnen erleben dasselbe Problem: Allein mit Domain-Expertise können sie sich nicht mehr ausreichend differenzieren
• Das Unternehmen stellt inzwischen wieder für einige Rollen ein, aber Vertrautheit mit einer Domain ist kein starkes Differenzierungsmerkmal mehr
  • Früher lauteten die Ausschreibungen „Software Engineer - Bereich“, heute nur noch „Software Engineer“, und die Teamzuordnung erfolgt erst nach Annahme des Angebots
• Für hervorragende Engineers, die nie die Chance hatten, tiefe Domain-Erfahrung aufzubauen, haben sich die Jobchancen verbessert
• Gleichzeitig konkurrieren auch hervorragende Engineers, die ihr ganzes Berufsleben Domain-Wissen aufgebaut haben, nun auf derselben Spur
• Die einzige Möglichkeit, langfristige Beschäftigungsfähigkeit zu sichern, scheint zu sein, die eigene Spezialisierung in Bereiche zu verlagern, in denen LLMs nicht so leicht gut werden
• Ich denke darüber nach, an die Universität zurückzukehren, Mathematik, Statistik und fortgeschrittenes Machine Learning zu studieren und mich auf Forschungsrollen in Frontier Labs zu bewerben
  • In meinem Wohnland gibt es keine Frontier Labs, und bei den wenigen existierenden Forschungseinrichtungen ist der Bewerberandrang hoch
  • Wegen familiärer Umstände ist ein Umzug in ein anderes Land schwierig
  • Bis ein Umzug möglich wäre, könnte RSI (rekursive Selbstverbesserung) Forschende womöglich bereits überflüssig machen
• Ich bin so ratlos, dass ich sogar darüber nachdenke, mein Hobby Holzarbeiten zum Beruf zu machen

[GN⁺]

Hacker-News-Kommentare

• Was? Ich steuere zwar den ganzen Tag LLMs, aber ich würde niemals zustimmen, die Verantwortung für ein Finanzprodukt zu tragen
  Die erste Säule steht weiterhin. Vielleicht kennt der Autor seine eigene Hebelwirkung nicht, aber an den zurückgerollten PRs sehe ich, dass ich, sobald ich mich außerhalb eines Bereichs bewege, den ich wirklich gut kenne, nicht mehr beurteilen kann, ob der Agent Unsinn redet. Selbst unser stärkster Agent, der laut Autor sogar Zugriff auf verteilte Systeme hat, liegt oft daneben, hat einen engen Blickwinkel und macht ständig dumme Sachen. Am Ende bringt die Fachkompetenz der Ingenieure im Team alles wieder auf Kurs

  • Ich schreibe von einem Wegwerf-Account, um meine Identität nicht preiszugeben. Ich arbeite bei einem FinTech, das regulierte Produkte baut, und habe Zugriff auf Mythos
    Mythos hat selbstsicher behauptet, ein Teil unserer Codebasis verstoße gegen bestimmte Vorschriften, und gesagt, dass der Betrieb in der aktuellen Form ein ernstes Risiko darstelle. Das stimmte aber nicht; es hatte Anforderungen der Regulierung halluziniert. Ich konnte das wissen, weil der betreffende Code bereits von menschlichen Rechtsberatern geprüft worden war. Und das soll der derzeit verfügbare State of the Art sein. Für Unterstützung beim Schreiben von Code nutze ich generative AI viel, aber selbst mittelfristig kann man sich bei der tatsächlichen Entwicklung regulatorisch konformer Finanzprodukte nicht auf solche Tools verlassen. Das wäre völlig verrückt. Viele FinTech-Unternehmen setzen Agenten ein, um schneller zu werden, das stimmt, aber wenn man sie für einen Produkt-Launch nutzt, ohne dass Menschen wirklich tief eingestiegen sind, geht man ein enormes Risiko ein
  • Du sagst zwar, dass „die Fachkompetenz der Ingenieure im Team alles wieder auf Kurs bringt“, aber wie kannst du sicher sein, dass deine Kollegen mehr Experten sind als ich?
    Vor den LLMs gab es in den meisten Unternehmen Raum dafür, dass hervorragende und durchschnittliche Ingenieure zusammen arbeiteten. Nach den LLMs werden nur noch die „Besten“ überleben können. Durchschnittliche Ingenieure braucht man nicht mehr. Wegen der HN-Demografie werden die meisten Ingenieure, die diesen Beitrag lesen, glauben, sie gehörten in ihrem Unternehmen, ihrer Stadt oder ihrem Land zu den Top 10 bis 5 %, und deshalb seien sie nicht die „durchschnittlichen“ Ingenieure, die von der Einführung von LLMs betroffen sein werden. Statistisch gesehen liegen sie damit wahrscheinlich falsch. Letztlich ist es eine Frage des Egos. Wahrscheinlich bist du kein Rockstar, und LLMs könnten am Ende deinen Job übernehmen. Wie immer gewinnen nur Unternehmen und Führungskräfte, und die meisten von uns stehen ganz unten in der Kette und werden den Schaden tragen
  • Bei PRs mit komplexen Anforderungen ist die Zeit bis zum ersten PR zwar viel kürzer geworden, aber danach sehe ich, wie das Pingpong zwischen Reviewer und Entwickler beginnt
    In meinem Fall hat der Entwickler Teile per Vibe Coding gebaut und hatte weder ein tiefes Verständnis der Anforderungen noch seines eigenen Codes, weshalb mehrere Schleifen nötig waren, bis es korrigiert war. Man kann sagen, das sei ein menschliches Problem, aber der Nettoeffekt, den ich sehe, ist folgender: In komplexen Fällen scheint sich die frühere „ziemlich lange PR-Erstellungszeit + ziemlich lange Review-Zeit“ in „sehr kurze PR-Erstellungszeit + noch längere Review-Zeit“ verwandelt zu haben. Ich weiß nicht, ob das hier tatsächlich einen Gewinn bringt. Manchmal ist der Code funktional korrekt, aber durch zu viele Zwischenfunktionen unnötig weitschweifig, und das dürfte künftige Reviews beeinflussen
  • Leider übernimmt die gesamte softwarebezogene Industrie LLM-/Codegenerierung. Banken, FinTech und Versicherungen tun das alle
    Ich habe dieselben Bedenken, aber sie werden oft abgewiegelt oder mit Formulierungen wie „Die Liefergeschwindigkeit und der ROI sind es wert, also mach dir keine Sorgen“ weggeredet
  • Ich weiß nicht, wie lange die Aussage „Ich steuere den ganzen Tag LLMs, aber ich würde niemals zustimmen, die Verantwortung für ein Finanzprodukt zu tragen“ bei einem bestimmten Arbeitgeber noch Bestand haben wird
    Jedes FinTech-Unternehmen, mit dem ich persönlich zu tun habe, hatte seit letztem Jahr so etwas wie AI-Accounts für Entwickler. Sogar bei Jane Street haben Mitarbeiter Blogposts veröffentlicht und gesagt, dass sie größtenteils Agenten dirigieren. Wie lange glaubst du, dass dein Unternehmen noch durchhält?

• Ich sehe oft Kommentare wie: „AI kann X nicht mit 80–100 % Genauigkeit erledigen, also ist unser Beruf sicher.“
  Ich will nicht übertrieben pessimistisch klingen, aber die Modelle werden schnell besser. Wenn man vor etwa drei Jahren den heutigen Stand beschrieben und gesagt hätte: „Ein Modell erstellt mit einem einzigen Prompt in ungefähr 30 Minuten eine komplette MVP-App“, hätte das wie Science-Fiction geklungen. Die Hürden, mit denen Modelle heute noch kämpfen – geringere Halluzinationsraten, garantierte Regelkonformität, eine saubere Codebasis aufrechterhalten – wirken nicht mehr weit von einer Lösung entfernt. Auch das Abrufen spezifischer Informationen ist über mehrere MCP-Server bzw. RAG bereits teilweise möglich. Ich mache mir Sorgen um die Zukunft von Software Engineers. Wenn diese Mängel gelöst werden, wo bleibt dann noch Platz für den Beruf? Als Rolle, die Aufgaben an AI-Modelle delegiert? Leider erfordert das keine jahrelange Expertise und ist damit ein zweischneidiges Schwert. AI-Output prüfen? Man kann einfach verlangen, dass jede unverständliche Zeile erklärt wird. So wie menschliche Rechner durch digitale Computer ersetzt wurden, werden wir vermutlich noch größere Entlassungswellen sehen. Komplexe mathematische Berechnungen im Kopf auszuführen, kann eine interessante Herausforderung sein, aber es ist viel langsamer und fehleranfälliger als ein Computer. Genauso wird das Schreiben von Code von Hand wohl wie eine unterhaltsame „Herausforderung“ wirken, und AI wie der moderne Taschenrechner

  • Ich empfehle dringend, sich diesen kurzen Clip anzusehen
    https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r
  • Dass die Modelle schnell besser werden und der heutige Stand vor drei Jahren wie Science-Fiction geklungen hätte, stimmt vollkommen
    Vieles wird sich weiter deutlich verbessern. Wenn man sich jedoch die jüngere Geschichte abrupter Umbrüche durch Technologie ansieht, erkennt man ein wiederkehrendes Muster. Wie bei einer Lawine oder einer Sturzflut beginnen solche schnellen Veränderungen oft mit einem oder mehreren wichtigen Durchbrüchen in einer bestimmten Technologie. Anfangs ist das Tempo des Wandels hoch und ungestüm, verlangsamt sich dann aber allmählich, wenn die tief hängenden Früchte geerntet sind und man in neuem Terrain auf neue Barrieren und Reibung stößt. In einer frühen Phase solcher Entwicklungen ist die Vorhersagekraft gering, wenn man die jüngste außergewöhnliche Veränderungsrate einfach in die Zukunft extrapoliert. Plötzliche extreme Ausschläge neigen dazu, wieder zur langfristigen Trendlinie zurückzukehren. Die aktuelle LLM-Unruhe lässt sich als Ergebnis von Forschung seit 2010 verstehen, die sich 2017 mit dem Transformer-Paper gebündelt hat und rundherum weitere Forschung schnell ausgelöst hat. Wenn das so ist, könnten wir uns jetzt in der mittleren oder späten Phase der steilen LLM-Explosion befinden. Das Tempo grundlegender, breit wirksamer Durchbrüche, die alle LLM-Anwendungen voranbringen, hat sich klar verlangsamt, und viele der jüngsten einflussreichen Entdeckungen liegen in bereichsspezifischer Ausweitung, Optimierung, Tuning und Produktisierung. Das heißt nicht, dass morgen kein weiterer Durchbruch auf Transformer-Niveau kommen kann, aber historisch treten Black Swans nur selten im Rudel auf
  • Warum sollte es bei Entwicklerentlassungen aufhören? Wenn Software-Unternehmen beim Betrieb ihres Geschäfts von LLM-Anbietern abhängig werden, könnten wir bei diesen Firmen weltweit einen großflächigen Zusammenbruch sehen – von On-Premises-Produkten bis zu SaaS
    Kunden würden dann nicht mehr wie heute Software-Tools kaufen, sondern entweder alle benötigte Software intern erstellen oder sie von Prompt-Engineering-Beratern erstellen lassen. Das könnte eine völlig andere Welt werden
  • Was ist die Theorie dazu, wann AI 100 % erreicht? Werden PMs und Business-Analysten dann sämtliche Software bauen?
    Oder gibt es weltweit nur noch ungefähr 700 Ein-Personen-Gründerfirmen und alle anderen können nicht mehr arbeiten? Ist das dann die Matrix?
  • Wenn du glaubst, dass die Modelle so gut werden, ist das schon fast wahnhaft
    Meine Produktivität ist seit dem Erscheinen von Claude 3.5 nicht annähernd so stark gestiegen. Ich habe unbegrenzten Zugriff auf alle LLMs, aber die meisten sind Müll, und ich verbringe mehr Zeit damit, Dinge zu korrigieren, als sie selbst zu bauen. Von diesem Tool profitieren nur Leute, die schnell minderwertige Ergebnisse raushauen wollen. Wenn du nicht zustimmst, gehörst du auch zu diesen Leuten

• Mein Karriereweg ist dem des Autors erstaunlich ähnlich. Seltsamerweise wirkt der Teil, den der Autor als erste eingestürzte Säule sieht, derzeit am intaktesten.
  LLMs scheitern in den Besonderheiten unseres Geschäfts immer wieder. Dinge wie lokale Steuergesetze, Details von Buchhaltungsprozessen oder die Eigenheiten unserer Ledger-Implementierung. Beim Refactoring, bei Sprachmigrationen und beim Aufspüren von Bugs in bestehendem Code sind sie hervorragend, aber wenn es darum geht, unsere Domäne zu reproduzieren und zu erweitern, gibt es immer viele subtile Fehler. Vielleicht liegt das daran, dass die Firmen, bei denen ich gearbeitet habe, absichtlich komplexe Bereiche bearbeitet haben, um einen Burggraben aufzubauen. Das sind Firmen, deren Geschäft nur deshalb tragfähig ist, weil es kein Buch gibt, nach dem man eine Kopie bauen könnte, und weil das Know-how intern bleibt. Und wenn ein FinTech-Manager dazu rät, Design-Dokumente schnell mit KI zu erstellen, wirkt das für ein Geschäft, das mit Geld umgeht, zu sorglos. Besonders wenn eine große Zahl kleiner Transaktionen anfällt, ist es viel zu leicht, Fehler in Millionenhöhe falsch zuzuordnen. Solche Bugs sind wirklich schwer zu behandeln. Die Korrektur der Logik ist nur Schritt 1; danach muss man falsch berechnete Daten in einer unveränderlichen Datenbank korrigieren und regulatorische Prozesse sowie die Kundenkommunikation abwickeln. Fixes werden zu Fallstricken, die neue Features und Observability berücksichtigen müssen. So nach dem Motto: „Denk daran, dass der Ausreißer in den Daten vom 2. Februar auf Vorfall X zurückgeht.“

  • Wenn man wirklich etwas baut, das es vorher noch nie gab, kann man LLMs nicht mit Architekturentscheidungen betrauen.
    Ich baue mehrere Produkte auf Basis physikalischer Simulationen, rein aus ersten Prinzipien abgeleitet. Wenn man das ohne aktive Forschung, Nachdenken und Verifikation delegiert, erzeugt es Rechencode, der um Hunderte Größenordnungen langsamer ist, fügt absurde Ausweichpfade und Abkürzungen ein und produziert am Ende unbrauchbare Berechnungen. Das passiert wahrscheinlich in etwa 95 % der Fälle. Aufsicht ist extrem wichtig, und architektonisches Denken kann man noch nicht auslagern. Auslagern kann man nur die Ausführung.
  • Lokale Steuergesetze, Buchhaltungsprozesse und die Eigenheiten einer Ledger-Implementierung sind Domänenexpertise, dafür braucht man nicht zwingend einen Softwareingenieur.
    Natürlich sind Senior-Softwareingenieure oft Experten darin, aber zwingend ist das nicht. Traditionell war es für eine reibungslose Produktion nützlich, wenn Ingenieure etwa 90 % der Arbeit erledigen konnten, ohne Fachexperten aus dem Business fragen zu müssen, aber genau das Ende dieser „Tradition“ ist der Kern des Originalbeitrags. In der neuen Welt besteht die Arbeit eines Senior Engineers nicht darin, diese Domänenexpertise selbst zu besitzen, sondern dafür zu sorgen, dass Agenten sie besitzen oder erwerben, und sicherzustellen, dass sie nachprüfbar korrekt ist. Senior Engineers, die sich daran festhalten, dass fortgeschrittene Business-Domänenexpertise sie absichert, werden genauso bald in einer Sackgasse landen wie Juniors, die den Wandel nicht mitgemacht haben.
  • Ich bekomme weder Claude noch GPT-5 dazu, auch nur Ablaufdiagramme für gängige Use Cases durchgängig gut zu erstellen. Von domänenspezifischen Inhalten ganz zu schweigen.
    Es verfügt über ein tiefes Vokabular und klingt dadurch, als wüsste es mehr, als tatsächlich der Fall ist. Code zu schreiben und sichtbare Fehler zu debuggen, kann es sehr gut, aber das liegt zur Hälfte auch an der Test-Harness.
  • Eine Technik könnte helfen, Produktfunktionen und die Vorschriften, die diese Funktionen abbilden müssen, zusammen mit einem LLM in ein gemeinsames Verständnis zu überführen.
    Die Kernidee ist, dem LLM Dokumente zu geben und es viele Fragen stellen zu lassen, um Mehrdeutigkeiten und mögliche Missverständnisse auszuräumen. Ich empfehle, sich Skills einmal anzusehen. Das hilft wirklich. https://www.youtube.com/watch?v=6BB6exR8Zd8
  • Auch unser Unternehmen hat viel mit komplexen Vorschriften und domänenspezifischen Systemimplementierungen zu tun, und früher hatte KI damit zu kämpfen.
    Wir konnten das Problem mit gut gepflegten claude.md/agents.md-Dateien lösen. Außerdem haben wir supermemory.ai integriert, sodass neu getroffene Entscheidungen von KI-Agenten beim Start jeder neuen Sitzung immer wieder abgerufen werden.

• Ich denke oft an Steve Jobs’ berüchtigten Satz „Ideen sind billig“.
  Alles hängt von der Umsetzung ab, und wenn Frontier-LLMs die Umsetzung lösen, werden Ideen zum Tor zum Überfluss. Aber Überfluss selbst garantiert noch keine „Bindungskraft“. Was oft übersehen wird, ist der menschliche Wille, bei einer Sache dranzubleiben, und die Bereitschaft, sich darum zu kümmern. Viele Menschen wollen sich nicht genug kümmern, um etwas zu erschaffen, zu pflegen und zu besitzen. V1 lässt sich vielleicht schneller veröffentlichen, aber kann man immer weiter nachlegen? Ein gutes Beispiel ist das AI-Musiktool Suno. Es liefert inzwischen ziemlich gute Ergebnisse. Viele Menschen spielen eine Weile in ihrer eigenen kleinen Welt damit herum, werden dann schnell müde und verschwinden wieder, und nur eine kleine Zahl produktiver Kreativer bleibt übrig und macht daraus ein „arbeitsähnliches“ Umfeld. Das Ausmaß und die Wirtschaftlichkeit von Delegation und Umsetzung mögen sich verändert haben, aber es gibt noch viele Faktoren zu bedenken

  • Ich habe Suno ein wenig benutzt und würde der Aussage, es liefere „wirklich gute Ergebnisse“, nicht zustimmen.
    Selbst als jemand mit begrenzter musikalischer Bildung empfinde ich das so, daher sind Musiker wahrscheinlich noch kritischer. Die ersten paar Male ist es beeindruckend, und die Melodien sind eingängig. Früher klang es im Hintergrund merkwürdig, aber das meiste davon wurde behoben. Doch nach einigen Dutzend Songs beginnt alles ähnlich zu klingen. Alles wirkt generisch, die Songs erzählen keine Geschichte und fühlen sich an wie Musik unter einer Unternehmenswerbung. Selbst mit präziseren Prompts hat es nicht gut funktioniert, und die Details, die einen Song interessant machen würden, werden meist ignoriert. Die interessantesten Ergebnisse entstanden eher dann, wenn ich es wie durch einen Bug aus der Bahn geraten ließ. Als ich bat, zwei sehr unterschiedliche Genres zu mischen, kam etwas mit einem unheimlichen Gefühl heraus, an das ich mich nicht erinnern kann, es jemals zuvor gehört zu haben. Aber wenn man weiter daran arbeiten will, wird es immer schwierig, es will ständig wieder zu generischen Ergebnissen zurückkehren und ignoriert detaillierte Anweisungen. Suno kann remixen. Es ist ähnlich wie bei Code. LLMs sind schon jetzt sehr gut beim Portieren von etwas, das bereits funktioniert, damit es in einer anderen Sprache läuft. Aber wenn man nur eine Idee hat, scheitern sie an den originellen Teilen. Damit ein LLM eine Idee sauber umsetzt, muss man so viele Anweisungen geben, dass man gegen die Mehrdeutigkeit natürlicher Sprache kämpft und faktisch fast selbst den Code schreibt
  • Frontier-LLMs „lösen“ die Umsetzung nicht.
    Wenn man genug Druck macht und ein System hat, das tatsächlich funktionierenden Code hervorbringen kann, kann man die Umsetzung lösen. Aber genau das ist Engineering. Im jetzigen Standardzustand sind wir noch sehr weit davon entfernt, Engineering zu ersetzen. In drei Jahren vielleicht. Es bewegt sich schnell. Aber heute kann man nicht einfach sagen: „Mach mir einen besseren Rust-Compiler“, sich zurücklehnen und auf das Ergebnis warten
  • Suno ist ein gutes Beispiel. Ich habe viele Songtexte geschrieben und sie mit Suno „produziert“, aber bis der gewünschte Klang herauskam, brauchte es Dutzende bis Hunderte von Remixes/Covern/Erweiterungs-Korrekturen oder viel Zeit im Editor.
    Ich mag die Songs und würde sie in meiner Playlist hören, aber im Suno-Algorithmus haben sie keine große Resonanz bekommen. Auch anderswo habe ich sie nicht stark beworben, und selbst als ich sie hochgeladen habe, gab es nur ein paar Likes. Das enttäuscht mich nicht. Ich habe Musik für mich selbst gemacht, und das Teilen war nur ein Nebeneffekt. Meine Schlussfolgerung daraus ist, dass es viel Arbeit braucht, damit Menschen sich für das interessieren, was ich gemacht habe, und es genießen. Man muss Marketing machen, es vor die Leute bringen und dafür sorgen, dass sie darauf aufmerksam werden. Ich bin außerdem überzeugt, dass man ihnen einen Grund geben muss, es zu mögen, indem man es mit Videos, einer Geschichte, einer Persona oder einer bestimmten Stimmung verbindet. Damit etwas „haften bleibt“, muss man all das beim selben Publikum wiederholen, damit es sich daran gewöhnt. Deshalb braucht es Beständigkeit, und man muss sich wirklich um das kümmern, was man zu verkaufen versucht. Bevor Menschen dabeibleiben, muss ich selbst zuerst dabeibleiben
  • https://x.com/chamath/status/2033385903520129161
    https://en.wikipedia.org/wiki/Sturgeon%27s_law
    Sturgeons Gesetz besagt: „90 % von allem sind Mist.“ Dieses Bonmot wurde vom amerikanischen Science-Fiction-Autor und Kritiker Theodore Sturgeon geprägt, als er den Wert des Genres verteidigte. Sturgeon vertrat die Ansicht, dass in jedem Bereich die meisten Werke von geringer Qualität seien und Science-Fiction daher nicht auf einzigartige Weise minderwertig sei
  • Kannst du mehr über AI-Musiktools erzählen?
    Mein Eindruck ist, dass sie wie Tools verwendet werden, die etwas in einem Durchgang erzeugen. Ich kenne mich mit Musik nicht gut aus, aber ich nehme an, dass Künstler viele Dinge brauchen, die ich nicht kenne: Zwischenschritte, Track-Separation, Instrumenten-Anpassung und so weiter. Ohne so etwas scheint es mir schwer, sie für professionelle Arbeit einzusetzen

• Ich stimme diesem Beitrag nicht vollständig zu. Vibe-Coder können kein System mittlerer Komplexität entwerfen, entwickeln und implementieren, ohne dabei alles zu sprengen.
  Ein großer Teil dabei, Anwendungen wie Claude gut zu nutzen, ist konzeptionelles Verständnis und Erfahrung mit Informatik-Konzepten. Genau das haben Vibe-Coder überhaupt nicht. Wenn sie es hätten, wären sie keine Vibe-Coder

• „Ich weiß nicht, was ich tun soll“ bedeutet einfach: auf der Welle reiten.
  Als Websites/Web-Apps die Welle waren, bin ich auch mitgeritten. Ich bin noch vor dem Internet in die Softwarebranche eingestiegen und habe mich immer wieder auf neue Dinge umgestellt. Man ist nie zu alt, um neue Technologien zu lernen. Neue Wellen schaffen neue Arten von Arbeit und neue Arten von Arbeitskräften. Dann wird man eben zu einer davon. Reite das Biest, meistere das Werkzeug. Es ist wieder dasselbe Spiel.

  • Stimme zu.
    Wenn es eine Fähigkeit gibt, die dauerhaft gefragt ist, dann ist es die Fähigkeit, Dinge im Kopf zu strukturieren — neue Arbeit, neue Prozesse, neue Menschen, was auch immer. Ich habe diese Fähigkeit bei der Arbeit als Prototypenmechaniker als scharfes Werkzeug verstanden und weiterentwickelt. Für Leute, denen das nichts sagt: Ein Prototypenmechaniker ist jemand, der Woche für Woche unter engen Fristen erledigt, was nötig ist, um schwierige Teile herzustellen. Metall, Kunststoff, alles Mögliche. Man wird gut darin, sich schnell in Prozesse, Werkzeugmaschinen und Materialien einzuarbeiten. Wenn man das eine Weile macht, kann man neue Informationen extrem schnell aufnehmen und versteht Aufgaben viel schneller und präziser als viele andere. Jeder kann damit anfangen. Sei neugierig und bau etwas. Und dann bau mehr. Teile, was du gebaut hast, und baue Dinge, die andere haben wollen.
  • Insgesamt fühlt es sich so an, als würde die Gesellschaft stärker schwanken, aber im Kern ist es wieder dieselbe alte Nummer.
    In den 90ern und 2000ern gab es die Welle „Objektorientierte Programmierung wird alles verändern“. Dinge, die man zuvor schon Hunderte Male erfolgreich gemacht hatte, machte man jetzt eben objektorientiert. Schreibst du Code für Flugzeuge? An der Uni hat man uns tatsächlich erzählt, man müsse einfach ein allmächtiges Flugzeug-Objekt kaufen, das alles am Flugzeug macht. Stellte sich heraus, OOP war doch keine Universallösung? Dann kam Codegenerierung, probier mal Ruby on Rails aus. In 2 Sekunden baust du eine Website. Codegenerierung war überall. Dann bog es komisch ab und TDD kam auf. Ich habe echte Diskussionen gesehen, in denen Leute meinten, wer kein TDD macht, sei ein so schlechter Engineer, dass er ins Gefängnis gehöre. Nein, nicht TDD, sondern BDD sei die Lösung. Lean, nein Agile, nein kleingeschriebenes agile, aber am Anfang war es das, nein Scrum, nein XML, Moment, das war letztes Jahrzehnt, dann JSON und schließlich SAFe. Und jetzt heißt es: „Hast du diesen Chatbot gesehen?“ Jede Wiederholung bringt etwas Gutes, wenn man aufpasst. Aber sie bringt auch viel Hype und Angst mit. Man muss einfach experimentieren und lernen. Eine Sache, die für mich unverändert geblieben ist: Fast alle würden lieber sterben, als die Folgen ihres wahr gewordenen Traums sorgfältig zu durchdenken. Solange das weiter stimmt, werden Menschen weiterhin dafür bezahlen, dass jemand für sie den Drachen eines überhypten Trends reitet.
  • Du sagst zwar „Meistere das Werkzeug“, aber das eigentliche Wertversprechen dieser Werkzeuge ist doch gerade, dass es nichts aufzubauen und nichts zu meistern gibt.
    Der ganze Fließbandprozess minderwertiger Ergebnisse — oder eben der „AI-native“-Prozess — läuft so: „Wow, ich habe einen Chatbot dazu gebracht, etwas zu bauen, das ich überhaupt nicht verstehe. Ich bin ja so gut in meinem Job!“ Das ist wie ein Trostpreis fürs Bauen. Etwas anderes hat es gebaut, und ich streiche die Lorbeeren ein, obwohl ich es kaum verstehe. Es gibt keinen Zinseszinseffekt auf meinen Einsatz. Keine Lektion, die ich gelernt hätte. Kein Verständnis, das sich aufbaut. Keine Einsicht, die zu künftiger Innovation führt. Keine Differenzierung. Man brüllt einfach so lange betäubt ins Nichts, bis der Spielautomat irgendeine minderwertige Mischung ausspuckt, die „gut genug aussieht“, und dann wiederholt man das am nächsten Tag. Wenn das das Spiel ist, bin ich raus. Schön für andere, wenn es ihnen Spaß macht, aber zu glauben, hier stecke irgendeine Meisterschaft drin, ist Wahn. Die einzige Voraussetzung, um mit diesem Werkzeug „erfolgreich“ zu sein, ist, aufzuhören, sich zu kümmern, und zu kapitulieren.

• Ich habe das schon einmal gepostet, aber es lohnt sich, es noch einmal zu posten.
  Ich arbeite im DevOps bei einem Unternehmen, das LLMs sehr aggressiv einsetzt. Die Phasen waren ungefähr so: dem LLM „vieles“ machen lassen, noch mehr machen lassen, mehrere Agenten laufen lassen, dann wieder zurück zu einem einzelnen Agenten, ihn aber Werkzeuge bauen lassen, und dann hin zu deterministischen Werkzeugen, die sowohl Menschen als auch LLMs nutzen können. Der Grund ist folgender: Sowohl bei Deployments als auch bei Tests liefern deterministische Werkzeuge binäre Antworten und sind wiederholbar. Wenn etwas ausfällt, kann man immer zu einem Werkzeug zurückkehren, das ein Mensch ausführen kann. Es ist schneller. Ein einfaches Skript läuft in unter 30 Sekunden, aber „plausibel klingender Unsinn“ schien immer 2–3 Minuten zu brauchen. Am Ende landet man wieder bei diesem Artikel: https://spawn-queue.acm.org/doi/10.1145/3194653.3197520. Also: „Erstelle eine Aufgabenliste, schreibe für jede Aufgabe ein Skript, kombiniere die Skripte zu Funktionen, und die Funktionen werden zum System.“ Zusätzlich dazu: Wenn man das LLM einfach machen lässt, schreibt es bereitwillig Code. Man kann Tests hinzufügen, um zu prüfen, ob die Tests funktionieren. Das haben wir bei menschlichem Code früher auch gemacht. Man kann den Code auch lesen. Und wenn man den Code liest, merkt man, dass es zwar funktionierenden Code erzeugen kann, dabei aber trotzdem komplett wahnsinnige Dinge tut. Menschen tun das auch, aber das ist eine andere Geschichte. Am Ende muss man immer noch prüfen, ob das gebaute System überhaupt Sinn ergibt. Einfacher gesagt: Vielleicht ist Coding tot, aber Software Engineering lebt und ist putzmunter.

  • Genau so ist es richtig.
    Man kann große LLMs alles machen lassen. Das geht, und es wird auch tatsächlich gemacht. Aber es ist extrem teuer und dauert lange. Wenn man stattdessen mit AI Werkzeuge baut, die so viele Aufgaben im Prozess wie möglich deterministisch erledigen, und dann die AI diese Werkzeuge benutzen lässt, läuft alles viel schneller und billiger. Als Bonus kann man irgendwann die teure Cloud-AI loswerden und auf kleine oder mittlere lokale Modelle umsteigen.

• Wenn die Zukunftsvision des Autors stimmt, sind fähige Software Engineers auf der sicheren Seite
  Domänenwissen lässt sich viel schneller lernen als die Anwendung guter Engineering-Prinzipien. Engineers, deren Hauptvorteil Domänenwissen ist, sind im eigentlichen Engineering vielleicht nicht besonders stark. Trotzdem können sie in anderen Bereichen der Branche Jobs finden, in denen ihr angesammeltes Domänenwissen gebraucht wird

  • Im gesamten Thread letzte Woche hieß es, Domänenexpertise sei schon immer der eigentliche Burggraben gewesen: https://news.ycombinator.com/item?id=48340411
  • Ich bin nicht sicher, ob die Aussage allgemein stimmt, dass man Domänenwissen viel schneller lernen kann als gute Engineering-Prinzipien
    Viele gute Software Engineers, die arrogant annahmen, leicht verfügbares Domänenwissen reiche aus, haben zahllose ERP-Systeme ruiniert. Ein gewaltiger Teil der IT besteht buchstäblich darin, Geschäftsregeln in Systeme zu gießen
  • Dem stimme ich teilweise nicht zu. Allgemeines Domänenwissen kann man schnell lernen, aber es zu einem feinen Verständnis auszubauen, das die Komplexität berücksichtigt, kann Jahre bis Jahrzehnte dauern, besonders in einzigartigen Organisationen, die oft nicht als „Softwareentwicklungsunternehmen“ gelten
    Trotzdem sehe ich weiterhin „professionelle“ Softwareentwickler, die keine guten Software-Engineering-Praktiken befolgen, und reviewe auch ihren Code. Die Aussage, dass Engineers, deren Hauptvorteil Domänenwissen ist, im Engineering vielleicht nicht herausragend sind, gilt genauso für Engineers ohne Domänenwissen. Zumindest ist das meine Erfahrung. Vielleicht hatten wir einfach Pech
  • Die Entwicklung und der Erwerb von wertvollem Domänenwissen ist ein schwieriger, riskanter, teurer und langsamer Prozess
    Denn wertvolles Domänenwissen ist nicht das Wissen von gestern, sondern das von heute und morgen. In Bereichen, in denen Domänenwissen wichtig ist, ist es tief mit dem Engineering verflochten. Niemand würde Jeff Dean damit beauftragen, die Unreal Engine von Grund auf zu entwickeln. Trotzdem gibt es viele Software-Engineering-Prinzipien, die Domänenexperten nicht vollständig verinnerlicht oder nicht ausreichend umgesetzt haben. Solange Domänenwissen wertvoll ist, wird dieser Zustand auch bestehen bleiben. Denn Software Engineering ist ebenfalls nur eine weitere Domäne
  • Lässt sich Domänenwissen wirklich schneller lernen? Ich bin da anderer Meinung
    Methodik lässt sich viel schneller verbessern als Fachwissen aufzubauen. Ersteres ist eine Frage des Ansatzes und kann erzwungen und schnell angehoben werden. Letzteres hängt von der Lernneigung der Person, ihren Fähigkeiten und der verfügbaren Zeit ab und lässt sich über angemessene Unterstützung hinaus nicht erzwingen. Außerdem baut es auf sich selbst auf, weshalb die Lernkurve am Anfang deutlich steiler ist

• Ich nutze Claude Code und Opus 4.7, und das erzeugte Code ist nicht so sehr falsch, sondern eher zu umfangreich
  Es hat weiterhin Wert, eine bestimmte Funktion zu durchdenken und sie so einzubauen, wie sie am besten in den Code passt. Claude wählt oft eine Ebene des Stacks, zum Beispiel die Darstellungsschicht, und stopft es dort hinein. Wenn dieselben Daten ein paar Wochen später auch anderswo gebraucht werden, kann Claude den Code der Service-Schicht nicht wiederverwenden und macht eine Art „Transplantation“. Wenn ein Mensch nicht aufmerksam ist, verdoppelt sich die Code-Menge und die Logik wird dupliziert. Ich glaube nicht, dass AI-Tools wie Claude darin bald besser werden. Bei uns im Unternehmen gibt es bereits Druck, die Nutzung von Opus 4.7 zu reduzieren, um Kosten zu sparen. Jemand meinte, für „einfache Bugfixes“ solle man kleinere Modelle verwenden. Manchmal mag das funktionieren, aber wie oft weiß man im Voraus wirklich, dass es ein einfacher Bugfix ist? Wenn die Kosten steigen, dürfte das Interesse sinken, mit diesem Tool „den gesamten Code“ zu schreiben. Wenn die Leute zu billigeren und weniger effektiven Modellen wechseln, verschwindet wahrscheinlich auch der Druck, deren Code nicht mehr zu reviewen. Mal sehen, wo das endet, aber vielleicht ändert sich am Ende doch nicht alles so dramatisch, wie der Autor befürchtet

  • Ich stimme der Kritik zu, dass AI zu viel Code schreibt
    Es ist erstaunlich effektiv, der AI einfach zu sagen, sie solle die Zahl der produktiven Codezeilen halbieren und prüfen, ob es andere Bibliotheken gibt, die wiederverwendet werden können. Man könnte wohl auch einen Refactoring-Bot bauen, der Duplikate erkennt und herauszieht. Das ist derzeit nicht standardmäßig eingebaut, aber es ist eindeutig nicht unmöglich
  • Ich sehe das Problem mit zu viel Code ebenfalls
    Die offene Frage ist allerdings, ob zu viel Code tatsächlich ein Problem ist. Diese Tools sind jetzt Teil des Lebens. Wenn sie Probleme schneller lösen oder Debugging beschleunigen und die Software weniger Bugs hat, dann ist das vielleicht nicht zu viel Code, sondern genau die richtige Anzahl Codezeilen
  • Vor Kurzem gab es im Codebase eine Situation mit zwei Funktionen, fooBar() und fooBarExtended()
    Letztere hatte die zusätzlichen Parameter und Funktionen, die für das aktuelle Problem nötig waren. Aber statt diese Funktion aufzurufen, wollte Claude der ersten Funktion immer wieder dieselben erweiterten Parameter hinzufügen. Selbst nachdem ich gesagt hatte, es solle das nicht tun, machte es später denselben Vorschlag noch einmal, und das ist manchmal wirklich nervig

• Unabhängig davon, wie man die Zukunft der Branche sieht, halte ich es für schwer, im Holzhandwerk größeren beruflichen Erfolg zu finden als mit handwerklich geschriebener Software

  • Der Markt für maßgefertigte Möbel/Schränke ist schon jetzt ziemlich hart, und Tischlerei ist unter Programmierern ein viel zu verbreitetes Hobby, sodass der Markt schnell massiv übersättigt wäre, wenn viele von uns dort einsteigen würden
    Mir wurde schon gesagt, ich solle versuchen, die Möbel zu verkaufen, die ich gebaut habe, aber meine Antwort ist immer dieselbe. Ich habe einmal den Fehler gemacht, ein Hobby zum Beruf zu machen, und werde diesen Fehler nicht noch einmal machen. Zumindest zahlt Software immer noch ziemlich gut
  • Das hängt davon ab, was man unter Holzarbeit versteht
    Mit mir arbeitet jemand zusammen, der Dinge wie Terrassen, Gärten, Wohnwagen, Schuppen und Zäune baut, und der verdient wirklich sehr gut. Fairerweise muss man sagen, dass er auch extrem gut darin ist
  • Ich besitze ein historisches Haus mit einzigartig geformten, von Hand geschnitzten Türen
    Der Türrahmen war verrottet, und ich habe einem Schreiner 4.000 Dollar bezahlt, um einen Ersatz anzufertigen. Die Tür selbst zu ersetzen würde leicht 25.000 Dollar kosten. Wenn man in einen größeren historischen Bezirk mit vielen handgeschnitzten Türen zieht, kann man damit ganz ordentlich Geld verdienen
  • Ein sehr kleiner Teil des Marktes, wahrscheinlich nicht einmal 1 %, ist immer noch bereit, für Handarbeit zu zahlen. Wenn sie vollständig modern und zugleich retro ist, gibt es sogar Bonuspunkte. Zum Beispiel Steampunk-Tastaturen
    Aber der Anteil des Marktes, der für handgemachte Software zahlen will, liegt exakt bei 0 %
  • Schau auf layoffs.fyi. Du wirst wahrscheinlich bald entlassen. Vielleicht nicht morgen, aber gib AI noch ein paar Jahre, bis sie besser wird. Das ist eine Einbahnstraße bergab
    Es ist nicht Tischlerei, sondern Landwirtschaft. Du musst Land beschaffen und dein eigenes Essen anbauen. Sich überhaupt nicht an der Wirtschaft zu beteiligen ist der einzige Weg zu überleben