Connect with us

Künstliche Intelligenz

World Computer Day: 80 Jahre ENIAC


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Heute ist der Weltcomputertag. Er wird alljährlich am 15. Februar zum Jahrestag der Vorstellung des „Electronic Numerical Integrator and Computer“ (ENIAC) gefeiert und ist dieses Jahr ein ganz besonderes Ereignis. Denn ENIAC wurde vor 80 Jahren der US-amerikanischen Öffentlichkeit vorgestellt. Davor war die Arbeit an dem frei programmierbaren Rechner streng geheim: Ab 1943 arbeiteten J. Prosper Eckert und John W. Mauchly mit 50 Mitarbeitern an der Entwicklung eines Leitbahnrechners zur Erstellung von ballistischen Schusstafeln für das Ballistic Research Center der US-Army, der im Aberdeen Proving Ground eingesetzt werden sollte. Als ENIAC im Dezember 1945 termingerecht fertiggestellt wurde war der Krieg jedoch zu Ende. Die Maschine berechnete anschließend thermonukleare Gleichungen für das Los Alamos Projekt der Wasserstoffbombe, ehe sie der Welt vorgeführt wurde.

Weiterlesen nach der Anzeige

Zum 80. Geburtstag gibt es am World Computer Day eine Reihe von Veranstaltungen, von denen der ENIAC Day im Amerikanischen Helicoptermuseum in Westchester im US-Bundesstaat Pennsylvania die wichtigste sein dürfte. Hier treten die Kinder von Eckert und Mauchly auf, hier erzählen die Töchter der ENIAC-Programmierinnen, was diese geleistet haben. Die Veranstaltung wird vom Compuseum gesponsort, das Computernutzer in aller Welt dazu auffordert, um 14:15 EST ihren Computer zu Ehren von ENIAC für eine Minute auszuschalten. ENIAC selbst lief von 1945 bis 1955 möglichst ohne Abschaltungen, weil seine 17.800 Röhren empfindlich waren. Deshalb wurde versucht, ihn durchgehend laufen zu lassen. Den letzten echten Einsatz hatten einzelne Teile seiner Hardware an seinem 50. Geburtstag im Beisein des damaligen US-Vizepräsidenten Al Gore, der in seiner Rede ENIAC als „Urahn“ des Internets feierte. Gore erhielt dabei auch eine Auszeichnung der University of Pennsylvania für den Begriff des „Information Superhighway“, den er popularisierte.

Dass ENIAC auch vor dreißig Jahren noch wirklich rechnen konnte, lag an einem Chip, den Studenten der Universität von Pennsylvania zum 50. Jubiläum entwickelt hatten und der als „ENIAC-on-a-Chip“ bekannt wurde. Zum nun 80. Jubiläum kann man in Gilbert im US-Bundesstaat Arizona das genaue Gegenteil bestaunen. Hier wurde der seinerzeit 30 Tonnen schwere Koloss, obwohl nicht lauffähig, originalgetreu von 80 neurodivergenten Schülerinnen und Schülern in der Turnhalle der PS Academy nachgebaut. Deren Smartphones sind leistungsfähiger als ENIAC.

Die Geschichte von ENIAC ist vielfach erzählt, die seiner ersten öffentlichen Präsentation weniger. Die PR der US-Army gab ein Papier heraus, das ENIAC als „mathematischen Roboter“ beschrieb; der erste Bericht erschien noch am Tag der Vorstellung in der New York Times. Ob das Lösen von Differentialgleichungen das Publikum interessierte, ist nicht bekannt. Der erste, der die Bedeutung der Erfindung erkannte und wissenschaftlich beschrieb, war der britische Mathematiker Douglas Rayner Hartree. Er hatte im zweiten Weltkrieg an einer Differentialmaschine gearbeitet und wurde bereits 1945 in die USA geschickt, um ENIAC zu studieren. Zur öffentlichen Präsentation des Rechners an der Moore School of Electrical Engineering an der Universität von Pennsylvania reiste Hartree mit Alan Turing, John Womersley und Maurice Wilkes an.

Sein zweiteiliger Bericht erschien 1946 in „Nature“ als „The ENIAC, an electronic calculating machine“ und „The ENIAC, an electronic computing machine“. Im Osten las der Computerpionier Nikolaus J. Lehmann die Berichte von Hartree und plädierte, dass man solche empfindlichen Schränke nicht bauen sollte. Er machte sich an die Entwicklung seines Tischrechners D1. Im Westen schrieb der Ballistiker Heinrich Pösch 1947 in der „Zeitschrift für angewandte Mathematik und Mechanik“ über „Eine automatische Rechenmaschine mittels Röhren“. Pösch war zu dieser Zeit Mitarbeiter des französischen Instituts SEA, das die ersten französischen Röhrenrechner baute.

Weiterlesen nach der Anzeige

Abseits der Fachwelt wurde das deutschsprachige Publikum von Artikeln wie dem über die „Maschine mit Gehirn“ informiert. 1950 beschrieb der „Spiegel“ seiner Leserschaft das Maschinengehirn ENIAC, das „beängstigend menschlich“ funktioniert. „Die Hauptarbeit leisten Tausende von elektronischen Röhren: Eine Gruppe erledigt die eigentliche Rechenaufgabe. Eine zweite stapelt Zwischenlösungen und Befehle an die Maschine auf. Sie stellt eine Art „Gedächtnis“ dar, einen Speicher, aus dem die Maschine zur richtigen Zeit das gerade Gebrauchte herbeiholt.“

Besonders gruselig wird es, wenn das Innere der Maschine beschrieben wird: „Das Innere eines Elektronengehirns ähnelt der Schaltzentrale eines Rundfunkhauses. An den Wänden befinden sich Regale mit Tausenden von Röhren, Schaltern und Kontrolllampen. Dahinter ein Spinngewebe von Leitungen. In der Mitte des „Gehirnkastens“ ist ein „Willenszentrum“, eine Zentrale, von der aus die Zahlen an die Maschine gehen. Zusammen mit den Befehlen, was damit geschehen soll.“ So ist diese frühe Beschreibung eines Rechners gar nicht so weit entfernt von der heutigen Debatte über Künstliche Intelligenz, wenn sich das „Willenszentrum“ angeblich selbstständig macht.

Eckert und Mauchly hatten nichts für das Raunen über „Elektronengehirne“ übrig. Sie machten sich gleich nach der Fertigstellung des ENIAC an die Arbeit, eine verbesserte Version ihrer Rechneridee zu bauen. Befragt, wie er denn seine Arbeit an ENIAC bewertete, antwortete John Presper Eckert: „Was mich am meisten überraschte, war die Tatsache, dass nichts wie der ENIAC da war, obwohl es alle benötigten Komponenten 10 oder sogar 15 Jahre früher schon gab. Der ENIAC hätte 10 oder 15 Jahre früher erfunden werden müssen und die echte Frage ist doch die, warum das nicht schon früher passierte.“


(nie)



Source link

Künstliche Intelligenz

Claude Code geleakt: Milliarden für KI-Sicherheit, null für Softwarehygiene


Es klingt nach dem nächsten großen Skandal: Über 500.000 Zeilen Quellcode von Anthropics CLI-Tool Claude Code tauchen öffentlich auf. Die Security-Community horcht auf, Wettbewerber reiben sich die Hände, Kommentatoren wittern den nächsten Beweis, dass KI eh an allem schuld ist. Doch wer genauer hinschaut, findet keine ausgeklügelte Attacke, keinen Zero-Day-Exploit, nicht einmal Social Engineering. Sondern schlicht eine Source Map im npm-Paket, die da nicht hingehörte. Also bloß ein vergessener Schalter in der Build-Pipeline. System scheint hier nur die Schludrigkeit zu haben.

Weiterlesen nach der Anzeige


Ein Kommentar von Moritz Förster

Ein Kommentar von Moritz Förster

Moritz Förster schreibt seit 2012 für die iX und heise online. Er betreut neben dem iX-Channel den Bereich Arbeitsplatz.

Source Maps sind nützliche Helfer in der Entwicklung. Sie bilden kompilierten Code zurück auf den lesbaren Quelltext – unverzichtbar beim Debuggen, fatal in der Produktion. Dass sie im fertigen Paket landen, passiert nicht durch einen raffinierten Angriff oder eine ausgerastete KI. Es passiert, weil niemand den Build-Prozess sauber konfiguriert hat. Oder weil die Konfiguration irgendwann still und leise überschrieben wurde. Oder weil schlicht niemand nachgeschaut hat.

Entwickler kennen das Muster. Es ist die vergessene .env-Datei im Git-Repository. Das Docker-Image mit eingebetteten Credentials. Die Debug-API, die seit Monaten offensteht, weil sie ja „nur intern“ ist. Genau das ist Prozessversagen.

Moderne Build-Pipelines sind überaus komplex. Bundler, Transpiler, Minifier, Packager – jeder Schritt erzeugt Artefakte, jeder Schritt kann Dinge durchreichen, die nicht nach draußen gehören. Die Verantwortung dafür verteilt sich auf ein Tohuwabohu an Tools, Konfigurationsdateien und Teams. Am Ende fühlt sich niemand zuständig. „Die Pipeline macht das schon“ ist aktuell einer der gefährlichsten Sätze in der Softwareentwicklung.

Weiterlesen nach der Anzeige

Bei klassischen Projekten geht das meistens noch gut. Die Artefakte sind langweilig, der Schaden überschaubar. Bei einem KI-Tool wie Claude Code sieht das anders aus. Hier stecken im Code nicht nur Implementierungsdetails, sondern Architekturentscheidungen, Feature-Flags für unveröffentlichte Funktionen und die komplette Orchestrierungslogik eines agentischen Systems. Wer das lesen kann – und das kann jeder mit npm und etwas Geduld –, bekommt eine Blaupause frei Haus.

KI-Unternehmen stehen unter enormem Innovationsdruck. Releases folgen in kurzen Zyklen, Features müssen raus, bevor der Wettbewerber sie zeigt. In diesem Tempo bleiben Sicherheits-Gates auf der Strecke. Nicht aus Schlampigkeit oder gar Böswilligkeit, sondern aus Pragmatismus. Die nächste Demo zählt mehr als das nächste Audit.

Das Ergebnis: Tools, die tief in lokale Entwicklungsumgebungen eingreifen, Code lesen, schreiben und ausführen, werden mit derselben Release-Disziplin behandelt wie ein Frontend-Widget. Dass das schiefgeht, ist keine Überraschung. Es ist nur eine Frage der Zeit.

Der aktuelle Vorfall wirkt nicht wie ein völlig isolierter Ausrutscher: Medienberichten zufolge ist es bereits die zweite unbeabsichtigte Offenlegung rund um Claude Code in etwas mehr als einem Jahr. Ganz allgemein kennt die Branche das Problem schon lange. OWASP listet „Cryptographic Failures“ (vormals Sensitive Data Exposure) seit Ewigkeiten in den Top Ten. Trotzdem passiert es immer wieder – nur dass die Konsequenzen wachsen.

Denn ein geleakter Quellcode ist hier mehr als ein PR-Problem. Er zeigt Wettbewerbern, wie Anthropic agentische Workflows orchestriert. Er zeigt Angreifern, wo die Logik Annahmen macht, die man ausnutzen kann. Er zeigt der Öffentlichkeit, dass ein Unternehmen, das Milliarden für KI-Sicherheit einwirbt, bei grundlegender Softwarehygiene patzt.

Der Reflex nach solchen Vorfällen ist vorhersehbar: mehr Security-Tools, mehr Monitoring, mehr Abwehr nach außen. Aber gegen was genau? Hier gab es keinen Angreifer, den man hätte aufhalten können. Keine Firewall der Welt schützt vor einem falsch konfigurierten Build-Skript.

Was helfen würde, ist weniger spektakulär: automatisierte Prüfungen, die vor jedem Release den Paketinhalt scannen. Klare Verantwortlichkeiten im Build-Prozess. Vier-Augen-Prinzip bei Releases sensibler Tools. Alles Dinge, die in der klassischen Softwareentwicklung längst Standard sein sollten – und die offenbar auch bei einem der bestfinanzierten KI-Unternehmen der Welt nicht zuverlässig greifen.

Und genau weil der eigentlich etablierte Prozess das Problem ist, sollte dieser Vorfall mehr beunruhigen als ein aufsehenerregender KI-Hack. Gegen die in der IT-Branche an vielen Stellen vorherrschende Nachlässigkeit hilft nur Disziplin – und die lässt sich bekanntlich schlecht skalieren.


(fo)



Source link

Weiterlesen

Künstliche Intelligenz

Last Call: OpenAI Codex – Coding-Agenten in VS Code, Terminal und CI/CD


OpenAI bietet mit Codex ein eigenes KI-Coding-Tool an. Die Agenten-Plattform unterstützt Entwicklerinnen und Entwickler dabei, ihre Entwicklungsprozesse zu beschleunigen und zu automatisieren. Unser KI-Coding-Experte Rainer Stropek zeigt, wie man Codex in VS Code, im Terminal, im Web, über SDKs und in der OpenAI Agent Platform produktiv nutzt. Unser Classroom OpenAI Codex für Entwickler – Coding-Agenten in VS Code, Terminal und CI/CD geht dabei auf die neuesten Entwicklungen ein. Erst kürzlich veröffentlichte OpenAI die Version 5.3, die wieder zahlreiche Neuerungen bringt und die unser Experte detailliert behandelt.

Weiterlesen nach der Anzeige

Zunächst steht der Unterschied zwischen ChatGPT und Codex im Vordergrund sowie welches Modell sich für welche Aufgabe am besten eignet. Darauf aufbauend lernen Teilnehmende typische Pair-Programming-Workflows und Spec-driven Development mit TypeScript-Projekten kennen. Anschließend geht es ins Terminal mit Slash-Commands, Terminal User Interface (TUI) vs. Headless-Modus, Konfiguration, AGENTS.md und Best Practices für sichere Änderungen an der Codebasis.

Danach steht Codex im Web im Fokus. Teilnehmende delegieren Aufgaben an Codex Cloud, integrieren Codex in GitHub-Workflows und nutzen Codex für Code Reviews. Darüber hinaus bauen sie anhand eines praktischen Beispiels in TypeScript ein Multi-Agentensystem mit dem Open Source OpenAI Agent SDK und vertiefen ihr Wissen über die Programmierschnittstellen Codex SDK und Model Context Protocol (MCP). Rainer Stropek zeigt, wie man Entwicklungsprozesse automatisiert und Codex mit MCP-Servern sowie -Clients verbindet.

Abschließend ordnet unser Experte Codex in die OpenAI Agent Platform ein: AgentKit, ChatKit, Agents SDK und Apps SDK. Er zeigt, wie man aus einem Codex-basierten Coding-Agenten eine Multi-Agenten-Lösung macht, auf die man über Web-UIs (ChatKit) und ChatGPT-Apps zugreift. Alle Sessions bieten zahlreiche Beispiele, praxisnahe Workflows und setzen einen Fokus auf Teams, die Codex oft über ihre ChatGPT-Subscription zur Verfügung haben. Die Termine sind:

  • 22.04.26: Programmieren mit OpenAI Codex in Visual Studio Code
  • 29.04.26: Codex im Terminal – Codex CLI in der Praxis
  • 06.05.26: Codex Cloud und GitHub-Integration – Aufbau von Multi-Agentensystemen
  • 13.05.26: Codex SDK und Model Context Protocol – Automatisierung von Entwicklungsprozessen
  • 20.05.26: Codex in der OpenAI Agent Platform – KI-Agenten mit Web-UI und ChatGPT-Integration erstellen




Bereits ab dem zweiten Classroom oder einem Classroom und drei Videokursen rechnet sich unser Professional Pass mit Zugriff auf den gesamten heise academy Campus!

Jetzt entdecken

Weiterlesen nach der Anzeige

Die Sessions haben eine Laufzeit von jeweils vier Stunden und finden von 9 bis 13 Uhr statt. Alle Teilnehmenden können sich nicht nur auf viel Praxis und Interaktion freuen, sondern haben auch die Möglichkeit, das Gelernte mit allen Aufzeichnungen und Materialien im Nachgang zu wiederholen und zu vertiefen. Fragen werden direkt im Live-Chat beantwortet und Teilnehmende können sich ebenfalls untereinander zum Thema austauschen. Der nachträgliche Zugang zu den Videos und Übungsmaterialien ist inklusive.

Weitere Informationen und Tickets finden Interessierte auf der Website des Classrooms.

E-Mail-Adresse

Ausführliche Informationen zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten erhalten Sie in unserer Datenschutzerklärung.


(cbo)



Source link

Weiterlesen

Künstliche Intelligenz

Multi-Agenten-Systeme: Wie dezentrale KI komplexe Aufgaben löst


Die Natur macht es vor: Ein Schwarm aus tausenden Vögeln ändert gleichzeitig die Richtung, um Räuber zu verwirren – ohne Anführer, ohne sichtbares Kommando. Und wo eine einzelne Termite nichts ausrichten kann, errichten Millionen von ihnen ohne Bauplan und ohne zentrale Steuerung meterhohe Bauwerke aus Erde und Speichel. Die einzelnen Vögel und Termiten folgen nur einfachen lokalen Regeln. Im Zusammenspiel entstehen aber koordinierte Bewegungen und kollektive Entscheidungen. Was die Natur vormacht, wird nun zum Vorbild technischer Systeme.

Immer größere KI-Modelle stoßen an Grenzen bei Kosten, Robustheit und Anpassungsfähigkeit. Statt komplexe Aufgaben in Unteraufgaben zu zerlegen und diese linear abzuarbeiten, denken Programmierer immer häufiger in Netzwerken aus autonomen Akteuren – sogenannten Agenten. Jeder Agent verfolgt eigene Ziele, reagiert auf seine Umgebung und trifft Entscheidungen. Erst aus ihrem Zusammenspiel entsteht die Lösung eines Problems.

  • Dezentrale KI-Architekturen organisieren Aufgaben nicht mehr zentral, sondern über viele autonome Agenten mit eigenen Rollen und Zielen.
  • Der Artikel zeigt anhand von Sozialsimulationen, LLM-Systemen und Robotik, wie solche Systeme aufgebaut und eingesetzt werden.
  • Daraus wird sichtbar, in welchen Szenarien Kooperation Vorteile bringt – und wo Koordination zur eigentlichen Herausforderung wird.

Die dezentrale Herangehensweise hat mehrere Vorteile. Systeme werden robuster, weil der Ausfall einzelner Komponenten nicht gleich das gesamte System lahmlegt. Sie werden anpassungsfähiger, weil Agenten auf Veränderungen reagieren und ihr Verhalten in Echtzeit korrigieren können. Und sie lassen sich leicht skalieren: Wird ein Problem komplexer, können mehr Agenten hinzugefügt werden, ohne eine zentrale Steuerung zu überfordern. Welche dieser Vorteile in der Praxis tragen und wo neue Probleme entstehen, zeigt ein Blick auf konkrete Anwendungen.


Das war die Leseprobe unseres heise-Plus-Artikels „Multi-Agenten-Systeme: Wie dezentrale KI komplexe Aufgaben löst“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.



Source link

Weiterlesen

Beliebt