Die Geschichte der App von Anton Baranov ist eine von der Sorte: Wo ein Wille ist, ist auch ein Weg. Nein, nicht gleich die vom Tellerwäscher zum Millionär, aber immerhin vom Küchentisch nach Cupertino hat es der 22-Jährige gebracht. Seine erste Reise in die USA. All das gelang mithilfe der Apple-Programmiersprache Swift. Und mit großem Engagement und Zeiteinsatz, was er im Gespräch eher beiläufig erwähnt.

Für Anfang Juni hat Apple ihn nach Kalifornien, in den Apple Park, den futuristischen Stammsitz des iPhone-Herstellers, eingeladen. Dort beginnt am 8. Juni 2026 die Entwicklerkonferenz WWDC. Baranov ist einer von 50 geladenen Nachwuchsentwicklern aus aller Welt, die beim jährlichen Wettbewerb Swift Student Challenge die Jury begeistern konnten und dorthin eingeladen wurden.

Erste Teilnahme und gleich nach Cupertino

Aus dem Stand hat der Student es geschafft, gleich bei seiner ersten Teilnahme an der Challenge in die erste Reihe der Distinguished Winners aufzusteigen. Die Reise nach Cupertino ist die höchste Ehre. Manche brauchen dafür Jahre, viele schaffen es nie. Insgesamt hat Apple 350 junge Menschen aus 37 Ländern ausgezeichnet. 50 erhielten den Titel des „Distinguished Winner“ – für herausragende Einreichungen. Die frohe Botschaft erreichte ihn im Frankfurter Hauptbahnhof, erinnert er sich. „Ich habe die Mail aufgemacht und dachte erst: Okay, ich habe verloren. Weil die normalerweise direkt mit Glückwunsch anfangen.“ Er öffnet sie trotzdem. Liest. Liest noch einmal. Und war begeistert.

Die App, um die es geht, heißt „Pitch Coach: Sicher auftreten“ und sie ist seit März im App Store verfügbar. Pitch Coach analysiert Sprache in Echtzeit. Die App erkennt Füllwörter wie „ähm“, „halt“ oder „irgendwie“ und misst die Redegeschwindigkeit. Nach jeder Sitzung wird eine KI-generierte Auswertung angezeigt. Das Besondere: Die gesamte Verarbeitung läuft auf dem Gerät selbst. Kein Ton, keine Daten verlassen das iPhone. Möglich macht dies Apples Foundation-Models-Framework, das seit iOS 26 für Entwicklerinnen und Entwickler zugänglich ist.

Noch eine Funktion sticht heraus: Wer AirPods trägt, bekommt auch Feedback zur Körperhaltung. Die Bewegungssensoren in den Ohrhörern verraten, ob jemand den Kopf hängen lässt, ob die Haltung kippt. „Ich habe irgendwo gelesen, dass AirPods so einen Sensor haben. Einfach gegoogelt – und es hat funktioniert“, sagt Baranov. „Voll cool.“

Idee entstand am Küchentisch

Die Idee zur App entstand am heimischen Küchentisch. Seine Mutter, von Beruf Professorin, erzählte vom Uni-Alltag. Von talentierten Studenten, die hinter ihren Möglichkeiten bleiben, weil Sprache und Haltung nicht das ausstrahlen, was sie können. Baranov hörte zu – und erkannte sich selbst. Dass es darauf ankommt, wie man sich präsentiert, wie man spricht, wie man wirkt. Eine App, die dabei hilft, fand er im App Store nicht.

Die gute Idee ist das eine, die Umsetzung aber nochmal eine ganz andere Sache. Im August 2024 fing der 22-Jährige an, erste Projekte mit Swift umzusetzen, las Bücher und veröffentlichte Apps im App Store. Hier war es von Vorteil, dass Baranov Softwaretechnologie an der Technischen Hochschule Mittelhessen (THM) studiert – dual, in Kooperation mit der Deutschen Bank.

Seine App wurde inzwischen 9000 Mal heruntergeladen – das Neunfache dessen, was er sich als Ziel bis zum Sommer vorgenommen hatte. Und das Interesse dürfte durch die Medienberichterstattung über die Student Challenge noch zunehmen. Die Lokalisierung in 20 Sprachen ist bereits erledigt, weitere Updates sollen folgen. Und mit jedem User kommen neue Ideen. Manche Nutzungsszenarien überraschen ihn, sagt er. „Ich dachte, die Menschen bereiten Präsentationen vor, üben für Vorstellungsgespräche. Und dann schickt mir jemand eine Audio-Datei von einem Rap. Jemand anderes übt Stand-up-Comedy.“ Er zuckt mit den Schultern. „Users define the app. Wenn sie sie dafür benutzen, dann ist das eben so.“

Vibe-Coding und die Zukunft

Vibe-Coding – die Möglichkeit, dass jeder ohne Programmierkenntnisse heutzutage eine App per Zuruf erstellen kann – bereitet dem Challenge-Gewinner übrigens keine großen Sorgen. Man müsse wissen, welche Libraries gefragt sind, welche APIs genutzt werden, wie man ein Problem überhaupt präzise beschreibt. „Man steuert das trotzdem.“ Damit bestätigt er, was Forscher zuletzt in Studien herausgefunden haben: Entwickler mit solidem Hintergrundwissen sind die besseren Vibe-Coder – weil sie KI-Werkzeugen genau sagen können, was sie brauchen. Baranov sieht das pragmatisch: Die Tools erleichtern die Arbeit, aber sie machen nicht die Arbeit.

Und wo geht seine Reise nach diesem Erfolg beruflich hin? Die WWDC sieht Baranov auch als große Chance an, zu netzwerken. An seiner derzeitigen beruflichen Laufbahn bei der Bank will er aber aktuell nicht rütteln: Diese Erfahrung sei wertvoll, sagt er. Aber dass der Bilderbuchstart bei der Swift Student Challenge irgendwann doch in eine Solo-Karriere mündet – wer möchte das schon ausschließen?

(mki)

Mit Version 5.0.0 baut La Suite Docs vor allem seine Dokument-API um. Der größte Einschnitt: Inhalt und Metadaten eines Dokuments sind nun getrennt. Laut den offiziellen Release Notes und der Upgrade-Anleitung heißt der bisherige Content-Pfad jetzt formatted-content, das Feld content fällt aus der regulären Dokumentantwort weg und für Lesen sowie Schreiben kommen eigene Endpunkte hinzu. Für bestehende API-Clients ist das ein Breaking Change.

La Suite Docs ist ein quelloffener Editor für die Zusammenarbeit von Teams und versteht sich als souveräne Alternative zu Notion oder Google Docs. Zielgruppen sind öffentliche Einrichtungen ebenso wie Unternehmen. Hinter dem Projekt stehen das deutsche Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) und die französische Interministerielle Behörde für Digitales (DINUM).

Inhalt und Metadaten getrennt

Den Grund für den harten Schnitt nennen die Entwickler im Commit d7a186a. Bisher liefen Inhaltsänderungen über denselben Update-Endpunkt wie andere Dokumenteigenschaften. Selbst beim simplen Umbenennen lieferte der Server den kompletten Inhalt mit aus – und griff dafür unnötig auf den im S3-Speicher abgelegten Dokumentzustand zu. Dafür gibt es jetzt einen eigenen Endpunkt: PATCH /api/v1.0/documents/{document_id}/content/. Die Upgrade-Anleitung zeigt als erwartete Payload ein Base64-codiertes Feld content. Ist der übergebene Dokumentzustand ungültig, antwortet der Server mit 400 Bad Request und der Fehlermeldung invalid yjs document. Wer nur Metadaten wie Titel oder Sichtbarkeit ändert, muss damit nicht mehr den eigentlichen Dokumentinhalt mitschleppen.

Auch zum Lesen gibt es einen eigenen Endpunkt. GET /api/v1.0/documents/{document_id}/content/ streamt den Inhalt laut Upgrade-Anleitung als text/plain. Der Commit 6b3d197 zeigt, dass dafür StreamingHttpResponse und 8192 Byte große Chunks zum Einsatz kommen. Fehlt die Datei im Storage, liefert der Endpunkt trotzdem HTTP 200 mit leerem Body. Die Tests im selben Commit dokumentieren auch die Zugriffsmatrix: Anonyme Nutzer dürfen öffentliche Dokumente abrufen; für nicht öffentliche Dokumente erhalten sie 401. Authentifizierte Nutzer ohne Berechtigung bekommen bei restricted ein 403. Im Code spricht das Projekt von „raw Yjs content“. Yjs ist eine Bibliothek für Echtzeit-Kollaboration, die gemeinsame Datentypen automatisch synchronisiert. Der Endpunkt liefert also eher den kollaborativen Rohzustand eines Dokuments als ein fertig gerendertes Austauschformat.

Konverter und KI-Anbindung umgebaut

Für Selfhoster dürfte die zweite große Nachricht das Upgrade des Konvertierungsdiensts auf DocSpec 3.0.x sein. Pull Request #2220 hält ausdrücklich fest, dass das Docker-Image ghcr.io/docspecio/api:3.0.0 gemeinsam mit dem Anwendungscode aktualisiert werden muss. Das neue Request-Format ist nicht abwärtskompatibel; wer nur eine Seite aktualisiert, riskiert Ausfälle bei der Dokumentkonvertierung. Derselbe Pull Request beschreibt ferner die technische Umstellung: Statt eines Multipart-Uploads schickt der Client den Dokumentinhalt jetzt direkt im Request-Body und setzt Content-Type und Accept explizit. Wer eigene Compose-, Helm- oder Kubernetes-Setups pflegt, muss den Konverter also fest in den Major-Upgrade-Plan einplanen.

Neu ist außerdem eine Mistral-Anbindung für die neue KI-Pipeline. Der Commit b6efac3 führt eine Provider-Auswahl ein, die je nach Konfiguration entweder OpenAIChatModel oder MistralModel verwendet. In der Dokumentation der Umgebungsvariablen tauchen dafür OPENAI_SDK_API_KEY, OPENAI_SDK_BASE_URL, MISTRAL_SDK_API_KEY und MISTRAL_SDK_BASE_URL auf. Die Upgrade-Anleitung benennt zugleich die früheren Variablen AI_API_KEY und AI_BASE_URL in OPENAI_SDK_* um. Wichtig für Betreiber eigener KI-Infrastruktur: Der Mistral-Pfad funktioniert nur im Async-Betrieb mit uvicorn. Für Endanwender ändert sich damit zunächst wenig; die Neuerung zielt auf Installationen, die nicht ausschließlich OpenAI-kompatible Gegenstellen nutzen.

Kleinere Verbesserungen für Betrieb und Frontend

Daneben gibt es in Version 5.0.0 mehrere praxisnahe Updates für Betrieb und UI. Pull Request #2241 begründet den jetzt konfigurierbaren Forward-Auth-Header damit, dass Traefik andere Header-Namen verwendet; per Konfiguration lässt sich der auszulesende Header etwa auf HTTP_X_FORWARDED_URI setzen. Im Frontend wandert die Crisp-Hilfefunktion laut PR #2222 ins Hilfemenü – der bisherige Button habe Teile der App überlagert.

Hinzu kommen kleinere, aber nützliche Korrekturen: Angeheftete Dokumente sortiert das Backend laut PR #2028 nun nach updated_at absteigend und ungültige Verschiebeoperationen im Dokumentbaum quittiert der Server laut PR #2208 mit 400 Bad Request statt mit 500 Internal Server Error. Die Release Notes listen zudem mehrere Verbesserungen bei der Barrierefreiheit und kleinere Frontend-Fixes auf.

Unterm Strich ist Version 5.0.0 kein großes Feature-Release, sondern ein Backend- und Infrastruktur-Umbau mit spürbaren Folgen für API-Clients, Selfhoster und Betreiber eigener Zusatzdienste. Endanwender bekommen vor allem kleinere UI-Verbesserungen zu sehen. Für Integratoren bringt die neue Trennung zwischen Metadaten, formatiertem Inhalt und rohem Inhaltsstream dagegen einige Anpassungen mit sich.

(fo)

AWS hat seinen MCP-Server allgemein verfügbar gemacht. Der Dienst soll KI-Agenten und Coding-Assistenten kontrollierten Zugriff auf AWS-Ressourcen geben, ohne ihnen pauschal weitreichende Rechte einzuräumen. Über den verwalteten Remote-Server können Agenten AWS-APIs aufrufen und aktuelle AWS-Dokumentation zur Laufzeit abfragen. Der MCP-Server ist Teil des Agent Toolkit for AWS.

Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Anwendungen externe Werkzeuge, Datenquellen und Dienste anbinden können. Mit der Schnittstelle können KI-Modelle nicht nur auf ihre Trainingsdaten zurückgreifen, sondern bei Bedarf auch aktuelle Informationen abrufen und Funktionen nutzen.

Kompakter Werkzeugkasten gegen veraltetes Modellwissen

AWS will mit dem Dienst ein praktisches Problem vieler Coding-Agenten angehen: Bei AWS-Aufgaben verlassen sie sich oft auf veraltetes Modellwissen, kennen neuere Dienste nicht oder erzeugen zwar lauffähige, aber nicht produktionsreife Infrastruktur. Als Beispiele nennt AWS zu weit gefasste IAM-Policies oder die Tendenz, eher zur AWS CLI als zu CDK oder CloudFormation zu greifen.

Im Kern bietet der MCP-Server eine kleine, feste Zahl von Werkzeugen. Das Tool call_aws deckt mehr als 15.000 AWS-API-Operationen ab und nutzt dafür die vorhandenen IAM-Anmeldedaten. Über search_documentation und read_documentation können Agenten zudem aktuelle AWS-Dokumentation und Best Practices nachladen. Damit will AWS Halluzinationen reduzieren und Antworten näher an den aktuellen Stand der Plattform bringen.

Neue Funktionen: Sandbox für Python-Skripte

Mit der allgemeinen Verfügbarkeit kommen mehrere neue Funktionen hinzu. Der Server unterstützt jetzt IAM Context Keys, sodass sich Zugriffe feiner über reguläre IAM-Policies steuern lassen. Das Nachschlagen von Dokumentation funktioniert künftig ohne Authentifizierung. Auch der Token-Bedarf pro Interaktion sinkt nach AWS-Angaben – ein Punkt, der vor allem bei längeren, mehrstufigen Workflows ins Gewicht fällt.

Technisch am interessantesten ist das neue Tool run_script. Damit kann ein Agent kurze Python-Skripte serverseitig in einer Sandbox ausführen. Die Laufzeitumgebung übernimmt zwar die IAM-Berechtigungen des Nutzers, hat aber weder Netzwerkzugriff noch Zugriff auf das lokale Dateisystem oder eine Shell. So lassen sich mehrere API-Aufrufe in einem Schritt verketten, Ergebnisse filtern und auswerten, statt jeden Schritt einzeln über Tool-Aufrufe abzubilden. Praktisch wird das etwa, wenn ein Agent Konfigurations-, Inventar- und Tagging-Daten aus mehreren AWS-Diensten zusammenführen soll.

Skills ersetzen Agent SOPs

Aus Sicht von AWS ist der Wechsel von Agent SOPs zu Skills die wichtigste konzeptionelle Änderung. Skills sind kuratierte Handlungsanleitungen und Best Practices für typische Aufgaben, bei denen Agenten häufig Fehler machen. Die jeweiligen AWS-Service-Teams pflegen sie. Damit will AWS Agenten schneller zu korrekten Ergebnissen führen, die Liste verfügbarer Werkzeuge schlank halten und so Fehler, Halluzinationen und Token-Verbrauch senken.

Für Unternehmen rückt AWS Governance- und Compliance-Aspekte in den Vordergrund. Der Dienst trennt menschliche Nutzerberechtigungen klar von Agentenrechten. Über IAM-Policies oder Service Control Policies lässt sich etwa festlegen, dass ein Nutzer Ressourcen ändern darf, während derselbe Zugang über den MCP-Server auf Leseoperationen beschränkt bleibt. Für die Überwachung liefert AWS eigene CloudWatch-Metriken im Namespace AWS-MCP; CloudTrail protokolliert die API-Aufrufe zusätzlich.

Demo mit S3 Vectors zeigt den Unterschied

Wie der Dienst in der Praxis funktioniert, zeigt AWS in einer Herstellerdemo mit Claude Code. Ein Modell mit Wissensstand Mai 2025 beantwortet darin die Frage, wie sich Embeddings auf S3 speichern lassen, zunächst ohne Bezug auf Amazon S3 Vectors – ein Dienst, der erst im Juli 2025 als Preview startete und im Dezember 2025 allgemein verfügbar wurde. Mit angebundenem MCP-Server ruft der Agent laut AWS aktuelle Dokumentation ab und verweist dann auf S3 Vectors. Die Demo illustriert vor allem den Unterschied zwischen statischem Modellwissen und Laufzeitzugriff auf aktuelle Produktdokumentation.

Der MCP-Server steht zunächst in den Regionen US East (N. Virginia) und Europa (Frankfurt) bereit, kann API-Aufrufe aber in beliebige AWS-Regionen absetzen. Für den Dienst selbst fallen keine zusätzlichen Gebühren an; abgerechnet werden nur die genutzten AWS-Ressourcen und gegebenenfalls Datenübertragung. Als kompatible Clients nennt AWS in der Ankündigung unter anderem Claude Code, Kiro und Cursor; grundsätzlich funktioniert jeder MCP-fähige Client.

(fo)