heise developer News

KI-Agenten bezahlen APIs automatisch mit Cloudflare Wallets

2026-08-16T16:08:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Cloudflare hat ein Wallet-System vorgestellt, mit dem KI-Agenten für die Nutzung von APIs zahlen können. Grundlage ist das Projekt x402.

(Bild: Jan Mahn / heise medien)

16.08.2026, 18:08 Uhr

Lesezeit: 4 Min.

Developer

Von

Johann Heuer

KI-Agenten, die im Auftrag eines Nutzers Aufgaben erledigen oder mit Diensten im Internet interagieren, könnten in Zukunft ein gängiger Weg sein, Computer zu bedienen. Wenn sie kostenpflichtige APIs im Internet bedienen sollen, stoßen Agenten aktuell aber noch an Hürden, weil sich solche Angebote bisher an menschliche Entwickler mit Maus, Tastatur und Kreditkarte gerichtet haben. Das Unternehmen Cloudflare will das ändern und hat ein Monetarisierungsgateway und ein zugehöriges Wallet-System vorgestellt, das automatisierte API-Bezahlung vereinfachen kann.

Wofür ein solches System nötig ist, wird an einem einfachen Szenario deutlich: Gibt man einem KI-Agenten mit Zugriff aufs Internet beispielsweise den Auftrag, historische Wetterdaten bei einem kommerziellen API-Anbieter abzurufen und die Werte als Diagramm darzustellen, landet der Agent nach kurzer Zeit auf einer für Menschen gemachten Seite mit verschiedenen Abomodellen. Von dort gelangt er in der Regel zu einem Zahlungsdienstleister. Weil kaum jemand seinem Agenten die Kreditkarten- oder Paypal-Anmeldedaten überlassen dürfte, kann er aber kein Abo abschließen und daher kein Zugangstoken besorgen. Der Agent kann diese Aufgabe nur an den Nutzer zurückgeben und wird erst aktiv, wenn der Mensch selbst den Bezahlvorgang erledigt und ein Token beschafft hat.

402 Payment Required

Cloudflares Wallet-System baut auf dem noch jungen Standard x402 auf. Das Projekt, das sich um dessen Entwicklung kümmert, wurde Anfang des Jahres in die Linux Foundation aufgenommen. Der Name kommt vom HTTP-Status „402 Payment Required“. Ein kostenpflichtiges API, das diese Technik nutzt, beantwortet Anfragen mit dem Status 402 und verschickt den Header PAYMENT-REQUIRED. Darin platziert der Server Zahlungsanweisungen im JSON-Format als Base64-kodierten String, zum Beispiel, welche Blockchain-Netzwerke vom Server akzeptiert werden und was der Zugriff kostet. Am x402-Projekt beteiligen sich aktuell bereits Zahlungs- und Kreditkartenanbieter wie Visa, Mastercard, Adyen und Stripe und deren Bezahlarten sollen künftig auch unterstützt werden – aktuell sind Stablecoins (wie Solana) auf der Ethereum Virtual Machine (EVM) das bevorzugte Zahlungsmittel.

Der Client, der ebenfalls x402 beherrschen muss, antwortet mit einer erneuten Anfrage und fügt den Header PAYMENT-SIGNATURE hinzu. Dieser beinhaltet dann in Base64 kodierte und kryptografisch signierte JSON-Daten, welche den abzuwickelnden Transfer autorisieren. Dieser Vorgang findet aktuell zumeist abseits der Blockchain statt und nutzt EIP-712-Signaturen. Diese erlauben das Bündeln mehrerer Autorisierungen für die spätere On-Chain-Abwicklung (Batching), was die Gebühren pro Transaktion minimiert und Mikrotransaktionen erst wirtschaftlich werden lässt.

Die abschließende Antwort des Servers beinhaltet dann ein PAYMENT-RESPONSE Header-Feld, welches Statusinformationen über die erfolgreiche oder misslungene Zahlung beinhaltet. Die gesamte Abwicklung kann ohne Nutzerinteraktion erfolgen.

Cloudflares Umsetzung

Cloudflare hat die x402-Technik bereits in sein Monetarisierungs-Gateway eingebaut. Betreiber von APIs und anderen Diensten, die ihre Server hinter das Monetarisierungs-Gateway stellen, können per x402 bestimmen, was sie für Anfragen verlangen.

Im zweiten Schritt bietet Cloudflare für Nutzer ein passendes Gegenstück in Form einer Wallet an. In einer Weboberfläche soll man Guthaben verwalten und es Agenten zuweisen können. Pro KI-Agent darf man dazu „virtuelle Wallets“ erstellen. Jede dieser untergeordneten Brieftaschen kann individuelle Guthaben und Richtlinien erhalten, um zu vermeiden, dass der damit ausgestattete KI-Agent versehentlich zu viel Geld ausgibt. Das kann den potenziellen Schaden minimieren, zum Beispiel wenn einer der KI-Agenten in eine fehlerhafte Schleife gerät.

Cloudflares Wallet für automatisierte Zahlungen per x402 ist noch nicht fertig, aktuell kann man lediglich einen Benutzernamen reservieren.

Fertig und nutzbar ist Cloudflares Wallet noch nicht, die Ankündigung enthält lediglich Screenshots. Bisher kann man lediglich eine Nutzer-ID sichern, den „Wallet Handle“, unter dem man dann bei Cloudflare identifizierbar ist.

Videos by heise

Geht es nach Cloudflare und anderen Beteiligten am x402-Projekt, steht das Zeitalter des „Agentic Commerce“ kurz bevor. Für den automatischen Kauf von Waren arbeiten verschiedene Akteure parallel am Agentic Commerce Protocol.

(jam)

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

KI macht Teams schneller – leider auch bei schlechten Prozessen

2026-08-16T07:30:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Agentic Engineering im Großkonzern: Was klingt wie ein Experiment, ist bei SAP gelebte Praxis. Oliver Nocon und Lukas Heimann berichten über KI in der Praxis.

(Bild: iX)

16.08.2026, 09:30 Uhr

Lesezeit: 6 Min.

Developer

Von

Matthias Parbel

„Vibe Coding“ polarisiert: Für die einen ist es der überfällige Produktivitätssprung, für die anderen ein Synonym für unkontrollierten KI-generierten Code. Bei SAP hat man sich entschieden, den Begriff ernst zu nehmen – und ihn mit klaren Strukturen zu unterlegen. Oliver Nocon und Lukas Heimann, beide im Bereich Developer Experience bei SAP tätig, zeigen auf der CLC-Konferenz 2026, wie Agentic Engineering im Konzernmaßstab funktionieren kann: mit der internen Plattform Hyperspace als zentralem Enabler.

Oliver Nocon stand vor der Frage "Wie skaliert man KI sicher für 25.000 Entwickler?" Oliver hat dieses Szenario bei SAP Realität werden lassen. Als Produktmanagement Lead nutzt er die Prinzipien von Continuous Delivery, um die Balance zwischen Entwickler-Freiheit und Governance zu schaffen und zu zeigen, wie aus Trends wie „Vibe Coding“ echter Unternehmenswert entsteht.

Lukas Heimann ist System Architect für die KI-Themen in SAPs interner Developer Platform für Cloud-Entwicklung. Sein Fokus: KI-gestützte Entwicklung sicher und skalierbar in den Konzernalltag bringen – nicht nur schneller, sondern nachhaltig besser im Sinne des DORA-Frameworks.

heise developer: „Vibe Coding“ klingt für viele erfahrene Entwicklerinnen und Entwickler erst mal nach Kontrollverlust. Was bedeutet der Begriff bei SAP konkret – und wo verläuft die Grenze zwischen Produktivitätsgewinn und Wildwuchs?

Oliver Nocon: Die Frage nach dem Kontrollverlust trifft genau den Punkt — und ich würde sie direkt umdrehen: Für mich steht „Vibe Coding“ nicht für Kontrollverlust, sondern für die Herausforderung, Kontrolle in einem Umfeld zu behalten, das sich in Rekordgeschwindigkeit verändert.

Ich verstehe „Vibe Coding“ eher weiter gefasst – so, wie es auch Gene Kim und Steve Yegge in ihrem Buch mit genau diesem Titel darlegen. Für mich steht „Vibe Coding“ gleichbedeutend mit „Agentic Engineering“, einer modernen Arbeitsweise, in der KI den Großteil des Codes schreibt, aber Menschen als Reviewer und Architekten die Kontrolle behalten.

Den Begriff haben wir bewusst provokant gewählt, weil er auf der CLC-Konferenz 2026 genau die Gespräche auslöst, die wir für notwendig halten.

Bei SAP beantworten wir diese Frage mit Hyperspace — unserer internen Entwicklungsplattform, die genau diese Balance zwischen Mensch und KI halten soll. Die Grenze zwischen Produktivitätsgewinn und Wildwuchs liegt für uns nicht in der Technologie selbst, sondern in der Plattform, die drumherum gebaut ist. Das DORA AI Capabilities Model bestätigt, was wir in der Praxis sehen: Teams, die am meisten von KI profitieren, arbeiten in kleinen, schnellen Zyklen, sind nah am Kunden — und werden von einer soliden internen Plattform unterstützt, die ihnen Leitplanken gibt, ohne sie zu bremsen. Genau das ist der Anspruch von Hyperspace: nicht Kontrolle durch Einschränkung, sondern Kontrolle durch gutes Design.

Mehr zu Agentic AI, digitaler Souveränität und weiteren Themen finden interessierte Developer, Software-Architekten, DevOps- und Platform-Engineering-Teams auf der CLC-Konferenz vom 11. bis 12. November 2026 in Mannheim.

☞ Sichern Sie sich jetzt die Tickets zum Frühbucherpreis. ☜

heise developer: Wie stellt ihr sicher, dass KI-generierter Code in einem Konzern wie SAP den Anforderungen an Sicherheit, Compliance und Wartbarkeit standhält? Welche Guardrails habt ihr eingezogen?

Lukas Heimann: Vieles davon ist gar nicht neu, etliche Methoden aus dem klassischen Software Engineering bleiben auch weiterhin relevant: Linting und statische Codeanalyse, Lizenz- und Sicherheitsscans verwendeter Drittanbieter- und Open-Source-Software. Qualitäts-Checks so früh wie möglich – „Shift Left“. In der KI-Welt braucht es dann den nächsten Schritt, und diese „Sensoren“ (dazu zählen die genannten Methoden, also beispielsweise auch Ergebnisse eines Scans) müssen für den Agenten direkt als Datenquelle verfügbar sein. Sensoren sind neben den Guides ein Kernkonzept aus dem Harness Engineering.

Hinzu kommen neue Werkzeuge aus dem Context Engineering. Viele firmenspezifische Informationen, die menschliche Entwickler in ihre Arbeit einfließen lassen, kennt ein Sprachmodell erstmal nicht: etwa Produktstandards, Integrationskonzepte oder interne Wissensdatenbanken. Über die Entwicklungsplattform bringen wir diesen Kontext als zentrale Skills und MCP-Server in den KI-getriebenen Entwicklungsprozess hinein – sei es im lokalen Coding Agent oder im Pull Request über einen Review Bot, den wir für Teams automatisch einrichten.

Das Risiko endet aber nicht beim generierten Code. Coding Agents besitzen meist hohe Berechtigungen und große Flexibilität – das macht sie zum Einfallstor, von Prompt Injection bis zur Datenexfiltration über MCP-Server. Compliance-Prozesse in Unternehmen führen oft zu schwammigen Aussagen, die Entwicklerinnen und Entwickler nicht verstehen. Bei uns ist das anders: der Zugriff auf die Sprachmodelle erfolgt nur über unseren zentralen Proxy, eine Registry für erlaubte Agent Assets wie Skills und MCP-Server, klare Vorgaben für erlaubte Agent Harnesses und Human-in-the-Loop – all das integriert in die Tools, die unsere Entwicklungsteams sowieso schon verwenden.

heise developer: Was ist das eine Learning aus eurem Rollout, das ihr jedem Team mitgeben würdet, das gerade überlegt, KI-gestützte Entwicklung breiter einzuführen?

Oliver: Die für mich wichtigste Erkenntnis ist, dass KI ein Verstärker ist. Gute Praktiken werden verstärkt — aber eben auch schlechte. Das bedeutet: Wer ernsthaft in KI investiert, muss gleichzeitig in Engineering-Kultur und Prozessreife investieren. Erst dann wirkt KI als echter Multiplikator für Qualität, Liefergeschwindigkeit und letztlich auch für die Zufriedenheit der Teams.

Videos by heise

Lukas: Für mich ist ein wichtiges Learning, dass Entwicklerinnen und Entwickler sehr kreativ sind – und das ist auch genau richtig. Wenn es aber zum Beispiel keine offizielle Integration mit dem internen Backlog-Management gibt, wird meist sehr schnell eine – oft sogar mit Hilfe von KI – gebaut, und schon hat man Schatten-IT.

Der einzige Ausweg: Die zentral angebotene Lösung muss schlicht die bessere sein – passend für den Use Case, sicher, und so einfach einzurichten, dass der selbstgebaute Workaround keine attraktive Alternative mehr ist. Wer Entwicklerinnen und Entwickler mit guten Werkzeugen versorgt, muss deren Kreativität nicht bremsen, sondern kann sie gezielt kanalisieren.

heise developer: Oliver, Lukas, vielen Dank für das Interview!

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(map)

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Developer-Häppchen: Security-Patches für GitLab, Postgres und Python

2026-08-15T07:15:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Kleine, aber interessante Meldungshäppchen vom News-Buffet zu pnpm, Django, GitLab, Mojo, Postgres, Zed Delta, Google Credentio, Python und React Native.

(Bild: Natalia Klenova / Shutterstock.com)

15.08.2026, 09:15 Uhr

Lesezeit: 3 Min.

Developer

Von

In unserem leckeren Häppchen-Überblick servieren wir alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:

Das Team hinter pnpm hat den JavaScript-Paketmanager für Version 12 neu in Rust geschrieben. Er bleibt aber bei allen Befehlen, Settings und Formaten kompatibel zu pnpm 11.
GitLab hat die Patch-Releases 19.2.2, 19.1.4, 19.0.6 veröffentlicht, die wichtige Security-Fixes mitbringen, unter anderem für Cross-Site-Scripting-Schwachstellen, die mit ihren CVSS-Werten als schweres Risiko eingestuft sind.
PostgreSQL bekommt einen komplett neuen JDBC-Treiber, der sich derzeit noch in der Pre-Release-Phase befindet. Er optimiert unter anderem die Nebenläufigkeit mit Virtual Threads, die es seit Java 21 gibt. Außerdem aktualisiert Postgres alle noch unterstützten Versionen: 18.6, 17.11, 16.15, 15.19 und 14.24 sowie die dritte Beta von Version 19. Auch hier geht es unter anderem um Sicherheitslücken der Stufe High (8,8).

(Bild: AliaAyah / Shutterstock)

Am 22. und 23. September findet die heise devSec 2026 in Marburg statt. Im Fokus stehen dieses Jahr unter anderem die sichere Software Supply Chain und der Security-Aspekt bei Agentic AI in der Softwareentwicklung.

Das Python-Webframework Django wird künftig regelmäßig alle zwölf Monate erscheinen. LTS-Releases soll es nicht mehr geben, sondern jede Version erhält drei Jahre Support. Die Neuerung greift ab dem für Januar 2028 geplanten Django 2028.
Die Programmiersprache Mojo ist in Version 1.0 erschienen. Die Motivation für die Entwicklung von Mojo war, eine Sprache zu schaffen, die für Machine-Learning-Anwendungen optimiert ist und dabei für den vollständigen Stack von der Hardwareprogrammierung bis zur Businesslogik einsetzbar ist.

Lesen Sie auch

Passkeys in der Praxis – Teil 2: Registrierung und Authentifizierung

Ein gutes Produkt reicht nicht: Sales für Entwicklerinnen und Entwickler

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Effizient, aber nicht authentisch: Wenn Agenten nur noch mit Agenten reden

2026-08-15T05:45:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Maschinen schreiben Issues und Maschinen beantworten sie. Auch E-Mails kommen immer öfter vom Agenten. Gefährlich wird es, wenn keiner darüber redet.

(Bild: Wolf Hosbach/iX/KI)

15.08.2026, 07:45 Uhr

Lesezeit: 11 Min.

Developer

Von

Stefan Wintermeyer

Letztens hat einer meiner langjährigen Kunden ein Issue in einem unserer GitHub-Projekte eröffnet. Saubere Überschrift, darunter ein Befund: fehlende Alt-Texte auf Bildern, Verweis auf WCAG 1.1.1 zur Accessibility, dazu eine korrekt analysierte Anomalie in unserem Datenbankschema und schließlich das Angebot, für rund 1.500 Bilder inhaltlich geprüfte Alt-Texte zu liefern. Fachlich gab es nichts zu meckern. Trotzdem stimmte etwas nicht. Kein Gruß, kein persönliches Wort, und der Text erklärte mir mein eigenes Projekt so geduldig, als wäre ich gestern neu dazugestoßen. So schreibt nicht der Mensch, mit dem ich seit gut zehn Jahren zusammenarbeite. So schreibt sein KI-Agent.

Stefan Wintermeyer ist Consultant und Trainer für Software- und Systemarchitektur. Fokus: Phoenix, Ruby on Rails, Web-Perf, Asterisk/VoIP, KI und Agentic Programming, effektive Workflows und nutzerseitige Verhaltensmuster.

Geantwortet habe ich natürlich auch nicht selbst. Claude Code hat das Issue analysiert, den Fix gebaut, einen ausführlichen Kommentar hinterlassen und das Issue geschlossen. Höflich, gründlich, mit einem Gegenvorschlag zum Datenformat des Kunden. Als ich die Antwort später las, blieb ich an einem Gedanken hängen: Hier sprechen nicht mein Kunde und ich miteinander. Hier reden zwei Maschinen, und wir Menschen lesen bestenfalls noch Protokoll.

Mein Agent ist höflicher als ich

Seit über einem Jahr läuft meine GitHub-Kommunikation fast vollständig über einen Agenten. Nur selten tippe ich noch selbst einen Kommentar. Die Bilanz fällt eindeutig aus: Ich bin deutlich produktiver geworden. Und, das gebe ich ungern zu, zu den meisten Menschen auch freundlicher. Amerikaner sagen mir seit Jahren, dass ich nichts sugarcoate: Deutsche Direktheit wirkt im Englischen schnell ruppig, meine erst recht. Umgekehrt überlese ich als Deutscher manche höflich verpackte Botschaft komplett. Schreibt ein amerikanischer Reviewer unter meinen Pull Request „You might want to consider adding a test here“, lese ich einen unverbindlichen Vorschlag, über den ich bei Gelegenheit mal nachdenken kann. Gemeint ist: Ohne Test wird das hier nicht gemergt. Und sein „Interesting approach!“ ist kein Lob, sondern höflich verpackte Skepsis. Mein Agent erkennt diese sprachlichen Codes in beide Richtungen.

Dazu kommt ein Luxus, den mir kein Mensch bieten könnte: Ich kann mit dem Agenten so reden, wie ich mich gerade fühle. Super unfreundlich, wenn mich etwas nervt. Super happy, wenn ein Fix endlich sitzt. Dem Agenten ist das egal, er ist ja nie beleidigt. Er kümmert sich darum, dass die Botschaft ankommt, ohne dass sich am anderen Ende jemand auf den Fuß getreten fühlt.

Videos by heise

Für meine Open-Source-Projekte ist er ein Lebensretter. Eines davon ist vutuv, eine quelloffene Alternative zu LinkedIn, die ich als einziger Entwickler betreue. An manchen Tagen kommen dort dutzende Feature Requests herein, dazu hin und wieder ein paar Bug-Meldungen. Als Einzelkämpfer ist man damit schnell überfordert, jedenfalls ohne einen Agenten an der Seite. Auf ausführliche Antworten zu Issues hatte ich früher oft weder Zeit noch Lust. Verdient hätten die Menschen dahinter sie trotzdem. Wer sich die Mühe macht, einen Fehler ordentlich zu melden, bekommt jetzt eine ordentliche Antwort und am Ende ein ehrliches Dankeschön. Und diese Antwort hat mehr Substanz, als ich je hineintippen würde: Der Agent weiß haarklein, wie er und ich gemeinsam den Fehler behoben haben, wie langwierig und kompliziert das war und welche Fallstricke unterwegs lauerten. Er war ja dabei. Mir fehlt die Zeit, das alles aufzuschreiben, ihm nicht. Win-win für alle Beteiligten.

Damit das nach mir klingt und nicht nach Pressestelle, habe ich dem Agenten eigene Tonfall-Regeln geschrieben. In meiner CLAUDE.md, der zentralen Konfigurationsdatei, stehen Anweisungen wie: Schreibe in der ersten Person, warm und freundlich. Nenne kurz den Grund, dann hör auf, kein Füllmaterial. Wenn ich etwas ablehne, nie als plattes Nein, sondern freundlich und mit dem Warum. Und wenn der Thread auf Deutsch geführt wird, antworte auf Deutsch.

Es gibt auch eine weniger vorzeigbare Seite. Manche Open-Source-Diskussionen fressen Zeit, ohne je irgendwo anzukommen. Dann sage ich Claude Code: „Mach hier bitte einen Deckel drauf. Die Sache ist entschieden, ich mag das nicht ewig weiterdiskutieren.“ Der Agent bleibt daraufhin freundlich beim Nein und schließt im Zweifel das Issue. Ich delegiere in diesem Moment etwas anderes als Arbeit: nämlich einen Konflikt. Ob die Betroffenen ahnen, dass eine Maschine den Schlussstrich gezogen hat? Vermutlich nicht. Wie es sich umgekehrt anfühlt, wenn ein Maintainer meine sorgfältig geschriebene Bug-Meldung von einem Agenten abmoderieren lässt, weiß ich dagegen nicht. Bisher war ich immer der, der den Deckel in der Hand hält.

Das Minenfeld bekommt eine zweite Ebene

Textkommunikation war schon immer ein Minenfeld. Ironie kommt nicht an, Knappheit wird als Kälte gelesen, ein fehlendes Smiley verschiebt die Bedeutung eines ganzen Absatzes. Bisher half die Erfahrung mit dem Absender: Nach ein paar Jahren weiß ich, wie mein Kunde klingt, wenn er sich freut, und wie, wenn es brennt. Diese Kalibrierung läuft jetzt ins Leere. Der Ton, den ich lese, stammt von einem Werkzeug und dessen Konfiguration. Wenn eine Seite das nicht weiß, entstehen Missverständnisse zwischen zwei Personen, die an dem Gespräch gar nicht teilgenommen haben.

Wie selten bei agentengeschriebenen Pull Requests überhaupt noch ein Mensch draufschaut, ist inzwischen ausgezählt (siehe Textbox „Studienlage: Agenten prüfen Agenten“). Nicht selten liegt morgens eine E-Mail in meinem Postfach, der ich ansehe, dass ein Agent sie geschrieben hat. Marketingleute haben diese Werkzeuge längst genauso für sich entdeckt wie wir Entwickler. Manche Menschen kommunizieren sogar ausschließlich so: Sie lassen Systeme wie OpenClaw ihre E-Mails und Tweets vollautomatisch beantworten. Wer ihnen schreibt, bekommt eine Antwort von jemandem, der die Nachricht nie gelesen hat.

Zwei Übersichtsarbeiten von 2024 zu KI-Agenten in der Softwareentwicklung ordnen das Feld. Junwei Liu und Kollegen werten Arbeiten zu LLM-Agenten in der Softwareentwicklung aus – inzwischen sind es 124 – und behandeln Multi-Agenten-Systeme sowie die Zusammenarbeit von Mensch und Agent in eigenen Kapiteln. Yanlin Wang und Kollegen legen daneben eine Architektur aus Wahrnehmung, Gedächtnis und Aktion vor.

Spannender als die Überblicke sind die Messungen, und die gibt es seit 2026. Grundlage ist meist AIDev, ein Datensatz von Hao Li, Haoxiang Zhang und Ahmed E. Hassan: 932.791 Pull Requests, die fünf Agenten (Codex, Devin, Copilot, Cursor und Claude Code) in 116.211 GitHub-Repositories eröffnet haben, Stand August 2025.

Darauf aufbauend hat eine polnische Gruppe um Kacper Duma jene 33.596 agentengeschriebene Pull Requests untersucht, die in Projekten mit mehr als 100 Sternen liegen. 61,38 Prozent davon bekommen überhaupt kein Review. Von denen, die eines bekommen, werden 58,77 Prozent ausschließlich von anderen Agenten begutachtet und nur 10,14 Prozent ausschließlich von Menschen. Zusammengerechnet durchlaufen 84 Prozent aller agentengeschriebenen Pull Requests entweder kein Review oder nur eines, an dem kein Mensch beteiligt war. Von sämtlichen Review-Kommentaren stammen 71,58 Prozent von Agenten.

Wie viel von alldem überhaupt sichtbar ist, steht auf einem anderen Blatt. Arsham Khosravani und Audris Mockus haben 180 Millionen Repositories nach Agentenspuren durchsucht und kommen auf über 320.000 Commits pro Monat. Wer sich auf die offiziellen Bot-Accounts verlässt, übersieht den Großteil davon: Bei Claude Code fanden die beiden 850.157 Commits, von denen die Bot-Suche nur 28.154 erfasste, also 3,3 Prozent. Der Rest läuft unter menschlichem Namen.

Eine Ebene bleibt unvermessen: Wie oft ein Mensch am Ende gar nicht mehr mitliest, weiß niemand. Die Zahlen erfassen Pull Requests und Reviews, nicht die Frage, ob der Kunde sein eigenes Issue je gelesen hat.

Zum zweiten Thema dieses Artikels, der Offenlegung, liefert die Organisationsforschung die Zahlen. Die im Text zitierte Arbeit von Oliver Schilke und Martin Reimann stützt sich auf dreizehn Experimente mit über 5.000 Teilnehmern, quer durch Rollen und Branchen, vom Professor über den Analysten bis zum Investmentfonds. Den Vertrauensverlust in Texte, die als KI-generiert offengelegt sind, erklären die beiden mit geringerer wahrgenommener Legitimität, nicht mit Zweifeln an der Qualität des Ergebnisses. Bei Befragten mit positiver Technikeinstellung fällt er schwächer aus, verschwindet aber nicht.

Meinem Kunden habe ich nach dem Issue von heute Morgen eine SMS geschrieben und das Thema offen angesprochen. Das hat die Sache ohne Verstimmung entschärft. Wir wissen jetzt beide, dass unsere Agenten miteinander reden. Unausgesprochen wäre die Kommunikation ein schleichendes Gift geworden. Er hätte sich irgendwann gefragt, warum ich so distanziert schreibe. Ich hätte mich gefragt, warum er mich neuerdings für begriffsstutzig hält.

Brandgefährlich ist das Ganze ausgerechnet bei Menschen wie ihm: bei denen, mit denen ich seit Jahren eng zusammenarbeite, ob im Kundenprojekt oder bei Open Source. Sie kennen mich persönlich, und genau deshalb richtet ein fremder Ton den größten Schaden an. Da steht ein Text, der schlicht nicht ich bin, und der Empfänger kennt mich gut genug, um genau das zu spüren. In gewachsenen Arbeitsbeziehungen kann er die Kommunikation zerreißen.

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

.NET 11.0 Preview 7 bringt viele Neuigkeiten und Breaking Changes

2026-08-13T14:34:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die siebte Preview bringt abermals eine Spracherweiterung für C#, verbesserte Komprimierungs-APIs und neue Features für Blazor.

(Bild: Pincasso / Shutterstock.com)

13.08.2026, 16:34 Uhr

Lesezeit: 16 Min.

Developer

Von

Dr. Holger Schwichtenberg

.NET 11.0 Preview 7 gibt es kostenfrei zum Download bei Microsoft. Dabei handelt es sich um die letzte Preview-Version vor dem ersten Release Candidate. Parallel dazu ist ein Update für Visual Studio 2026 Insiders auf die Version 12106.202 erschienen.

Dr. Holger Schwichtenberg hat Fachbücher zu .NET 10.0, C# 14.0, Blazor 10.0 und Entity Framework Core 10.0 veröffentlicht. Er arbeitet als Berater und Trainer bei www.IT-Visions.de.

Installation des .NET 11.0 SDK in der Version Preview 7 (Abb. 1)

Mehr Schleifenkontrolle: break und continue mit Bezeichnern

Die Sprachkonstrukte break zum Abbrechen und continue zum vorzeitigen Fortsetzen von Schleifen gibt es in den meisten Programmiersprachen, so auch in C# seit der ersten Version. Nun ergänzt Microsoft aber eine bislang in C# fehlende Option: Entwicklerinnen und Entwickler können hinter break und continue jeweils Namen angeben, die sich auf äußere Schleifen beziehen. Damit kann der Compiler nicht nur die jeweils direkt umgebende Schleife, sondern auch übergeordnete Schleifen abbrechen oder vorzeitig fortsetzen. Ein solches Label kann man bei den Schleifenkonstrukten for, foreach, while und do sowie bei der Verzweigung mit switch einsetzen.

(Bild: King / stock.adobe.com)

Das ist neu in .NET 11.0: Dr. Holger Schwichtenberg und weitere Experten präsentieren am 17. November 2026 auf der Online-Konferenz betterCode() .NET 11.0 die Änderungen für Entwicklerinnen und Entwickler. Tickets zum Frühbucherpreis sind im Online-Shop verfügbar.

Das folgende Listing zeigt dazu ein Beispiel, in dem vermieden wird, dass die drei Schleifenebenen jeweils einzeln abgebrochen werden müssen, wenn ein passender Regalplatz gefunden wurde.

public void Run()
 {
  List<string> Gaenge = ["A", "B", "C", "D", "E"];
 
  // bool sackgasse = false; // --> nicht notwendig dank continue mit Label
  // bool gefunden = false; --> nicht notwendig dank break mit Label
 
 regalgangSchleife:
  foreach (var regalgang in Gaenge)
  {
   for (int regal = 1; regal <= 20; regal++)
   {
    for (int platz = 1; platz <= 50; platz++)
    {
     // Sackgasse: In einigen Regalen gibt es Sackgassen
     if (regal % 2 == 1 && platz % 13 == 0)
     {
      CUI.Warning($"Sackgasse: Gang={regalgang}/Regal={regal}/Platz={platz}");
      // sackgasse = true; --> nicht notwendig dank continue mit Label
      continue regalgangSchleife;
 
     }
     CUI.Print($"Prüfe Gang={regalgang}/Regal={regal}/Platz={platz}");
 
     bool istFrei = IstFrei(regalgang, regal, platz);
     bool istGrossGenug = IstGrossGenug(regalgang, regal, platz);
 
     if (istFrei && istGrossGenug)
     {
      CUI.Success($"Gefunden: Gang={regalgang}/Regal={regal}/Platz={platz}");
 
      // gefunden = true; --> nicht notwendig dank break mit Label
      break regalgangSchleife;
     }
    }
    // if (sackgasse) continue; --> nicht notwendig dank continue mit Label
    // if (gefunden) break; --> nicht notwendig dank break mit Label
   }
   // if (sackgasse) continue; --> nicht notwendig dank continue mit Label
   // if (gefunden) break; --> nicht notwendig dank break mit Label
  }
 }

Listing 1: Einsatz von Labels bei break und continue

Der Compiler prüft, ob sich der hinter break oder continue angegebene Bezeichner auf eine Schleife oder ein switch bezieht (Abb. 2).

Lesen Sie auch

.NET 11.0 Preview 6: Union Types machen sich in den .NET-Bibliotheken breit

.NET 11.0 Preview 5 vereinfacht das statische serverseitige Rendering in Blazor

Union Types werden in .NET 11.0 Preview 3 endlich nutzbar

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

LiteLLM-Angriff: Mehr als 2500 Unternehmen betroffen

2026-08-13T11:01:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

IT-Forscher haben Zugriff auf die abgeflossenen Daten von tausenden Firmen beim LiteLLM-Supply-Chain-Angriff aus dem März erhalten.

(Bild: William Potter/Shutterstock.com)

13.08.2026, 13:01 Uhr

Lesezeit: 3 Min.

Security

Von

Dirk Knop

Bei einem Lieferkettenangriff auf die populäre LiteLLM-Bibliothek im März dieses Jahres haben Angreifer im Python Packages Index (PyPI) kompromittierte Pakete eingeschleust. Diese wurden offenbar von automatisierten Build-Systemen zigtausendfach heruntergeladen und verwendet, bei mehr als 2500 auch namhaften Unternehmen – obwohl die kompromittierten Pakete lediglich 40 Minuten online waren.

Die Angreifer haben potenziell rund 434.000 automatisierte Entwickler-Build-Pipelines unterwandert, die bei mehr als 2500 Firmen zum Einsatz kommen, führen die IT-Sicherheitsforscher von CloudSEK in einem Blogbeitrag aus. Die Daten deuten darauf hin, dass Angreifer darauf hätten zugreifen können, belegen jedoch nicht, dass sie das auch getan haben und dass alle Zugangsdaten entwendet wurden. Laut den Analysten ist die Bedrohung noch immer aktuell, da auch das FBI im Juli davor gewarnt hat, dass mit der Cybergang TeamPCP verbundene Akteure die gestohlenen Zugangsdaten wahrscheinlich noch lange nach dem eigentlichen Angriff missbrauchen. Daher sollten potenziell Betroffene Sicherheitsmaßnahmen wie Ändern der Zugangsdaten, Schließen der möglichen Schwachstelle und Härtung der Systeme ergreifen, empfehlen die IT-Forscher.

Die Auflistung betroffener Unternehmen führt einige große und namhafte Firmen auf. Airbus, Amazon Web Services, Cisco, Hoffmann-La Roche AG, Salesforce, Samsung, ServiceNow, Siemens, aber auch Epic Games, FedEx, der Rückversicherungsriese Munich Re, die Robert Bosch GmbH, Thales Group, Volkswagen AG oder X Corp tauchen dort auf. Von denen und vielen weiteren haben die Angreifer teils Geheimnisse wie Zugangsdaten ergattert, in allen Fällen liefen jedoch in den automatisierten KI-Build-Systemen die kompromittierten Versionen – zum Teil tausende Male.

Entwendete Objekte

Zu den geklauten Daten zählen laut CloudSEK Cloud-Keys, Repository-Token, SSH-Keys, Kubernetes-Secrets, Zugangsdaten für Paket-Publishing, Umgebungsvariablen und KI-Anbieter-Keys. Das Entfernen der bösartigen Pakete allein reicht daher nicht, da derartige Zugangsdaten noch Wochen oder Monate nutzbar bleiben, sofern sie nicht geändert und Hinweise auf unbefugte Aktivitäten untersucht werden.

Die Infostealer-Malware, die Google „Sandclock“ nennt, lief auf kompromittierten Build-Systemen, weitete ihre Rechte zu root aus und suchte dann nach den Daten. Insbesondere auf KI-Build-Systemen sucht sie nach LLM-API-Keys und Gateway-Konfigurationen. Die Daten haben die Angreifer mit AES-256 und einem fest einprogrammierten RSA-4096-Key verschlüsselt und an Server gesendet, die eine Typosquatting-Domain nutzten. Wenn das Ausschleusen fehlschlägt, legt die Malware ein öffentliches Repository innerhalb des GitHub-Kontos der Opfer an und verfrachtet die Daten dorthin.

Videos by heise

CloudSEK gibt in der Analyse noch weitere Tipps und Hinweise für Admins, wie sie eine Kompromittierung aufspüren, eindämmen und wie sie sich vor den Attacken schützen können.

(dmk)

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Neue Docker-Virtualisierung: Schneller Start und besseres Speichermanagement

2026-08-13T08:47:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Schneller und effizienter: Docker trennt sich von den bisherigen Komponenten zur Virtualisierung und stellt eine eigene Entwicklung vor.

(Bild: Wolf Hosbach / KI / iX)

13.08.2026, 10:47 Uhr

Lesezeit: 1 Min.

Developer

Von

Wolf Hosbach

Docker hat eine neue, selbst entwickelte Virtualisierungsschicht, Docker Virtual Machine Manager (VMM) 4.86, angekündigt. Sie soll effizienter, schneller und besser zu managen sein als die bisherigen Komponenten.

Docker VMM 4.86 ersetzt die bisherigen Virtualisierungen libkrun unter macOS und WSL 2 unter Windows. Als Vorteile hebt Docker hervor, dass VMM dem Host beim Speichermanagement ungenutzten Speicher automatisch zurückgibt, wenn Container nicht aktiv sind. So belegt Docker Desktop Arbeitsspeicher nur während deren Aktivität. Außerdem verbessert der VMM den Datenaustausch zwischen Host und Container, indem sich Latenzzeiten reduzieren. Schließlich soll die neue Technik die Startzeit der Engine und der Container verkürzen.

Die Virtualisierungsschicht von Docker sitzt zwischen Host und der Docker Engine.

(Bild: Docker)

Speziell unter Windows soll die neue Engine die Stabilität verbessern und die volle Isolation von Hyper-V mit der Geschwindigkeit von WSL2 kombinieren.

Videos by heise

VMM in Version 4.86 verlangt mindestens 4 GB Arbeitsspeicher auf der Linux-Maschine. Nach dem Wechsel ist unter Umständen ein Neustart nötig. Ein Problem gibt es noch mit Bind Mounts bei Auto-Shares: Tritt der Fehler „file is not shared from the host“ auf, ist eine händische Freigabe erforderlich.

Die neue Virtualisierung liegt auch den Docker Sandboxes (SBX) zugrunde und soll auf Dauer als Basis für eine plattformübergreifende, einheitliche Runtime dienen. Die allgemeine Verfügbarkeit ist für Ende Oktober 2026 geplant und VMM soll dann standardmäßig bei Docker Desktop aktiv sein.

Lesen Sie auch

c’t-Workshop: Container sicher planen, automatisieren und betreiben

Wie man den Passwortsafe Vaultwarden selbst hostet

Container-Images ohne CVEs: BellSofts neuer Buildpacks-Builder

Podman 6 baut Docker-Kompatibilität aus

GitHub-Alternative Forgejo mit Actions zur automatisierten Codeschmiede machen

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Gratis Delphi 13 Vollversion bietet komplette IDE für Windows und Mobile

2026-08-12T09:15:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit der Community Edition stellt Embarcadero eine komplette Entwicklungsumgebung für Windows und Mobile gratis zur Verfügung.

(Bild: Wolf Hosbach / KI / iX)

12.08.2026, 11:15 Uhr

Lesezeit: 1 Min.

Developer

Von

Wolf Hosbach

Embarcadero hat die Community Edition von Delphi 13 freigegeben. Sie basiert auf Delphi 13 Florence und umfasst die komplette IDE inklusive der Tools VCL und FireMonkey, ist aber auf private, akademische und Start-up-Nutzung eingeschränkt.

Unternehmen, die die Gratis-Edition einsetzen wollen, dürfen nicht mehr als fünf Entwicklerinnen oder Entwickler beschäftigen und nicht mehr als 5000 US-Dollar umsetzen. Die Lizenz ist zudem auf ein Jahr begrenzt, was Embarcadero bei Vorgängerversionen aber regelmäßig verlängert hat.

Videos by heise

Neu in Version 13 ist die Unterstützung weiterer Plattformen: Es gibt eine 64-Bit-Version der IDE für Windows mit einem zugehörigen Language Server. Außerdem lässt sich nun die ARM-Plattform als Compiler-Ziel einstellen. Für die Android-Toolchain gibt es ein Update auf API-Version 35, die Funktionen von Android 15 umfasst. Bei iOS unterstützt der Compiler Version 18. Die kommerzielle Version 13.1 von Delphi geht hier mit Android 16 und iOS 26 deutlich weiter.

Für die plattformübergreifende Entwicklung enthält die Community Edition das Tool FireMonkey, das der Hersteller durch das GPU-beschleunigte Kopieren von Bitmaps und flüssigere Animationen optimiert hat. Das Framework VCL für die Windows-Entwicklung verbessert die Integration von WebView2, um Edge-Anwendungen nativen Zugriff aufs System zu erlauben.

Delphi ist aus Pascal hervorgegangen und hat vergangenes Jahr sein 30-jähriges Jubiläum gefeiert.

(who)

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Ein gutes Produkt reicht nicht: Sales für Entwicklerinnen und Entwickler

2026-08-12T07:12:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Vertrieb gilt vielen Entwicklerinnen und Entwicklern als notwendiges Übel. Oliver Gehrmann erklärt im Interview, warum Sales vor allem ein Handwerk ist.

(Bild: Manuel Masiero / KI / iX)

12.08.2026, 09:12 Uhr

Lesezeit: 15 Min.

Developer

Von

Golo Roden

Viele Entwicklerinnen und Entwickler träumen davon, mit einem eigenen Produkt erfolgreich zu sein – und unterschätzen dabei fast reflexhaft, welche Rolle der Vertrieb spielt. Sales gilt in der Szene oft als notwendiges Übel, im schlimmsten Fall als etwas Anrüchiges.

Oliver Gehrmann kennt beide Welten: Er hat als IT-Consultant mit den Schwerpunkten DevOps und Cloud begonnen und ist heute Head of Sales der Public Cloud Group. Damit ist er der ideale Gesprächspartner, um mit dem Thema aufzuräumen – jenseits der Klischees und mit dem Blick von jemandem, der den Weg von der Technik in den Vertrieb selbst gegangen ist.

Vom IT-Consultant zum Head of Sales

Du bist Head of Sales der Public Cloud Group. Was genau kann man sich darunter vorstellen? Was machst du, was gehört zu deinen Aufgaben, womit beschäftigst du dich?

Oliver Gehrmann: Ich leite den Vertrieb für unsere Business-Unit im Security- und Compliance-Bereich. Meine meiste Zeit verbringe ich möglichst nah an unseren Kunden, um immer ein aktuelles Verständnis zu haben, was am Markt wirklich passiert, wie sich Bedürfnisse ändern und wie wir echte Mehrwerte liefern können.

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Darüber hinaus arbeite ich eng mit meinen Vertriebsmitarbeitern zusammen, strukturiere Deals, helfe ihnen bei der Weiterentwicklung und stehe als Sparringspartner zur Verfügung.

Ebenfalls verantworte ich die gesamte Neu- und Bestandskundenakquise, bin also nah am Markt, entwickle neue Angebote oder verbessere unsere bestehenden, habe unsere Akquisekanäle im Auge und verantworte Budgets, Zahlen und Forecasts.

Bevor wir tiefer einsteigen: Dein Weg dorthin ist bemerkenswert. Ursprünglich hast du als IT-Consultant mit den Schwerpunkten DevOps und Cloud gearbeitet – also klar auf der technischen Seite. Wie kam es zum Wechsel in den Vertrieb? Was war der Auslöser, und was hat dich an Sales gereizt, das du in der Technik so nicht gefunden hast?

Oliver Gehrmann

(Bild: Oliver Gehrmann)

Oliver Gehrmann leitet den Vertrieb der Business-Unit Security & Compliance bei der Public Cloud Group. Er tauscht sich regelmäßig direkt mit Kunden aus, um Marktbedürfnisse frühzeitig zu erkennen. Neben der Steuerung von Neu- und Bestandskundenakquise verantwortet er Budgets, Forecasts und die Weiterentwicklung des Angebotsportfolios. Intern agiert er als Sparringspartner für sein Vertriebsteam – von der Deal-Strukturierung bis zur persönlichen Weiterentwicklung der Mitarbeitenden.

Oliver Gehrmann: Der Auslöser kam bereits sehr früh in meiner Ausbildung zum Fachinformatiker, als mein damaliger Chef mir sagte, dass er mich eher im Vertrieb anstatt in der Technik sieht. Damals ist da natürlich eine Welt für mich zusammengebrochen, weil all meine „Vorbilder“ in der Firma Techniker waren. Heute weiß ich aber genau, was er meinte. Die Arbeit mit Menschen und das Finden von kreativen Lösungen lag mir schon immer mehr als das Tief-Technische.

Videos by heise

Über meine Arbeit als Consultant im DevOps-Bereich habe ich mich dann immer mehr von der Technik auf beratende und strategische Themen fokussiert, woraus dann in meiner ersten Firmengründung ganz natürlich eine immer vertriebslastigere Position entstanden ist, ohne dass ich es wirklich gemerkt habe. Mein „Vertrieb“ war also quasi die Kundenberatung, welche Lösung die optimale ist, und so denke ich auch heute noch. Ein guter Vertriebler muss dem Kunden nichts aufquatschen, sondern dabei helfen, echte Lösungen mit Mehrwert zu finden.

Was ist dran am Klischee vom Verkäufer?

Viele Menschen haben keine allzu hohe Meinung von Sales. Man denkt sofort an das Klischee des unseriösen Autoverkäufers. Was würdest du diesem Vorurteil entgegnen?

Oliver Gehrmann: Gerade in Deutschland haben viele bei dem Gedanken an Vertrieb den klassischen Staubsaugervertreter im Kopf, der arme Hausfrauen so lange belabert, bis sie weich werden und kaufen. In den USA ist das beispielsweise komplett anders. Dort ist Vertrieb ein sehr angesehener Beruf und wird als das wahrgenommen, was er eigentlich ist: ein Berater, der dem Kunden hilft, die richtige Lösung zu finden. Natürlich gibt es schwarze Schafe, die ausschließlich auf den Abschluss schauen, aber diese Menschen sind vertrieblich meiner Erfahrung nach nie erfolgreich.

Die besten Vertriebler, die ich kennenlernen durfte, sind extrem empathische Menschen, die an anderen ernsthaft interessiert sind und sich dafür einsetzen, die Erwartungen des Kunden zu übertreffen. Genauso baut man langfristige Beziehungen auf, verschafft sich einen guten Ruf und wird auch gerne weiterempfohlen, was, wie ich finde, die schönste Form der Anerkennung seiner Kunden ist. Klassische Kaltakquise, wie sich viele ja den Vertrieb vorstellen, ist so gar nicht mehr nötig, weil Kunden über Empfehlungen kommen oder von sich aus bei dir anfragen, weil sie dich schon online kennengelernt haben. So macht der Vertrieb dann auch richtig Spaß, weil du niemanden mehr überzeugen musst, sondern nur mit Leuten sprichst, die mit dir auf Augenhöhe sind.

Viele Entwicklerinnen und Entwickler wünschen sich, mit einem eigenen Produkt erfolgreich zu sein. Mir fällt immer wieder auf, dass der Glaube vorherrscht, man müsse dafür lediglich ein sehr gutes Produkt entwickeln. Wie siehst du das?

Oliver Gehrmann: Ein gutes Produkt ist für mich die Voraussetzung für alles und auch wieder die Basis dafür, von seinen Kunden Vertrauen entgegengebracht zu bekommen. Wenn ich ein schlechtes Produkt verkaufe, werden automatisch all diese Vorurteile wahr, die wir über Vertriebler kennen: müssen den Kunden überreden, jagen skrupellos den Abschlüssen hinterher, interessieren sich nicht mehr für den Kunden, sobald die Unterschrift da ist. Das wollen wir nicht.

Dennoch wird niemand von dir und deinem Produkt erfahren, wenn du nicht sichtbar wirst. In der heutigen Zeit finden 80 Prozent des Vertriebs online statt. Wenn ich eine neue Waschmaschine kaufe, mache ich mich durch LLMs, Google und eigenen Research schlau, welches das für mich ideale Modell ist, und gehe maximal noch in ein Fachgeschäft, um die Bestellung aufzugeben oder mir ein finales Bild vor Ort zu machen.

Mit Services und Produkten, die wir verkaufen, ist es nicht anders. Noch nie waren Endkunden besser informiert als heute. Daher ist es gerade so wichtig, eine Top-Reputation zu haben, sichtbar zu sein und dem Kunden möglichst viele Gelegenheiten zu bieten, dich schon vor dem ersten Kontaktpunkt kennenzulernen. Wichtig dabei ist immer, dass Menschen von Menschen kaufen. Nicht ohne Grund haben Steve Jobs, Bill Gates, Elon Musk und Co. viel mehr Reichweite als ihre eigentlichen Firmen. Und genauso muss es mit dir als Gründer auch sein. Wenn du deine eigene Story erzählst und aufzeigst, was dich bewegt hat, dein Produkt zu entwickeln, und die Leute an deinem Weg teilhaben lässt, fällt es um ein Vielfaches einfacher, eine Beziehung aufzubauen, als mit einer unpersönlichen Marke.

Vertrieb ist ein Handwerk

Genau wie Software entwickeln zu können, ist auch Sales eine Mischung aus Handwerk und Kunst. Was überwiegt für dich, und woran machst du das fest?

Oliver Gehrmann: Ich werde oft gefragt, ob man nicht zum Vertriebler geboren sein muss. Natürlich hilft es, Spaß am Kontakt mit Menschen zu haben, aber der „Vertrieb“ an sich ist ein Handwerk wie jedes andere. Tatsächlich sieht man in der Praxis oft viel Freestyle und Gespräche, die ins Leere führen, weil sie keinem klaren Prozess folgen. Bei uns war es so, dass, je klarer der Prozess wurde, auch unsere Abschlussquoten massiv stiegen. Dazu gehört eine glasklare Qualifizierung, ob der Kunde überhaupt zu einem passt. Dafür gibt es Frameworks wie BANT (Budget, Authority, Need, Timing), um schon im Erstgespräch zu evaluieren, ob erstens überhaupt Budget für ein Projekt vorhanden ist, zweitens unser Gesprächspartner die finale Entscheidung treffen darf, drittens ein echter Bedarf vorhanden ist oder der Kunde sich nur informieren will, und viertens ob der Kunde auch zeitnah starten kann. Nur nachdem diese Punkte klar sind, ergibt es auch Sinn, in dem Prozess weiter fortzufahren.

Wie lernt man das? Kann man Sales überhaupt vollumfänglich lernen oder bleibt am Ende immer ein Quäntchen, das vom persönlichen Talent abhängt?

Oliver Gehrmann: 20 Prozent sind Talent, 80 Prozent Skill, den man lernen kann. Es gibt Unmengen an Sales-Trainings, die ich besucht habe, von Philipp Semmelroth, Volker Hein, den Baulig-Brüdern und so weiter. Keiner ist perfekt, aber jeder bietet ein Buffet an Skills und Tricks, an denen man sich bedienen kann, um seinen eigenen Prozess zu verbessern. Kombiniert mit viel Übung und Erfahrung entsteht so über die Zeit ein maßgeschneiderter Prozess, der replizierbar ist und mit dem du und auch deine Kunden sich wohlfühlen, ohne Druck zu erzeugen.

Du bist den Weg von der Technik in den Vertrieb selbst gegangen. Würdest du Entwicklerinnen und Entwicklern rückblickend empfehlen, sich (pro)aktiv mit dem Thema Sales zu beschäftigen, auch wenn sie gar nicht vorhaben, den Beruf zu wechseln?

Oliver Gehrmann: Ein guter Freund von mir, Maurice Bork, hat das Buch „Du kannst nicht nicht verkaufen“ geschrieben, in dem es genau um das Thema geht, dass wir uns eigentlich immer verkaufen; sei es in der Gehaltsverhandlung mit dem Chef, auf einem Date oder wenn wir unseren Kindern „verkaufen“, warum Brokkoli für sie gesund ist. Grundlegende Sales-Skills bringen uns im Leben massiv voran. Gerade dort, wo man die größten Widerstände spürt, liegt in der Regel das größte Wachstum. Wenn ihr beim Lesen noch immer denkt, dass Sales euch nicht weiterbringt und ihr nur technisch besser werden müsst, um das nächste Karrierelevel zu erreichen, dann nehmt euch wirklich mal die Zeit, das zu hinterfragen. Bucht doch einfach mal das nächste Sales-Seminar über ein bis zwei Tage und schaut, ob ihr was mitnehmen könnt. Im Worst Case habt ihr etwas Zeit verschwendet, aber habt die Sicherheit, zu sagen, dass euch Sales wirklich nichts bringt. Und Klarheit ist immer besser als Annahmen.

Der Gründer als erster Vertriebler

Gerade am Anfang ist der Gründer selbst der erste Vertriebler, ob er will oder nicht. Was machen technische Gründerinnen und Gründer im Verkauf oft überraschend gut, und wo liegen ihre typischen blinden Flecken?

Oliver Gehrmann: Die Antwort ist ganz einfach. Gründer sind von ihrem Produkt überzeugt. „Du kannst in anderen nur entzünden, was in dir selbst brennt“, sagte schon der Philosoph Augustinus von Hippo vor rund 1600 Jahren. Es gibt niemanden, der mehr von seinem Produkt überzeugt ist als der Gründer. Sonst wärst du nicht so wahnsinnig, dich selbstständig zu machen und das Risiko einzugehen, das damit verbunden ist. Und andere Menschen spüren diese Überzeugung zu 1000 Prozent. Das damit verbundene Risiko kommt aber erst bei der Skalierung zum Vorschein. Der Gründer ist irgendwann daran gewöhnt, automatisch „gut“ zu verkaufen, und ist dann schnell enttäuscht, wenn die ersten Vertriebsmitarbeiter nicht genauso pitchen können. Aber die Erwartungshaltung ist falsch. Der beste Vertriebler der Welt wird deine eigene Story nie so authentisch erzählen können wie du selbst, und genau deswegen ist es wichtig, gute Prozesse zu haben.

Ein definierter Pitch, Gesprächsleitfäden, Checklisten, Discovery – alles nach Best Practice definiert und so gebaut, dass es immer wieder geübt, verbessert und replizierbar durchgeführt werden kann. Nur so ist es möglich, dass man vertrieblich wachsen kann.

Erzähl doch mal, wie ein guter erster Verkaufskontakt in der Praxis wirklich abläuft. Viele stellen sich darunter einen Pitch vor: Ich rede, das Gegenüber hört zu und sagt am Ende ja oder nein. Wie realistisch ist dieses Bild?

Oliver Gehrmann: Wir messen tatsächlich den Redeanteil in unseren Gesprächen und geben als Faustformel mit, dass der Kunde etwa 70 Prozent Redeanteil haben sollte. Jedes Wort des Kunden, vor allem in Erstgesprächen, ist Gold wert. Mit den richtigen Fragen finden wir genau heraus, was er eigentlich braucht, ob die BANT-Kriterien erfüllt sind und ob wir überhaupt weiterhelfen können.

Der Pitch kommt erst, wenn wir diese ganzen Informationen haben, und dann auch nur in der Kurzform, um dem Kunden Lust auf ein weiteres Gespräch zu machen. Sind alle Voraussetzungen in der Discovery erfüllt, vereinbaren wir einen ausführlichen Termin, in dem dann inhaltlich geplant wird. Mehr „Inhalt“ hat im Erstgespräch nichts zu suchen.

Wann sich der erste Sales-Hire lohnt

Vertrieb heißt auch, permanent Absagen einzustecken. Für viele, die im Modus „Problem lösen – es funktioniert oder eben nicht“ arbeiten, ist das ungewohnt und kann kränken. Wie geht man mit Ablehnung um, ohne zu verhärten oder auszubrennen?

Oliver Gehrmann: Tatsächlich erfahren wir gar nicht so viel Ablehnung, wenn wir unsere Kunden gut qualifizieren, Vertrauen aufgebaut haben, sichtbar sind und guten Prozessen folgen. Ein guter Verkaufsprozess nimmt dem Kunden schon alle Einwände vorweg, die er haben könnte. In der Regel sind das Bedenken, ob wir wirklich der richtige Partner sind und unsere gemachten Versprechen umsetzen können. Meiner Erfahrung nach scheitern Projekte oder Verkaufsprozesse nur selten an Budgetthemen. Wenn wir etwas wirklich wollen und davon überzeugt sind, findet man immer Wege, das Budget zu realisieren.

Angenommen, es läuft, und die Zeit des Gründers reicht nicht mehr aus. Wann ist der richtige Moment für die erste echte Vertriebsstelle und worauf sollte man bei der Besetzung achten? Was macht einen guten ersten Sales-Hire aus?

Oliver Gehrmann: Meiner Erfahrung nach sollte jede Firma einen technisch-operativ geprägten und einen vertrieblich geprägten Gründer haben. Das sind in der Regel immer die erfolgreichsten Setups. Der vertriebliche Gründer sollte dann mindestens 80 Prozent seiner Zeit in Kundengesprächen verbringen, ein Kundenfundament schaffen und möglichst viele Abschlüsse reinholen. Mit Zeit und Erfahrung werden sich Muster ergeben, die man dann systematisieren kann. Welche Einwände gibt es, welche Fragen haben Kunden, welche Probleme ergeben sich bei dem Onboarding von neuen Kunden und so weiter. Diese Muster gilt es dann zu erkennen und systematisch über Prozesse abzubilden.

Sobald man sich sicher ist, dass der Prozess einigermaßen funktioniert, kann man auch anfangen, die ersten Vertriebsmitarbeiter einzustellen. Am Anfang eng geführt mit großem Fokus auf Prozesstreue, und über die Zeit zunehmend lockerer, wenn mehr Erfahrung für Produkt und Kunden da ist. Die besten Vertriebler denken mit und helfen, den Prozess immer weiter zu verbessern, sodass der Einstieg für weitere Mitarbeiter immer leichter fällt, weil es keine Edge-Cases mehr gibt.

Zum Abschluss: Wenn du einer Entwicklerin oder einem Entwickler, die gerade mit einem eigenen Produkt starten, nur einen einzigen Rat zum Thema Sales geben dürftest – welcher wäre das?

Oliver Gehrmann: Generiere so schnell es geht die ersten Kunden. Auch wenn du dein Produkt fast umsonst rausgibst. Das Wichtigste am Anfang ist die Erfahrung, wie deine Kunden das Produkt wirklich nutzen, ob es den Mehrwert bietet, den du denkst, und Testimonials einzusammeln. Ich würde neue Produkte immer erst meinem Netzwerk kostenlos zum Testen anbieten, als Tausch gegen eine Referenz, die Du auch öffentlich auf der Website und Co. verwenden kannst. Nur so baust du eine Trustbase auf, die dann auch Kunden außerhalb deines Netzwerks anzieht.

Vielen Dank, dass du dir die Zeit für dieses Gespräch genommen und deine Erfahrung so offen geteilt hast.

(mro)

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Passkeys in der Praxis – Teil 2: Registrierung und Authentifizierung

2026-08-11T10:14:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die exakten Abläufe bei Registrierung und Anmeldung per Passkey sind komplex. Wer sie kennt, kann das Verfahren sicher und spezifikationsgemäß implementieren.

(Bild: Maika Möbus / KI / iX)

11.08.2026, 12:14 Uhr

Lesezeit: 18 Min.

Developer

Von

Martina Kraus

Passkeys bestehen aus einem kryptografischen Schlüsselpaar, das bei der Registrierung erzeugt und bei jeder späteren Anmeldung wiederverwendet wird. Die genauen Abläufe – bei WebAuthn heißen sie Ceremonies – Registration und Authentication folgen dabei demselben Grundmuster: Der Server generiert eine Challenge, der Client ruft die WebAuthn API auf, der Authenticator signiert, und der Server validiert. Was sich unterscheidet, ist die Richtung: Registration (navigator.credentials.create()) erzeugt ein neues Credential und speichert den Public Key. Authentication (navigator.credentials.get()) beweist den Besitz des zugehörigen Private Key. Wer dieses Muster einmal wirklich versteht, kann alle Validierungsschritte direkt einordnen und erkennt sofort, wo eine Implementierung sicherheitskritische Abkürzungen nimmt.

Martina Kraus beschäftigt sich schon seit frühen Jahren mit der Webentwicklung. Das Umsetzen großer Softwarelösungen in Node.js und Angular hat sie schon immer begeistert. Als selbstständige Softwareentwicklerin arbeitet sie vornehmlich mit Angular mit Schwerpunkt auf Sicherheit in Webanwendungen.

Die Registration Ceremony (§7.1)

Die Registration Ceremony nach §7.1 der W3C-WebAuthn-Level-2-Spezifikation beginnt auf dem Server. Bevor navigator.credentials.create() im Browser aufgerufen werden kann, muss der Server ein PublicKeyCredentialCreationOptions-Objekt zusammenstellen und an den Client senden. Dieses Objekt ist mehr als eine Konfigurationsdatei, denn jedes seiner Felder trifft eine Entscheidung, die sich auf Sicherheit und Nutzererfahrung auswirkt.

PublicKeyCredentialCreationOptions – Feld für Feld

Bevor die einzelnen Felder im Detail besprochen werden, zeigt das folgende Listing, wie ein vollständiges PublicKeyCredentialCreationOptions-Objekt in der Praxis aussieht:

const creationOptions: PublicKeyCredentialCreationOptions = {
  challenge: crypto.getRandomValues(new Uint8Array(32)), // serverseitig generiert
  rp: {
    id: "example.com",
    name: "Example App",
  },
  user: {
    id: crypto.getRandomValues(new Uint8Array(16)), // keine PII!
    name: "martina@example.com",                    // nur für UI
    displayName: "Martina",
  },
  pubKeyCredParams: [
    { type: "public-key", alg: -7   }, // ES256
    { type: "public-key", alg: -257 }, // RS256
  ],
  excludeCredentials: existingCredentialIds.map(id => ({
    type: "public-key",
    id,
  })),
  authenticatorSelection: {
    residentKey: "required",
    userVerification: "required",
  },
  attestation: "none",
  timeout: 60000,
};

Listing 1: PublicKeyCredentialCreationOptions

Das wichtigste Feld ist challenge. Diese ist ein Puffer aus kryptografisch zufälligen Bytes, den der Server generiert – mindestens 16 Bytes müssen es laut Spezifikation sein. In der Praxis haben sich allerdings 32 Bytes bewährt, weil sie einen deutlichen Sicherheitspuffer über dem Minimum bieten, ohne die Nutzlast spürbar zu vergrößern. Die Challenge wird serverseitig gespeichert, bis die Validierungsantwort eintrifft, und darf nur einmal verwendet werden. Ihr Zweck ist es, Replay-Angriffe zu verhindern: Ohne eine frische, serverseitig verifizierte Challenge könnte ein Angreifer eine abgefangene Authenticator-Antwort erneut einspielen.

Das rp-Objekt identifiziert die Relying Party (RP). Aus Teil 1 bekannt ist die Regel: Die id muss eine registrierbare Domain-Teilmenge der aktuellen Origin sein. In der Praxis bedeutet das, dass id entweder die exakte Domain oder eine übergeordnete Domain ist. shop.example.com kann demnach example.com als rpId nutzen, aber nicht umgekehrt. Der name ist ausschließlich für die Authenticator-UI relevant, nicht für die Sicherheit.

Das user-Objekt enthält Informationen über den registrierenden Nutzer. Hier lauert ein häufiger Fehler: Die user.id ist ein opaker – also für Client und Nutzer inhaltlich bedeutungsloser – Byte-Puffer, der keine personenbezogenen Daten enthalten soll, insbesondere keine E-Mail-Adresse und keinen Benutzernamen. Der Authenticator verknüpft das Credential intern mit dieser ID, und sie wird bei der Authentication im userHandle zurückgegeben. Eine zufällig generierte UUID ist die richtige Wahl. Die Spec schreibt außerdem vor, dass user.id zwischen 1 und 64 Bytes groß sein muss. Wer einen zu langen Puffer übergibt, bekommt einen TypeError. name und displayName werden nur in der Authenticator-UI angezeigt.

pubKeyCredParams ist ein Array, das angibt, welche Algorithmen der Server akzeptiert, in Prioritätsreihenfolge von oben nach unten. Die gängigen Einträge sind -7 für ES256 (ECDSA über P-256 mit SHA-256), -257 für RS256 und -8 für EdDSA. Ein moderner Server sollte mindestens ES256 und RS256 beherrschen, um eine breite Authenticator-Kompatibilität zu gewährleisten.

Mit excludeCredentials kann der Server verhindern, dass derselbe Authenticator mehrfach für dasselbe Konto registriert wird. Das Feld enthält eine Liste von credentialId-Werten, die dem Nutzer bereits gehören. Ist der Authenticator schon registriert, bricht der Browser die Anfrage ab. Das Feld ist optional, aber es ist Best Practice, es zu befüllen. Ohne diese Prüfung kann ein Nutzer denselben Passkey mehrfach anlegen, was die Credential-Verwaltung unnötig verkompliziert.

authenticatorSelection ist das Feld, mit dem die RP Einfluss auf den Authenticator-Typ nimmt. authenticatorAttachment mit dem Wert "platform" schränkt auf eingebettete Authenticators ein, "cross-platform" auf externe Geräte. Wichtiger ist residentKey: Mit dem Wert "required" wird ein Discoverable Credential erzeugt – eines, das der Authenticator selbst findet, ohne dass der Server eine credentialId mitschickt. Das ist die technische Voraussetzung für ein Log-in ohne Nutzernamen. "preferred" ist ein sinnvoller Kompromiss, wenn Kompatibilität wichtiger als garantierte Discoverable Credentials ist. Das dritte relevante Unterfeld ist userVerification: "required" bedeutet, dass der Authenticator zwingend Biometrie oder PIN verlangen muss. Diese Einstellung hat direkte Auswirkungen auf die spätere Assertion-Validierung – der Server muss bei jeder Authentication prüfen, ob das UV-Flag (User Verification) in der authData dem hier konfigurierten Wert entspricht.

Das attestation-Feld gibt an, welche Art von Attestationsdaten der Server erwartet. "none" ist für die meisten Consumer-Anwendungen die richtige Wahl: Der Server interessiert sich nicht dafür, welches Gerät das Credential erzeugt hat. "direct" liefert eine vollständige Zertifikatskette, mit der der Server das Authenticator-Modell verifizieren kann. Das ist relevant für Enterprise-Szenarien oder wenn nur zertifizierte Hardware akzeptiert werden soll. Wichtig dabei: Das attestation-Feld ist ein Hinweis, keine harte Vorgabe. Ein Authenticator kann trotz "none" eine vollständige Attestation zurückliefern – der Server entscheidet dann, ob er sie validiert oder ignoriert.

Videos by heise

Das attestationObject – Aufbau und Inhalt

Das nächste Listing demonstriert eine rpIdHash-Prüfung in TypeScript:

// rpIdHash-Prüfung
const expectedRpIdHash = await crypto.subtle.digest(
  "SHA-256",
  new TextEncoder().encode(rpId)
);
const actualRpIdHash = authData.slice(0, 32);

if (!bufferEqual(expectedRpIdHash, actualRpIdHash)) {
  throw new Error("rpIdHash mismatch – Credential für falsche RP");
}

Listing 2: rpIdHash-Prüfung in TypeScript

Nachdem navigator.credentials.create() aufgerufen wurde und die Nutzerin oder der Nutzer den Authenticator bedient hat, gibt der Browser ein PublicKeyCredential zurück, dessen response eine AuthenticatorAttestationResponse enthält. Das Herzstück davon ist das attestationObject, ein CBOR-kodiertes Objekt mit drei Feldern.

fmt gibt das Attestation-Format an: "packed", "tpm", "android-key", "fido-u2f", "apple" oder "none". Es bestimmt, wie das zweite Feld attStmt zu interpretieren ist. Bei "none" ist attStmt leer – der Authenticator macht keine Aussage über seine Herkunft. Bei "packed" enthält attStmt einen Algorithmus-Identifier (alg), eine Signatur (sig) und optional eine X.509-Zertifikatskette (x5c), mit der die Signatur verifiziert werden kann.

Das dritte Feld, authData, ist aus Teil 1 bekannt: der SHA-256-Hash der rpId, das flags-Byte, der signCount und – bei der Registration, wenn das AT-Flag (Attested Credential Data) gesetzt ist – die attestedCredentialData mit aaguid, credentialId und credentialPublicKey. Es sind genau diese letzten drei Werte, die der Server dauerhaft in der Datenbank speichern muss.

Server-Validierung nach §7.1 – die Pflichtschritte

Die Validierung beginnt mit clientDataJSON. Der Server dekodiert den ArrayBuffer als UTF-8 und prüft drei Dinge: type muss "webauthn.create" sein, challenge muss mit der serverseitig gespeicherten Challenge übereinstimmen (Base64url-dekodiert), und origin muss der erwarteten Origin der Anwendung entsprechen. Diese drei Prüfungen sind nicht optional: Die type-Prüfung verhindert, dass eine Authentication-Antwort fälschlich als Registration akzeptiert wird, die challenge-Prüfung schützt vor Replay-Angriffen mit abgefangenen Antworten, und die origin-Prüfung verhindert Phishing, indem sie sicherstellt, dass die Antwort tatsächlich für die eigene Domain erzeugt wurde.

Anschließend wird das attestationObject CBOR-dekodiert, und der Server extrahiert die authData. Der erste sicherheitskritische Check: Der rpIdHash in authData[0..31] muss mit SHA-256(rpId) übereinstimmen. Ist das nicht der Fall, wurde das Credential für eine andere Relying Party erzeugt – der Server lehnt es ab, ohne Fallback. Danach folgen die Flag-Prüfungen: Das UP-Flag (User Presence) muss gesetzt sein. Das UV-Flag muss gegen die konfigurierte userVerification-Policy geprüft werden – wenn der Server "required" gesetzt hat und das Flag fehlt, ist die Registration ungültig.

Bevor das Credential gespeichert wird, muss der Server prüfen, ob die credentialId bereits in der Datenbank existiert. Doppelte IDs dürfen nicht entstehen. Was am Ende in der Datenbank landet, sind mindestens fünf Felder: credentialId, credentialPublicKey (im COSE-Format, CBOR Object Signing and Encryption), signCount (initial 0), aaguid und die Verknüpfung zur userId. Für Produktionssysteme, die Passkeys und Hardware-Keys unterschiedlich behandeln wollen, sind zusätzlich das BE-Flag (backupEligible) und das BS-Flag (backupState) aus den authData-Flags essenziell. Sie signalisieren, ob das Credential synchronisiert werden kann und ob es aktuell synchronisiert ist. Optional, aber ebenfalls empfehlenswert ist die transports-Angabe aus der Response, um den Browser bei zukünftigen Authentifizierungen besser zu steuern.

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Webentwicklung: Agenten checken selbstständig Bugs mit dem Chrome-Browser

2026-08-11T08:26:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Agenten lassen sich in der IDE WebStorm von JetBrains jetzt mit Spezifikationen steuern und können zum Debuggen direkt auf Chrome zugreifen.

(Bild: Wolf Hosbach / KI / iX)

11.08.2026, 10:26 Uhr

Lesezeit: 1 Min.

Developer

Von

Wolf Hosbach

JetBrains führt in der Webentwicklungs-IDE WebStorm 2026.2.1 die Erweiterung Chrome DevTools Connect ein, durch die KI-Agenten direkt aus der IDE heraus mit dem Browser Chrome interagieren. Die Agenten prüfen damit Anwendungen selbstständig zur Laufzeit, analysieren Fehler und verifizieren Codeänderungen.

Chrome DevTools Connect verbindet die Agenten über den Skill DevTools CLI mit dem Browser, sodass die KI-Helfer damit interagieren, Seiten analysieren, die Browserkonsole lesen, Netzwerkanfragen verfolgen oder Screenshots machen können. Entwicklerinnen und Entwickler müssen die IDE zum Debuggen nicht mehr verlassen.

(Bild: Kit8 d.o.o. / stock.adobe.com)

Agentische KI bringt eine neue Dynamik in die Webentwicklung. Erfahre am 22. Oktober 2026 auf der Online-Konferenz enterJS Agentic, wo Agenten glänzen oder stolpern, wie die Kosten-Nutzen-Abwägung gelingt und welche Fragen erst sichtbar werden, wenn man KI praktisch einsetzt. Bis zur Programmveröffentlichung sind vergünstigte Blind-Bird-Tickets verfügbar.

Design-Specs-Integration

Eine weitere WebStorm-Neuerung, Figma Connect, integriert Design-Spezifizierung in WebStorm: Die über Figma MCP eingebundenen Specs dienen den Agenten als Gerüst für das Projekt.

Videos by heise

Ein Update gibt es auch für die IDE IntelliJ IDEA, das kleinere Fehler korrigiert, zum Beispiel in der Reihenfolge bei der Ausführung von Markdown-Skripten.

(who)

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Software Testing: Was Bakterien besser machen als dein Scrum-Team

2026-08-11T06:27:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Softwareentwicklung kann sich von Strategien aus der Natur einiges abschauen, wie Anna Melbinger im Gespräch erläutert.

(Bild: Richard Seidl)

11.08.2026, 08:27 Uhr

Lesezeit: 2 Min.

Developer

Von

Richard Seidl
Anna Melbinger

Was können wir von Bakterien und Motten lernen, um besser mit Unsicherheit umzugehen? Mit Anna Melbinger spricht Richard Seidl darüber, wie Strategien aus der Natur auf Softwareprojekte und Projektmanagement übertragbar sind. Anna Melbinger bringt einen ungewöhnlichen Hintergrund mit: Jahre in der Wissenschaft, Physik studiert, biologische Fragestellungen mit Mathematik bearbeitet und heute im IT-Projektgeschäft. Die beiden reden darüber, warum Stillstand keine Robustheit erzeugt, warum Bug-Trends oft aussagekräftiger sind als einzelne Bugs und wann es sich lohnt, bewusst einen Schritt zu tun, der nicht direkt zum Ziel führt, nur um Wissen zu gewinnen. Am Ende landet das Gespräch bei Karl Popper und der Frage, ob das aktive Suchen nach Widerlegung eigentlich die ehrlichste Methode ist, mit komplexen Entscheidungen umzugehen.

Richard Seidl ist Berater, Speaker und Podcast-Host. Für ihn ist klar: Wer heute exzellente Software kreieren möchte, denkt den Entwicklungsprozess ganzheitlich: Menschen, Kontext, Methoden und Tools. Er hat seine Erfahrungen in acht Fachbüchern veröffentlicht, betreibt erfolgreich zwei Community-Podcasts und ist Beirat der heise-Konferenz betterCode() Testing.

„Manchmal lohnt es sich, bewusst innezuhalten. Schritte zu tun, nur um Wissen zu generieren.“ – Anna Melbinger

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Bevor Anna Melbinger in die IT wechselte, forschte sie viele Jahre als biologische Physikerin an komplexen Systemen – unter anderem an der LMU München, am Institut Pasteur in Paris und an der UC San Diego. Dort beschäftigte sie sich mit der Frage, wie biologische Systeme unter Unsicherheit funktionieren, Entscheidungen treffen und robust bleiben. Heute arbeitet sie seit über zehn Jahren im IT-Projektmanagement und begleitet anspruchsvolle Digitalisierungs- und Transformationsprojekte. Immer wieder erkennt sie dabei überraschende Parallelen zwischen Projektarbeit und biologischen Mechanismen. In ihren Vorträgen verbindet sie wissenschaftliche Tiefe mit praktischer Erfahrung – und zeigt, warum Orientierung, Anpassung und Robustheit oft wichtiger sind als perfekte Planung.

Softwarequalität im Gespräch

Dieses Format fokussiert sich auf Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste betrachten die Dinge, welche die Qualität in der Softwareentwicklung steigern.

Die aktuelle Episode ist auch auf Richard Seidls Blog verfügbar.

(mai)

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Erster alternativer App-Store bei Google Play USA

2026-08-11T03:05:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Android-Nutzer mit der US-Version des Google Play Store können erstmals alternative App-Stores direkt installieren. Den Anfang macht ein Anbieter aus der EU.

(Bild: Daniel AJ Sokolov)

11.08.2026, 05:05 Uhr

Lesezeit: 4 Min.

Von

Daniel AJ Sokolov

Google fügt sich der US-Justiz und ermöglicht die Installation alternativer App-Stores direkt aus Google Play heraus [–] allerdings nur für Geräte mit der US-Version Googles Plays. Den Anfang macht der portugiesische App-Store Aptoide.

Er kann ab sofort über einen eigenen Bereich Google Plays installiert werden. Der Prozess ist simpel, es gibt keine abschreckenden Warnungen oder andere Hürden. Aptoide gibt es schon seit 2009, musste bislang aber mit dem zusätzlichen Aufwand des Sideloadings installiert werden.

Das Portfolio Aptoides von offiziell einer Million Apps ist auf Spiele spezialisiert, doch steht an erster Stelle der „Top Charts” wie auch der „Trending”-Liste die chinesische Anwendung Huawei Health. Sie dient der Anbindung vernetzter, am Körper getragener Geräte („wearables”) wie Smartwatches und Fitnessarmbänder des chinesischen Konzerns.

Google baut Gelddrucker Android um

Grund für die Änderung ist die Niederlage Googles im Rechtsstreit mit Epic, ausgelöst durch den Ausschluss des Epic-Spieles Fortnite aus dem Play Store im Jahr 2020. Ende 2023 stellten US-Geschworene fest, dass Google außerhalb der Volksrepublik China ein Monopol für den Vertrieb von Android-Apps sowie Finanztransaktionen in diesen hat, und diese Monopole mit illegalen Mitteln aufrechterhalten hat. Das Bundesbezirksgericht verpflichtete Google daraufhin, in den USA alternative App-Stores zuzulassen.

Googles Berufung war erfolglos und der US Supreme Court (SCOTUS) lehnte einen Aufschub der Verfügung ab. Zunächst versuchte Google noch, den Supreme Court für den zugrundeliegenden Fall zu interessieren, einigte sich aber schließlich mit Epic. Nun baut Google das Android-Wirtschaftssystem weltweit um. App-Betreiber sollen mehr Optionen für Finanztransaktionen bekommen und alternative App-Stores sollen Einzug halten.

App-Store Aptoide (4 Bilder)

Liste alternartiver App-Stores

Die Liste alternativer App-Stores bei Google Play USA ist noch überschaubar.

Dafür entzieht Google den Geräteinhabern ein großes Stück Autonomie: Ab Herbst 2026 können nur noch Apps auf zertifizierten Android-Geräten installiert werden, deren Herausgeber sich zuvor bei Google registriert und dann die jeweilige Anwendung signiert hat. Für Installationen über den Google Play Store gilt das schon seit 2023; künftig soll Anonymität auch für Sideloading, also für direkt am Gerät, ohne Nutzung des Play Stores installierte Programme und alternative App-Stores abgeschafft werden.

Aptoide hat Huawei

Die Huawei-App soll bereits mehr als 100 Millionen mal heruntergeladen worden sein. Die hohe Nachfragebei Aptoide liegt daran, dass Huawei im März 2019 aus Google Play geflogen ist. Damals erklärte US-Präsident Donald Trump den Telekommunikationssektor per Dekret zu einer sicherheitskritischen Branche, und das US-Handelsministerium setzte Huawei auf die Liste jener Unternehmen, mit denen US-Firmen nur nach Genehmigung der US-Regierung Handel treiben dürfen.

Videos by heise

Die Portugiesen versuchen offenbar einen Mittelweg: Huawei Health ist vorhanden und installierbar, der Suchbegriff „Huawei” war bei Versuchen heise onlines allerdings gesperrt. Aptoide überwacht übrigens die Aktivitäten seiner Nutzer nicht nur im App-Store, sondern auch in den darüber installierten Programmen. Das versucht der Anbieter mit der Ausschüttung von Punkten schmackhaft zu machen. Wer nicht überwacht werden möchte, muss sich das in den Kontoeinstellungen verbitten. Seit dem Vorjahr kann Aptoide in der EU als alternativer App-Store auf iOS installiert werden, inzwischen sind Japan und Brasilien hinzugekommen.

Das als Epic v Google bekannte Verfahren hieß offiziell In Re Google Play Store Antitrust Violation und wurde am US-Bundesbezirksgericht für das nördliche Kalifornien unter dem Az. 20-cv-05671 verhandelt. In dem Verfahren wurden Klagen aus mehreren Teilen der USA zusammengefasst, wofür es eine weitere Aktenzahl gibt: 21-md-02981.

(ds)

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Meta veröffentlicht Muse Glimmer: Offenes 30-Milliarden-Parameter-Modell

2026-08-10T15:32:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Meta hat mit Muse Glimmer ein offenes 30-Milliarden-Parameter-Modell veröffentlicht, das lokal auf Consumer-Hardware läuft und kommerziell nutzbar ist.

(Bild: Poetra.RH / Shutterstock.com)

Update 10.08.2026, 17:32 Uhr

Lesezeit: 4 Min.

Von

Malte Kirchner

Meta hat mit Muse Glimmer ein neues offenes KI-Sprachmodell vorgestellt, das gezielt für den Einsatz auf gewöhnlicher Consumer-Hardware entwickelt wurde. Die Künstliche Intelligenz vorantreibenden Meta Superintelligence Labs veröffentlichen die Gewichte des 30-Milliarden-Parameter-Modells unter der Apache-2.0-Lizenz auf Hugging Face – frei nutzbar auch für kommerzielle Zwecke. Begleitet wurde die Veröffentlichung von einem sehr langen Schreiben von Meta-Chef Mark Zuckerberg, der darin die künftige KI-Strategie seines Konzerns darlegt.

Anders als viele aktuelle Spitzenmodelle ist Muse Glimmer nicht auf Cloud-Infrastruktur angewiesen. Es soll auf einem Mac oder PC mit einer einzelnen Consumer-GPU laufen und eignet sich laut Meta für lokale Agenten, Function Calling, Coding-Aufgaben und den Einsatz als LLM-Judge zur Bewertung anderer Modellausgaben. In das Modell ist laut Meta Wissen des größeren Modells Muse Spark eingeflossen, das aktuell noch geschlossen ist, was sich aber auch bald ändern soll. Mark Zuckerberg kündigte in einem X-Post an, dass die Gewichte bald veröffentlicht werden sollen.

Technische Kniffe für Tempo auf schwacher Hardware

Damit das Modell überhaupt in den Speicher eines Consumer-Rechners passt, schrumpft Meta die Gewichte auf rund 4 Bit Präzision. Aus über 55 GByte bei voller Präzision werden so unter 20 GByte.

Anhand eigener Benchmarks (u. a. SWE-Bench, τ-Bench, MCP-Atlas, DeepSearch QA) will Meta zeigen, dass Muse Glimmer gegenüber vergleichbar großen Modellen wie Gemma4-31B und Qwen3.6-27B in seiner Gewichtsklasse gut abschneidet – wie belastbar solche herstellereigenen Vergleiche sind, muss sich wie üblich erst in unabhängigen Tests zeigen.

Videos by heise

Meta kündigt Unterstützung durch Ollama, LM Studio, Unsloth, llama.cpp, ExecuTorch, MLX, vLLM, SGLang sowie Hosting-Angebote von Together AI, Fireworks AI und OpenRouter an. Mit Muse Spark 1.1 hatte Meta zuvor bereits aggressive Preise für seine kommerzielle Modell-API angekündigt, um OpenAI und Anthropic Marktanteile abzunehmen. Zur Anpassung an eigene Anwendungsfälle verweist Meta auf PyTorchs TorchTitan-Trainingsframework. Bei der Hardware-Optimierung arbeitet der Konzern mit AMD, Arm, Dell, Intel und Nvidia zusammen.

Zuckerberg: KI-Fähigkeiten für alle öffnen

Zuckerberg selbst ordnet das Modell in seinem parallel veröffentlichten Grundsatzpapier „The Path to a Positive AI Future“ in Metas KI-Strategie ein. Zentrale Frage seiner Zeit sei, wer Zugang zu Superintelligenz haben werde und wer sie kontrolliere. Seine Antwort: eine möglichst breite Verteilung der Fähigkeiten, denn je mehr Menschen Zugang zu Cybersicherheits-Superintelligenz hätten, desto sicherer würden letztlich alle technischen Systeme. Übertragen auf Muse Glimmer heißt das: Offene Gewichte sind bei Meta kein Geschenk, sondern Ausdruck einer Theorie, wonach Konzentration von KI-Fähigkeiten bei wenigen Akteuren gefährlicher sei als deren breite Streuung.

In seinem langen Schreiben versucht Zuckerberg auch zahlreiche Ängste zu zerstreuen: KI könne dem Arbeitsmarkt und der Wirtschaft nützlich sein, argumentiert er. Sie aktiv zu nutzen, könne helfen, sich gegen Bedrohungen in der Cybersecurity, Bioterrorismus und andere schädliche KI-Erzeugnisse zu wehren. Und auch die Sorge, dass die USA in ihrer Führungsrolle abgelöst werden können, adressiert der Facebook-Gründer.

Was Meta sich davon verspricht

Diese Argumentation dient zugleich als Gegenentwurf zu konkurrierenden Anbietern: Zuckerberg unterstellt jenen, die auf geschlossene Modelle setzen, dass sie damit tendenziell Institutionen statt Individuen stärken – die meisten anderen konzentrierten sich auf KI für Unternehmen, Regierungen oder andere Institutionen. Meta positioniert sich dagegen als das Unternehmen, das Superintelligenz gezielt für Einzelpersonen baut. Dahinter dürfte vor allem die Absicht stecken, das Unternehmen zu sein, das künftig die Standards setzt.

Update 11.08.2026, 09:51 Uhr

Ergänzung, dass Muse Spark bald auch geöffnet werden soll.

Lesen Sie auch

Anthropic sagt, sein Wasserzeichen funktioniere. Vielleicht. Manchmal.

Lokale KI ausprobiert: Das leistet Qwen3.8-27B

ChatGPT zeigt mehr Nutzern Werbeeinblendungen

KI macht Teams schneller – leider auch bei schlechten Prozessen

Geplanter Börsengang: Anthropic könnte SpaceX bei Weitem übertreffen

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

curl: Niemand will mit Windows arbeiten

2026-08-10T14:08:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Das siebenköpfige Security-Team von curl nutzt kein Windows. Nun sucht Entwickler Daniel Stenberg dringend Unterstützung für das Projekt.

357

(Bild: Dirk Knop / KI / heise medien)

10.08.2026, 16:08 Uhr

Lesezeit: 2 Min.

iX Magazin

Von

Moritz Förster

Niemand bei curl will mit Windows arbeiten: Entwickler Daniel Stenberg beschwert sich auf Mastodon über das Betriebssystem und Meldungen zu Sicherheitslücken. Konkret geht es um das siebenköpfige Security-Team von curl, in dem niemand Windows nutzt. Aber auch darüber hinaus sind Stenberg bei dem Projekt allgemein keine geeigneten Personen bekannt – die also als Mitwirkende aktiv genug sind, sich mit dem Betriebssystem auskennen und Interesse an einer Mitarbeit beim Security-Team haben.

curl ist für das Übertragen von Daten über Netzwerkprotokolle wie HTTP und HTTPS zuständig. Die zugrunde liegende Bibliothek libcurl steckt zudem in zahlreichen Anwendungen und vernetzten Geräten. Beide Bestandteile des Projekts stehen als Open-Source-Software unter einer MIT-ähnlichen Lizenz.

Hilferuf

Aktuell würden Meldungen zu Windows-exklusiven Sicherheitslücken im Team Stöhnen und verdrehte Augen nach sich ziehen – und manchmal würden sie ein wenig hyperventilieren. Stenberg ruft daher die Community auf Mastodon dazu auf, sich bei ihm zu melden, falls es jemanden geeigneten gibt. In den öffentlichen Antworten auf seinen Beitrag gibt es jedoch vor allem weitere Beschwerden über Windows und Diskussionen über Vorzüge und Nachteile von Linux und macOS – aktuell ist unklar, ob curl durch seinen Aufruf einen geeigneten Entwickler gefunden hat.

Videos by heise

curl hat wie viele andere Open-Source-Projekte ohnehin mit massenhaft eingereichten Bug-Reports zu kämpfen: Stenberg beschwerte sich bereits Anfang des Jahres über die KI-Flut. Anschließend beendete das Projekt sein Bug-Bounty-Programm; Sicherheitslücken lassen sich jetzt ohne Prämien melden. Eine später folgende Pause beim Abarbeiten von Sicherheitsmeldungen nannte Stenberg „curls Sommer voller Glückseligkeit“. Gleichzeitig sind das Kommandozeilenprogramm curl und die Programmbibliothek libcurl als grundlegende Transportwerkzeuge des Internets von zentraler Bedeutung für die Softwarelandschaft.

(fo)

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Claude Code fragt künftig seltener: „Darf ich das?“

2026-08-10T11:36:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Anthropic aktiviert den Auto Mode in Claude Code standardmäßig. Die KI arbeitet dann selbstständig bei Shell-, Git- und Tool-Aufrufen.

(Bild: gguy/Shutterstock.com)

10.08.2026, 13:36 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Moritz Förster

Der Auto Mode ist in Claude Code künftig standardmäßig für neue Sitzungen aktiviert: Die Änderung greift ab dem 14. August für Nutzer der Lizenzen Pro, Max und Team. In Folge arbeitet Claude Code bei Shell-, Git- und Tool-Aufrufen selbstständig, ohne bei jedem einzelnen Schritt um Erlaubnis zu bitten. Laut Anthropic ist der Auto Mode wenigstens genauso sicher wie die manuellen Freigaben durch den Anwender.

Bei Claude Code handelt es sich um ein KI-Werkzeug zum Entwickeln von Software. Bisher erfordern einige Aktionen eine aktive Freigabe durch Anwender. Der Auto Mode ersetzt die einzelnen Bestätigungen nicht durch einen uneingeschränkten Zugriff; vielmehr soll ein Klassifikator jeden Tool-Aufruf auf seine Sicherheit hin bewerten. Hierzu gehört, ob die Änderung potenziell irreversibel, destruktiv oder auf Ziele außerhalb der vorgesehenen Umgebung gerichtet ist.

Im Zweifelsfall soll der Klassifikator einen als unsicher erkannten Schritt blockieren und entweder nach besseren Alternativen suchen oder vom Nutzer eine Freigabe anfordern. Außerdem stellt Claude Code automatisch auf manuelle Freigaben um, wenn es drei aufeinanderfolgende Blockierungen oder 20 Blockierungen in einer Sitzung gab. Anthropic empfiehlt in der Ankündigung explizit eine menschliche Prüfung bei Änderungen an produktiver Infrastruktur.

Permission Fatigue bei den Anwendern

Als Grund für die Umstellung nennt Anthropic die sogenannte Permission Fatigue der Nutzer. Damit ist gemeint, dass Anwender die Sicherheitsabfragen von Claude Code reflexhaft bestätigen würden – 97 Prozent der Nachfragen der KI würden abgenickt, nur 3 Prozent abgelehnt. Bei übergeordneten Planungsdialogen würden die Nutzer hingegen 39 Prozent der Vorschläge zurückweisen. Das Problem der Permission Fatigue ist so auch aus anderen Sicherheitsbereichen bekannt.

Videos by heise

Anthropic hat darüber hinaus eine kontrollierte Studie durchgeführt, laut der Menschen lediglich 13,6 Prozent absichtlich eingeschleuste Befehle erkannt hätten, die laut Anbieter klar gefährlich waren. Der Auto Mode habe hingegen 89 Prozent blockiert. Zudem hat Anthropic in einer Auswertung durch die eigene Safety-Pipeline markierter Sitzungen festgestellt, dass 6,3 Prozent der Sitzungen mit manueller Freigabe eine nicht ausdrücklich vom Nutzer angeforderte schädliche Aktion mit mindestens produktionsrelevant eingestufter Schadensschwere enthielten. Der Auto Mode kam im Vergleich auf einen Anteil von 2,4 Prozent.

Mehrere Schutzmechanismen im Auto Mode

Im Rahmen der Ankündigung verweist Anthropic auf die Schutzmechanismen des Auto Mode. Hierzu zählen Hard Denies, die der Klassifikator nie selbst freigibt. Darunter fällt insbesondere eine mögliche Datenexfiltration, zum Beispiel das Kopieren von Quellcode an externe Ziele. Für Git-Aktionen zieht der Klassifikator außerdem den Kontext hinzu, um etwa nicht committete Änderungen berücksichtigen zu können. Bei Datenzielen prüft das System zuvor, ob das Ziel-Repository öffentlich, privat oder als vertrauenswürdig eingestuft ist. Auch ein Prompt-Injection-Screening wird im Auto Mode durchgeführt, um manipulierte Anweisungen zu erkennen.

Anthropic versucht ebenfalls mit internen und externen Red-Teaming-Tests Vertrauen bei den Nutzern zu werben. Sie sollen zeigen, wie gut der Klassifikator im Auto Mode gezielt konstruierte Angriffe erkennt.

Schwerer dürfte bei Unternehmen jedoch das Produktivitätsversprechen wiegen: Nutzer des Auto Mode sollen etwa 25 Prozent mehr Pull Requests abliefern, Anthropic verweist hier auf den Einsatz bei Adobe, Nuro, Gusto und Garner Health. Allerdings sagt die Menge der Pull Requests wenig über die abschließende Qualität aus; Angaben zu Durchlaufzeiten, Fehlerquoten, Review-Aufwand und Produktionsvorfälle fehlen in der Ankündigung.

Die Umstellung auf den Auto Mode geschieht standardmäßig, sofern Kunden nicht zuvor eine andere Vorgabe eingestellt haben. Der Klassifikator verbraucht zwar zusätzliche Token, diese Zusatzkosten will Anthropic für die Tarife Pro, Max und Team ab sofort aber nicht mehr berechnen. Für Nutzer von Claude Enterprise, die Claude API sowie Claude Code über AWS, Amazon Bedrock, Google Cloud Agent Platform und Microsoft Foundry ändert sich aktuell nichts – Anthropic will sie jedoch im Laufe des kommenden Monats ebenfalls standardmäßig auf den Auto Mode umstellen.

Lesen Sie auch

Last Call: Claude Code in der Praxis – KI-Chat-Agenten in 5 Sessions entwickeln

Claude: Was den Chatbot ausmacht und worauf man achten sollte

Claude Code in der Praxis – eigenen KI-Chat-Agenten in fünf Sessions entwickeln

Claude Code erhält Zugriff auf iPhone-Simulator

Claude Code in der Praxis – eigenen KI-Chat-Agenten in fünf Sessions entwickeln

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Developer-Häppchen: Kotlin-LSP für Cursor und Sneak Peek für Kubernetes

2026-08-08T07:15:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Kleine, aber interessante Meldungshäppchen vom News-Buffet zu Kubernetes, Servo, Symfony Polyfill, Python, Rust, Pandoc, Coreutils, JetBrains und Quasar.

(Bild: Natalia Klenova / Shutterstock.com)

08.08.2026, 09:15 Uhr

Lesezeit: 3 Min.

Developer

Von

In unserem leckeren Häppchen-Überblick servieren wir alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:

Mit dem Sneak Peek auf Kubernetes 1.37 gibt das Projektteam einen Vorgeschmack auf die für den 26. August 2026 geplante Version. Vorgesehen sind unter anderem die allgemeine Verfügbarkeit der Metrics API, die Deprecation des --filename-Flags (oder -f) in kubectl run sowie die Einschränkung von Secrets- und ConfigMap-Referenzen in statischen Pods.
Servo 0.4.0, die Browser-Engine in Rust, bündelt die Änderungen aus Juni 2026 in einem Release mit einer Rekordzahl: 558 Commits verbessern Layout-Korrektheit, WebGPU-Unterstützung und Stabilität. Die Tech-Demo steht zum Download bereit.
Mit Symfony Polyfill 1.41.0 steht die neue Io\Poll-API aus der anstehenden Version 8.6 nun auch für PHP 8.1 und höher bereit. Das neue Paket symfony/polyfill-io-poll liefert die objektorientierte Schnittstelle für I/O-Polling portabel nach.

(Bild: Sylverarts / stock.adobe.com)

Der Product Owner Day 2026 findet am 19. November statt. Teilnehmende lernen auf der Online-Konferenz aktuelle Trends kennen, erhalten Inspiration und bekommen einen konkreten Werkzeugkasten an die Hand. Tickets zum Frühbucherpreis sind im Online-Shop verfügbar.

Python 3.15.0rc1 ist der erste Release Candidate für Python 3.15. Ab diesem Punkt sind nur noch geprüfte Bugfixes erlaubt. Ein zweiter Release Candidate ist für den 1. September 2026 geplant, bevor die finale Version erscheint.
Das Rust-Funding-Team hat seinen Fortschrittsbericht für Juli 2026 veröffentlicht und dabei Details zum Maintainer-in-Residence-Programm (MiR) bekanntgegeben. Bisher sind 350.000 US-Dollar an Spenden eingegangen. Das Funding-Team priorisiert unter anderem die Teams hinter rustup, rustfmt, clippy und cargo. Die erste MiR-Auswahl soll bis Ende August 2026 bekanntgegeben werden.

Lesen Sie auch

Dirty Hacks: Die Notlügen, die hoffentlich nicht auffallen

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Lieferketten-Angriff auf keyv: Shai-Hulud-Wurm infiziert mehr als 440 npm-Pakete

2026-08-07T10:54:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die populäre Key‑Value‑Datenbank keyv und andere weit verbreitete npm-Pakete waren Ziel einer Lieferkettenattacke. Der potenzielle Schaden ist groß.

(Bild: VADZIM SHUBICH/Shutterstock.com / Bearbeitung heise medien)

07.08.2026, 12:54 Uhr

Lesezeit: 3 Min.

Developer

Von

Manuel Masiero

Der GitHub-Account des Maintainers der Key‑Value‑Datenbank keyv wurde am 4. August im Rahmen einer Shai-Hulud-Lieferkettenattacke kompromittiert. Ein Großteil der betroffenen Pakete ist mittlerweile zwar entfernt, der Angriff birgt aber ein enormes Schadenspotenzial. Er erstreckt sich auf die komplette Paketfamilie von keyv, die es monatlich zusammen auf mehr als 2 Milliarden Downloads bringt.

Zu den betroffenen npm-Paketen gehören neben keyv 6.0.0, das pro Monat im Schnitt etwa 600 Millionen Downloads verzeichnet, auch folgende weitere Pakete des keyv-Maintainers: flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cacheable 2.5.1, @cacheable/memory 2.2.1, cache-manager 7.2.10, @cacheable/node-cache 3.1.2 und @cacheable/utils 2.5.1.

Über diese Kernpakete verbreitete sich der Wurm aktiv weiter auf Pakete anderer Maintainer und Organisationen, etwa @deliveroo/reevent, @or-sdk/invitations, @picsart/ai-sdk, @qlik/embed-runtime und picasso.js.

Am 5. August identifizierten die IT-Forscher von Aikido Security 1381 bösartige Versionen von 444 npm-Paketen. Socket zählt in seinem Live-Tracker inzwischen mehr als 2400 infizierte Paketartefakte. Die kompromittierten Pakete enthalten eine Mini-Shai-Hulud-Variante, der StepSecurity den Namen ChainDrop gegeben hat.

Schadcode mit Autostart

Bei der Lieferkettenattacke erhielt jedes der kompromittierten Pakete mit setup.mjs und Math_Symbol.js zwei neue Dateien sowie den neuen Eintrag "preinstall": "node setup.mjs" in der package.json-Datei. Ein npm install startet den Schadcode dann automatisch. Dabei lädt der stark verschleierte Dropper setup.mjs die Bun‑JavaScript‑Runtime herunter und führt mit Bun den eigentlichen Schadcode Math_Symbol.js aus.

Videos by heise

Auf betroffenen Systemen suchen die bösartigen Paketversionen im Anschluss an die Installation nach einer breiten Palette von Zugangsdaten. Im Fokus stehen beispielsweise GitHub‑, npm‑ und HashiCorp-Vault-Tokens, AWS‑ und Microsoft-Azure-Credentials, Logins für Stripe und Slack sowie Kubernetes-Secrets.

Die gesammelten Daten verschlüsselt der Wurm und lädt sie anschließend in öffentliche GitHub-Repositories hoch, die die Angreifer kontrollieren, zu erkennen an der Zeile „Shai‑Hulud: Here We Go Again“ im Readme.md. Über gestohlene npm-Token kann sich die Malware selbst weiterverbreiten.

Der ChainDrop-Angriff reiht sich in die mittlerweile lange Liste der Shai-Hulud-Lieferkettenangriffe ein. Seit April dieses Jahres waren unter anderem npm-Pakete von SAP und TanStack sowie die Managed-Cloud-Services von Red Hat betroffen. Die Cybergang TeamPCP veröffentlichte Mitte Mai den Quellcode des npm-Wurms Shai-Hulud auf GitHub und rief zu einem Wettbewerb um den größten Supply-Chain-Angriff auf.

(mro)

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Dirty Hacks: Die Notlügen, die hoffentlich nicht auffallen

2026-08-07T07:30:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Kleine Hacks sind oft harmlos – wie die meisten Notlügen. Aber sie können sich aufsummieren und zu technischen Schulden werden.

(Bild: Rainald Menge-Sonnentag / KI / iX)

07.08.2026, 09:30 Uhr

Lesezeit: 9 Min.

Developer

Von

Alex Kirsch

„Wie kommt deine Mutter mit der Reha zurecht?“ – „Ganz gut, danke.“ – „Ich habe sie aber gestern beim Einkaufen gesehen.“ – Ups, das ist jetzt peinlich. Ungefähr so peinlich wie die Webanwendung, die zum dritten Mal diese Woche stillsteht. Oder das coole neue Feature, das nach sechs Monaten immer noch nicht implementiert ist.

Alex Kirsch ist IT-Beraterin, Coach und freie Wissenschaftlerin. Mit ihrem Hintergrund in Künstlicher Intelligenz, User Experience Design und Entscheidungsfindung macht sie Software- und Entwicklungsteams fit für die harte Realität.

Aller Anfang ist harmlos

Dabei fängt es immer so harmlos an. „Wir fahren am Wochenende auf die Hütte von meinem Onkel. Kommst du mit?“ – „Nee, hab keine Lust, und schon gar nicht auf diese modrige Hütte“ ist eine schlechte Antwort. Daher besser: „Klingt toll. Aber meinen Eltern geht es gerade nicht so gut, da will ich nicht ein ganzes Wochenende so weit wegfahren. Vielleicht brauchen sie mich.“ Höflich, unspezifisch, Problem gelöst.

Oder in der Welt des Programmierens: Da ist jetzt noch ein Sonderfall aufgetaucht. Der passt überhaupt nicht ins Konzept, aber wir können ja kaum alles komplett umschreiben. Also hier ein weiterer If-Block, da eine Funktion kopiert und mit ein paar kleinen Änderungen versehen. Schnell, unkompliziert, Problem gelöst.

Meistens endet die Geschichte hier. Aber nicht immer.

Videos by heise

„Kommst du am Sonntag zum IT-Kaffee? A propos, geht es deiner Mutter besser?“ Wie praktisch, dieses Mal wird die Ausrede gleich mitgeliefert. „Eigentlich ganz gut. Aber nach so einer Hüft-OP ist man halt eingeschränkt. Ich helfe ihr am Wochenende beim Putzen.“ – „Das kenne ich. Mein Onkel musste drei Wochen in die Reha. Wieso ist deine Mutter zu Hause?“ – „Sie wartet noch auf einen Platz. Nächste Woche sollte es losgehen.“ Kurve gekriegt, Wochenende frei gehalten, alles gut.

Parallel dazu im Programmierprojekt: Zu dem Sonderfall haben sich noch ein paar weitere gesellt. Der harmlose If-Block ist zu einem großen Entscheidungsbaum gewachsen, und die kopierte Funktion wurde dreimal erweitert und zweimal weiterkopiert. Alles läuft irgendwie. Also auf zum nächsten Feature, alles gut.

Das bittere Ende

Manchmal geht das Ganze so weit, dass es peinlich wird. Der Schwindel fliegt auf oder die Software wird instabil. Beim Lügen ist oft das Ende klar, etwa weil man sich verplappert. Bei Software ist das weniger eindeutig.

Dort bauen sich technische Schulden auf. Woran erkennt man diese Schulden und ab wann werden sie zum Problem? Software ist nicht per se schuldenbehaftet, nur weil sie alt ist, und nicht jeder kleine Hack führt direkt in eine Schuldenspirale.

Das Problem ist die Passung zwischen Code und Konzept. Peter Naur hat schon 1985 in seinem Artikel „Programming as theory building“ beschrieben, dass ein Programm nicht in erster Linie Code ist, sondern die Instanziierung eines Konzepts – er nennt es sogar Theorie. Ändert man ein Programm, fügt man nicht nur Codezeilen hinzu, ändert oder löscht sie, sondern verändert das Gesamtkonzept.

Lesen Sie auch

KI als Spiegel: Fehlende Bedeutung in Code und Architektur

Die Broken-Windows-Theorie: Null Toleranz für Softwarequalität

Held oder Märtyrer – Willkommen im Projektchaos

Top 10: Die beste elektrische SUP-Pumpe im Test

Top 10: Die beste elektrische Kühlbox im Test

Top 10: Der beste Ventilator im Test

Neu in .NET 10.0 [34]: Keine doppelten Attributwerte bei JSON-Deserialisierung

2026-08-07T07:19:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die neue Einstellung "AllowDuplicateProperties = false" löst bei doppelten Werten in der JSON-Deserialisierung einen Laufzeitfehler aus.

(Bild: Pincasso / Shutterstock.com)

07.08.2026, 09:19 Uhr

Lesezeit: 1 Min.

Developer

Von

Dr. Holger Schwichtenberg

Die JSON-Bibliothek System.Text.Json war bisher sehr tolerant bei der Deserialisierung von doppelten Attributwerten.

Dr. Holger Schwichtenberg ist technischer Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland.

Der folgende Programmcode führt bisher und auch im Standard System.Text.Json in .NET 10.0 nicht zu einem Laufzeitfehler:

 string json = """{ "FirstName": "Holger", "LastName": "Schwichtenberg", "LastName": "www.IT-Visions.de" }""";
  Console.WriteLine(json);
 
  CUI.H2("Deserialisierung im Standard");
  var person = JsonSerializer.Deserialize<Person>(json);
  Console.WriteLine(person);

In diesem Beispiel wird "LastName" zweimal gesetzt: einmal auf den Nachnamen und fälschlicherweise ein zweites Mal auf eine Website-URL. Dabei verwendet der JSON-Serializer immer den letzten Wert, das heißt, die Ausgabe ist nicht „Person: Holger Schwichtenberg“, sondern „Person: Holger www.IT-Visions.de“.

(Bild: King / stock.adobe.com)

In System.Text.Json gibt es seit .NET 10.0 Preview 6 bei den JsonSerializerOptions eine neue Eigenschaft AllowDuplicateProperties. Diese hat im Standard den Wert true. Mit der Umstellung auf false erreicht man, dass beim Deserialisieren von JSON-Dokumenten ein Laufzeitfehler entsteht, falls ein Attribut mehrfach gesetzt wird.

Videos by heise

Mit AllowDuplicateProperties = false führt diese Situation zu dem Laufzeitfehler

Duplicate property 'LastName' encountered during deserialization

sowohl beim Aufruf der Methode Deserialize() als auch beim Aufruf der Methode Parse().

Folgender Beispielcode nutzt AllowDuplicateProperties = false:

  try
  {
   CUI.H2("Deserialisierung mit AllowDuplicateProperties = false");
   JsonSerializerOptions options = new() { AllowDuplicateProperties = false };
   JsonSerializer.Deserialize<Person>(json, options); // JsonException
  }
  catch (Exception ex)
  {
   CUI.PrintError(ex);
  }
 
  try
  {
   CUI.H2("Parse mit AllowDuplicateProperties = false");
   JsonDocumentOptions docOptions = new() { AllowDuplicateProperties = false };
   JsonDocument.Parse(json, docOptions); // throws JsonException
  }
  catch (Exception ex)
  {
   CUI.PrintError(ex);
  }

(rme)