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

Groups > ger.ct > #653296 > unrolled thread

US-Wirtschaftswachstum 4,3%

Back to article view | Back to ger.ct

Contents

  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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#653359

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

[toc] | [prev] | [next] | [standalone]

#653366

Am 25.12.2025 um 10:08 schrieb Dr. Joachim Neudert:

[Ein ellenlangen Fullquote]

Was soll das?

-- 
bis denn, BEN

[toc] | [prev] | [next] | [standalone]

#653368

Bernd Ohm <invalid@invalid.invalid> wrote:
> Am 25.12.2025 um 10:08 schrieb Dr. Joachim Neudert:
> 
> [Ein ellenlangen Fullquote]
> 
> Was soll das?
> 

Damit man die lange Liste der zitierten Bausteine überfliegen kann und sich
überlegen kann, welche Jobs davon die KI seither auch schon beherrscht…

-- 
please forgive my iPhone typos

[toc] | [prev] | [next] | [standalone]

#653371

Am 25.12.2025 um 11:22 schrieb Dr. Joachim Neudert:

> Damit man die lange Liste der zitierten Bausteine überfliegen kann und sich
> überlegen kann, welche Jobs davon die KI seither auch schon beherrscht…

Dunkel ist deiner Rede Sinn. :-(

-- 
bis denn, BEN

[toc] | [prev] | [next] | [standalone]

#653379

Bernd Ohm <invalid@invalid.invalid> wrote:

> Am 25.12.2025 um 11:22 schrieb Dr. Joachim Neudert:
> 
> > Damit man die lange Liste der zitierten Bausteine überfliegen kann
> > und sich überlegen kann, welche Jobs davon die KI seither auch
> > schon beherrscht…  
> 
> Dunkel ist deiner Rede Sinn. :-(

Im Westen nix neues ...

-- 
LIBERTÉ ÉGALITÉ FCKAFD

[toc] | [prev] | [next] | [standalone]

#653373

Am 25.12.25 um 11:22 schrieb Dr. Joachim Neudert:
> Bernd Ohm <invalid@invalid.invalid> wrote:
>> Am 25.12.2025 um 10:08 schrieb Dr. Joachim Neudert:
>> [Ein ellenlangen Fullquote]
>>
>> Was soll das?
> 
> Damit man die lange Liste der zitierten Bausteine überfliegen kann und sich
> überlegen kann, welche Jobs davon die KI seither auch schon beherrscht…

Meine Mathe-Kenntnisse sind ja eher so oberflächlich (wie alle anderen 
übrigens auch) und das hier übersteigt meine Möglichkeiten gleich mal um 
etliche Größenordnungen:

| Extremal descendant integrals on moduli spaces of curves: An
| inequality discovered and proved in collaboration with AI

https://arxiv.org/abs/2512.14575

Aber wer von euch kann das nachollziehen - und hätte es auch gekonnt?

-- 
"Only the tiniest fraction of mankind want freedom. All the rest want 
someone to tell them they are free."
               —— Irving Layton

[toc] | [prev] | [next] | [standalone]

#653403

Bernd Ohm <invalid@invalid.invalid> wrote:

> Am 25.12.2025 um 10:08 schrieb Dr. Joachim Neudert:
> 
> [Ein ellenlangen Fullquote]
> 
> Was soll das?

Lass es dir (Achtung OnT) von der KI deines geringsten Misstrauens knackig
zusammenfassen.
Ich persönlich lese Fidels c&p erst gar nicht.

-- 
bis denne

[toc] | [prev] | [next] | [standalone]

#653406

Am 26.12.2025 um 10:16 schrieb Ruediger Lahl:

> Ich persönlich lese Fidels c&p erst gar nicht.

ACK.
Es mag ja manchmal sinnvoll sein wenn es hinter
einer Paywall ist.
Allerdings sollten Paywalls für hiesige Regulars
kein soooo großes Problem sein. ;-)

Ich verstehe nur nicht, warum der iDoc grundsätzlich
Fullquotes in seine Posts setzt.
Sein Thunderbird könnte doch so einfach geeignet konfiguriert
werden.

-- 
bis denn, BEN

[toc] | [prev] | [next] | [standalone]

#653408

Bernd Ohm wrote on 26.12.25 12:21:
> Am 26.12.2025 um 10:16 schrieb Ruediger Lahl:
> 
>> Ich persönlich lese Fidels c&p erst gar nicht.
> 
> ACK.

NAK.

> Es mag ja manchmal sinnvoll sein wenn es hinter
> einer Paywall ist.
> Allerdings sollten Paywalls für hiesige Regulars
> kein soooo großes Problem sein. ;-)

Das gehört sich nicht.

> Ich verstehe nur nicht, warum der iDoc grundsätzlich
> Fullquotes in seine Posts setzt.

Tut er nicht, und diesmal ging's wimre um Bausteine.

> Sein Thunderbird könnte doch so einfach geeignet konfiguriert
> werden.

Thunderbird kann grundsätzlich nicht einfach konfiguriert werden.

Und jetzt netkoppt schön weiter, interessiert zum Glück eh niemanden.

[toc] | [prev] | [next] | [standalone]

#653422

Carlo XYZ <carloxyz@invalid.invalid> wrote:

> Bernd Ohm wrote on 26.12.25 12:21:
> > Ich verstehe nur nicht, warum der iDoc grundsätzlich
> > Fullquotes in seine Posts setzt.  
> 
> Tut er nicht, und diesmal ging's wimre um Bausteine.

Halt in 9/10 Fällen.

-- 
LIBERTÉ ÉGALITÉ FCKAFD

[toc] | [prev] | [next] | [standalone]

#653370

Salve allerseits,

Dr. Joachim Neudert schrieb:
> Am 25.12.25 um 09:28 schrieb Fidel Sebastián Hunrichse-Lara:
>> 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.
>> 
>> | 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. 
> 
> 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?
>
+--- <hier abknabbern> ---
| Mitten im Meeting Englisch sprechen, während das Gegenüber die Worte in
| perfektem Spanisch hört – in Echtzeit. Was lange als Science-Fiction
| galt, rollt Google nun mit Meet und auf Pixel-Geräten aus. Hinter der
| Funktion steckt dieselbe KI, die auch Gemini antreibt – und ein
| komplexes Zusammenspiel spezialisierter Übersetzungsmodelle und
| generativer Sprach-Module.
|
| Wir haben mit Googles Director Product Management, Niklas Blum, über die
| zugrunde liegende Technik gesprochen: Wie funktioniert die
| End-to-End-Sprachübersetzung, die sogar die Originalstimme erhält? Wie
| arbietet das internationale Team? Und wo liegen die größten Hürden bei
| der Übersetzung von gesprochener Sprache?
|
| Mit Google Meet kann jeder in einer anderen Sprache sprechen – in
| Echtzeit. Das klappt mittels KI, konkret ist es derselbe Übersetzer wie
| in Gemini. Wie funktioniert das? Was passiert in dem Modell?
|
| Aktuell setzen wir spezialisierte Modelle für die Übersetzung und Gemini
| für die Sprachgenerierung ein. Diese Architektur setzt auf das
| AudioLM-Framework sowie Transformer-Blöcke und ist darauf ausgelegt,
| kontinuierliche Audioströme zu verarbeiten. Das ermöglicht es dem
| Modell, selbstständig zu entscheiden, wann die Übersetzung ausgegeben
| wird. Wir haben dazu kürzlich einen technischen Research-Blogpost
| veröffentlicht, der die Funktionsweise dieser End-to-End
| Speech-to-Speech Translation (S2ST) unter Beibehaltung der
| Originalstimme erläutert.
|
| Wie kommt es, dass an dem Echtzeit-Übersetzer ein Team aus Deutschland
| arbeitet?
|
| Unser Team und unsere Kunden sind global aufgestellt. Die Teams, die an
| diesem Feature arbeiten, verteilen sich auf Berlin, Stockholm, Zürich,
| New York und Mountain View. Das Google-Team in Stockholm ist dabei ein
| zentraler Hub für Googles Echtzeitkommunikation.
|
| Wofür lässt sich der Echtzeit-Übersetzer bisher nutzen? Er ist in Google
| Meet verfügbar, aber wo kommt er noch zum Einsatz, was ist geplant?
|
| Die Technologie zur Echtzeit-Übersetzung ist auch auf Pixel-10-Geräten
| für Anrufe und in Google Translate verfügbar. Bei Google Meet
| konzentrieren wir uns speziell auf Anwendungsfälle für
| Echtzeit-Gespräche in Unternehmen, die in verschiedenen Märkten tätig
| sind und mit Sprachbarrieren zu tun haben. Wir glauben, dass diese
| Technologie, auch wenn sie noch am Anfang steht, sich rasant
| weiterentwickeln wird. Echtzeit-Übersetzungen haben das Potenzial,
| Menschen zu verbinden und Gespräche zu ermöglichen, die so vorher kaum
| realisierbar waren.
|
| *Der Übersetzer ist ein „Lookahead*“
|
| Gesprochene Sprache ist fehlerhafter als geschriebene Sprache. Wie geht
| das Modell damit um? Wird eins zu eins übersetzt, also auch jedes “ähm”
| und im Zweifelsfall ein abgebrochener Satz? Denn so sprechen wir
| manchmal ja. Oder zieht der Echtzeit-Übersetzer auch Schlüsse und
| bereinigt die Sprache quasi?
|
| Unser Modell zur Echtzeit-Übersetzung nutzt Transformer-Blöcke und
| besteht aus zwei Hauptkomponenten: einem Streaming-Encoder, der die
| Quell-Audiodaten basierend auf den vorangegangenen zehn Sekunden der
| Eingabe zusammenfasst, und einem Streaming-Decoder. Letzterer sagt das
| übersetzte Audio autoregressiv vorher und nutzt dabei den komprimierten
| Encoder-Status sowie Vorhersagen aus früheren Iterationen.
|
| Die Transformer-Blöcke ermöglichen es dem Modell, selbstständig zu
| entscheiden, wann die Übersetzung ausgegeben wird. Basierend auf den
| Trainingsdaten ist das Modell in der Lage, über reine
| Wort-für-Wort-Übersetzungen hinauszugehen. Das ist besonders hilfreich
| bei Redewendungen oder dem Erkennen von Eigennamen. Begriffe wie die
| „Golden Gate Bridge” werden nicht übersetzt.
|
| Was ist die größte Schwierigkeit bei der Übersetzung gesprochener
| Sprache? Wo hapert es vielleicht auch manchmal noch?
|
| Bei der Übersetzung gesprochener Sprache stehen drei wesentliche
| Herausforderungen in Konkurrenz zueinander: Wir wollen eine möglichst
| hohe Übersetzungsqualität, eine minimale Verzögerung und gleichzeitig
| die originale Stimmcharakteristik beibehalten. Für Echtzeit-Gespräche
| wird aktuell eine Standardverzögerung von zwei Sekunden genutzt, was für
| die meisten Sprachen gut funktioniert. Ein längerer „Lookahead“ des
| Modells würde durch den zusätzlichen Kontext zwar die
| Übersetzungsqualität verbessern, beeinträchtigt aber das
| Echtzeit-Erlebnis. Eine optimale Übersetzungsqualität in möglichst
| kurzer Zeit zu erzielen, bleibt die zentrale Herausforderung und ein
| Bereich für weitere Verbesserungen.
|
| Generell haben die Fortschritte bei der KI-Audioverarbeitung und der
| Modellqualität zuletzt große Sprünge gemacht. Das dürfte der Grund sein,
| weshalb branchenweit eine zunehmende Integration von Sprachübersetzung
| in verschiedene Produkte stattfindet.
|
| Es gab eine Zeit, da haben Google und auch andere Anbieter ähnliche
| Übersetzungstools nicht veröffentlicht, weil Missbrauch drohte. Was hat
| sich geändert?
|
| Wir integrieren diese Funktion nun in unsere Produkte, weil die
| Technologie einen gewaltigen Sprung nach vorn gemacht hat. Ich glaube,
| dass es bis vor Kurzem nicht möglich war, wirklich hochwertige
| dialogorientierte Dienste zu entwickeln, die den erforderlichen
| Qualitätsstandards entsprechen.
|
| Wie steht es um die Gefahren vor Missbrauch, vor Deepfakes? Welche
| Schutzmaßnahmen gibt es?
|
| Wir sind natürlich zum Einhalten der geltenden Datenschutzgesetze
| verpflichtet. Im Laufe der Jahre haben wir eng mit Datenschutzbehörden
| auf der ganzen Welt zusammengearbeitet und strenge Datenschutzmaßnahmen
| umgesetzt. So haben wir für Meet klare Richtlinien, wie unser Tool
| genutzt werden darf. Nutzer:innen ist es beispielsweise nicht gestattet,
| Meet zu verwenden, um sich als eine andere Person auszugeben.
+--- </hier abknabbern> ---

©<https://www.heise.de/hintergrund/Google-Echtzeit-Uebersetzer-Mehr-als-Wort-zu-Wort-Uebersetzungen-11122554.html>

	M.f.G.

-- 
Diese E-Mail-Adresse wird nur aus nostalgischen Gründen verwendet. Sie
wird praktisch nie gelesen.  Das MausNet ist nicht tot – es riecht nur
etwas komisch... ;-)

[toc] | [prev] | [next] | [standalone]

#653374

Am 24.12.25 um 14:50 schrieb Dr. Joachim Neudert:
> Am 24.12.25 um 14:41 schrieb Walter Brill:
>> Am Radio hiess es noch: "1 Programmierer + KI würden 10 IT-ler ersetzen".
>>
>> Ciao
>> Walter
> 
> Eher 20 oder 30, meinst Du?

Ich will mir kein "Aua" einfangen;-)

[toc] | [prev] | [next] | [standalone]

#653375

Salve allerseits,

Walter Brill schrieb:
> Am 24.12.25 um 14:50 schrieb Dr. Joachim Neudert:
>> 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?
> 
> Ich will mir kein "Aua" einfangen;-)
> 
Nach Silvester einfach noch einmal auf MTV schalten! Da läuft zum
letzten Mal /MTV in the Mix/...							щ（ﾟДﾟщ ）

	M.f.G.

-- 
Diese E-Mail-Adresse wird nur aus nostalgischen Gründen verwendet. Sie
wird praktisch nie gelesen.  Das MausNet ist nicht tot – es riecht nur
etwas komisch... ;-)

[toc] | [prev] | [next] | [standalone]

#653380

Walter Brill <WalterBrill@t-online.de> wrote:

> Am 24.12.25 um 14:50 schrieb Dr. Joachim Neudert:
> > Am 24.12.25 um 14:41 schrieb Walter Brill:  
> >> Am Radio hiess es noch: "1 Programmierer + KI würden 10 IT-ler
> >> ersetzen".
> >>
> >> Ciao
> >> Walter  
> > 
> > Eher 20 oder 30, meinst Du?  
> 
> Ich will mir kein "Aua" einfangen;-)

s/Aua/schallendes Gelächter/. Irgendein bayrischer CSU(was sonst)-
Politik-Kasper meinte wohl auch, durch KI würde ein Entwickler
zehnmal schneller.

Dumm nur, dass *alle* belastbaren Zahlen eher das Gegenteil behaupten.

-- 
LIBERTÉ ÉGALITÉ FCKAFD

[toc] | [prev] | [next] | [standalone]

#653428 — Entwickler und KI (was: US-Wirtschaftswachstum 4,3%)

Dietz Proepper schrieb:

> Walter Brill <WalterBrill@t-online.de> wrote:
> 
>> Am 24.12.25 um 14:50 schrieb Dr. Joachim Neudert:
>> > Am 24.12.25 um 14:41 schrieb Walter Brill:  
>> >> Am Radio hiess es noch: "1 Programmierer + KI würden 10 IT-ler
>> >> ersetzen".
>> >>
>> >> Ciao
>> >> Walter  
>> > 
>> > Eher 20 oder 30, meinst Du?  
>> 
>> Ich will mir kein "Aua" einfangen;-)
> 
> s/Aua/schallendes Gelächter/. Irgendein bayrischer CSU(was sonst)-
> Politik-Kasper meinte wohl auch, durch KI würde ein Entwickler
> zehnmal schneller.

Es wurde vermutlich nicht präzise gesagt, wobei genau der Entwickler
schneller wird.

Da auch derzeitige Gesellschaften Kakistokratie und Verblödung fördern,
propagieren inflationär auch immer mehr Politiker/innen ein anderes
Verständnis für "gute Qualität" als es redliche Menschen propagieren.

Es kann schon sein, dass eine Entwicklerin/ein Entwickler durch
Verwendung von KI schneller wird. Über die Qualität dessen, was sie/er
schnell produziert, ist dabei aber nichts gesagt.

Ich halte Trainingsdaten, die in einem ineinandergreifenden Konglomerat
an kakistokratischen Hierarchien dadurch angehäuft wurden, dass Leute
Schaumschlägerei betrieben und dabei das Ziel hatten, wirklich
kompetente Konkurrenz auf unredliche Weise auszumanövrieren, die Massen
zu verblenden und über ihr eigenes Nichtwissen und ihre eigenen Defizite
hinwegzutäuschen und große Kompetenz vorzulügen, für etwas, das nicht
garantiert, dass KI guten Output produziert.

> Dumm nur, dass *alle* belastbaren Zahlen eher das Gegenteil behaupten.
Ich habe keine "belastbaren" Zahlen an der Hand und was das Coden
angeht, sehe ich in mir eher einen passionierten Amateur denn einen
Profi. Außerdem halte ich mich da eher für einen Nischenbesetzer.

Aber als jemandem, der sich hobbymäßig mit dem Textsatzsystem TeX und
dem darauf aufbauenden TeX-Format LaTeX beschäftigt, begegnen mir z.B.
auf TeX LaTeX Stack Exchange immer mehr Anfragen von Leuten, die davon
nichts verstehen und sich, anstatt die Aufgabe, die sie mit TeX/LaTeX zu
bewältigen suchen, abzulehnen oder sich einzulernen, darauf verlegen,
von einer KI ein Stück Code basteln zu lassen und dann vor dem Problem
stehen, dass dieses Stück Code beim Kompilieren und/oder beim
Ausführen/Verarbeiten des Kompilats nicht bewirkt, was es nach der
Intension der Anfragenden bewirken soll, die nun im Prinzip keine "I
want to learn"-Frage, sondern eine "Do-it-for-me"-Frage formulieren,
weil sie wollen, dass jemand sich den Mist anschaut und ihn für sie so
abändert, dass das Resultat des Abänderns beim Kompilieren das bewirkt,
was sie sich vom nicht-abgeänderten KI-erzeugten Stück Code erhofften.
(Immer wieder kommt dabei heraus, dass die Leute nicht nur
Schwierigkeiten beim Implementieren in (La)TeX haben, sondern schon das
Erfassen, was für Probleme gelöst werden müssen und das Sich-Befassen
mit der Frage, wie ein problemlösender Algorithmus aussieht, an KI
auszulagern versuchen.)
Oft besteht die nötige Abänderung des KI-erzeugten Codestücks darin, den
Mist insgesamt gegen etwas zu ersetzen, was man komplett selbst
geschrieben hat.

Auch wenn man ausprobiert, wie KI-Chatbots mit LLM die
Computersprache/Textsatzsprache TeX und die Konzepte, nach denen der
Kompiler funktioniert, erklären (Tokenizing, Expansion, Assignment,
Typesetting-Modes, Aufbau von Boxen, Absatzumbruchsalgorithmen,
Seitenumbruchsalgorithmen, Output-Routinen, ...), wird einem so gut wie
immer etwas Wohlklingendes erzählt, was falsch ist und was einem oft
schon früher begegnet ist, als nicht künstliche sogenannte
Intelligenzen, sondern Menschen es von sich gaben.
Entweder Menschen, die dabei nicht den Anspruch erhoben, Wahrheiten zu
formulieren, sondern beim Nachfragen ihre aus inkorrekten oder inkorrekt
zusammengefügten Informationen bestehenden Ausgangspunkte darlegten,
damit man ihnen helfen könne, ihre Irrtümer zu korrigieren und ihr
Verständnis zu verbessern, wobei beim Training von KI mit diesen Daten
nicht hinreichend berücksichtigt wurde, dass es den Erzeugern dieser
Daten nicht darum ging, Wahrheiten zu formulieren, sondern darum, als
Ausgangspunkt für verständnisfördernde Erklärungen durch
Antwortgeber/innen den möglicherweise inkorrekten Stand ihres eigenen
Verständnisses darzulegen.
Oder - das ist heutzutage auch häufig der Fall - Menschen, die laberten,
um sich zu inszenieren und die dabei nicht korrekt Bescheid wussten und
bewusst darüber hinwegtäuschten, deren inkompetentes Gelabere aber in
den Bestand an Trainingsdaten einging.

Wenn ein Entwickler bezogen auf ein ihm neues Werkzeug eine Lernphase
absolvieren muss, wird sie wohl nicht schneller absolviert sein, wenn er
KI einsetzt, die ihm die Dinge falsch erklärt.

Mit freundlichem Gruß

Ulrich

[toc] | [prev] | [next] | [standalone]

#653439 — Re: Entwickler und KI (was: US-Wirtschaftswachstum 4,3%)

Ulrich D i e z <ud.usenetcorrespondence@web.de> wrote:

> Dietz Proepper schrieb:
> 
> > Walter Brill <WalterBrill@t-online.de> wrote:
> >   
> >> Am 24.12.25 um 14:50 schrieb Dr. Joachim Neudert:  
> >> > Am 24.12.25 um 14:41 schrieb Walter Brill:    
> >> >> Am Radio hiess es noch: "1 Programmierer + KI würden 10 IT-ler
> >> >> ersetzen".
> >> >>
> >> >> Ciao
> >> >> Walter    
> >> > 
> >> > Eher 20 oder 30, meinst Du?    
> >> 
> >> Ich will mir kein "Aua" einfangen;-)  
> > 
> > s/Aua/schallendes Gelächter/. Irgendein bayrischer CSU(was sonst)-
> > Politik-Kasper meinte wohl auch, durch KI würde ein Entwickler
> > zehnmal schneller.  
> 
> Es wurde vermutlich nicht präzise gesagt, wobei genau der Entwickler
> schneller wird.

Die Ansage war iirc, dass "KI" den Entwickler 10x produktiver macht.

Und bei einer Sache wird er auf jeden Fall produktiver - Zahl der
"WTF?!"/s beim code review.

> Da auch derzeitige Gesellschaften Kakistokratie und Verblödung
> fördern,

Inwiefern?

> propagieren inflationär auch immer mehr Politiker/innen ein
> anderes Verständnis für "gute Qualität" als es redliche Menschen
> propagieren.

*Seufz*.

> Es kann schon sein, dass eine Entwicklerin/ein Entwickler durch
> Verwendung von KI schneller wird. Über die Qualität dessen, was sie/er
> schnell produziert, ist dabei aber nichts gesagt.

Oh, wenn Qualität keine Rolle spielt, dann braucht's keine KI, um die
Produktivität zu vervierfachen.

> Ich halte Trainingsdaten, die in einem ineinandergreifenden
> Konglomerat an kakistokratischen Hierarchien dadurch angehäuft
> wurden, dass Leute Schaumschlägerei betrieben und dabei das Ziel
> hatten, wirklich kompetente Konkurrenz auf unredliche Weise
> auszumanövrieren, die Massen zu verblenden und über ihr eigenes
> Nichtwissen und ihre eigenen Defizite hinwegzutäuschen und große
> Kompetenz vorzulügen, für etwas, das nicht garantiert, dass KI guten
> Output produziert.

Naja, "KI" ist deutlich mehr als genAI.

> > Dumm nur, dass *alle* belastbaren Zahlen eher das Gegenteil
> > behaupten.  
> Ich habe keine "belastbaren" Zahlen an der Hand und was das Coden
> angeht, sehe ich in mir eher einen passionierten Amateur denn einen
> Profi. Außerdem halte ich mich da eher für einen Nischenbesetzer.

Bspw. https://www.theregister.com/2025/12/17/ai_code_bugs/

> Auch wenn man ausprobiert, wie KI-Chatbots mit LLM die
> Computersprache/Textsatzsprache TeX und die Konzepte, nach denen der
> Kompiler funktioniert, erklären (Tokenizing, Expansion, Assignment,
> Typesetting-Modes, Aufbau von Boxen, Absatzumbruchsalgorithmen,
> Seitenumbruchsalgorithmen, Output-Routinen, ...), wird einem so gut
> wie immer etwas Wohlklingendes erzählt, was falsch ist und was einem
> oft schon früher begegnet ist, als nicht künstliche sogenannte
> Intelligenzen, sondern Menschen es von sich gaben.

Tja. Das Ziel von openai ist ja auch nicht, "richtige" Antworten zu
produzieren, sondern Antworten, die den Anwender bei der Stange halten.

> Wenn ein Entwickler bezogen auf ein ihm neues Werkzeug eine Lernphase
> absolvieren muss, wird sie wohl nicht schneller absolviert sein, wenn
> er KI einsetzt, die ihm die Dinge falsch erklärt.

Insbesondere wird der Entwickelnde dann nicht in der Lage sein, die
Qualität des genAI-Generats zu beurteilen und ggf. die Fehler zu
beheben.

Aber in der nächsten Generation wird alles besser werden, frag' den
Altman.

-- 
LIBERTÉ ÉGALITÉ FCKAFD

[toc] | [prev] | [next] | [standalone]

#653761

Dr. Joachim Neudert schrieb:
> Am 23.12.25 um 20:04 schrieb Ruediger Lahl:
>> *Dr. Joachim Neudert* schrieb:
>>
>>> 4,3% Wirtschaftswachstum auf jährlicher Basis für das 3. Quartal.
>>>
>>> Hmmmm....
>>>
>>> Impressive. Most impressive.
>>
>> Irgendwo hatte ich gelesen, dass das Wachstum hauptsächlich von den paar
>> Tech-Firmen kommt, die vom KI-Hype profitieren. Bekanntlich schmeißen
>> die gerade die Milliarden nur so zum Fenster raus.
> 
> 
> OK.
> 
> Aber wer hat denn unsere begnadeten IT-Entwickler gehindert, LLMs zu bauen? 
> Ich meine, ausser Chuck und Stefan F. aus W, die klar wissen daß da draus 
> nie was werden kann. Aber auf die hört doch sonst auch keiner?
> 
> What went wrong?
> 

Mein direkter Bürokollege war unheimlich stolz, als sein Töchterchen mit 
knapp 2 Jahren schon ganze "Dreiwortsätze" von sich geben konnte, die sogar 
einen Sinn ergaben. Dieses Entwicklungsstadium haben Berufsschüler im HSK 
nicht einmal entwicklet, und der trend geht eindeutig dahin, dass sich 
Nachwuchskräfte auch nicht weiterentwickeln werden. Und Du verlangst ein 
"Großes Sprachmoedell". Deutshcland verblödet immer mehr, ab dem nchsten 
Schuljahr lernen die Grundschüler in Niedersachsen weder das schriftliche 
Dividieren noch das Rechnen mit Dezimalzahlstellen. Der alte Witz, nach dem 
bayrische Schüler als Aufnahmeprüfung fürs Gymnasium norddeutsche 
Abiturprüfungen korrigieren müssen, wird Realität.

Wie ich heute morgen schon zu meiner frau gesagt habe: Es ist gut, das Ende 
des berufslebens absehen zu können. Da setzen wir uns schon mal auf den 
Beckenrand und schauen verwundert auf das getümmel.

-- 
  Mit freundlichen Grüßen
    Andreas Bockelmann

[toc] | [prev] | [next] | [standalone]

#653759

Ruediger Lahl schrieb:
> Irgendwo hatte ich gelesen, dass das Wachstum hauptsächlich von den paar
> Tech-Firmen kommt, die vom KI-Hype profitieren. 
Böses Thema. Ich habe mich zu lange nicht um mein Depot gekümmert. Der 
KI-Hype hat meine Adobe-Aktien relativ entwertet, die sind nach sehr hohen 
Flügen wieder bei meinem Einstandskurs.


-- 
  Mit freundlichen Grüßen
    Andreas Bockelmann

[toc] | [prev] | [next] | [standalone]

#653776

Am 30.12.25 um 13:46 schrieb Andreas Bockelmann:
> Ruediger Lahl schrieb:
>> Irgendwo hatte ich gelesen, dass das Wachstum hauptsächlich von den paar
>> Tech-Firmen kommt, die vom KI-Hype profitieren. 
> Böses Thema. Ich habe mich zu lange nicht um mein Depot gekümmert. Der 
> KI-Hype hat meine Adobe-Aktien relativ entwertet, die sind nach sehr 
> hohen Flügen wieder bei meinem Einstandskurs.
> 

Ich verwende ein selbst geschriebenes Python Programm
welches mir mit wget
<https://www.tagesschau.de/wirtschaft/boersenkurse/suche/?suchbegriff=+%09DE 
usw>
Börsenkurse einliest und mir damit Übersicht
über Stand und Entwicklung meiner Depots erstellt.

[toc] | [prev] | [next] | [standalone]

#653778

Hermann Riemann <nospam.ng@hermann-riemann.de> writes:

> Ich verwende ein selbst geschriebenes Python Programm
> welches mir mit wget
> <https://www.tagesschau.de/wirtschaft/boersenkurse/suche/?suchbegriff=+%09DE
> usw>
> Börsenkurse einliest und mir damit Übersicht
> über Stand und Entwicklung meiner Depots erstellt.

Und deine Bank kriegt das nicht hin?

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | ger.ct

csiph-web