Humanoide haben deshalb eine menschenähnliche Größe und eine ähnliche Gelenkstruktur, damit man für sie nicht eigens Werkzeuge oder Fertigungslinien bauen muss.
Wir haben doch bereits solchen Unsinn wie den Aufbau, Betrieb und die Wartung von unternehmensweitem RAG ausprobiert und mit dem Aufkommen von Agenten und MCP eingesehen, dass das gar nicht nötig gewesen wäre, oder? Warum sollten wir denselben Fehler jetzt nur auf andere Weise wiederholen?
Die altbackene Idee, dass Agenten statt Menschen das Web durchsuchen, wird am Ende wohl weniger an der Technik scheitern als an politischen Faktoren, weil sie das wichtigste Einnahmemodell von Google bedroht, das selbst ein Teil des Webs ist.
Am Ende ist webMCP ohnehin nur eine Übergangslösung, bis RPA-Agenten wirklich ausgereift sind. So geht das noch so weit, dass am Ende sogar wieder jemand fordert, zu xul zurückzukehren.
Für Ingenieurinnen und Ingenieure, die mit KI arbeiten, ist es keineswegs ein verborgenes oder überraschendes Grundaxiom, dass bei großen Sprachmodellen (LLMs) letztlich sowohl „Kreativität“ als auch „Halluzination“ dasselbe Ergebnis probabilistischer Next-token prediction sind; das Whitepaper übertreibt diesen Punkt jedoch, als würde es damit ein großes Geheimnis enthüllen.
Etwas enttäuschend ist die Logik, mit der die „autonome Korrektur“ von Multi-Agenten-Systemen einfach auf eine „tautologische Wiederholung (Homogeneous Iteration)“ innerhalb desselben Kontexts reduziert und dann kritisiert wird.
Wenn man in realen Entwicklungsumgebungen intelligente Agenten in eine IDE integriert und fortgeschrittenes Prompt Engineering betreibt, ist diese probabilistische Natur des Modells weniger ein „unüberwindbarer fataler Mangel“ als vielmehr schlicht eine „Grundbedingung“, die beim Systemdesign als Konstante anzusetzen ist. In der Praxis geht man ohnehin davon aus, dass das Modell den Kontext verlassen kann, und sichert sich reale Kontrolle, indem man klar getrennte Kontexte bereitstellt oder durch Kontexte unterschiedlicher Größenordnung arbeitet.
Dieses Whitepaper verpackt jedoch diese allseits bekannte Tatsache in großspurige akademische Begriffe wie „Kategorienfehler“ und „probabilistische Umgehung“ und schürt damit Verunsicherung. Der Zweck scheint klar: Nur wenn die Autonomie von LLMs selbst vollständig abgewertet wird, lässt sich der Wert des von ihnen vorgeschlagenen „deterministischen, vom Menschen direkt entworfenen Kontrollnetzes (SERA-System)“ maximal herausstellen.
Letztlich ist dieser Text weniger ein Whitepaper mit technischem Augenmaß als vielmehr ein tendenziöser Sales Pitch, der sich an Entscheidungsträger in Enterprise-Umgebungen richtet, die Risiken durch Halluzinationen fürchten, und sie davon überzeugen soll: „Führt statt unkontrollierbarer Agenten lieber unsere hartcodierte deterministische Pipeline ein.“
Den Code für die Arbeit überlasse ich komplett den AI-Agenten und sorge dafür, dass sie möglichst lange in der Schleife laufen.
An privaten Hobbyprojekten arbeite ich dagegen direkt selbst, ohne AI-Assistenten oder AI-Autovervollständigung zu verwenden (...)
Ich bin wegen AI von vim zu VS Code gewechselt,
habe aber das Gefühl gehabt, die Freude am Entwickeln verloren zu haben, und bin deshalb zu vim zurückgekehrt.
Ich nutze AI als Assistant, und ich habe das Gefühl, die Freude am Entwickeln dadurch definitiv wiedergefunden zu haben.
Es ist zwar kompliziert formuliert, aber letztlich ist die Aussage etwas, das auch auf Menschen zutrifft.
Die Frage ist doch, ob ein von Dummkopf A geschriebener Text dadurch besser wird, dass Dummkopf A ihn noch einmal anschaut.
Natürlich gibt es in wenigen Fällen Spielraum, dass er besser wird, und es gibt auch eine Wahrscheinlichkeit, alle Fragen einfach richtig zu raten und in der CSAT die volle Punktzahl zu bekommen, aber in den meisten Fällen kehrt man nur zum durchschnittlichen Niveau von Dummkopf A nach dem N-ten Versuch zurück.
(Chapter 2 kann ich allerdings nicht vollständig zustimmen.)
Ich wünschte nur, man würde verstehen, dass das im Paper erwähnte what-ever Scaling Law ein vorübergehendes Wachstumsgesetz ist und nichts Ewiges.
Wenn man das OpenAI-Paper richtig gelesen hätte, würde man so etwas gar nicht behaupten.
Eigentlich wäre die Sache mit einem Schlag erledigt, wenn man statt 100 solcher Papers einfach beweisen würde, dass die Person, die behauptet, es funktioniere einfach, auch recht hat.
Das Problem ist, dass man nur diese Alchemie des "Es funktioniert" betreibt.
Ich persönlich spüre schmerzhaft, wie schlecht AI in meinem Fachgebiet ist. Ich vermute, dass es Experten in anderen Bereichen ähnlich geht. Natürlich ist sie eine große Hilfe. Zwar muss man den ganzen Tag lang belehrende Dokumente schreiben, aber mit der früheren Produktivität ist das überhaupt nicht zu vergleichen.
Attention bildet sich durch Mehrheitsentscheidungen.
Ein Verifizierungsagent muss nur die Bewertungsfunktion bestehen.
Hervorragender Industrie-Code ist größtenteils nicht öffentlich zugänglich.
Open Source ist Code, der zum Vorzeigen gedacht ist.
Diesen Punkt sollte man beim Einsatz immer im Hinterkopf behalten.
Nach den Experimenten unseres Labors ist dies ein Modell, das ein Qwen-Team ohne Qwen-Team überhastet veröffentlicht hat, nur um die Marktunsicherheit zu kontrollieren und lediglich auf Benchmarks zu passen. Der Tool-Fetisch ist stark ausgeprägt. Gegenüber 3.5 sehen wir es als einen Rückschritt an.
Ich weiß nicht, was vom Agilen außer kurzen Release-Zyklen überhaupt noch übrig bleibt.
Backlog und Sprint gab es schon vorher in anderer Form, und auch die Kommunikation mit dem Kunden passt in vielen Punkten nicht zur Realität. Letztlich haben meiner Meinung nach Verbesserungen bei DevOps mehr Fortschritt in der Entwicklung gebracht als Agile.
Beim Schreiben von Software ist nicht so sehr Abstraktheit das Problem, sondern eher Unklarheit. Natürliche Sprache ist ihrem Wesen nach mehrdeutig. Sie kann verschiedene Bedeutungen haben. Vielleicht funktionieren deshalb Versuche, in natürlicher Sprache zu programmieren, nicht besonders gut.
Unter diesen Umständen ist es völlig undenkbar, dass natürliche Sprache Code ersetzt.
So etwas wirkt wie ein Festhalten an früheren Arbeitsweisen. Solche Bereiche wird die KI ohnehin besser beherrschen. Wichtig ist jetzt die Erfahrung darin, mit KI zu arbeiten und die Teile zu verbessern, die noch nicht gut funktionieren. Aber auch das halte ich für zeitlich begrenzt.
Das ist sicher von Person zu Person unterschiedlich, aber ich denke, dass die meisten beim Lernen im Computerbereich auf die von Ihnen beschriebene Weise vorgehen. Heutzutage gibt es auch die Möglichkeit, per Video zu lernen, daher sollte man die Lernmethode wählen, die am besten zu einem passt.
Dann stellt sich die Frage: Wie habt ihr eine rein funktionale Programmiersprache gelernt? Ich habe Programmiersprachen (C, Go, Python usw.) bisher mit Fachbüchern + Side Projects gelernt; kann man bei funktionalen Programmiersprachen ebenfalls so vorgehen?
AI fühlt sich an wie die Nutzung einer elektrischen Bohrmaschine, einer Kettensäge oder eines Baggers. Seit der Nutzung von Mobiltelefonen gibt es viele Menschen, die nicht einmal mehr ihre eigene Telefonnummer auswendig kennen.
...Man kann so etwas als Abbau sehen, aber ich betrachte es als Effizienz. Aus meiner Erfahrung als Entwickler und in verschiedenen anderen Rollen sind AI-Tools aus meiner Sicht auch Werkzeuge, die dabei helfen und die Chance bieten, aus der Welt nur für Entwickler auszubrechen und eine breitere Perspektive zu gewinnen. In einem Bereich mag es zu einem Abbau kommen, aber dieser Bereich wird mit etwas anderem gefüllt.
Nach meiner Erfahrung und dem Fazit vieler anderer galt lange als der richtige Weg, funktionale Sprachen anhand einer rein funktionalen Sprache zu lernen.
Das war eine Aussage aus der Zeit, als funktionale Sprachen aufkamen und dann starkes Interesse auf sich zogen, und ich konnte dem zustimmen. Ich selbst habe in der Anfangszeit von Erlang damit gelernt, und das war damals eine ziemlich schockierende und erstaunliche Erfahrung.
Clojure gibt es schon ziemlich lange, daher frage ich mich, warum jetzt wieder darüber gesprochen wird.
Ich habe in den frühen Tagen von Clojure einmal ein Buch dazu rezensiert. Später habe ich einige Unternehmen gesehen, die versucht haben, es einzusetzen, aber das Fazit war, dass es für den Einsatz in Unternehmen nicht einfach ist. Dann schien es in Vergessenheit zu geraten, und ich frage mich, warum es jetzt wieder zum Thema wird.
Ich habe Java seit den Anfängen lange verwendet, aber die JVM wird meiner Meinung nach heute der Zeit nicht mehr gerecht. Sie wird zwar immer noch viel genutzt, weil in Großunternehmen bereits viel Software in Java entwickelt wurde, weil es (in den USA) viele indische Fachkräfte gibt, die überwiegend Java beherrschen, und weil Java von der Highschool bis zur Universität gelehrt wird. Ich mag Lisp, aber im obigen Artikel konnte ich nicht erkennen, welche Vorteile einer ziemlich nischigen Sprache auf einer aus meiner Sicht alternden JVM-Architektur im KI-Zeitalter nun wieder neue Aufmerksamkeit verschaffen.
Werbung und Marketing waren schon vor dem Internet so, aber jetzt, da sich das, was die Menschen sehen, verändert hat und Regulierung unmöglich geworden ist, wimmelt es von Methoden, die fast schon an Betrug grenzen.
Ich habe noch nie richtig eine funktionale Programmiersprache gelernt und überlege, mit Clojure anzufangen. Wie sollte ich am besten lernen? Ich freue mich über viele Ratschläge von den Entwicklerinnen und Entwicklern.
Wäre es nicht besser, Beiträge zu ordnen, die gegen die EULA verstoßen?
Humanoide haben deshalb eine menschenähnliche Größe und eine ähnliche Gelenkstruktur, damit man für sie nicht eigens Werkzeuge oder Fertigungslinien bauen muss.
Wir haben doch bereits solchen Unsinn wie den Aufbau, Betrieb und die Wartung von unternehmensweitem RAG ausprobiert und mit dem Aufkommen von Agenten und MCP eingesehen, dass das gar nicht nötig gewesen wäre, oder? Warum sollten wir denselben Fehler jetzt nur auf andere Weise wiederholen?
Die altbackene Idee, dass Agenten statt Menschen das Web durchsuchen, wird am Ende wohl weniger an der Technik scheitern als an politischen Faktoren, weil sie das wichtigste Einnahmemodell von Google bedroht, das selbst ein Teil des Webs ist.
Am Ende ist webMCP ohnehin nur eine Übergangslösung, bis RPA-Agenten wirklich ausgereift sind. So geht das noch so weit, dass am Ende sogar wieder jemand fordert, zu xul zurückzukehren.
Das liegt daran, dass die Dimensionen und Layer des Modells nicht gleichmäßig ausgebacken wurden. Wie immer eben.
Für Ingenieurinnen und Ingenieure, die mit KI arbeiten, ist es keineswegs ein verborgenes oder überraschendes Grundaxiom, dass bei großen Sprachmodellen (LLMs) letztlich sowohl „Kreativität“ als auch „Halluzination“ dasselbe Ergebnis probabilistischer Next-token prediction sind; das Whitepaper übertreibt diesen Punkt jedoch, als würde es damit ein großes Geheimnis enthüllen.
Etwas enttäuschend ist die Logik, mit der die „autonome Korrektur“ von Multi-Agenten-Systemen einfach auf eine „tautologische Wiederholung (Homogeneous Iteration)“ innerhalb desselben Kontexts reduziert und dann kritisiert wird.
Wenn man in realen Entwicklungsumgebungen intelligente Agenten in eine IDE integriert und fortgeschrittenes Prompt Engineering betreibt, ist diese probabilistische Natur des Modells weniger ein „unüberwindbarer fataler Mangel“ als vielmehr schlicht eine „Grundbedingung“, die beim Systemdesign als Konstante anzusetzen ist. In der Praxis geht man ohnehin davon aus, dass das Modell den Kontext verlassen kann, und sichert sich reale Kontrolle, indem man klar getrennte Kontexte bereitstellt oder durch Kontexte unterschiedlicher Größenordnung arbeitet.
Dieses Whitepaper verpackt jedoch diese allseits bekannte Tatsache in großspurige akademische Begriffe wie „Kategorienfehler“ und „probabilistische Umgehung“ und schürt damit Verunsicherung. Der Zweck scheint klar: Nur wenn die Autonomie von LLMs selbst vollständig abgewertet wird, lässt sich der Wert des von ihnen vorgeschlagenen „deterministischen, vom Menschen direkt entworfenen Kontrollnetzes (SERA-System)“ maximal herausstellen.
Letztlich ist dieser Text weniger ein Whitepaper mit technischem Augenmaß als vielmehr ein tendenziöser Sales Pitch, der sich an Entscheidungsträger in Enterprise-Umgebungen richtet, die Risiken durch Halluzinationen fürchten, und sie davon überzeugen soll: „Führt statt unkontrollierbarer Agenten lieber unsere hartcodierte deterministische Pipeline ein.“
Den Code für die Arbeit überlasse ich komplett den AI-Agenten und sorge dafür, dass sie möglichst lange in der Schleife laufen.
An privaten Hobbyprojekten arbeite ich dagegen direkt selbst, ohne AI-Assistenten oder AI-Autovervollständigung zu verwenden (...)
Ich habe die AI-Funktionen in VSCode deaktiviert und nutze Claude Code; das ist definitiv angenehmer.
Ich bin wegen AI von vim zu VS Code gewechselt,
habe aber das Gefühl gehabt, die Freude am Entwickeln verloren zu haben, und bin deshalb zu vim zurückgekehrt.
Ich nutze AI als Assistant, und ich habe das Gefühl, die Freude am Entwickeln dadurch definitiv wiedergefunden zu haben.
Es ist zwar kompliziert formuliert, aber letztlich ist die Aussage etwas, das auch auf Menschen zutrifft.
Die Frage ist doch, ob ein von Dummkopf A geschriebener Text dadurch besser wird, dass Dummkopf A ihn noch einmal anschaut.
Natürlich gibt es in wenigen Fällen Spielraum, dass er besser wird, und es gibt auch eine Wahrscheinlichkeit, alle Fragen einfach richtig zu raten und in der CSAT die volle Punktzahl zu bekommen, aber in den meisten Fällen kehrt man nur zum durchschnittlichen Niveau von Dummkopf A nach dem N-ten Versuch zurück.
(Chapter 2 kann ich allerdings nicht vollständig zustimmen.)
Ich wünschte nur, man würde verstehen, dass das im Paper erwähnte what-ever Scaling Law ein vorübergehendes Wachstumsgesetz ist und nichts Ewiges.
Wenn man das OpenAI-Paper richtig gelesen hätte, würde man so etwas gar nicht behaupten.
Eigentlich wäre die Sache mit einem Schlag erledigt, wenn man statt 100 solcher Papers einfach beweisen würde, dass die Person, die behauptet, es funktioniere einfach, auch recht hat.
Das Problem ist, dass man nur diese Alchemie des "Es funktioniert" betreibt.
Ich persönlich spüre schmerzhaft, wie schlecht AI in meinem Fachgebiet ist. Ich vermute, dass es Experten in anderen Bereichen ähnlich geht. Natürlich ist sie eine große Hilfe. Zwar muss man den ganzen Tag lang belehrende Dokumente schreiben, aber mit der früheren Produktivität ist das überhaupt nicht zu vergleichen.
Attention bildet sich durch Mehrheitsentscheidungen.
Ein Verifizierungsagent muss nur die Bewertungsfunktion bestehen.
Hervorragender Industrie-Code ist größtenteils nicht öffentlich zugänglich.
Open Source ist Code, der zum Vorzeigen gedacht ist.
Diesen Punkt sollte man beim Einsatz immer im Hinterkopf behalten.
Nach den Experimenten unseres Labors ist dies ein Modell, das ein Qwen-Team ohne Qwen-Team überhastet veröffentlicht hat, nur um die Marktunsicherheit zu kontrollieren und lediglich auf Benchmarks zu passen. Der Tool-Fetisch ist stark ausgeprägt. Gegenüber 3.5 sehen wir es als einen Rückschritt an.
Ich weiß nicht, was vom Agilen außer kurzen Release-Zyklen überhaupt noch übrig bleibt.
Backlog und Sprint gab es schon vorher in anderer Form, und auch die Kommunikation mit dem Kunden passt in vielen Punkten nicht zur Realität. Letztlich haben meiner Meinung nach Verbesserungen bei DevOps mehr Fortschritt in der Entwicklung gebracht als Agile.
Beim Schreiben von Software ist nicht so sehr Abstraktheit das Problem, sondern eher Unklarheit. Natürliche Sprache ist ihrem Wesen nach mehrdeutig. Sie kann verschiedene Bedeutungen haben. Vielleicht funktionieren deshalb Versuche, in natürlicher Sprache zu programmieren, nicht besonders gut. Unter diesen Umständen ist es völlig undenkbar, dass natürliche Sprache Code ersetzt.
So etwas wirkt wie ein Festhalten an früheren Arbeitsweisen. Solche Bereiche wird die KI ohnehin besser beherrschen. Wichtig ist jetzt die Erfahrung darin, mit KI zu arbeiten und die Teile zu verbessern, die noch nicht gut funktionieren. Aber auch das halte ich für zeitlich begrenzt.
Das ist sicher von Person zu Person unterschiedlich, aber ich denke, dass die meisten beim Lernen im Computerbereich auf die von Ihnen beschriebene Weise vorgehen. Heutzutage gibt es auch die Möglichkeit, per Video zu lernen, daher sollte man die Lernmethode wählen, die am besten zu einem passt.
Dann stellt sich die Frage: Wie habt ihr eine rein funktionale Programmiersprache gelernt? Ich habe Programmiersprachen (C, Go, Python usw.) bisher mit Fachbüchern + Side Projects gelernt; kann man bei funktionalen Programmiersprachen ebenfalls so vorgehen?
AI fühlt sich an wie die Nutzung einer elektrischen Bohrmaschine, einer Kettensäge oder eines Baggers. Seit der Nutzung von Mobiltelefonen gibt es viele Menschen, die nicht einmal mehr ihre eigene Telefonnummer auswendig kennen.
...Man kann so etwas als Abbau sehen, aber ich betrachte es als Effizienz. Aus meiner Erfahrung als Entwickler und in verschiedenen anderen Rollen sind AI-Tools aus meiner Sicht auch Werkzeuge, die dabei helfen und die Chance bieten, aus der Welt nur für Entwickler auszubrechen und eine breitere Perspektive zu gewinnen. In einem Bereich mag es zu einem Abbau kommen, aber dieser Bereich wird mit etwas anderem gefüllt.
Nach meiner Erfahrung und dem Fazit vieler anderer galt lange als der richtige Weg, funktionale Sprachen anhand einer rein funktionalen Sprache zu lernen.
Das war eine Aussage aus der Zeit, als funktionale Sprachen aufkamen und dann starkes Interesse auf sich zogen, und ich konnte dem zustimmen. Ich selbst habe in der Anfangszeit von Erlang damit gelernt, und das war damals eine ziemlich schockierende und erstaunliche Erfahrung.
Clojure gibt es schon ziemlich lange, daher frage ich mich, warum jetzt wieder darüber gesprochen wird.
Ich habe in den frühen Tagen von Clojure einmal ein Buch dazu rezensiert. Später habe ich einige Unternehmen gesehen, die versucht haben, es einzusetzen, aber das Fazit war, dass es für den Einsatz in Unternehmen nicht einfach ist. Dann schien es in Vergessenheit zu geraten, und ich frage mich, warum es jetzt wieder zum Thema wird.
Ich habe Java seit den Anfängen lange verwendet, aber die JVM wird meiner Meinung nach heute der Zeit nicht mehr gerecht. Sie wird zwar immer noch viel genutzt, weil in Großunternehmen bereits viel Software in Java entwickelt wurde, weil es (in den USA) viele indische Fachkräfte gibt, die überwiegend Java beherrschen, und weil Java von der Highschool bis zur Universität gelehrt wird. Ich mag Lisp, aber im obigen Artikel konnte ich nicht erkennen, welche Vorteile einer ziemlich nischigen Sprache auf einer aus meiner Sicht alternden JVM-Architektur im KI-Zeitalter nun wieder neue Aufmerksamkeit verschaffen.
Werbung und Marketing waren schon vor dem Internet so, aber jetzt, da sich das, was die Menschen sehen, verändert hat und Regulierung unmöglich geworden ist, wimmelt es von Methoden, die fast schon an Betrug grenzen.
Ich habe noch nie richtig eine funktionale Programmiersprache gelernt und überlege, mit Clojure anzufangen. Wie sollte ich am besten lernen? Ich freue mich über viele Ratschläge von den Entwicklerinnen und Entwicklern.