Connect with us

Entwicklung & Code

Gas Town 1.0.0: Agenten brauchen jetzt eine Freigabe


Gas Town hat Version 1.0.0 erreicht und gilt damit als produktionsreif. Nach 14 Vorabversionen (v0.5.0 bis v0.13.0) bringt das Release vor allem mehr Stabilität, bessere Sicherheit und neue Werkzeuge für die Orchestrierung komplexer Abläufe. Im Mittelpunkt stehen eine Workflow-basierte Ausführung, die direkte Anbindung an GitHub Merge Queues sowie zusätzliche Kontroll- und Schutzmechanismen für automatisierte Systeme.

Weiterlesen nach der Anzeige

Gas Town ist ein Open-Source-Projekt, das Entwicklungs- und Automatisierungsprozesse orchestriert – insbesondere mehrstufige, teils agentenbasierte Workflows. Konzepte wie „Formulas“, „Polecats“ oder „Refinery“ stehen für die Verbindung strukturierter Abläufe mit automatisierten Akteuren, die sich in bestehende Entwicklungsumgebungen wie GitHub einfügen. Entwickler arbeiten dazu nur mit einem einzigen, zentralen Agenten zusammen, dem Mayor, der die anderen Agenten selbsttätig ins Leben ruft und orchestriert.

Die wichtigste funktionale Neuerung sind Workflow-Formeln. Der neue Typ „workflow“ in gt formula run erlaubt es, mehrstufige, interaktive Abläufe zu definieren und auszuführen. Statt einzelner Befehle lassen sich damit ganze Prozessketten abbilden – etwa Codegenerierung, Testlauf und Pull-Request-Erstellung in einem Durchgang. Für Entwicklungsteams entspricht das einer leichtgewichtigen Workflow-Engine, die besonders bei KI-gestützten Prozessen nützlich ist.

Dazu passend bindet die Komponente „Refinery“ jetzt nativ GitHub Merge Queues an. Mit merge_strategy=pr reiht Gas Town Pull Requests direkt in die Warteschlange ein. GitHub führt Änderungen dann seriell und erst nach erfolgreichem CI-Lauf zusammen. In automatisierten Setups entfällt damit ein guter Teil der eigenen Merge-Logik, gleichzeitig sinkt das Risiko von Konflikten durch parallele Änderungen.

Version 1.0 bringt außerdem einen ersten Windows-Support. Gas Town implementiert dafür plattformspezifisches Signal-Handling, Prozessmanagement und die Nachverfolgung von tmux-Prozesshierarchien. Da sich diese Mechanismen unter Windows grundlegend von Unix unterscheiden, war eine eigene Umsetzung nötig. Teams mit gemischten Betriebssystemlandschaften können Gas Town damit erstmals durchgängig einsetzen.

Weiterlesen nach der Anzeige

Beim Thema Sicherheit bündelt das Release mehrere Maßnahmen. Die Entwickler haben eine SQL-Injection-Lücke in dolt_remotes geschlossen. Ein neuer „PreToolUse“-Guard blockiert kritische Systemeingriffe wie sudo-Aufrufe oder Paketinstallationen. Zusätzlich lehnt Gas Town unsignierte Binärdateien ab. Die Kombination aus Schwachstellenbehebung und Laufzeitkontrollen zielt vor allem auf agentenbasierte Szenarien, in denen automatisierte Akteure potenziell gefährliche Aktionen auslösen könnten.

Neu sind auch „Mayor Approval Gates“ als Governance-Mechanismus. Bevor ein Polecat – also ein ausführendes Modul oder ein Agent – seinen Wirkungsbereich erweitert, braucht er eine Freigabe. Das betrifft etwa den Zugriff auf zusätzliche Ressourcen oder Komponenten. Das Prinzip ähnelt Policy-Engines oder Human-in-the-Loop-Ansätzen und soll verhindern, dass automatisierte Systeme eigenmächtig ihre Berechtigungen ausweiten.

Ein neues Rate-Limit-Watchdog-Plugin rundet das Release ab. Es erkennt HTTP-429-Antworten und stoppt den betroffenen Prozess automatisch. Das verhindert, dass Workflows bei API-Überlastung in Endlosschleifen laufen oder ungewollt hohe Kosten verursachen.

Alle Details zur Version 1.0.0 finden sich in den Release Notes auf der GitHub-Projektseite von Gas Town.


(fo)



Source link

Entwicklung & Code

OpenAI: Neue Audio-Modelle für Echtzeit-KI-Support


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Künstliche Intelligenz wird in Zukunft immer häufiger am anderen Ende der Leitung sein, wenn Menschen eine Supporthotline anrufen oder in einer App Unterstützung suchen. Mit drei neuen Audio-Modellen, die per Entwicklerschnittstelle (API) zur Verfügung stehen, will OpenAI jetzt deren Qualität auf eine neue Stufe stellen. Konkret hat das US-amerikanische KI-Unternehmen die Modelle GPT-Realtime-2, GPT-Realtime-Translate und GPT-Realtime-Whisper vorgestellt.

Weiterlesen nach der Anzeige

Wie die Namen schon erahnen lassen, geht es um einen Dreiklang an Funktionen: GPT-Realtime-2 soll Echtzeit-Gespräche zwischen Maschine und Mensch ermöglichen, GPT-Realtime-Translate kommt in der Mensch-zu-Mensch-Kommunikation als Übersetzer und GPT-Realtime-Whisper zur Transkribierung von Mensch zu Maschine zum Einsatz. GPT-Realtime-2 ist überdies das erste Sprachmodell mit GPT-5-Reasoning in Echtzeit. OpenAI hat zuletzt auch GPT-5.5 als agentisches Arbeitsmodell vorgestellt, das Aufgaben selbstständig planen und über längere Zeiträume konsistent bearbeiten soll.

In Praxisvideos zur Ankündigung zeigt OpenAI die Modelle im Einsatz. Ein Augenmerk liegt darauf, dass sich die KI besser in die menschliche Kommunikation einfügt. Da ist zum Beispiel eine Situation, wo jemand ein Mensch-KI-Gespräch unterbricht und die KI angewiesen wird, für den Moment abzuwarten. Auch die Rückmeldungen der KI kommen menschlicher daher: sei es, wie Zahlen- und Buchstabenfolgen ausgesprochen werden oder bei der Live-Übersetzung, dass die KI jeweils abwartet, bis sie genug gehört hat, um sinnhaft übersetzen zu können. Zudem sollen Probleme besser kommuniziert werden, anstatt die Kommunikation einfach stillschweigend scheitern zu lassen.

Das Kontextfenster von GPT-Realtime-2 wurde gegenüber dem Vorgängermodell GPT-Realtime-1.5 von 32.000 auf 128.000 Token erweitert. Reasoning-Stufen sind einstellbar: von minimal bis sehr hoch, im Standard ist es auf niedrig eingestellt. Auch sind parallele Aufrufe von Tools möglich, sodass das Modell im laufenden Gespräch parallel mehrere externe Dienste abfragen kann. OpenAI wirbt zudem mit einem deutlich besseren Abschneiden bei Benchmarks, etwa bei Big Bench Audio von 81,4 auf 96,6 Prozent im Vergleich zu GPT-Realtime-1.5. Beim allgemeinen Release der Realtime API im vergangenen Jahr hatte das Vorgängermodell diesen Benchmark gegenüber der Beta-Version bereits von rund 65 auf über 82 Prozent verbessert.

GPT-Realtime-Translate unterstützt über 70 Eingangssprachen und kann in 13 Sprachen übersetzen. Die Deutsche Telekom testet das Modell laut OpenAI bereits, um es im mehrsprachigen Kundensupport einzusetzen. Die Kosten für Entwickler betragen 0,034 US-Dollar pro Minute Nutzung.

Weiterlesen nach der Anzeige

GPT-Realtime-Whisper soll Live-Transkription mit sehr niedriger Latenz ermöglichen. Typische Einsatzbereiche sind Untertitel in Meetings oder bei Streams, Kundensupport, medizinische Anwendungen und der Handel. Die Kosten betragen 0,017 US-Dollar pro Minute.

Alle drei Modelle stehen ab sofort über die Realtime API zur Verfügung. Die neuen Modelle reihen sich in OpenAIs jüngste Strategie spezialisierter KI-Modelle ein: Neben der Sprachverarbeitung hat das Unternehmen zuletzt auch GPT-Rosalind für die Biologieforschung vorgestellt, das auf Wirkstoffentdeckung und Genomik zugeschnitten ist. Die Nutzung von GPT-Realtime-2 kostet für den Input 32 US-Dollar pro Million Token (0,40 US-Dollar für gecachte Token) sowie 64 US-Dollar pro Million Token im Output. Damit bleiben die Preise gegenüber dem Vorgängermodell unverändert. Für europäische Entwickler relevant: Die Realtime API unterstützt EU Data Residency, sodass Anfragen und Antworten in der EU verarbeitet und nicht auf OpenAIs Servern gespeichert werden – allerdings mit einem Vorbehalt: Das Tracing, also die Nachverfolgung von API-Aufrufen zu Debugging-Zwecken, ist derzeit noch nicht EU-Data-Residency-konform.


(mki)



Source link

Weiterlesen

Entwicklung & Code

Atlassian: KI-Agenten übernehmen die Routinearbeit


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Atlassian hat auf seiner Hauskonferenz Team ’26 mehrere neue Funktionen vorgestellt, die KI-Agenten stärker in die tägliche Zusammenarbeit von Anwendern einbinden sollen. Im Mittelpunkt stehen der Ausbau des Teamwork Graph als unternehmensweite Kontextschicht sowie die Weiterentwicklung der KI-Plattform Rovo. Deren Agenten sollen Aufgaben künftig nicht nur unterstützen, sondern eigenständig planen und ausführen.

Weiterlesen nach der Anzeige

Atlassian entwickelt Werkzeuge für Zusammenarbeit und Softwareentwicklung. Hierzu zählen Jira, Confluence und Loom. Alle diese Tools sollen Aufgaben, Wissen und Kommunikation in Teams zusammenführen.

Eine zentrale Rolle spielt der Teamwork Graph. Er bildet Beziehungen zwischen Aufgaben, Dokumenten, Personen und Systemen ab und liefert KI-Agenten den nötigen Kontext. Neu ist, dass dieser Kontext nicht mehr nur innerhalb der Atlassian-Produkte zur Verfügung steht. Über ein neues Kommandozeilentool – das sich aktuell in einer Open Beta befindet – greifen Entwickler direkt im Terminal auf den Graph zu. Zusätzlich stellt Atlassian Schnittstellen über das Model Context Protocol (MCP) bereit, sodass auch externe Agenten und Copiloten die Daten nutzen können. KI-Systeme können damit Zusammenhänge wie Verantwortlichkeiten, Abhängigkeiten oder frühere Entscheidungen einbeziehen, statt isolierte Abfragen zu beantworten. Ein Agent kann so zum Beispiel ermitteln, welche Incidents mit einem bestimmten Deployment zusammenhängen und wer für deren Behebung zuständig ist.

Parallel baut Atlassian Rovo – ein KI-gestütztes Such- und Wissensermittlungstool – aus und entwickelt es von einem reinen Assistenzwerkzeug zu einem Tool für agentisches Arbeiten weiter. KI-Agenten sollen komplexe, mehrstufige Aufgaben eigenständig zerlegen, planen und ausführen. Der bereits angekündigte Reasoning-Modus „Max“ in Rovo Chat soll künftig solche Abläufe über mehrere Werkzeuge hinweg orchestrieren. Ein Beispiel für den Praxiseinsatz wäre ein Quartalsbericht, für den ein Agent Daten aus verschiedenen Quellen zusammenführt, aufbereitet und fehlende Informationen kennzeichnet.

KI-Agenten rücken zudem näher an bestehende Arbeitsabläufe. In Jira lassen sich Aufgaben nun gezielt an Agenten zuweisen (genannt Agents in Jira, bereits allgemein verfügbar), die diese eigenständig bearbeiten oder vorbereiten. In Confluence überführt die Funktion Remix Inhalte in andere Formate wie Präsentationen oder Diagramme, ohne dass Anwender die Umgebung verlassen müssen. Loom wandelt Videoanleitungen in strukturierte Aufgaben um, die sich beispielsweise als Jira-Tickets weiterverarbeiten lassen. Punktuelle KI-Abfragen sollen damit einer dauerhaft eingebetteten Automatisierung weichen.

Mit Rovo Studio bietet Atlassian zudem eine No-Code-Plattform, auf der Anwender eigene Agenten, Automatisierungen und Anwendungen erstellen. Sie setzt auf dem Teamwork Graph auf und richtet sich ausdrücklich nicht nur an Entwickler. Workflows lassen sich ereignisbasiert definieren und mit Funktionen wie Rollenmodellen, Freigaben und Versionierung absichern. Ein Beispiel wäre ein Onboarding-Prozess, bei dem ein Agent automatisch Konten anlegt, Dokumente bereitstellt und Aufgaben verteilt, sobald ein neuer Mitarbeiter im System erfasst ist.

Weiterlesen nach der Anzeige

Speziell für Softwareentwickler erweitert Atlassian sein Angebot im Bereich Developer Experience (DX). Neue Funktionen wie „Agent Experience“, „AI Code Insights“ und „AI Pulse“ sollen Transparenz über den KI-Einsatz im Entwicklungsprozess schaffen. Damit lässt sich nachvollziehen, welcher Anteil des Codes von KI stammt, wie Agenten in Workflows eingebunden sind und wie sich das auf Produktivität und Qualität auswirkt.

Mit der Product Collection kündigt Atlassian außerdem eine neue Produktreihe für das Produktmanagement an. Sie erweitert bestehende Werkzeuge wie Jira Product Discovery und soll den gesamten Prozess von der Sammlung von Kundenfeedback über die Priorisierung bis zur Umsetzung und Erfolgsmessung abdecken.

Neu sind zudem die Dia Reports, wobei es sich um browserbasierte Briefings handelt, die Informationen aus dem Teamwork Graph mit Daten aus typischen Arbeitswerkzeugen wie Kalendern oder Kommunikationsplattformen verbinden. So entstehen etwa automatisch generierte Tageszusammenfassungen, die offene Aufgaben, relevante Diskussionen und anstehende Termine bündeln.

Mehr Details zu allen neuen Funktionen finden sich im Atlassian-Blog.

Lesen Sie auch


(fo)



Source link

Weiterlesen

Entwicklung & Code

Neu in .NET 10.0 [22]: SDK-Werkzeugerweiterungen direkt starten


Werkzeugerweiterungen für das .NET-SDK-Kommandozeilenwerkzeug dotnet.exe (bzw. dotnet) musste man bisher lokal in einem Projekt von NuGet installieren, beispielsweise:

Weiterlesen nach der Anzeige

dotnet tool install dotnet-runtimeinfo


Der Dotnet-Doktor – Holger Schwichtenberg

Der Dotnet-Doktor – Holger Schwichtenberg

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.

oder global installieren:

dotnet tool install -g dotnet-runtimeinfo

bevor eine Ausführung mit

dotnet-runtimeinfo

möglich war.

Weiterlesen nach der Anzeige

Seit .NET 10.0 können Entwicklerinnen und Entwickler ein solches Werkzeug herunterladen und einmalig ausführen, ohne es lokal zu speichern. Dafür gibt es den neuen Befehl dotnet tool exec. So funktioniert beispielsweise

dotnet tool exec dotnet-runtimeinfo

Dabei kommt es vor der erstmaligen Ausführung zu einer Nachfrage, ob man das Werkzeug wirklich starten will (siehe Abbildung 1). Diese Nachfrage kann man vorab mit „Ja“ beantworten, indem man
-y oder --yes angibt:

dotnet tool exec dotnet-runtimeinfo -y

Zudem kann man dotnet tool exec mit dnx abkürzen:

dnx dotnet-runtimeinfo -y


Screenshot

Screenshot

dotnet tool exec fragt zur Sicherheit vor der Ausführung nach (Abb. 1).

Wer schon länger dabei ist, wird sich erinnern, dass es in den Anfangstagen von .NET Core bereits ein Werkzeug namens dnx.exe gab, das später in dotnet.exe umbenannt wurde. Microsoft hält sich in den Release Notes zu .NET 10.0 Preview 6 offen, den Namen dnx in Zukunft wieder stärker einzusetzen: „The actual implementation of the dnx command is in the dotnet CLI itself, so we can evolve its behavior over time. Today it runs tools, but who knows what the future may hold.“


(rme)



Source link

Weiterlesen

Beliebt