Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #653359

Re: US-Wirtschaftswachstum 4,3%

Show all headers | View raw

Am 25.12.25 um 09:28 schrieb Fidel Sebastián Hunrichse-Lara:
> Salve allerseits,
> 
> Michael Bode schrieb:
>> "Dr. Joachim Neudert" <neudert@5sl.org> writes:
>>> Am 24.12.25 um 14:41 schrieb Walter Brill:
>>>
>>>> Am Radio hiess es noch: "1 Programmierer + KI würden 10 IT-ler ersetzen".
>>>
>>> Eher 20 oder 30, meinst Du?
>>
>> So what? Vor 100 Jahren gab es im Deutschen Reich um die 22 Millionen
>> Erwerbstätige. Danach gab es wohl einige Rationalisierungswellen durch den
>> technischen Fortschritt. Das Ergebnis war eine Reduktion der Arbeitsplätze von
>> 22 Millionen auf 46 Millionen in 2025. Falls jemand damals wahlweise die
>> Massenarbeitslosigkeit oder das wir-werden-nicht-mehr-arbeite-müssen
>> prophezeit hat, lag er grandios daneben.
>>
> +--- <hier abknabbern> ---
> | Vor einigen Monaten habe ich an dieser Stelle beschrieben, wie
> | künstliche Intelligenz die Softwareentwicklung verändert und warum
> | bestimmte Tätigkeiten in diesem Berufsfeld mittelfristig wegfallen
> | werden. Die Reaktionen darauf waren gemischt: von Zustimmung über
> | Skepsis bis hin zu offener Ablehnung. Doch eine Frage tauchte in den
> | Kommentaren und in Gesprächen auf Konferenzen immer wieder auf: Wenn KI
> | tatsächlich Code schreiben kann, was bleibt dann für Menschen übrig?
> |
> | Diese Frage ist berechtigt. Sie verdient eine ehrliche Antwort. Und
> | diese Antwort führt uns zu einem Thema, das in der Debatte um KI in der
> | Softwareentwicklung oft zu kurz kommt: die Rolle der Architektur, des
> | Domänenwissens und der konzeptuellen Arbeit. Meine These lautet: Diese
> | Bereiche werden nicht weniger wichtig, sondern wichtiger. Die
> | Wertschöpfung verschiebt sich von der Umsetzung zur Konzeption. Und
> | genau das hat weitreichende Konsequenzen für alle, die in diesem Feld
> | arbeiten, von der Entwicklerin am Anfang ihrer Karriere bis zur
> | Führungskraft, die Investitionsentscheidungen trifft.
> |
> | *Was KI heute kann und was nicht*
> |
> | Beginnen wir mit einer ehrlichen Bestandsaufnahme dessen, was moderne
> | KI-Systeme im Bereich der Softwareentwicklung leisten. Die Fortschritte
> | der letzten zwei Jahre sind beeindruckend, und wer sie leugnet, macht
> | sich etwas vor. LLMs (Large Language Models) können heute Funktionen,
> | Klassen und ganze Module auf Zuruf generieren. Sie erkennen Muster in
> | bestehendem Code und wenden Best Practices an, ohne dass man sie
> | explizit darauf hinweisen muss. Sie schreiben Tests, die tatsächlich
> | sinnvolle Randfälle abdecken. Sie erstellen Dokumentation, die oft
> | besser ist als das, was überarbeitete Entwickler um 23 Uhr produzieren.
> | Sie schlagen Refactorings vor, die technische Schulden reduzieren.
> |
> | Wer heute mit GitHub Copilot, Claude, ChatGPT oder ähnlichen Werkzeugen
> | arbeitet, erlebt täglich, wie viel Routinearbeit diese Systeme abnehmen
> | können. Eine REST-API mit Standard-CRUD-Operationen, die früher einen
> | halben Tag gekostet hätte, entsteht in dreißig Minuten. Ein
> | Datenmigrationsskript, für das man früher Stack Overflow durchsucht
> | hätte, generiert sich fast von selbst. Das ist real, das ist nützlich,
> | und es wird noch besser werden.
> |
> | Das ist die beeindruckende Seite. Und sie wird noch beeindruckender
> | werden. Die Modelle werden besser, die Integration in
> | Entwicklungsumgebungen wird nahtloser, die Anwendungsfälle werden
> | breiter. Wer glaubt, dass wir den Höhepunkt dieser Entwicklung bereits
> | erreicht haben, unterschätzt das Tempo des Fortschritts.
> |
> | Doch es gibt auch blinde Flecken, die bei aller Euphorie nicht übersehen
> | werden dürfen. Und diese Flecken werden nicht kleiner, wenn die Modelle
> | größer werden – denn sie sind struktureller Natur.
> |
> | KI-Systeme arbeiten auf der Ebene von Syntax und Mustern. Sie haben
> | gelernt, welche Codezeilen typischerweise auf welche anderen folgen. Sie
> | wissen, wie ein Repository-Pattern in C# aussieht, weil sie Zehntausende
> | davon gesehen haben. Aber sie wissen nicht, warum ein bestimmtes System
> | dieses Pattern verwenden sollte, oder ob es überhaupt das Richtige ist.
> | Sie kennen die Form, nicht die Bedeutung.
> |
> | Das zeigt sich besonders deutlich bei Halluzinationen. Ein LLM kann eine
> | Funktion generieren, die syntaktisch korrekt ist, alle Konventionen
> | einhält und auf den ersten Blick vernünftig aussieht, aber inhaltlich
> | falsch ist. Nicht, weil das Modell lügt, sondern weil es gar nicht weiß,
> | was „richtig“ in einem bestimmten fachlichen Kontext bedeutet. Es
> | optimiert Wahrscheinlichkeiten für Zeichenfolgen, nicht für
> | Geschäftslogik. Es produziert, was statistisch plausibel ist, nicht was
> | sachlich korrekt ist.
> |
> | Hinzu kommt das Problem des lokalen Optimums: KI optimiert das
> | Offensichtliche. Wenn Sie nach einer Lösung für ein Problem fragen,
> | bekommen Sie die wahrscheinlichste Lösung basierend auf den
> | Trainingsdaten. Das ist oft eine gute Lösung. Aber es ist selten die
> | beste Lösung für Ihren spezifischen Kontext, denn den kennt das Modell
> | nicht. Es weiß nicht, dass Ihr Team nur aus zwei Personen besteht und
> | keine Zeit für eine Microservices-Architektur hat. Es weiß nicht, dass
> | Ihre Datenbank-Performance der eigentliche Engpass ist. Es weiß nicht,
> | dass der Fachbereich nächstes Jahr alles umwerfen wird.
> |
> | Die Schlussfolgerung daraus ist einfach: KI ist ein hervorragendes
> | Werkzeug für die Umsetzung. Aber das setzt voraus, dass jemand weiß, was
> | umgesetzt werden soll. Die entscheidende Frage verschiebt sich damit von
> | „Wie schreibe ich diesen Code?“ zu „Welchen Code sollte ich überhaupt
> | schreiben?“. Und diese Frage kann KI nicht beantworten.
> |
> | *Die Rolle des Architekten neu betrachtet*
> |
> | Damit sind wir bei der Architektur. Und hier lohnt es sich, zunächst zu
> | klären, was dieser Begriff eigentlich bedeutet, denn er wird (zu) oft
> | missverstanden.
> |
> | Architektur ist nicht das Diagramm mit den großen Boxen und Pfeilen, das
> | in jeder Projektdokumentation auftaucht und nach dem Kick-Off nie wieder
> | angeschaut wird. Architektur ist auch nicht die Entscheidung für ein
> | bestimmtes Framework oder eine bestimmte Cloud-Plattform. Architektur
> | ist vielmehr die Summe der Entscheidungen, die schwer zu ändern sind. Es
> | sind die Entscheidungen über Struktur, über Kommunikationswege, über
> | Grenzen zwischen Komponenten, über Verantwortlichkeiten. Es sind die
> | Entscheidungen, bei denen eine Änderung später teuer wird, sei es
> | technisch, organisatorisch oder beides.
> |
> | Diese Entscheidungen sind aus mehreren Gründen nicht automatisierbar.
> | Und diese Gründe werden auch nicht verschwinden, wenn die Modelle größer
> | werden.
> |
> | Erstens erfordern Architekturentscheidungen Kontextwissen, das nicht im
> | Code steht. Um zu entscheiden, ob ein System als Monolith oder als
> | verteiltes System gebaut werden sollte, muss man die Organisation
> | kennen, die es betreibt. Wie groß ist das Team? Wie sind die
> | Deployment-Zyklen? Welche Teile des Systems ändern sich häufig, welche
> | selten? Wie sieht die bestehende Infrastruktur aus? Welche Kompetenzen
> | sind vorhanden, welche fehlen? Diese Informationen stehen in keinem
> | Repository. Sie existieren in Köpfen, in Gesprächen, in der gelebten
> | Praxis einer Organisation.
> |
> | Zweitens erfordern Architekturentscheidungen Abwägungen zwischen
> | konkurrierenden Zielen. Soll das System maximal performant sein oder
> | maximal wartbar? Soll es schnell ausgeliefert werden oder langfristig
> | stabil sein? Soll es flexibel erweiterbar sein oder einfach zu
> | verstehen? Diese Trade-offs haben keine objektiv richtige Antwort. Sie
> | hängen von Prioritäten ab, die Menschen setzen müssen, basierend auf
> | Geschäftszielen, Ressourcen und Risikobereitschaft.
> |
> | Drittens erfordern sie Voraussicht. Was könnte sich in zwei Jahren
> | ändern? Welche Annahmen, die wir heute treffen, werden sich als falsch
> | herausstellen? Welche Teile des Systems müssen flexibel bleiben, welche
> | dürfen in Beton gegossen werden? Wo lohnt sich Investition in
> | Abstraktion, wo ist sie Over-Engineering? Diese Fragen erfordern
> | Erfahrung, Intuition und die Fähigkeit, mit Unsicherheit umzugehen. Sie
> | erfordern das, was erfahrene Architekten „Bauchgefühl“ nennen: eine
> | internalisierte Mustererkennung, die sich nicht in Regeln fassen lässt.
> |
> | Viertens erfordern sie Dialog. Architektur entsteht nicht im stillen
> | Kämmerlein. Sie entsteht im Gespräch mit Fachbereichen, mit
> | Stakeholdern, mit dem Entwicklungsteam. Sie erfordert die Fähigkeit,
> | zuzuhören, nachzufragen, zwischen verschiedenen Welten zu übersetzen.
> | Ein Architekt muss verstehen, was der Vertrieb meint, wenn er von
> | „flexiblen Rabatten“ spricht, und das in eine technische Struktur
> | übersetzen. Diese Übersetzungsleistung ist zutiefst menschlich.
> |
> | Es gibt noch einen fünften Punkt, der oft übersehen wird:
> | Architekturentscheidungen sind soziale Akte. Sie formen Teams, sie
> | definieren Schnittstellen zwischen Menschen, sie beeinflussen, wer mit
> | wem zusammenarbeiten muss. Die Entscheidung, ein System in drei Services
> | aufzuteilen, ist nicht nur eine technische Entscheidung. Sie ist auch
> | eine Entscheidung darüber, wie die Arbeit verteilt wird, welche Teams
> | entstehen, wie Kommunikation fließt. Diese organisatorischen
> | Implikationen zu verstehen und zu gestalten, erfordert
> | Einfühlungsvermögen und politisches Gespür. All das sind Eigenschaften,
> | die kein Sprachmodell besitzt.
> |
> | Ein LLM kann das Observer Pattern implementieren. Aber es kann nicht
> | entscheiden, wann dieses Pattern die richtige Wahl ist. Es kann
> | Microservices generieren. Aber es kann nicht beurteilen, ob
> | Microservices für eine bestimmte Organisation überhaupt sinnvoll sind,
> | oder ob sie die Komplexität nur verlagern, statt sie zu reduzieren. Die
> | wertvollste Architekturentscheidung ist oft die Entscheidung, etwas
> | nicht zu bauen. Und genau diese Entscheidung liegt außerhalb dessen, was
> | ein generatives Modell leisten kann.
> |
> | *Kein LLM kennt die Domäne*
> |
> | Das führt uns zum zweiten Bereich, der durch KI nicht ersetzt wird: das
> | Domänenwissen.
> |
> | Jede Software existiert, um ein Problem in einer bestimmten Domäne zu
> | lösen. Ein Bestellsystem löst Probleme im E-Commerce. Eine Patientenakte
> | löst Probleme im Gesundheitswesen. Eine Handelssoftware löst Probleme an
> | den Finanzmärkten. Eine Produktionssteuerung löst Probleme in der
> | Fertigung. Die Software ist nie Selbstzweck. Sie ist immer Mittel zu
> | einem fachlichen Zweck. Diese Erkenntnis klingt banal, wird aber in der
> | Praxis erstaunlich oft vergessen.
> |
> | Um gute Software zu bauen, muss man diesen Zweck verstehen. Man muss die
> | Domäne verstehen. Und genau hier stößt KI an eine fundamentale Grenze,
> | die sich nicht durch größere Modelle oder bessere Trainingsdaten
> | überwinden lässt.
> |
> | LLMs wurden auf öffentlich verfügbarem Text trainiert. Sie kennen, was
> | über Domänen geschrieben wurde. Sie kennen die allgemeinen Konzepte von
> | Bestellungen, Patienten, Handelspositionen, Fertigungsaufträgen. Aber
> | sie kennen nicht die spezifische Logik eines bestimmten Unternehmens.
> | Sie wissen nicht, dass in Ihrem Unternehmen eine „Bestellung“ drei
> | verschiedene Zustände haben kann, die nirgendwo dokumentiert sind, weil
> | das historisch so gewachsen ist. Sie wissen nicht, dass der Begriff
> | „Kunde“ in der Buchhaltung etwas anderes bedeutet als im Vertrieb. Sie
> | wissen nicht, dass bestimmte Produkte aus regulatorischen Gründen anders
> | behandelt werden müssen als andere.
> |
> | Die richtige Frage ist nicht „Wie baue ich ein Bestellsystem?“. Die
> | richtige Frage ist: „Was bedeutet eine Bestellung in diesem Geschäft?
> | Wann beginnt sie? Wann endet sie? Was passiert, wenn sie storniert wird?
> | Was passiert, wenn sie teilweise geliefert wird? Wer darf sie ändern,
> | und unter welchen Bedingungen? Welche Ereignisse in der Domäne sind
> | relevant, welche nicht?“
> |
> | Diese Fragen lassen sich nicht durch Prompt-Engineering beantworten. Sie
> | erfordern Gespräche mit Fachexperten. Sie erfordern das geduldige
> | Herausarbeiten von implizitem Wissen, das oft nicht einmal den
> | Fachleuten selbst bewusst ist. Es ist Wissen, das in Routinen steckt, in
> | Ausnahmen. In den Geschichten, die erzählt werden, wenn etwas
> | schiefgelaufen ist. Dieses Wissen sichtbar zu machen, erfordert Methoden
> | wie Event-Storming oder Collaborative Modeling, bei denen Menschen
> | gemeinsam an einem Whiteboard stehen und rekonstruieren, was in ihrer
> | Domäne eigentlich passiert.
> |
> | Das ist zutiefst menschliche Arbeit. Es ist Arbeit, die Geduld
> | erfordert, die Ambiguitätstoleranz verlangt, die manchmal frustrierend
> | ist, weil die Antworten nicht sofort klar sind. Es ist Arbeit, die man
> | nicht beschleunigen kann, indem man schneller tippt. Und genau deshalb
> | wird sie durch KI nicht obsolet, sondern im Gegenteil: Je mehr die
> | Umsetzung automatisiert wird, desto wichtiger wird es, das Richtige
> | umzusetzen. Und um das Richtige zu identifizieren, benötigt man
> | Domänenwissen.
> |
> | Ich erlebe in meiner Beratungsarbeit regelmäßig, dass Projekte
> | scheitern, nicht weil die Technik schlecht wäre, sondern weil niemand
> | die richtigen Fragen gestellt hat. Das neue System wurde gebaut, es
> | funktioniert technisch einwandfrei – aber es bildet die falschen
> | Prozesse ab, verwendet die falschen Begriffe, macht die falschen
> | Annahmen. Das sind keine Fehler, die KI verhindern wird. Es sind Fehler,
> | die entstehen, wenn man die Domäne nicht versteht. Und sie werden
> | häufiger werden, wenn die Illusion entsteht, dass schnelle
> | Codegenerierung auch schnelles Verstehen bedeutet.
> |
> | *Die neue Arbeitsteilung*
> |
> | Was bedeutet das alles für die Praxis? Wie verändert sich die
> | Arbeitsteilung in der Softwareentwicklung? Diese Fragen höre ich oft,
> | und die Antworten sind weniger düster, als manche befürchten.
> | Vorausgesetzt, man versteht die Richtung der Veränderung.
> |
> | Zunächst das Offensichtliche: Routineaufgaben werden schneller und
> | günstiger. Code, der früher Stunden gebraucht hat, entsteht heute in
> | Minuten. Die Einstiegshürde „etwas zu bauen“ sinkt dramatisch. Das ist
> | grundsätzlich positiv. Es demokratisiert den Zugang zur
> | Softwareentwicklung und ermöglicht schnellere Experimente. Ideen können
> | ausprobiert werden, bevor man sich auf eine teure Implementierung
> | festlegt.
> |
> | Aber es birgt auch eine Gefahr: die Gefahr, das Falsche sehr effizient
> | zu bauen. Wenn es einfach wird, Code zu generieren, besteht die
> | Versuchung, sofort loszulegen, ohne vorher gründlich nachzudenken. Das
> | Ergebnis sind Systeme, die technisch funktionieren, aber am eigentlichen
> | Bedarf vorbeigehen. Oder Systeme, die kurzfristig funktionieren, aber
> | langfristig nicht wartbar sind. Die Geschwindigkeit der Codegenerierung
> | kann eine trügerische Sicherheit vermitteln. Man fühlt sich produktiv,
> | obwohl man eigentlich nur schneller in die falsche Richtung läuft.
> |
> | Bestimmte Fähigkeiten werden in dieser neuen Welt wichtiger:
> |
> | • Abstraktionsfähigkeit: die Fähigkeit, das Wesentliche vom
> |   Unwesentlichen zu trennen, komplexe Sachverhalte auf ihre Kernstruktur
> |   zu reduzieren.
> |
> | • Kommunikationsfähigkeit: die Fähigkeit, zwischen Fachbereich und
> |   Technik zu übersetzen, Anforderungen zu verstehen und technische
> |   Implikationen zu erklären.
> |
> | • Urteilsvermögen: die Fähigkeit zu entscheiden, wann KI hilft und wann
> |   sie schadet, wann man ihrem Output vertrauen kann und wann eine
> |   manuelle Prüfung nötig ist.
> |
> | • Systemdenken: die Fähigkeit, Wechselwirkungen zu verstehen, nicht nur
> |   einzelne Komponenten isoliert zu betrachten.
> |
> | Andere Fähigkeiten verlieren an Bedeutung. APIs und Syntax auswendig zu
> | kennen, wird weniger wertvoll, wenn man jederzeit nachfragen kann.
> | Boilerplate-Code zu schreiben war nie besonders erfüllend und wird
> | künftig noch weniger nötig sein. Routine-Debugging bei Standardproblemen
> | lässt sich zunehmend automatisieren. Das ist kein Verlust, sondern eine
> | Befreiung, vorausgesetzt, man nutzt die gewonnene Zeit für wertvollere
> | Tätigkeiten.
> |
> | Eine besondere Warnung möchte ich an dieser Stelle aussprechen: Hüten
> | Sie sich vor der Prompt-Engineering-Illusion. Die Vorstellung, dass man
> | nur „die richtige Frage stellen“ müsse, um von KI perfekte Ergebnisse zu
> | bekommen, ist gefährlich. Ja, gute Prompts führen zu besseren
> | Ergebnissen. Aber wer die richtige Frage nicht kennt, bekommt
> | bestenfalls plausible Antworten auf die falsche Frage. Prompt
> | Engineering ersetzt kein Domänenwissen. Es setzt es voraus. Wer nicht
> | versteht, was gebaut werden soll, kann auch nicht sinnvoll danach fragen.
> |
> | *Was jetzt zu tun ist*
> |
> | Lassen Sie mich mit konkreten Empfehlungen schließen.
> |
> | Für Entwicklerinnen und Entwickler: Nutzen Sie KI als Werkzeug, nicht
> | als Ersatz für das Denken. Lassen Sie sich Routinearbeit abnehmen, aber
> | geben Sie die Verantwortung für das Ergebnis nicht ab. Prüfen Sie
> | generierten Code kritisch, verstehen Sie ihn, bevor Sie ihn committen.
> | Investieren Sie in Architektur und Domänenwissen, nicht nur in
> | Technologie. Lernen Sie, mit Fachbereichen auf Augenhöhe zu sprechen.
> | Kultivieren Sie die Fähigkeit, Anforderungen zu hinterfragen, statt sie
> | blind umzusetzen. Die Frage „Warum benötigen wir das?“ ist wertvoller
> | als die Frage „Wie bauen wir das?“.
> |
> | Für Führungskräfte und Unternehmen: Widerstehen Sie der Versuchung,
> | „alles mit KI zu machen“. Die Technologie ist mächtig, aber sie ist kein
> | Ersatz für Nachdenken. Erkennen Sie Architektur- und Domänenkompetenz
> | als strategisches Asset. Diese Fähigkeiten lassen sich nicht kurzfristig
> | einkaufen oder durch Tools ersetzen. Sie entstehen über Jahre, durch
> | Erfahrung, durch Fehler, durch intensive Beschäftigung mit einer Domäne.
> | Investieren Sie in Menschen, die verstehen, nicht nur in Tools, die
> | generieren. Und stellen Sie sich regelmäßig die Frage: Wissen wir
> | eigentlich, was wir bauen wollen? Wenn die Antwort unklar ist, wird auch
> | die beste KI nicht helfen.
> |
> | Für die Ausbildung: Der Fokus auf Syntax und Programmiersprachen wird
> | weniger wichtig. Konzepte, Modellierung und Abstraktion werden
> | wichtiger. Interdisziplinäres Denken sollte gefördert werden, also die
> | Fähigkeit, technische und fachliche Perspektiven zu verbinden. Und vor
> | allem: die Fähigkeit, mit Unsicherheit umzugehen. Denn in einer Welt, in
> | der sich Technologie schnell verändert, ist die Bereitschaft zum
> | lebenslangen Lernen wichtiger als jedes spezifische Wissen. Die
> | Absolventen von heute werden in ihrer Karriere Technologien nutzen, die
> | heute noch nicht existieren. Was bleibt, sind die Grundlagen: logisches
> | Denken, Abstraktion, Kommunikation.
> |
> | *Der Mensch als Bedeutungsgeber*
> |
> | Die Entwicklung, die wir gerade erleben, ist keine Bedrohung, sondern
> | eine Verschiebung. Dabei wandert die Wertschöpfung von der Umsetzung zur
> | Konzeption. Die Frage ist nicht mehr „Können wir das bauen?“, denn das
> | können wir fast immer, und es wird immer einfacher. Die Frage ist:
> | „Sollten wir das bauen? Und wenn ja, was genau? Für wen? Mit welchem
> | Ziel?“
> |
> | Diese Fragen zu beantworten, erfordert etwas, das KI nicht hat: ein
> | Verständnis von Bedeutung. Software ist nicht nur Code. Sie ist ein
> | Ausdruck von Geschäftslogik, von Prozessen, von menschlichen
> | Bedürfnissen. Sie bildet ab, wie Menschen arbeiten, wie sie
> | kommunizieren, wie sie Entscheidungen treffen. Den Sinn hinter dem Code
> | zu verstehen und zu gestalten, das bleibt menschliche Arbeit.
> |
> | Architekten, Domänenexperten und konzeptuelle Denker werden in dieser
> | neuen Welt nicht weniger gebraucht. Sie werden mehr gebraucht. Denn je
> | leichter es wird, irgendetwas zu bauen, desto wichtiger wird es, das
> | Richtige zu bauen. Die Fähigkeit, das Richtige zu identifizieren, wird
> | zur Kernkompetenz. Und diese Kompetenz ist nicht angeboren. Sie lässt
> | sich entwickeln. Wer heute anfängt, in Architekturdenken und
> | Domänenverständnis zu investieren, wird in fünf Jahren einen erheblichen
> | Vorsprung denen gegenüber haben, die nur auf das nächste Tool warten.
> |
> | Software war nie Selbstzweck. Sie war immer Mittel zu einem Zweck. Und
> | den Zweck definieren Menschen. Das war vor dreißig Jahren so, das ist
> | heute so, und das wird auch in zehn Jahren noch so sein – egal, wie
> | leistungsfähig die Modelle dann geworden sind.
> |
> | Die gute Nachricht ist: Wer diese Verschiebung versteht und sich darauf
> | einstellt, hat eine glänzende Zukunft.
> +--- </hier abknabbern> ---
> 
> ©<https://www.heise.de/blog/KI-macht-Entwickler-ersetzbar-aber-gute-Architekten-nicht-11097760.html?seite=all>
> 
> 	M.f.G.
> 

Alles nur klassische Rückzugsgefechte. Wetten, während dieser Artikel 
ersonnen, geschrieben, redigiert und publiziert wurde, ist schon wieder 
einer der zitierten Bausteine an die KI gefallen?
-- 
Ammersee
Meer braucht's ned

Back to ger.ct | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

US-Wirtschaftswachstum 4,3% "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-23 16:26 +0100
  US-Wirtschaftswachstum (was: US-Wirtschaftswachstum 4,3%) ram@zedat.fu-berlin.de (Stefan Ram) - 2025-12-23 16:00 +0000
    Re: US-Wirtschaftswachstum "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-23 17:21 +0100
      Re: US-Wirtschaftswachstum "Wendelin Uez" <wuez@online.de> - 2025-12-24 12:46 +0100
    Re: US-Wirtschaftswachstum Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-23 17:29 +0100
    Re: US-Wirtschaftswachstum "DER GELAeUTERTE" <dergelaeuterte@web.de> - 2025-12-23 19:46 +0100
  Re: US-Wirtschaftswachstum 4,3% Ruediger Lahl <ruediger.lahl@gmx.de> - 2025-12-23 20:04 +0100
    Re: US-Wirtschaftswachstum 4,3% "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-23 20:31 +0100
      Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-23 21:21 +0100
        Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2025-12-24 10:15 +0100
          Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-24 10:34 +0100
      Re: US-Wirtschaftswachstum 4,3% Ruediger Lahl <ruediger.lahl@gmx.de> - 2025-12-23 22:36 +0100
        Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-23 22:58 +0100
        Re: US-Wirtschaftswachstum 4,3% Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2025-12-27 10:32 +0000
      Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-24 09:52 +0100
        Re: US-Wirtschaftswachstum 4,3% Walter Brill <WalterBrill@t-online.de> - 2025-12-24 14:41 +0100
          Re: US-Wirtschaftswachstum 4,3% "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-24 14:50 +0100
            Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-24 15:41 +0100
              Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-24 15:45 +0100
              Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-25 09:28 +0100
                Re: US-Wirtschaftswachstum 4,3% "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-25 10:08 +0100
                Re: US-Wirtschaftswachstum 4,3% Bernd Ohm <invalid@invalid.invalid> - 2025-12-25 10:59 +0100
                Re: US-Wirtschaftswachstum 4,3% Dr. Joachim Neudert <neudert@5sl.org> - 2025-12-25 10:22 +0000
                Re: US-Wirtschaftswachstum 4,3% Bernd Ohm <invalid@invalid.invalid> - 2025-12-25 11:48 +0100
                Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-25 14:52 +0100
                Re: US-Wirtschaftswachstum 4,3% Lars Gebauer <lgebauer@live.de> - 2025-12-25 12:46 +0100
                Re: US-Wirtschaftswachstum 4,3% Ruediger Lahl <ruediger.lahl@gmx.de> - 2025-12-26 09:16 +0000
                Re: US-Wirtschaftswachstum 4,3% Bernd Ohm <invalid@invalid.invalid> - 2025-12-26 12:21 +0100
                Re: US-Wirtschaftswachstum 4,3% Carlo XYZ <carloxyz@invalid.invalid> - 2025-12-26 12:30 +0100
                Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-26 16:44 +0100
                Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-25 11:48 +0100
            Re: US-Wirtschaftswachstum 4,3% Walter Brill <WalterBrill@t-online.de> - 2025-12-25 12:47 +0100
              Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-25 12:54 +0100
              Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-25 14:55 +0100
                Entwickler und KI (was: US-Wirtschaftswachstum 4,3%) Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2025-12-26 17:05 +0100
                Re: Entwickler und KI (was: US-Wirtschaftswachstum 4,3%) Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-26 18:55 +0100
      Re: US-Wirtschaftswachstum 4,3% Andreas Bockelmann <xotzil@gmx.de> - 2025-12-30 13:54 +0100
    Re: US-Wirtschaftswachstum 4,3% Andreas Bockelmann <xotzil@gmx.de> - 2025-12-30 13:46 +0100
      Re: US-Wirtschaftswachstum 4,3% Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-12-30 14:58 +0100
        Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-30 15:14 +0100
          Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-30 15:16 +0100
          Re: US-Wirtschaftswachstum 4,3% Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-12-30 15:29 +0100
        Re: US-Wirtschaftswachstum 4,3% Andreas Bockelmann <xotzil@gmx.de> - 2025-12-30 19:27 +0100
          Re: US-Wirtschaftswachstum 4,3% Dr. Joachim Neudert <neudert@5sl.org> - 2025-12-30 19:17 +0000
            Re: US-Wirtschaftswachstum 4,3% Andreas Bockelmann <xotzil@gmx.de> - 2025-12-30 20:28 +0100
              Re: US-Wirtschaftswachstum 4,3% Dr. Joachim Neudert <neudert@5sl.org> - 2025-12-30 19:51 +0000
                Re: US-Wirtschaftswachstum 4,3% Andreas Bockelmann <xotzil@gmx.de> - 2025-12-31 09:19 +0100
  Re: US-Wirtschaftswachstum 4,3% Lothar Kimmeringer <news201705@kimmeringer.de> - 2025-12-24 19:20 +0100
    Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-25 09:27 +0100
      Re: US-Wirtschaftswachstum 4,3% "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-25 10:17 +0100
        Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-25 10:26 +0100
        Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-25 12:01 +0100
        Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-25 15:00 +0100
    Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-25 14:56 +0100
    Re: US-Wirtschaftswachstum 4,3% Alfred <Dez.2025@anon.invalid> - 2025-12-25 20:57 +0100
  Re: US-Wirtschaftswachstum 4,3% Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-12-25 18:12 +0100

csiph-web