Der Gebrauch von KI-Coding-Tools soll bei Amazon zu Ausfällen seiner E-Commerce-Plattform geführt haben. Laut einem Bericht wurde deshalb ein bislang freiwilliges wöchentliches Meeting umgewidmet, an dem alle beteiligten Entwickler teilnehmen müssen. Ein erstes Ergebnis: Künftig sollen KI-assistierte Code-Änderungen nur noch nach Prüfung durch erfahrene Kräfte freigegeben werden.

Anfang März soll es zu knapp sechsstündigen Ausfällen auf Amazon.com und in der Shopping-App gekommen sein. Kunden konnten dem Bericht zufolge keine Käufe tätigen, ihre Daten oder Preise abrufen. Als Ursache wurde offiziell eine fehlerhafte Software-Aktualisierung genannt.

Einzelne Fehler mit weitreichenden Folgen

Internen Unterlagen zufolge hätten KI-generierte Änderungen die Probleme ausgelöst, berichtet die Financial Times unter Berufung auf nicht genannte Quellen im Unternehmen. Es fehlten Best Practices und Sicherheitsmechanismen für den Gebrauch der generativen KI. Einzelne Fehler hätten deshalb zu weitreichenden Folgeschäden geführt. Bereits vor knapp anderthalb Jahren war öffentlich geworden, dass Amazon von Softwareentwicklern inzwischen erwartet, dass sie KI für viele Programmieraufgaben verwenden.

Neben der Einkaufsseite soll auch Amazons Cloud-Sparte AWS in mindestens zwei Fällen Probleme durch KI-Coding-Assistenten verzeichnet haben. Im Dezember etwa habe das Amazon-eigene KI-Tool „Kiro“ eigenständig eine Produktionsumgebung gelöscht und sie neu erstellt. Folge sei ein 13-stündiger Ausfall eines Kostenkalkulators für AWS-Kunden gewesen. Amazon selbst habe nur von einem sehr kleinen Problem gesprochen, das nur einen einzelnen Dienst in Teilen Chinas betraf.

Intern soll es Diskussionen geben, ob nicht auch der Stellenabbau bei Amazon in die Probleme hineinwirkt. Amazon hatte sich von 16.000 Mitarbeitern getrennt. Seither sei die Zahl kritischer Probleme gestiegen, berichten Entwickler laut der FT. Amazon selbst bestreitet einen Zusammenhang. Auch die ergriffenen Maßnahmen seien „normaler Geschäftsbetrieb“ und Teil kontinuierlicher Verbesserungen.

(mki)

Der Terminal-Emulator Ghostty ist in Version 1.3.0 erschienen und bringt unter anderem eine Scrollback-Suche, native Scrollbars sowie die Option, den Cursor durch Klick in Shell-Prompts zu positionieren. Außerdem haben die Entwickler eine wichtige Sicherheitslücke geschlossen.

Ghostty ist ein moderner Terminal-Emulator für macOS und Linux, der auf GPU-Rendering setzt und in der Programmiersprache Zig geschrieben wurde. Entwickelt wird er vom HashiCorp-Gründer Mitchell Hashimoto. In die neue Version sind sechs Monate Arbeit geflossen, 180 Entwickler haben über 2.858 Commits beigetragen. Die Release Notes umfassen hunderte Verbesserungen, Bugfixes und Performance-Optimierungen auf allen unterstützten Plattformen.

Scrollback-Suche mit dediziertem Thread

Die neue Scrollback-Suche gehört zu den am häufigsten gewünschten Features. Sie lässt sich unter macOS mit Cmd+F, unter Linux mit Strg+Umschalt+F aufrufen. Die Implementierung hebt gefundene Treffer hervor und erlaubt die Navigation mit Pfeiltasten oder Cmd+G. Auf macOS lässt sich die Suchleiste zu einer der vier Ecken ziehen, falls sie wichtige Inhalte verdeckt. Die Suche integriert sich zudem in macOS-Komponenten wie der Menüleiste, den systemweiten Shortcuts für „Weitersuchen/Zurücksuchen“ und der System-Zwischenablage für Suchbegriffe. Technisch arbeitet die Suche mit einem dedizierten Thread, der nur kleine Lock-Zeit-Slices benötigt und sich bei Nichtnutzung selbst terminiert, um I/O und Rendering minimal zu beeinträchtigen.

Ebenfalls neu sind native Scrollbars im Overlay-Style, die sich systemkonform in macOS und GTK einfügen. Per Konfigurationsoption scrollbar lässt sich das Verhalten anpassen, standardmäßig übernimmt Ghostty die Systemeinstellung.

Klickbare Prompts und Command-Finished-Benachrichtigungen

Eine weitere Neuerung ist, dass man den Cursor per Klick in Shell-Prompts positionieren kann – wie in einem regulären Textfeld. Das Feature unterstützt hierzu die OSC-133-Extensions click-events und cl=line. Native Unterstützung bieten Fish ab Version 4 und Nushell ab 0.111, für andere Shells hängt der Support von Ghosttys eingebundener Shell-Integration ab. Die Entwickler haben ihre OSC-133-Implementierung überarbeitet und setzen nun auf eine region-basierte Erkennung, die genauer arbeitet als die row-basierte Variante mancher Konkurrenten. Ein Debug-Overlay für OSC-133-Bereiche hilft beim Troubleshooting.

Neu sind auch Benachrichtigungen über abgeschlossene Befehle. Nutzer können über drei Konfigurationsoptionen festlegen, wann und wie Ghostty Meldungen anzeigen soll: nie, nur bei nicht fokussiertem Fenster oder immer. Die Aktion lässt sich auf einen Klingelton (bell) oder eine Systembenachrichtigung einstellen, standardmäßig werden nur Befehle gemeldet, die länger als 5 Sekunden dauern. Auch dieses Feature benötigt OSC 133 oder die Shell-Integration.

Performance-Optimierungen und Sicherheitsfix

Die Entwickler haben die I/O-Performance deutlich verbessert. Tests mit 4 GByte großen asciinema-Dateien zeigen, dass die Replay-Zeit von mehreren Minuten auf wenige Sekunden gesunken ist. Die Renderer-Lock-Zeit konnte um den Faktor zwei bis fünf reduziert werden, oft arbeitet das System dank Dirty-Tracking völlig lock-frei. Das führt zu glatterem Scrolling und weniger Jitter bei starker Ausgabe.

Ein kritisches Speicherleck wurde behoben, das durch bestimmte KI-Tools wie Claude Code ausgelöst wurde. Bei intensiver Nutzung konnte der Speicherverbrauch nach zehn Tagen auf bis zu 37 GByte anwachsen. Der Fehler existierte seit Version 1.0 und betraf die Recycling-Logik für non-standard Scrollback-Pages. Die Stabilität bei intensiver Nutzung mit Logs oder Build-Ausgaben ist nun deutlich höher.

Mit CVE-2026-26982 wurde eine Sicherheitslücke geschlossen, bei der Control-Characters wie 0x03 (Ctrl+C) in eingefügten Texten oder per Drag-&-Drop übertragenen Inhalten zur Ausführung beliebiger Befehle in manchen Shells führen konnten. Der Angriff erfordert zwar User-Interaktion, aber solche Paste-Exploits sind in Terminal-Emulatoren nicht ungewöhnlich. Ghostty ersetzt nun unsichere Control-Characters beim Einfügen durch Leerzeichen, analog zu xterm.

Non-Profit-Projekt und neue Systemanforderungen

Ghostty ist nun offiziell ein Non-Profit-Projekt unter der Schirmherrschaft von Hack Club, einer 501(c)(3)-Organisation. Fast alle Spenden fließen direkt an Contributors, fünf davon haben bereits Verträge für insgesamt rund 300 Stunden Entwicklungsarbeit unterzeichnet. Die Umwandlung soll das Projekt langfristig vor Kommerzialisierung und Verkauf schützen.

Die Systemanforderungen haben sich geändert: Version 1.3.0 ist die letzte, die macOS 13 Ventura unterstützt. Ab Version 1.4 ist macOS 14 erforderlich, da Apple den Support für Ventura im Herbst 2025 eingestellt hat. Unter Linux benötigt Ghostty GTK 4.14 und libadwaita 1.5. Ältere Distributionen wie Debian Bookworm müssen auf Snaps oder Flatpaks ausweichen oder bei einer älteren Ghostty-Version bleiben.

Weitere Neuerungen umfassen erweiterte Keybind-Funktionen wie Key Tables und verkettete Keybinds, Unterstützung für das Kitty Keyboard Protocol sowie Unicode-17-Konformität. Unter macOS gibt es experimentelle AppleScript-Unterstützung zur Automatisierung sowie unaufdringliche Update-Mechanismen. Die eigenständige Bibliothek libghostty erlaubt es, den Terminal-Emulator in Drittanwendungen wie Neovim, Multiplexer oder PaaS-Lösungen zu integrieren.

Mehr Details zu Ghostty 1.3.0 finden sich in den Release Notes. Einen ausführlichen Test des Terminal-Emulators hat heise online im Februar 2025 veröffentlicht.

(fo)

In vielen Softwareteams läuft die Entwicklung wie geschmiert. Entwicklerinnen und Entwickler sammeln Anforderungen, setzen Features um, schließen Sprints ab und liefern Releases aus. Es wird gebaut, getestet, deployt, immer und immer wieder. Und doch bleibt häufig ein diffuses Gefühl zurück. Warum diese Arbeit, warum der ganze Code? Selbst wenn man mit KI-Unterstützung noch schneller mehr Code erzeugen kann, heißt das noch lange nicht, dass am Ende viel Wert entsteht.

Darin liegt das Problem, das viele Produktteams haben: Der Fokus liegt auf Output. Die Teams setzen mehr und mehr Features um und messen den Fortschritt anhand der erledigten Arbeit. Produkte sammeln immer mehr Funktionalität an und wachsen kontinuierlich. Viele Produktverantwortliche glauben, dass das nötig ist, um sich vom Wettbewerb zu differenzieren und bestehenden Nutzerinnen und Nutzern ständig etwas Neues zu bieten. Dabei ist nicht immer „mehr“ die Lösung, sondern manchmal sogar ein Problem. Je mehr Features das Produkt umfasst, umso mehr Arbeit muss in Bugfixing und Wartung fließen. Und genau hier setzt der Gedanke an, sich mehr auf Outcome statt Output zu konzentrieren.

Output ist nicht gleich Wert

Wo liegt der Unterschied zwischen Output und Outcome? Output beschreibt, was produziert wird. Outcome ist das, was das Produzierte bewirkt. Jede Funktion, jede neue Dokumentation, jeder neue Test ist erst einmal nur Output. Je mehr ein Team davon liefert, desto „produktiver“ ist es. Dabei bleibt zunächst unklar, was sich durch den erzeugten Output verändert. Was wird sich für Nutzerinnen und Nutzer ändern?

Zum Beispiel hat ein Onlineshop mit häufig wiederkehrenden Einkäufen (etwa für den Wocheneinkauf oder die Bestellung bei der Lieblingspizzeria) eine Funktion, die User beim Einkauf daran erinnern soll, dass sie ein oft gekauftes Produkt diesmal vergessen haben (zum Beispiel „Du nimmst normalerweise Pizzabrötchen dazu. Hast du sie vielleicht vergessen?“). Das Feature für diese Erinnerung ist erst einmal nur der Output. Wenn Kundinnen und Kunden das Feature aber nutzen und es dafür sorgt, dass sie mehr einkaufen, ist das der Outcome. In anderen Kontexten kann das dann auch eine schnellere Einarbeitung, glücklichere Kunden oder Ähnliches bedeuten. Outcome ist aber am Ende immer die Antwort auf die Frage, was sich durch den Output verbessern soll.

Das Konzept von Outcome und Output bei einem komplexen Produkt lässt sich gut am Beispiel des Essens für eine Feierlichkeit verdeutlichen. Jedes einzelne Gericht, jeder Dip, jede Soße und jede Beilage ist Output. Misst man den Erfolg der eigenen Arbeit an Output, so geht es in erster Linie darum, dass möglichst viel Essen auf dem Tisch steht. Geht es aber um Outcome, dann sind die Freude beim Essen, das Lächeln der Gäste und das Genießen des Essens von Bedeutung. Man geht demnach anders an die Arbeit, wenn man sich andere Fragen stellt. Braucht es möglichst viel Essen oder geht es darum, die Personen kulinarisch zufrieden zu stellen? Geht es um schlichte Sättigung oder um Begeisterung beim Essen? Bezogen auf Software: Nutzerinnen und Nutzer freuen sich nicht über zusätzliche Features an sich. Vielmehr freuen sie sich darüber, wenn sie ein Problem einfacher lösen, eine Arbeit schneller durchführen oder eine Funktion leichter bedienen können.

Output-Orientierung lässt sich in vielen Produktteams beobachten. Sie streben dann oft danach, die Arbeitszeit von Entwicklerinnen und Entwicklern maximal auszulasten. Eine hohe Anzahl an Arbeitsergebnissen erzeugt das Gefühl von Produktivität. Langfristig führt das aber nicht nur zu Produkten mit begrenzter Wirkung, sondern auch zu Frustration im Team. Gerade Developer erleben häufig, dass sie technisch anspruchsvolle Lösungen umsetzen, ohne zu wissen, ob diese überhaupt sinnvoll sind.

Outcome ist auch Entwickleraufgabe

Jetzt kann man es sich relativ einfach machen. Die Entscheidung, was gebaut wird, liegt häufig beim Produktmanagement oder der Konzeption. Als Entwicklerin oder Entwickler muss man „nur noch“ die Anforderungen umsetzen beziehungsweise in Code konvertieren. Dieses Übersetzen setzt jedoch einiges an Expertise voraus, denn gute Software zu bauen ist alles andere als trivial. Aber sich auf die Umsetzung von Features zurückzuziehen, entbindet Entwickler nicht von der Verantwortung, sich um die eigene Wirksamkeit zu kümmern. Sich nur als Umsetzende zu sehen, ist zu kurz gedacht, denn gerade Entwicklerinnen und Entwickler sitzen an zentraler Stelle. Sie übersetzen Ideen in Realität, treffen dabei aber wichtige Architekturentscheidungen und kennen die technischen Möglichkeiten und Grenzen am besten. Wenn sie in diesem Prozess Fragen zum angestrebten Outcome stellen, hilft Ihr Wissen dabei, gute Lösungen zu finden, statt nur Anforderungen umzusetzen.

Der stärkste Hebel sind die richtigen Fragen

Developer müssen aber nun keine neuen Rollen übernehmen. Häufig hilft es schon, an den richtigen Punkten die richtigen Fragen zu stellen (siehe Textkasten). Insbesondere in Terminen, in denen es um Anforderungen geht, entstehen oft wertvolle Diskussionen und somit auch Gelegenheiten, den Grund (den gewünschten Outcome) eines Features zu erfragen und durch das Gespräch gegebenenfalls den Fokus der Entwicklung zu verschieben. Warum soll das jeweilige Feature gebaut werden? Warum benötigen die User das Feature? Woran erkennt man hinterher, dass es sich gelohnt hat, das Feature zu entwickeln?

Natürlich ist es für diejenigen, die die Anforderungen stellen, einfacher, direkt eine bestimmte Funktion zu bestellen. Aber es ist überraschend, wie oft sich auch diese Menschen noch nicht so richtig Gedanken dazu gemacht haben, warum die Welt dieses Feature benötigt und welche Wirkung es eigentlich genau erzielen soll.

Sicherlich sollte jemand aus dem Produktmanagement oder anderen Bereichen die obigen Fragen beantworten können, aber zwei wichtige Aspekte darf man dabei nicht vergessen. Zum einen arbeiten auch dort nur Menschen. Vielleicht finden sie die Idee für das Feature einfach spannend oder haben einfach Lust darauf, es im Produkt zu sehen. Welche Wirkung es bei den Usern auslöst, wurde vielleicht nicht bedacht. Zum anderen passiert es jeder und jedem hin und wieder einmal, dass man sich sehr in einer Lösungsidee verfängt und aus den Augen verliert, dass die gleiche Wirkung auch auf einem anderen Weg erreichbar wäre.

Entwicklerinnen und Entwickler haben als vollwertige Teammitglieder auch die Aufgabe, dafür zu sorgen, die richtigen Dinge zu tun. Manche Teammitglieder wollen aber nicht als Widerstand empfunden werden. Vor allem wer noch nicht viel Arbeitserfahrung hat, stellt mitunter die eigene Perspektive hinten an und geht davon aus, dass der Rest schon wissen wird, warum es sinnvoll ist, das Feature zu bauen. Aber Fragen bremsen nicht, sie schärfen. Sie helfen Teams, bewusster Entscheidungen zu treffen.

Outcome in der täglichen Arbeit verankern

Eine verstärkte Outcome-Orientierung darf aber nicht vom Engagement einzelner Teammitglieder abhängen. Sie muss vielmehr Teil der Arbeitsroutine werden, und auch dazu gibt es wirksame Hebel. Einige Produktteams nutzen beispielsweise eine Definition of Ready (DoR), die beschreibt, welche Eigenschaften erfüllt sein müssen, damit eine Anforderung umgesetzt werden kann. Eine DoR kann dann unter anderem aufführen, dass bestimmte Fragen zum angestrebten Outcome beantwortet sein müssen. Zu diesen Fragen gehören beispielsweise die im Textkasten genannten. Durch die Einbindung solcher Fragen in die DoR müssen einzelne Entwicklerinnen und Entwickler nicht mehr jedes Mal nachfragen und gefühlt stören, sondern ein Team verpflichtet sich als Ganzes dazu, die Fragen abzuarbeiten. Wenn beim Überprüfen der DoR unklar ist, wofür eine Anforderung umgesetzt werden soll oder woran Erfolg erkennbar sein soll, ist es sinnvoll, die Umsetzung zu verschieben und erst einmal das angestrebte Ziel oder die angestrebte Wirkung zu klären.