Warum wiederholt sich der Hype, dass „Entwickler ersetzt werden“?

 (alonso.network)
46 Punkte von GN⁺ 2025-05-28 | 19 Kommentare | Auf WhatsApp teilen
  • Von NoCode bis AI tauchen Technologien, die Entwickler ersetzen sollen, immer wieder auf, tatsächlich werden Rollen jedoch entsprechend dem technologischen Wandel umgeformt
  • NoCode hat Entwickler nicht abgeschafft, sondern NoCode-Spezialisten und Integrationsfachleute hervorgebracht, und die Cloud hat mit dem DevOps Engineer ein anspruchsvolles Berufsbild geschaffen
  • Auch die heutigen AI-Entwicklungstools gehen einen ähnlichen Weg, und selbst in einer Zeit, in der AI Code schreibt, bleibt die Fähigkeit zur Systemarchitektur zentral
  • AI ist gut in lokaler Optimierung, aber schwach bei der Gestaltung gesamter Systeme; durch die hohe Generierungsgeschwindigkeit besteht das Risiko, strukturelle Fehler schnell zu verfestigen
  • Der Ersatz von Entwicklern ist letztlich nur eine Evolution und Höherentwicklung im Zuge veränderter Technologie-Stacks; die grundlegende Rolle wird weiterhin gebraucht

From NoCode to AI-Assisted

  • Im Abstand von einigen Jahren taucht jeweils eine neue Technologie auf, von der behauptet wird, sie werde Softwareentwickler ersetzen
  • Ähnliche Schlagzeilen mit überzogenen Erwartungen wie „Das Ende des Codings“, „Jetzt kann jeder Apps bauen“ oder „Sogar Kinder programmieren“ werden immer wieder produziert
  • Führungskräfte und Berater richten ihre Aufmerksamkeit auf diesen Trend, und Budgets werden umgeschichtet
  • In der Realität ging es jedoch nie um „Ersatz“, sondern immer um „Transformation“
    • Immer wieder zeigt sich die Tendenz, dass neue Rollen und höher qualifizierte Spezialberufe entstehen, die mit komplexer gewordener Technologie umgehen, und dass auch die Löhne steigen
  • NoCode weckte die Erwartung, Apps ohne Fachkräfte bauen zu können, doch am Ende blieben komplexe Probleme wie Datenmodellierung, Integration und Wartung, und dafür entstanden neue Berufsbilder
  • Die Cloud vermittelte den Eindruck, man könne ohne Systemadministratoren auskommen, in der Praxis verlangte sie jedoch hochspezialisierte DevOps-Expertise, und auch die Gehälter stiegen
  • Bei AI ist es ähnlich: Es wirkt, als könne AI den Code anstelle von Menschen schreiben, tatsächlich wächst aber die Bedeutung von erfahrenen Entwicklern, die AI steuern und orchestrieren können

Das sich wiederholende Karussell der Ersetzungsversprechen (The Endless Carousel of Replacement Promises)

NoCode/LowCode-Revolution

  • Die NoCode/LowCode-Revolution trat mit dem Versprechen auf, dass dank intuitiver Oberflächen jeder Apps erstellen könne
  • In der Praxis entstanden jedoch neue Probleme wie das Entwerfen von Datenmodellen, die Integration in bestehende Systeme und Datenbanken, Ausnahmebehandlung und Wartung
  • Entsprechend wurden nicht einfach allgemeine Entwickler gebraucht, sondern NoCode-Spezialisten, die zugleich Domänenwissen und technische Grenzen verstehen
  • Sie erhalten höhere Gehälter als traditionelle Entwickler

Cloud-Revolution

  • Es gab die große Erwartung, dass mit der Migration in die Cloud keine Systemadministratoren mehr nötig seien
  • Tatsächlich nahmen jedoch Cloud-Management-Kompetenz und Komplexität eher noch zu
  • Aus klassischen Systemadministratoren wurden DevOps Engineers mit höherem Gehalt, und das Arbeitsniveau entwickelte sich weiter in Richtung Infrastrukturautomatisierung, Deployment-Pipelines und Management verteilter Systeme
  • Die Arbeit verschwand nicht, sondern entwickelte sich zu einer neuen Form von Aufgaben
  • Auch beim Wechsel zu Microservices stieg die Komplexität, und es zeigte sich letztlich, wie wichtig Spezialisten für das grundlegende Management von Systemen sind

Der Offshore-Entwicklungsboom

  • Es entstand der Glaube, dass sich durch Outsourcing ins Ausland Kosten senken ließen, doch Kommunikationsprobleme, Qualitätsverluste und mangelndes Domänenwissen führten zu Schwierigkeiten
  • Am Ende wandelte sich die Strategie hin zu Strukturen für verteilte Teams, klaren Verantwortlichkeiten und einer starken Architektur, was insgesamt zu höheren Kosten führte als ursprünglich erwartet

Die Revolution der AI-Coding-Assistenten

  • Nun steht das Versprechen im Mittelpunkt, dass AI automatisch Code generiert
  • In der frühen Praxis enthält der von AI erzeugte Code jedoch oft subtile Fehler und Konsistenzprobleme
  • Senior Engineers verbringen viel Zeit damit, AI-Ergebnisse zu prüfen und zu korrigieren, und je erfahrener Entwickler sind, desto mehr Wert schaffen sie
  • Systeme, die nur mit AI-Unterstützung aufgebaut wurden, weisen häufig keine systematische Architektur auf
  • Das heißt: Nicht die Technologie ersetzt die Fachkräfte, sondern sie hebt deren Expertise auf eine höhere Abstraktionsebene

Warum dieser Zyklus besonders ist

  • Der entscheidende Punkt, den viele übersehen: Code ist kein Vermögenswert, sondern eine Verbindlichkeit
  • Je schneller und einfacher Code erzeugt wird, desto größer wird auch die Last von Wartung, Sicherheit und Refactoring
  • AI kann auf Funktionsebene optimieren, hat aber Schwächen bei der Gestaltung des Gesamtsystems
  • Je schneller die Implementierung wird, desto größer ist das Risiko, strukturelle Fehler schnell zu verfestigen
  • Letztlich bleibt auch im AI-Zeitalter die Fähigkeit zur Systemarchitektur der wahre Vermögenswert – und sie wird nicht ersetzt, sondern gestärkt
  • Die Behauptung „AI ersetzt Entwickler“ beruht auf den folgenden grundlegenden Missverständnissen
    • Code ist kein Vermögenswert, sondern eine Verbindlichkeit
    • Code erfordert fortlaufende Wartung, Prüfung, Sicherheitsmanagement und Austausch, und mit jeder zusätzlichen Zeile wächst diese Verbindlichkeit
  • Wenn AI Code schneller erzeugt, bedeutet das nur, dass auch die Verbindlichkeiten entsprechend schneller entstehen
  • Anders gesagt: AI ist gut in lokaler Optimierung (Funktionen, Teilfunktionen), aber schwach bei globalem Design und Architekturentscheidungen
  • Je schneller implementiert wird, desto größer wird die Gefahr, dass sich falsche Entwürfe im gesamten System „verfestigen“
  • Für einmalige, kurzfristige Website-Projekte mag das kein Problem sein, für Systeme, die sich langfristig weiterentwickeln, ist es jedoch fatal
  • Das Muster technologischer Innovation bleibt unverändert bestehen
    • Systemadministratoren werden zu DevOps Engineers, Backend-Entwickler zu Cloud-Architekten
  • AI beschleunigt jedoch alles. Die Fähigkeit, die überlebt und sich weiterentwickelt, ist nicht das Schreiben von Code
  • Es ist vielmehr das Entwerfen von Systemen (Architecting systems). Genau das ist die eine Sache, die AI nicht leisten kann

Verwandte Beiträge

19 Kommentare

 
aer0700 2025-05-31

Ich arbeite eher konservativ, deshalb habe ich AI-Tools noch nie in wichtige Aufgaben eingeführt; ich habe im Grunde nur das, was ich früher bei Google oder Stack Overflow gesucht habe, dadurch ersetzt, dass ich Gemini oder ChatGPT frage. Ich nutze sie also schon, aber ...
Wenn ich AI bitte, etwas zu erstellen, lasse ich mir etwa auf Funktionsebene eine Funktion bauen, bei der aus bestimmten Inputs bestimmte Outputs kommen, und ich denke, es wäre okay, sie so zu verwenden, dass ich die Logik zum Prüfen, ob der von der AI-Funktion zurückgegebene Rückgabewert korrekt ist, selbst schreibe.
 
dbs0829 2025-05-30

Ich bin skeptisch bei der Frage, ob sich der gesamte Kontext vollständig in ein Format bringen lässt, das die AI gut verstehen kann. Menschen verfügen nicht nur über den offensichtlich notwendigen Kontext für die aktuelle Entwicklungsarbeit, sondern auch über latenten Kontext, den sie bei der Entwicklung mit berücksichtigen. Ich glaube noch nicht, dass Menschen diese Aspekte in gut aufbereiteter Form ausdrücken können. Ich denke, das ist weniger ein Problem der AI als vielmehr eine menschliche Grenze. Vor allem halte ich auch die Schreibfähigkeiten vieler Menschen heute nicht für besonders gut.
 
geirdev 2025-05-29

Beängstigend ist nicht dieser Moment jetzt, sondern eher der Trend ...
 
hey23 2025-05-29

Jetzt ist das völlig anders.

Die Zukunft, in der alle Berufe ersetzt werden, steht unmittelbar bevor, und Entwickler sind nur einer davon.

So etwas war noch nie ein Trend.
 
kaykim 2025-05-29

Es wird wohl nicht exakt dieselbe Veränderung sein.

Aber es ist eine Veränderung, die viele Berufe schon vor langer Zeit in der Moderne durchlaufen haben. Zum Beispiel die Veränderung, die Künstler mit dem Aufkommen der Fotografie und Handwerker mit automatisierten Fabriken erlebt haben. Beim Coden scheint es nicht anders zu sein.

Ich erwarte, dass am Ende mehr Ingenieure als heute gebraucht werden, wenn Innovation zum Alltag wird. Die Ansprüche der Nutzer werden steigen, und wir werden größere und komplexere Dinge bauen müssen. So ähnlich, wie es die Rote-Königin-Hypothese beschreibt.

Natürlich ist es sehr gut möglich, dass sich die Art der Arbeit verändert oder bestimmte Aufgaben verschwinden. So wie Setzer irgendwann unbemerkt verschwunden sind. In diesem Kontext wäre das Entwerfen von Systemen vermutlich eher eine Metapher oder ein Beispiel für die weiter gestiegene Abstraktionsebene.
 
pcj9024 2025-05-29

Ich denke, es liegt daran, dass alle Entwickler durch irgendetwas ersetzen wollen.
Offenbar gibt es ziemlich viele Menschen, die glauben, Entwickler würden viel Geld bekommen, obwohl sie gar nichts tun.
 
draupnir 2025-05-29

Ich denke, dass solche Inhalte unabhängig davon, ob Entwickler tatsächlich ersetzt werden, immer wieder die Runde machen, weil sie provokant sind.
Wenn solche Schlagzeilen besonders zugespitzt formuliert werden, sind sie von vornherein meist kaum das Ergebnis einer tieferen Auseinandersetzung damit, wie die Realität eigentlich aussieht oder wie sich „Ersetzung“ überhaupt definieren ließe.
Ein wirklich durchdachtes Ergebnis würde sich vielmehr damit befassen, wie weit AI oder andere Tools derzeit tatsächlich kommen und in welche Richtung sie sich weiterentwickeln. Auf solche wenig spannenden Titel klickt die breite Öffentlichkeit aber nicht.
 
fanotify 2025-05-29

Es gibt viele reißerische Schlagzeilen..
 
kimjoin2 2025-05-29

Ich denke, man muss es als eine schrittweise Ersetzung betrachten.
Tatsächlich sinkt die Zahl der Menschen, die für dasselbe Arbeitsergebnis eingesetzt werden müssen.

Wenn es selbst beim „Entwerfen eines Systems“ gelingt, etwas, das zuvor 10 Menschen gemacht haben, mit 8 Menschen + AI-Support zu lösen,
sind damit bereits 2 Menschen ersetzt worden.
 
callakrsos 2025-05-29

Auch aus Sicht des Systemdesigns
liegt es vielleicht daran, dass man das beim Prompting normalerweise ohne große Überlegung einfach hineingibt
 
ahwjdekf 2025-05-28

Ich denke, das Problem ist, dass man die Folgen von Vibe Coding nur schwer in den Griff bekommt.
 
tkddls8848 2025-05-30

Aus persönlicher Erfahrung stimme ich dieser Meinung zu. AI ist letztlich auch nur ein Tool, daher ist sie von 1 bis 99 wirklich schnell und gut, aber es fühlt sich immer so an, als würde das letzte 1 fehlen.
 
ethanhur 2025-05-28

Dem stimme ich zu, aber ich denke, der Kern ist weniger „Systemdesign“ als vielmehr „die Lösung komplexer Probleme durch Systemdesign“.

Ich glaube, dass einfache Aufgaben noch einfacher werden und schwierige Aufgaben weiterhin immer schwieriger.
 
ididid393939 2025-05-28

Haha, haha
 
GN⁺ 2025-05-28
Hacker-News-Meinungen

  • Jemand berichtet von jüngsten Freelance-Erfahrungen mit Aufgaben wie einmaligen Marketing-Landingpages: Besonders kontrollierende Kunden fügen am Ende immer seltsame Anforderungen hinzu, die AI nicht sauber lösen kann, sodass man selbst die Probleme ausbaden muss. Selbst wenn AI immer klüger wird, liegt das eigentliche Problem bei Software nicht in der Technik, sondern darin, dass Menschen fortlaufend „unnötige Komplexität“ erzeugen. Die stärkste Waffe von Entwicklern sei letztlich das Wort „Nein“. Die Sorge: Wenn AIs miteinander konkurrieren, wird am Ende immer mindestens eine wie ein Mensch „Ja“ sagen.

    • Software lässt sich zwar perfekt implementieren, aber wenn die Anforderungen selbst die technische Realität nicht widerspiegeln, entsteht am Ende nur Chaos — das klassische Konzept eines „Requirements-Bugs“. Mit realen Beschränkungen wie Formaten oder Support-Fragen (z. B. dass gif keine Transparenz unterstützt) kann AI inzwischen umgehen, aber absurde Wünsche wie „Mach das Logo zu einem Quadrat, bei dem jeder Punkt gleich weit vom Zentrum entfernt ist“ werden Menschen weiter produzieren. Der Tippfehler bei jpg wird nebenbei als Witz erwähnt.

    • Zwischen „Nein“ und „Ja“ gibt es aus Erfahrung 50 Graustufen von „Ist das wirklich gemeint?“. Jemand wollte etwa eine Webseite, auf der man „die Datenbank herunterladen“ kann, meinte in Wirklichkeit aber nur einen einfachen csv-Export. Das unterstreicht, wie wichtig Kontextinterpretation ist. Es bleibt fraglich, ob chatgpt solche Nuancen wirklich richtig erfasst.

    • „Ablehnen“ sei tatsächlich der schwierigste und anstrengendste Teil der Entwicklerarbeit. Viele Entwickler mögen diese Rolle eigentlich nicht oder halten sie nicht für ihre Aufgabe. Der tatsächliche Projekterfolg werde letztlich nicht durch Technik, sondern durch Mensch-zu-Mensch-Kommunikation mit Stakeholdern entschieden. Deshalb werde immer jemand gebraucht, der als Entwickler faktisch auch die Rolle eines PM übernimmt.

    • All das stehe bereits gut beschrieben in dem Buch „Peopleware“. Deshalb möge man auch den Gruß „Mögen all deine Probleme technischer Natur sein“. In der Praxis seien Probleme, die tatsächlich per Code gelöst werden, abgesehen von einigen Edge-Cases, fast nie besonders schwer gewesen.

    • Zustimmung, dass das ein guter Punkt ist, sowie die Einschätzung, dass AI potenziell immer besser darin werden könnte, Komplexität abzuschätzen und davor zu warnen. Als Vergleich dient Schach, wo AI Menschen schon heute bei Bewertung und Urteilsvermögen weit übertrifft. Dabei ist AI hier nicht auf LLMs beschränkt, auch wenn Fortschritte innerhalb dieser Kategorie anerkannt werden.

  • Widerspruch zur Aussage des Artikels, „AI könne keine Systeme architektieren“: Tatsächlich werde AI in diesem Bereich bereits zunehmend besser, und ständig würden die notwendigen Kriterien umdefiniert, wodurch die Debatte verschoben werde. AI könne aber nicht selbst entscheiden, was sie wollen soll, oder die Motivation des Nutzers übernehmen — auch wenn sie Ideen liefern kann. Irgendjemand müsse weiterhin selbst handeln und Probleme lösen, damit die Gesellschaft funktioniert; die Rolle des Entwicklers ändere sich nur, während Problemlösung menschliche Aufgabe bleibe.

    • Es hieß, die Bedeutung von „Entwickler“ verändere sich, doch in Wahrheit sei das Wesen der Tätigkeit von Anfang an gleich geblieben: Programmierung bedeutet im Kern, unklare Anforderungen in klaren Code zu übersetzen. Nur die Mittel hätten sich von Maschinencode und Lochkarten zu Frameworks, GUIs und visuellen Werkzeugen verändert. Dass man am Ende doch Code schreibt, sei vor allem wegen seiner Klarheit und Kommunikationskraft der effektivste Weg. LLMs seien gut im Nachahmen bestehender Lösungen, aber bei wirklich neuartigen Aufgaben oder Erklärungen in natürlicher Sprache schnell frustrierend. Der Markt befinde sich zwar im Zustand maximalen Hypes, doch letztlich wiederhole sich nur ein Muster, das bei jeder neuen Technologie teils ähnliche Verschiebungen auslöst.

    • Es gebe bereits beobachtbare Veränderungen, etwa dass Firmen wegen AI weniger Juniors einstellen. Wenn AI alles außer dem Architektieren übernimmt, führe das strukturell dennoch dazu, dass insgesamt weniger Ingenieure benötigt werden.

    • Klare Aussage, dass AI derzeit noch kein Architekturing kann. Architekturing und Planning seien nicht dasselbe: Planning bedeute, Beschränkungen, Lösungen und Ressourcen zuzuweisen und Prognosen zu erstellen. Bis AI das effektiv leisten kann, sei es noch weit. Echtes Architekturing umfasse kooperative und konkurrierende Entwürfe über mehrere Layer hinweg; macht AI in nur einem Layer einen Fehler, kann das ganze System entgleisen. Solche Systeme könnten nur Menschen sicher entwerfen und beaufsichtigen.

    • Mit genügend Kontext könne AI durchaus ziemlich gut verstehen, was gewünscht ist. Das führe zugleich zu Warnungen hinsichtlich Privatsphäre: Wenn Organisationen mächtige System- und Kontext-Erkennungstechnologien in der Hand haben, könne AI irgendwann sogar die Wünsche oder nächsten Handlungen einer Person „hinreichend gut“ vorhersagen — und genau das sei der beängstigendere Teil.

    • Ehrliche Einschätzung, dass AI derzeit nicht architektiert, sondern nur simuliert, und oft nicht einmal das Coden richtig beherrscht.

  • Die Annahme, Unternehmen würden Qualität priorisieren, sei an sich falsch. Firmen interessiere nur Profitabilität, und hohe Qualität werde nur geliefert, wenn Kunden sie verlangen. Ehrlich gesagt wollten Kunden oft ebenfalls eher das „beste“ Preis-Leistungs-Verhältnis als Qualität, kauften also das billigste Tool auf Amazon und produzierten wiederholt ähnlich schlampigen vibe code. Wirklich wichtig sei Qualität am Ende nur für Ingenieure; deshalb könne man Zukunftsprognosen, die aus einer Ingenieursperspektive Qualität in den Mittelpunkt stellen, ruhig ignorieren.

    • Gegenposition: Qualität kann sehr wohl ein Differenzierungsmerkmal sein. Als das iPhone erschien, gab es viele Konkurrenzprodukte mit weit mehr Funktionen, aber die deutlich flüssigere und elegantere UI dominierte am Ende den Markt.

    • Vorstellung von Fractal Audio als persönlichem Lieblingsbeispiel für ein qualitätsgetriebenes Unternehmen: eine kleine Firma, die hardwarebasierte Modeler für Gitarren baut, also Verstärker- und Pedalboard-Simulatoren. Hervorgehoben werden fortlaufend innovative Updates und die Besessenheit des CEO von der Qualität des analogen Modelings. Die Qualität sei deutlich besser als bei Großunternehmen. Positioniert werde das Produkt ohne Provisionen, Abos oder Promi-Marketing, nur über Direktvertrieb und kostenlose Algorithmus-Updates. Das sei ein lebendiges Beispiel dafür, wie man mit Qualität Marktanteile gewinnt — und dass nicht jedes Business zwangsläufig nur einen Niedrigpreis-Niedrigqualitäts-Wettbewerb führt.

    • Widerspruch gegen die Sicht, Kunden würden Qualität nicht schätzen: Wäre Qualität bedeutungslos, müssten alle Startups mit unfertigen und billigen Produkten riesige Umsätze und Erfolge erzielen.

    • Aufzählung erfolgreicher Softwareprodukte, die größtenteils sehr hohe Qualität hatten: Google, iPhone, Stripe, Notion und andere Produkte, die sich langfristig im Markt halten, seien gerade nicht langsam oder voller Bugs. Vielmehr habe Qualität zu ihrem Erfolg beigetragen. Man fragt, wo die Gegenbeispiele seien.

    • Sorge, dass Qualität bis zu einem gewissen Grad durch Modularisierung, Abos und Internetabhängigkeit verwässert werden kann, aber irgendwann eine Zukunft droht, in der alles abrupt zerfällt: Geräte werden zu Ziegelsteinen, selbst einfache Webseiten brauchen 12 Sekunden zum Laden, gesellschaftliche Infrastruktur und staatliche Systeme verschlingen Milliarden und bleiben instabil, und alltägliche Gespräche finden mit LLMs statt.

  • Rückblick auf frühere Organisationsrevolutionen: Das UML-basierte Modell, in dem „Architekten Spezifikationen erstellen und Entwickler nur die Lücken füllen“, habe überkomplexe Systeme erzeugt und Agilität zerstört. Das später aufgekommene „Agile“ sei ebenfalls missverstanden worden und habe zu Mikromanagement von Entwicklern, Misstrauen und unkreativen Organisationskulturen geführt. Erfolgreiche Teams hätten sich am Ende immer dadurch ausgezeichnet, dass Nicht-Entwickler echtes Interesse an der Arbeit der Entwickler zeigten und Probleme gemeinsam lösten — unabhängig von Tools oder Prozessen. Versuche, Komplexität zu senken, seien dagegen immer gescheitert.

  • Zur These „Architekturing ist die wertvollste Fähigkeit, aber der Teil, den AI nicht ersetzen kann“: Wenn man AI explizit bittet, eine Systemarchitektur zu entwerfen, liefert sie in vielen Fällen Ergebnisse, die besser sind als die von mindestens 30 % der Designer, denen man in der Realität begegnet ist. AI-Nutzer stellten solche Anfragen nur zu selten.

    • Aktuelle LLMs seien vor allem mit mittelmäßigen Best-Practice-Antworten trainiert. Deshalb liefern sie natürlicherweise bessere Resultate als etwa das untere Drittel menschlicher Designer — also vernünftige, commonsense-basierte „solide“ Entwürfe. In völlig neuen Feldern oder Branchen mit extremen Performance-Anforderungen bleibe aber menschliches Denken aus ersten Prinzipien wichtiger. Ein von LLMs entworfener DB-Kernel werde eher grundlegend als innovativ sein.

    • Kritik am Artikelstil selbst: Er wirke typisch mit ChatGPT geschrieben, mit kurzen Sätzen, Wiederholungen und übermäßigem Einsatz von Formulierungsgeräten wie „nicht X, sondern X+1“ oder „nicht X, sondern Anti-X“. Dass solche Texte auf HN so viele Upvotes bekommen, sei überraschend.

    • Deutung, dass der Autor aus Wunschdenken heraus glaube — oder sich einrede —, seine eigene Kernkompetenz, nämlich Architekturing, sei unveränderlich und unersetzbar. Hätte er andere Stärken, würde er wohl diese für unersetzbar halten.

    • Zusammenfassung: Das Wesen eines Architekten liegt darin, Anforderungen und Beschränkungen präzise zu verstehen und sie im System abzubilden — also gute Prompts formulieren zu können, Antworten sauber zu lesen und bei Bedarf entschieden zu widersprechen.

    • Viele der realen „Architekten“, denen man begegnet sei, hätten in Wahrheit zu wenig praktische IT-Infrastrukturkompetenz und gedacht, es reiche, Zeichenwerkzeuge oder Excel bedienen zu können. Sie wirken wie Manager, aber nur wenige beherrschen die eigentliche Kernaufgabe.

  • Die Meinung, dass Unternehmen, die sich „zu stark“ auf AI verlassen, sich gerade dadurch größeren Innovationsschocks aussetzen. Im AI-Zeitalter sei nicht Codeproduktion, sondern die Kontrolle der Codequalität der Kernpunkt, doch der Markt fokussiere sich übermäßig auf automatische Codeerzeugung. Erwähnt wird Satya Nadellas Aussage, „30 % des MS-Codes würden von AI geschrieben“, sowie die Entwicklung, dass es auf GitHub im Monatsdurchschnitt mehr als 20 Vorfälle gebe (Beleglink: githubstatus.com/history). Erwartet wird, dass Firmen, die nur auf Effizienz setzen, später den Preis in Form sinkender Qualität zahlen — besonders kleine und mittlere Unternehmen, nicht nur Konzerne vom Kaliber Microsoft.

    • Gegenrede: Eher die Firmen, die AI ignorieren, würden ins Hintertreffen geraten.

    • Verweis auf die These, dass Firmen, die AI übermäßig nutzen, langfristig große Kosten tragen werden, samt Artikelhinweis (AI: Accelerated Incompetence).

  • Volle Zustimmung zur Aussage „Code ist kein Asset, sondern eine Verbindlichkeit“. Das Ziel sei, mit möglichst wenig Code den Zweck zu erreichen. Da AI Code aber zu leicht massenhaft erzeugt, wachse die Code-Schuld eher noch stärker.

    • Geteilter Wikipedia-Link zum Produktivitätsparadox technischer Entwicklung, also dem Phänomen, dass steigende Produktivität durch höhere Systemkomplexität real wieder aufgehoben wird (Productivity paradox).

    • Vergleich, dass das heutige Zeitalter AI-generierten Codes an die Zeit erinnert, als Webseiten mit MS FrontPage gebaut wurden und html zu 90 % aus nutzlosem Code bestand — das „Zeitalter des Cruft“.

    • Gegenfrage, ob die Schuldperspektive nicht an Bedeutung verliert, wenn Code ohnehin leicht ersetzbar wird: Künftig könnte ein Programmierer bei Fehlern einfach AI bitten, den Code neu zu schreiben, wodurch die Last geringer würde.

    • Jemand sieht Code auch als kreative und künstlerische Ausdrucksform und schildert die Erfahrung, bei gut lesbarem und elegantem Code sofort Schönheit zu empfinden.

  • Verweis darauf, dass schon in der Frühzeit von FORTRAN (1954) mit dem Slogan geworben wurde, FORTRAN werde das Codieren und Debuggen selbst abschaffen (BackusEtAl-Preliminary Report).

    • Geteilt wird zudem die Anekdote der „Turkey illusion“ — also die Idee, dass etwas fortlaufend falsch liegen und dann plötzlich doch kippen kann, wie beim Truthahn, der jeden Tag gefüttert wird und deshalb fälschlich Sicherheit annimmt, bis er eines Tages geschlachtet wird (Turkey illusion).

  • Unter all diesen Debatten liege die Annahme, dass technischer Fortschritt bald an Grenzen stößt. Falls das falsch ist, könnte irgendwann durchaus der Tag kommen, an dem AI die gesamte Infrastruktur, Logs, Finanzen und Dokumentation versteht und damit sogar das Business ganzheitlich erfasst und entwirft. AI-Modelle wachsen weiter, werden leistungsfähiger und billiger, weshalb manche eher glauben, dass sie irgendwann tatsächlich bis zum Kern der Ersetzbarkeit vordringen.

    • Zugleich bestünde dann die Gefahr, dass von AI gebaute Systeme immer undurchsichtiger und „außerirdischer“ werden und das bisher menschenzentrierte Entwicklungsökosystem minimiert wird. Deshalb bliebe gesellschaftliche Kontrolle unerlässlich: Einige Experten müssten weiterhin die softwaretechnischen Wege der AI überwachen und steuern. Dieser Übergang werde lang und komplex.

  • Die Entlassung von Entwicklern sei nicht Folge technischen Fortschritts, sondern eine Reaktion auf Unsicherheit; Verweise auf Technik oder AI seien nur nachträgliche Rechtfertigungen. Vor fünf Jahren seien Unternehmen noch bereit gewesen, trotz hoher Kosten mehr Softwareingenieure einzustellen, um Produktivität zu steigern. Daraus folge, dass Kosten nicht die eigentliche Wurzel des Problems seien.

    • Gegenrede: „Diese zusätzliche Produktivität taucht in keinem Wirtschaftsindikator auf.“ Wenn die Produktivität real gestiegen wäre, müsste man das gesamtwirtschaftlich erkennen können — genau das sei aber nicht zu sehen.
 
click 2025-05-28

Ich suche jemanden, der mein AI-Vibe-Coding überprüft. Es ist eigentlich schon alles fertig, aber bitte behebt nur kurz die Fehler. Solche Outsourcing-Anfragen gibt es bereits, dabei ist es oft schneller, es einfach neu zu machen.
 
aer0700 2025-05-31

Das habe ich auch selbst erlebt, und es war schrecklich...
 
mentee313 2025-05-29

Ob das Leute sind, die es nicht wissen, oder denen es egal ist – jedenfalls gibt es viele davon ...
Bei Übersetzungen ist es genauso ... KI ist zwar durchaus brauchbar? Aber ich glaube, sie macht vielen Menschen das Leben schwer ...
Auf den ersten Blick wirkt es plausibel, aber aus Sicht derjenigen, die es korrigieren müssen, wird die Arbeit nur noch mehr zum Heulen ...
 
heim2 2025-05-28

Gänsehaut lolol