Connect with us

Entwicklung & Code

APIs in KI integrieren: Neue Kreativität und zuverlässige Automatisierung



Erik Wilde

Erik Wilde

Erik Wilde hat jahrelange Erfahrung im API-Bereich. Als Botschafter bei der OpenAPI-Initiative setzt er sich für den Einsatz offener Standards und Best Practices in API-Design und -Management ein. Auf YouTube betreibt er den Channel Getting APIs to Work, der sich an IT-Experten, Entwicklerinnen und Produktmanager richtet. Außerdem hat Wilde zahlreiche Artikel und Bücher geschrieben, und er spricht regelmäßig auf Fachkonferenzen.

Weiterlesen nach der Anzeige

iX: Schnittstellen sind ein absolutes Grundkonzept der Softwarearchitektur; man entwirft, implementiert und überarbeitet sie ständig für die Anwendungsprogrammierung. Wann beginnt man, eine Schnittstelle als API zu bezeichnen? Die Semantik dieses Wortes geht über die reine Abkürzung hinaus.

Erik Wilde: Man bezeichnet eine Schnittstelle als API, sobald sie über ihren unmittelbaren Implementierungskontext hinaus von anderen genutzt werden soll. Eine Schnittstelle ist nur eine technische Grenze, eine API hingegen ein veröffentlichter Vertrag. Das bedeutet, dass sie absichtlich offengelegt, dokumentiert und stabil genug ist, damit andere – innerhalb oder außerhalb des Entwicklerteams oder Systems – sich darauf verlassen können. Es ist vor allem der Aspekt der Absicht und des breiteren Publikums, der eine API auszeichnet.

iX: Sind die Ansätze, die eine API für Menschen nützlich und zugänglich machen, nicht dieselben wie diejenigen, die sie für KI, also LLM-basierte Automatisierung, zugänglich machen?

Wilde: Sowohl Menschen als auch Maschinen benötigen zugängliche APIs, jedoch auf unterschiedliche Weise. Für Menschen funktioniert die Dokumentation am besten, wenn APIs einheitliche Muster aufweisen, da das nicht nur das Verständnis erleichtert, sondern auch die Wiederverwendung von Tools und Verfahren für verschiedene APIs ermöglicht. Menschen können auch einen breiteren Kontext heranziehen, ohne verwirrt zu werden. Maschinen hingegen benötigen eine klare, in sich geschlossene Beschreibung jeder API. Selbst wenn die Kontextfenster größer werden, ist mehr Kontext nicht immer hilfreich – KI hat oft Schwierigkeiten, größere Kontexte effektiv zu nutzen.

Menschen schätzen APIs, die offen, wiederverwendbar und flexibel anpassbar sind, während Maschinen mehr von einer geführten Abstraktionsebene profitieren, die den Schwerpunkt darauf legt, was erreicht werden kann und wie dies zu tun ist, anstatt jede mögliche Operation offenzulegen.

Weiterlesen nach der Anzeige

iX: Sie haben sich in der Vergangenheit in Ihrem YouTube-Channel „Getting APIs to Work“ mit dem ökologischen Fußabdruck von APIs befasst. Wenn man über Softwareeffizienz und CO2-Bewusstsein nachdenkt, passt das dann gut zu dem, was derzeit als Agentic AI beworben wird?

Wilde: Der ökologische Fußabdruck von Agentic AI ist erheblich, da die explorative Nutzung durch Agenten oft zu mehr Orchestrierung, mehr Rechenzyklen und einem höheren Energieverbrauch führt. Das scheint im Widerspruch zu den Bestrebungen nach Effizienz und CO2-Bewusstsein bei Software und APIs zu stehen.

Der Weg nach vorne besteht darin, sie als komplementär zu betrachten: Agenten können kreative Lösungen erforschen und neue Vorgehensweisen aufdecken, aber sobald ein vielversprechender Ansatz gefunden ist, sollte er in einen deterministischen, wiederholbaren Workflow kodifiziert werden, der energieeffizient, skalierbar und überprüfbar ist. Das bringt die Vorteile der Kreativität der KI mit der Notwendigkeit eines nachhaltigen und konformen Betriebs in Einklang, wobei so viel KI wie nötig, aber so wenig wie möglich eingesetzt wird.

Durch das Entwickeln von Architekturen, die einen reibungslosen und bewussten Übergang vom Experimentieren zur effizienten Ausführung ermöglichen, können wir sowohl die Unsicherheit hinsichtlich der Unvorhersehbarkeit der KI als auch die Notwendigkeit angehen, ihren erheblichen Energieverbrauch zu kontrollieren.

iX: In welcher Beziehung steht MCP zu OpenAPI? Verfolgen beide nicht dasselbe Ziel: die Standardisierung der Beschreibung von APIs und deren einfache Zugänglichkeit? Oder ähnelt es eher JSON:API, also der Standardisierung der APIs selbst?

Wilde: Bei MCP, OpenAPI und JSON:API geht es darum, Funktionen verfügbar zu machen, aber sie richten sich an unterschiedliche Nutzer. MCP wurde speziell für LLMs entwickelt und stellt ihnen Tools und Ressourcen zur Verfügung, die auf ihre Arbeitsweise zugeschnitten sind. OpenAPI hingegen richtet sich an Entwickler, die HTTP-APIs nutzen möchten, und konzentriert sich hauptsächlich darauf, Endpunkte zu strukturieren und diesen Schemata hinzuzufügen.

JSON:API fügt eine weitere Ebene hinzu, indem es standardisiert, wie die Schemata strukturiert sind und welche gemeinsamen Konzepte eine API offenlegen sollte, sodass Entwickler von bereits bekannten Konventionen profitieren und Tools wiederverwenden können, die diese unterstützen.

Es ist zwar möglich, MCP-Server automatisch aus OpenAPI zu generieren, aber das führt in der Regel nicht zu den besten Ergebnissen: Bei komplexeren APIs reicht eine Liste von Endpunkten nicht aus, da LLMs das implizite Verständnis fehlt, das Menschen beim Schreiben von Code mitbringen. Das ist der grundlegende Unterschied: OpenAPI und JSON:API gehen davon aus, dass ein menschlicher Developer die Lücken füllen kann, während MCP eine ausreichend aufgabenorientierte Struktur bereitstellen muss, damit ein LLM ohne diese menschliche Intelligenz erfolgreich sein kann.

iX: Machen LLMs bestimmte Ansätze zur Automatisierung überflüssig? Oder sind sie nur ein weiterer Anwendungsfall? Aufgrund der Nicht-Determiniertheit können sie eine zuverlässige Systemintegration vermutlich nicht wirklich ersetzen.

Wilde: Bei der Automatisierung geht es in der Regel um Zuverlässigkeit, Wiederholbarkeit und Effizienz, was LLMs nicht bieten. Sie sind nicht deterministisch, nicht zuverlässig reproduzierbar und nicht besonders effizient. Was sie jedoch bieten, ist eine neue Art von Kreativität: die Fähigkeit, Lücken zu schließen, Lösungen auszuprobieren und chaotischere Teile der Automatisierung zu bewältigen, die mit traditionellen Ansätzen nicht möglich sind.

Am besten betrachtet man sie als ein weiteres Werkzeug im Werkzeugkasten – eines, das wir selektiv einsetzen können, zum Erkunden oder für bestimmte Teile eines Prozesses, aber nicht für die Teile, die strenge Garantien erfordern. Architekturen, die LLM-gesteuerte Erkundung mit kodifizierten, deterministischen Workflows kombinieren, können das Beste aus beiden Welten vereinen: KI, wo Kreativität einen Mehrwert schafft, und traditionelle Automatisierung, wo Zuverlässigkeit unerlässlich ist.

Das Interview führte Richard Wallintin von WPS – Workplace Solutions.


(rme)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Gegen nervige Alltagsaufgaben: Amazon AWS bringt neue KI-Agenten


Auf seiner diesjährigen Hausmesse re:Invent machte AWS unmissverständlich klar, wohin die Reise geht: Agentische KI-Systeme sollen künftig nicht nur einfache Aufgaben erledigen, sondern stunden- oder sogar tagelang autonom arbeiten. Mit den sogenannten Frontier Agents kündigte Amazon eine neue Generation von KI-Agenten an, die ohne ständige menschliche Anleitung persistente Kontexte aufrechterhalten und komplexe Workflows bewältigen sollen.

Weiterlesen nach der Anzeige

Im Mittelpunkt stehen drei spezialisierte Agenten, die den Software-Entwicklungszyklus transformieren sollen. Der Kiro Autonomous Agent fungiert als virtueller Entwickler, der Backlogs abarbeitet, Bugs klassifiziert sowie priorisiert und Aufgaben über mehrere Code-Repositories hinweg eigenständig löst. Dabei lernt er kontinuierlich aus Feedback und Pull-Requests. Der AWS Security Agent übernimmt die Rolle eines virtuellen Sicherheitsberaters: Er überprüft Designdokumente und Pull-Requests auf Schwachstellen, orientiert sich dabei an organisationsspezifischen Vorgaben und verwandelt zeitaufwendige Penetrationstests in eine On-Demand-Funktion. Komplettiert wird das Trio durch den AWS DevOps Agent, der als Teil des operativen Teams Vorfälle diagnostiziert, Telemetrie- und Bereitstellungsdaten korreliert und proaktiv Verbesserungen vorschlägt.

Bedrock AgentCore wird erweitert

Die zentrale Plattform für den Betrieb dieser Agenten, Amazon Bedrock AgentCore, erhielt drei wesentliche Erweiterungen. Mit AgentCore Policy lassen sich nun in natürlicher Sprache formulierte Richtlinien, sogenannte Guardrails, durchsetzen, die unbefugte Agentenaktionen in Echtzeit blockieren. AgentCore Evaluations bietet 13 vorgefertigte Metriken zur Qualitätssicherung, etwa für Korrektheit und Kontextrelevanz. AgentCore Memory, ein episodischer Speicher, ermöglicht es Agenten, aus vergangenen Interaktionen zu lernen und ihre Entscheidungsfindung anzupassen.

Ergänzt wird das Portfolio durch Amazon Nova Act, einen Dienst zur Automatisierung von Browser-UI-Workflows, der laut AWS eine Zuverlässigkeit von 90 Prozent erreicht. Auch das Open Source KI-Agenten-SDK Strands Agents, das AWS erst im Mai diesen Jahres vorgestellt hatte und zunächst auf Python fokussiert war, wurde um TypeScript-Unterstützung erweitert und läuft nun auf Edge-Geräten für Automotive- und Robotik-Anwendungen.

Warnung vor explodierenden Kosten

Bei aller technischen Raffinesse hat die wirtschaftliche Seite der Agentisierung einen deutlichen Haken. Jeff Boudier, Chief Product & Growth Officer bei Hugging Face, ordnet in einem Gespräch mit der iX ein, dass der Einsatz von KI-Agenten grundsätzlich sorgfältig hinterfragt werden müsse. Der Übergang von klassischen LLM-Anwendungen hin zu agentischen Systemen führe aufgrund ihrer iterativen Arbeitsweise zu einem drastisch höheren Rechenaufwand.

Weiterlesen nach der Anzeige

„Anstatt dass eine Nutzeranfrage etwa einen Cent kostet, liegen wir bei agentischen Systemen schnell bei drei, fünf oder sogar mehr Dollar“, erklärt Boudier. „Dieser Wandel wird im kommenden Jahr noch eine enorme Menge an Engineering-Arbeit auslösen, um diese Kosten wieder zu senken.“

Unternehmen müssen sich deshalb vorab fragen, ob sie für einen konkreten Anwendungsfall überhaupt einen Agenten benötigen, welchen Wert eine korrekte Antwort hat und wie hoch das Risiko ist, wenn ein Agent falsche Entscheidungen trifft. Auch ob die von AWS versprochene Zuverlässigkeit und Skalierbarkeit ihrer Agenten die Mehrkosten rechtfertigen, wird sich erst in der Praxis zeigen müssen.


(fo)



Source link

Weiterlesen

Entwicklung & Code

Developer-Häppchen – Kleinere News der vergangenen Woche (ehemals Snapshots)


Die beliebten Developer-Snapshots haben wir neu in leckere Häppchen verpackt. Inhaltlich bleibt alles beim Alten – ein kleiner Überblick über alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:

Weiterlesen nach der Anzeige

    Codeformatierung mit Prettier 3.7: Das Open-Source-Tool hat an der Konsistenz zwischen Class- und Interface-Formatierung für TypeScript geschraubt. Daneben bringt es Updates für die Darstellung von JavaScript, CSS und mehr, ebenso wie Support für das aktuelle Release Angular 21.JetBrains hat den Release Candidate für IntelliJ IDEA 2025.3 veröffentlicht. Interessierte können darin neue Features wie Spring-Debugger-Updates und den Support für Spring Boot 4, Spring Framework 7 und Java 25 nutzen. Die Programmiersprache Julia hat nun eine offizielle Arbeitsgruppe für Sicherheit: die Julia Security Working Group (JSWG). Bisher haben Julia-Developer sich über Security-Arbeiten in einem informellen Rahmen ausgetauscht – via Slack, Repos und Pull Requests –, was nun jedoch in der JSWG gebündelt werden soll. Zunächst sollen Meetings im zweiwöchentlichen Takt eingeführt werden. Weitere Infos gibt es im Slack-Channel #security-dev.Apache Flink 2.2.0 bringt neue KI-Fähigkeiten mit: ML_PREDICT für LLM-Inferenz und VECTOR_SEARCH für Echtzeit-Vektor-Ähnlichkeitssuche sind nun mit an Bord.


Product Owner Days 2026

Product Owner Days 2026

(Bild: deagreez/123rf.com)

Die Product Owner Days am 5. und 6. Mai 2026 in Köln bieten über 20 Vorträge zu Product Ownership, KI im Produktmanagement, User Research, Product Discovery & Product Economics sowie weiteren aktuellen Themen. Vergünstigte Frühbuchertickets sind jetzt erhältlich.

    Was gibt es Neues im Insider-Programm für Visual Studio Code? Das erfahren Interessierte in einem Podcast, den das VS-Code-Team gestartet hat. Im Podcast sollen Gespräche mit Developern, Produktmanagern und Community-Mitwirkenden geführt werden. Das Python-Webframework Django ist in Version 6.0 erschienen. Mittels Content Security Policy (CSP) lassen sich darin Sicherheitsrichtlinien auf Browserebene konfigurieren und durchsetzen, um Content Injection vorzubeugen. Mit dem Release von Django 6.0 errreicht Django 5.2 das Ende seines Mainstream-Supports.

    JupyterLite, eine Jupyter-Distribution für Webbrowser, hat in Version 0.7 neue Features, Bugfixes und Verbesserungen eingeführt. Unter anderem bringt das Release Support für Workspaces, die es ermöglichen, Notebooks und Dateien in separaten Workspace-Umgebungen zu organisieren. Zudem bringt v0.7 integrierte Audio- und Video-Viewer mit, sodass Nutzerinnen und Nutzer entsprechende Dateien direkt aus dem UI heraus öffnen können.Die erste Beta von Vite 8, die unter der Haube den Bundler Rolldown nutzt, ist erschienen. Sie soll deutlich schnellere Produktions-Builds ermöglichen und den Weg für künftige Verbesserungen ebnen. Bisher setzte Vite auf die beiden Bundler esbuild und Rollup für verschiedene Aufgaben. Das in Rust geschriebene und für Vite konzipierte Rolldown wird nun als alleiniger Bundler eingesetzt.Das Rust-Team hat mit der Planung der Projektziele für die Programmiersprache im nächsten Jahr begonnnen. Die Planung betrifft nun nicht wie bisher jeweils sechs Monate, sondern das komplette Jahr 2026. Auch Rust-User sind dazu aufgerufen, ihre Ideen mitzuteilen.

Solltest du ein schmackhaftes Thema vermissen, freuen wir uns über deine Mail.


(mai)



Source link

Weiterlesen

Entwicklung & Code

Sulu 3.0: CMS mit neuem Content-Speicher und klarerer Architektur


Sulu 3.0 ist erschienen. Mit dem Release vollzieht das quelloffene Content-Management-System (CMS) laut Blogbeitrag eine größere technische Umstrukturierung. Statt auf das bislang genutzte PHPCR‑Repository setzt das Projekt künftig vollständig auf Doctrine ORM und JSON‑Felder – eine Entscheidung, die nicht nur die Performance heben, sondern auch die Einstiegshürde für Symfony‑Entwickler senken soll. Nach Angaben des Teams kamen rund 150.000 Zeilen Code neu hinzu, mehr als 265.000 wurden entfernt.

Weiterlesen nach der Anzeige

Das Open-Source-CMS Sulu basiert auf dem PHP-Framework Symfony und dient als Headless‑ oder klassisches CMS für komplexe, mehrsprachige Webprojekte. Es richtet sich vor allem an Entwicklerinnen und Entwickler, die flexible Inhaltsmodelle mit vertrauten Symfony‑Werkzeugen umsetzen wollen. Für Symfony sind kürzlich die Versionen 7.4 und 8.0 erschienen.

Von PHPCR zu Doctrine ORM

Mit der Abkehr vom speicherintensiven PHPCR führt Sulu ein neues Modell zur Ablage von Inhalten ein: Seiten, Artikel oder Snippets werden jetzt als reguläre Doctrine‑Entitäten mit JSON‑Spalten verwaltet. Damit greifen Developer direkt auf bekannte Tools und SQL‑Abfragen zurück, statt eine eigene Query‑Sprache lernen zu müssen.

Das System nutzt sogenannte Dimensionen, um Sprach‑, Veröffentlichungs‑ und Versionszustände abzubilden. So lassen sich nicht übersetzbare Felder in mehreren Sprachvarianten weiterverwenden – ein Ansatz, der die vorherige, tiefer verschachtelte Struktur ersetzt und sich offenbar leichter debuggen lässt.

Bessere Performance und Vereinfachungen

Nach Angaben des Teams bringt der neue Speicheransatz spürbare Leistungsgewinne. Content‑Strukturen lassen sich nun direkt in der Datenbank nachvollziehen, während Konfigurationsdaten weiterhin als XML im Repository bleiben.

Weiterlesen nach der Anzeige

Auch das Update der PHP-Bibliothek Flysystem auf Version 3 soll zur Vereinfachung der Handhabung von Mediendateien beitragen. Diese können künftig über eine einheitliche Schnittstelle auf unterschiedlichen Backends abgelegt werden, beispielsweise auf Amazon S3, Microsoft Azure, WebDAV oder Dropbox.

Entfall der Elasticsearch‑Pflicht für Artikel

Neben der Speicherarchitektur wurde das Artikel‑Bundle neu geschrieben. Es lässt sich nun ohne die Suchmaschine und das Analytic-Tool Elasticsearch betreiben, wodurch kleineren Projekten die Installation eines separaten Suchdienstes erspart bleiben soll. Für große Installationen bleibt die Option durch ein ergänzendes Bundle erhalten, das Elasticsearch wieder einbindet.

Ebenfalls neu ist SEAL, der Search Engine Abstraction Layer. Er bündelt Anbindungen an Suchsysteme wie Loupe, Meilisearch, Solr oder Elasticsearch hinter einer gemeinsamen API. Standardmäßig kommt Loupe zum Einsatz – eine SQLite‑basierte, PHP‑interne Lösung, die für mittlere Datenmengen ausreichend schnell arbeitet.

Migration und Unterstützung

Sulu liefert ein eigenes Tool, um vorhandene PHPCR‑Daten zu konvertieren. Das Migration‑Bundle überführt Seiten, Artikel, Snippets und URLs in die neue Speicherstruktur und protokolliert detailliert, wo gegebenenfalls Nacharbeit nötig ist.

Wer die Umstellung nicht allein durchführen möchte, kann laut Entwicklerteam auf Community‑Hilfe via Slack und GitHub oder auf professionelle Unterstützung zurückgreifen. Weitere Informationen zur Hilfe sowie zum Release finden sich im Blogbeitrag.

Weiterer Fahrplan

Mit Version 3.0 endet die Pflege für Sulu 1.6, während Sulu 2.6 als LTS-Version (Long-term Support) erhalten bleibt. Die neue Architektur soll künftige Funktionen erleichtern und das CMS langfristig wartbarer machen. Näheres zum Release und zum CMS auch auf GitHub.


(mdo)



Source link

Weiterlesen

Beliebt