Entwicklung & Code
Ghostling macht Terminal-Emulation zur C-Bibliothek
Mit Ghostling hat das Ghostty-Projekt eine Referenzimplementierung veröffentlicht, die den Kern des Terminal-Emulators als eigenständige C-Bibliothek nutzbar macht. Theoretisch wird die Terminal-Emulation so zu einer wiederverwendbaren Komponente, die sich in unterschiedliche Softwareprojekte einbetten lässt. Denkbar ist der Einsatz etwa in IDEs, Entwicklerwerkzeugen oder spezialisierten Workflow-Anwendungen, die eine integrierte Terminal-Ansicht benötigen, ohne diese selbst von Grund auf implementieren zu müssen.
Weiterlesen nach der Anzeige
Allerdings handelt es sich bei Ghostling aktuell nicht um einen vollwertigen Terminal-Emulator, sondern um eine bislang explizit minimale Demo. Das Projekt besteht im Kern aus einem einzigen C-File und verwendet die Grafikbibliothek Raylib für Fenster und Rendering. Ghostling soll zeigen, wie wenig Code nötig ist, um auf Basis der neuen Library libghostty-vt einen funktionierenden Terminal-Emulator aufzubauen. Trotz des geringen Umfangs deckt Ghostling bereits wesentliche Terminal-Funktionen ab, darunter 24-Bit-Farben, Unicode-Unterstützung, Maus-Tracking, das Kitty-Keyboard-Protokoll sowie Scrollback mit Text-Reflow.
libghostty-vt als Kernkomponente
Die für viele Entwickler spannende Neuerung ist libghostty-vt, eine aus dem Ghostty-Projekt extrahierte Bibliothek ohne externe Abhängigkeiten. Sie übernimmt das Parsen von VT-Sequenzen, die Verwaltung des Terminal-Zustands und das Management des Renderer-States. GUI-Funktionen wie Tabs, Split-Panes, Fensterverwaltung oder Konfigurationsoberflächen sind nicht Teil der Library. Diese sollen von den einbettenden Anwendungen selbst bereitgestellt werden. Einige Features wie das Kitty-Graphics-Protokoll oder OSC-Clipboard-Support sind noch nicht über die API verfügbar, stehen aber auf der Roadmap. Windows-Unterstützung ist auf Library-Ebene vorhanden, in Ghostling selbst jedoch noch nicht getestet.
Die Library basiert auf dem regulären Ghostty-Code und übernimmt dessen SIMD-optimiertes Parsing, Unicode-Support und die durch Fuzzing abgesicherte Codebasis. Sie bietet eine C- und eine Zig-API an und lässt sich laut Projektbeschreibung auf GitHub auch in WebAssembly-Umgebungen einsetzen. Erste Experimente mit libghostty in der Community finden sich in der zugehörigen Diskussion auf Hacker News. Bei Ghostling handelt es sich wie bei Ghostty um Open-Source-Software. Das Hauptprojekt liegt aktuell in Version 1.3.0 vor.
(fo)
Entwicklung & Code
KI-Coding-Tools: Geschwindigkeit ohne Kontrolle als Risiko
Für die meisten Unternehmen zahlt sich der Einsatz von KI‑Coding‑Tools stärker aus als erwartet. Das hohe Tempo agentischer Softwareentwicklung wirft aber die Frage auf, inwieweit Teams noch kontrollieren können, was sie an Code ausliefern. Zu diesen Ergebnissen kommt der AI Accountability Report von GitLab.
Weiterlesen nach der Anzeige
Im Unternehmensumfeld ist KI-gestützte Softwareentwicklung längst Standard. Laut dem GitLab-Report haben 91 Prozent der DevSecOps‑Befragten mindestens zwei Coding-Tools im Einsatz, 54 Prozent drei oder mehr. Dabei berichten 60 Prozent von einer höheren Investmentrendite als ursprünglich erwartet, 78 Prozent von schnellerem Code-Output und 73 Prozent sagen, dass sich die Codequalität verbessert habe.

Die beiden Bereiche Compliance & Audits sowie Sicherheit profitieren laut Umfrage am wenigsten von KI.
(Bild: GitLab)
Die Umfrage-Teilnehmerinnen und -Teilnehmer wenden lediglich 16 Prozent ihrer Arbeitszeit dafür auf, neuen Code zu schreiben. Eine deutliche Mehrheit von 85 Prozent sagt, dass sich der Fokus stattdessen auf Review und Validierung von KI-Output verschoben hat. Dort trägt KI allerdings am wenigsten dazu bei, die Geschwindigkeit oder Effizienz zu steigern.
Das KI-Produktivitäts-Paradoxon spüren deshalb 79 Prozent der Befragten: Die individuelle Produktivität hat nach ihrem Empfinden zugenommen, die Geschwindigkeit des Software‑Lieferprozesses als Ganzes hingegen kaum.
Governance wichtiger als Geschwindigkeit
GitLab macht AI Accountability, sinngemäß die Verantwortung eines Unternehmens im Umgang mit KI, an der Fähigkeit fest, drei Fragen beantworten zu können: Woher kommt der KI-generierte Code, wofür war er gedacht und wer ist dafür verantwortlich, sobald er Produktionsstatus erreicht hat?
Laut GitLab haben die meisten Unternehmen keine Antworten darauf. „Die Ereignisse der letzten Monate, die von Lieferketten-Angriffen über Zuverlässigkeitsprobleme bis hin zu strengeren behördlichen Auflagen hinsichtlich Nachverfolgbarkeit und Herkunft von KI reichen, zeigen, dass Geschwindigkeit ohne Kontrolle kein Vorteil, sondern ein Risiko ist“, so Manav Khurana, Chief Product and Marketing Officer von GitLab.
Weiterlesen nach der Anzeige
Im Report äußern 73 Prozent der Teilnehmerinnen und Teilnehmer Bedenken hinsichtlich der langfristigen Wartbarkeit von KI-generiertem Code; 80 Prozent meinen, dass ihr Unternehmen die KI-Werkzeuge schneller eingeführt hat, als Richtlinien zu deren Steuerung entwickelt wurden. Zudem birgt KI-generierter Code für 82 Prozent das Risiko, dass neue technische Schulden entstehen, auf die ihr Unternehmen noch nicht vorbereitet ist.
Besserung ist jedoch in Sicht: So wollen 91 Prozent der Teilnehmenden in den nächsten 12 Monaten Tools für KI-Code-Governance anschaffen. Ein Budget dafür haben 98 Prozent entweder bereits vorliegen oder zumindest eingeplant.

Wurde das Softwareproblem von KI-generiertem Code mitverursacht? 34 Prozent der Befragten konnten das im konkreten Fall nicht beantworten.
(Bild: GitLab)
Mensch oder Maschine: Wer hat’s geschrieben?
Bereits jetzt sind 87 Prozent der Befragten zuversichtlich, dass sie innerhalb von 24 Stunden feststellen könnten, ob KI-Code ein Produktionsproblem mitverschuldet hat. Allerdings waren 34 Prozent der Unternehmen genau dazu nicht in der Lage, als es zu einem solchen Vorfall kam. Als größte Hürden für Kontrolle und Nachverfolgbarkeit nennen 43 Prozent die Schwierigkeit, KI-generierten Code von manuell geschriebenem Code zu unterscheiden. Auf Platz zwei und drei folgen fragmentierte Toolchains (40 %) und Systeme, die die Code-Herkunft nicht erfassen (39 %).
Für den AI Accountability Report befragte GitLab im Februar 2026 insgesamt 1528 Personen, die sich zu etwa gleichen Anteilen aus sechs Ländern rekrutieren: USA, Deutschland, Großbritannien, Frankreich, Japan und Australien. Davon ordnen sich 43 Prozent dem Bereich IT Operations zu, 37 Prozent zu IT-Security und 20 Prozent zum Bereich Softwareentwicklung. Die vollständige Umfrage steht auf der GitLab-Webseite gegen Registrierung kostenlos zum Download bereit.
(mro)
Entwicklung & Code
Webentwicklung: Vite 8.1 soll große Anwendungen beschleunigen
VoidZero Inc. hat Vite 8.1 veröffentlicht. Das neue Release bringt den experimentellen Bundled Dev Mode, der Performancesteigerungen zum Ziel hat. Darüber hinaus kann das Frontend-Build-Tool Vite nun mit dem Proposal für die WebAssembly/ECMAScript-Module-Integration umgehen und nähert sich der standardmäßigen Nutzung von Lightning CSS.
Weiterlesen nach der Anzeige
Bundled Dev Mode
Bisher als Full Bundle Mode bezeichnet, bringt Vite 8.1 experimentellen Support für den Bundled Dev Mode. Dieser Modus soll dazu dienen, die Performance sehr großer Anwendungen mit vielen Modulen zu verbessern.
So hat VoidZero einen Test mit einer App durchgeführt, die 10.000 React-Komponenten geladen hat. Im Vergleich mit dem nicht gebundelten Dev-Server habe der Bundled Dev Mode eine 15-mal schnellere Start-up-Zeit und 10-mal schnellere vollständige Page Reloads verzeichnet – mit unmittelbarem Hot Module Replacement (HMR), unabhängig von der Anwendungsgröße.
Wie das Entwicklungsteam im Blogeintrag zur Vite-8.1-Ankündigung weiter ausführt, sei der Ansatz des Unbundled Dev Server einer der Gründe für Vites Schnelligkeit und Beliebtheit. Bei großen Anwendungen könne er jedoch die Performance beeinträchtigen, weshalb nun die Arbeit am Bundled Dev Mode begonnen hat. Auf GitHub können Interessierte die Roadmap des neuen Features einsehen.
Updates für Wasm und Lightning CSS
Zu den weiteren Neuerungen zählt der Support für das WebAssembly/ECMAScript Module Integration Proposal. Mit diesem Proposal wird WebAssembly wie JavaScript mit einem import-Statement oder per -Tag geladen. Derzeit befindet sich der Vorschlag in Phase 3 des WebAssembly-Prozesses, das heißt, der Implementierungsphase.
In Zusammenarbeit mit dem Team hinter Lightning CSS, einem in Rust geschriebenen CSS-Tool, hat dieses zwei neue Features erhalten. Es könnte schon in der nächsten Vite-Hauptversion das bisher zum CSS Preprocessing genutzte PostCSS ablösen und zum Standard werden, gibt VoidZero einen Ausblick.
Weiterlesen nach der Anzeige
VoidZero: Teil von Cloudflare
Erst kürzlich machte VoidZero von sich reden, da das Unternehmen in diesem Monat von Cloudflare gekauft wurde. Im Januar 2026 hatte Cloudflare bereits die Astro Technology Company übernommen, die hinter dem Open-Source-Webframework Astro steht. Sowohl dieses als auch die Open-Source-Technologien von VoidZero – Vite, Vitest, Rolldown, Oxc und Vite+ – sollen laut Angaben von Cloudflare quelloffen bleiben.
(mai)
Entwicklung & Code
Serverless mit Pausenfunktion: AWS stellt Lambda MicroVMs vor
AWS hat mit Lambda MicroVMs eine neue Laufzeitumgebung für serverlose Workloads vorgestellt. Die MicroVMs sollen VM-Level-Isolation mit sehr schnellen Start- und Fortsetzungszeiten verbinden und den Zustand einer laufenden Session erhalten. Amazon zielt damit auf Anwendungen, die Nutzer- oder KI-generierten Code ausführen und für jeden Nutzer oder Job eine eigene, abgeschottete Umgebung brauchen. Bisher mussten Entwickler laut AWS zwischen starker Isolation, schnellen Startzeiten und der Möglichkeit wählen, den Zustand einer Sitzung zu speichern.
Weiterlesen nach der Anzeige
Start aus Dockerfile, Zugriff per HTTPS
Zum Einstieg erzeugen Entwickler ein MicroVM-Image aus einem Dockerfile. Auf Basis dieses Images lassen sich MicroVMs starten. Jede MicroVM erhält eine dedizierte HTTPS-URL. Die Umgebung unterstützt laut Ankündigung HTTP/2, gRPC und WebSockets. Zudem gibt AWS an, dass sich die Ausführung für bis zu acht Stunden anhalten und später fortsetzen lässt.
Technisch basiert Lambda MicroVMs auf Firecracker, der Virtualisierungstechnik, die auch AWS Lambda selbst nutzt. Firecracker bildet aktuell die Grundlage für mehr als 15 Billionen Lambda-Aufrufe pro Monat, so Amazon.
Verfügbarkeit und Preis
Lambda MicroVMs ist laut AWS ab sofort in fünf Regionen verfügbar: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) und Europe (Ireland). Die Steuerung ist über die AWS Lambda Console, CloudFormation, das Cloud Development Kit und das Agent Toolkit for AWS möglich.
Beim Preis berechnet AWS die Baseline-Compute-Ressourcen, solange die MicroVM läuft. Zusätzliche Ressourcen fallen nur für die Zeit an, in der eine Workload über dieses Baseline-Niveau hinausgeht.
Weiterlesen nach der Anzeige
(fo)
-
Künstliche Intelligenzvor 3 MonatenEmpfehlungsalgorithmen bei TikTok erklärt: Die Maschine hinter dem Endlos‑Feed
-
Künstliche Intelligenzvor 3 MonateniX-Workshop Angriffsziel lokales AD − Schwachstellen finden und beheben
-
Künstliche Intelligenzvor 3 Monaten„Don’t Starve Elsewhere“: Survival‑Hit kehrt nach zehn Jahren zurück
-
Künstliche Intelligenzvor 2 MonatenWeitere Entlassungswelle bei Disney: Bis zu 1000 Mitarbeiter betroffen
-
Künstliche Intelligenzvor 3 MonatenKine‑Exakta: Die erste Spiegelreflexkamera fürs Kleinbild
-
Künstliche Intelligenzvor 2 Monaten
xTool P3 im Test: CO₂-Laser mit 80 Watt schneidet und graviert auch Acryl
-
Social Mediavor 1 MonatMetas neuer Creative Setup Workflow: Was sich wirklich ändert – und warum das nicht nur eine UI-Frage ist!
-
Apps & Mobile Entwicklungvor 2 MonatenMega-GPUs für Nvidia, AMD & Co: TSMC zeigt CoWoS-Package mit >11.600 mm² & 24 × HBM5E
