Das Team hinter Googles Programmiersprache Go hat die Community befragt, und es haben über 5000 Go-Developer geantwortet: Sie nutzen häufig KI-Tools für Informationssuche und Coding, sind mit diesen aber nur mittelmäßig zufrieden. Mit der Programmiersprache an sich sind die Go-Developer dagegen fast durchweg zufrieden: Das gaben 91 Prozent an.

Die Freitextantworten geben Aufschlüsse über die Gründe der Beliebtheit. Hierbei nennt das Go-Team als repräsentative Antwort unter anderem, dass andere Sprachen zu komplex seien, Go dagegen vergleichsweise klein und einfach. Eine andere Antwort betont die gute Skalierbarkeit der Sprache, die sowohl für einzelne Programmierer als auch für große Teams geeignet sei. Weitere Antworten heben das Tooling, die Standard Library und das Go-Ökosystem positiv hervor.

Die größten Hürden für Go-Developer

Die Schwierigkeiten bei der Go-Entwicklung wurden ebenfalls abgefragt. Die Top 3 der frustrierendsten Aspekte sind „Sicherstellung, dass Go-Code Best Practices und Go-Idiomen folgt“, „Ein Feature, das ich in einer anderen Programmsprache schätze, ist nicht in Go vorhanden“ und „Auffinden vertrauenswürdiger Go-Module und -Pakete“. Auch die Dokumentation und das Testing von Go-Code sowie das Erlernen von Go-Modulen finden viele der Entwicklerinnen und Entwickler schwierig.

KI-Tools mit Hindernissen

Über die Hälfte der Befragten nutzt täglich KI-Tools, während 29 Prozent diese entweder nie verwenden oder nur wenige Male innerhalb des Monats vor der Umfrage genutzt haben. Die am häufigsten genutzten KI-Assistenten sind ChatGPT (45 Prozent), GitHub Copilot (31 Prozent), Claude Code (25 Prozent) und Gemini (20 Prozent). Direkt auf dem fünften Platz folgt jedoch bereits mit 17 Prozent: „Ich verwende keine KI-Assistenten oder -Agenten, wenn ich Go-Code schreibe“.

Die Einsatzzwecke von KI sind vielfältig und gehen über das Schreiben von Code hinaus. Beispielsweise lernen Entwickler damit neue Konzepte, suchen nach Informationen, nutzen KI für Testing und reviewen ihren selbst geschriebenen Code. Den Code anderer Personen möchte allerdings ein Drittel nicht mit KI-Unterstützung reviewen, und für das Deployment einer Software zur Produktion lehnen die Befragten KI mehrheitlich ab.

Die Zufriedenheit mit den KI-Tools ist durchwachsen: Sehr zufrieden sind lediglich 13 Prozent, einigermaßen zufrieden („somewhat satisfied“) 42 Prozent. Unzufrieden sind 16 Prozent, sehr unzufrieden sieben Prozent. Die übrigen 22 Prozent sind neutral. Als Hauptproblem in Bezug auf KI-Entwicklertools gibt die Mehrheit nicht funktionierenden Code an, während knapp ein Drittel auch die Qualität des funktionierenden KI-generierten Codes bemängelt.

Sprachenübergreifende Erkenntnisse

In diesem Jahr fragte das Go-Team auch danach, was – neben Go – die andere Lieblingssprache der Programmiererinnen und Programmierer ist. Dabei stehen bei ihnen Python, Rust, TypeScript, C und Java ganz oben. Das Go-Team sieht hier das Potenzial, spezialisierte Tutorials zu erstellen, zum Beispiel „Error Handling in Go für Java-Entwickler“. Auch könne ein Teil solcher Anleitungen in Code-Analyzer integriert und somit direkt innerhalb einer IDE verfügbar gemacht werden.

Datengrundlage: Professionelle und erfahrene Go-Entwickler

Der 2025 Go Developer Survey fand vom 9. bis 30. September 2025 statt und ergab 5379 gültige Antworten. Von diesen arbeiten 87 Prozent als Entwicklerinnen und Entwickler. Die Befragten setzen Go vorrangig beruflich (82 Prozent) und privat beziehungsweise für Open-Source-Projekte (72 Prozent) ein, und ein Drittel hat bereits mehr als sechs Jahre Erfahrung mit Go vorzuweisen.

Weitere Informationen zu den Ergebnissen finden sich auf dem Go-Blog. Die Rohdaten sollen im ersten Quartal dieses Jahres ebenfalls erscheinen. Allerdings werden darin nur die Antworten der Personen, die dieser Veröffentlichung zugestimmt haben (82 Prozent), enthalten sein.

(mai)

Mit Open Responses ist ein Open-Source-Standard für eine herstellerunabhängige JSON-API erschienen, über die Sprachmodelle mit Clients kommunizieren. Sie basiert auf Responses API und stellt einen weiteren Baustein des agentischen KI-Ökosystems der Firma dar.

Zusammen mit der Responses API hatte OpenAI letztes Jahr integrierte Tools und ein Software Development Kit (ADK) vorgestellt, mit deren Hilfe sich eigene KI-Agenten erstellen lassen. Die Responses API kombiniert die Chat Completions API sowie die Assistent API von OpenAI und kann eigenständig agieren, statt sich auf das Liefern von Antworten zu beschränken. Bislang war für jedes LLM jedoch ein eigener Client-Adapter erforderlich. Dies soll Open Responses nun vereinheitlichen.

OpenAI will den offenen Standard in den kommenden Monaten zusammen mit der Community und Anbietern von Interferenzlösungen weiterentwickeln. Dazu konnte OpenAI Hugging Face, Nvidia, LLM, LM Studio, Ollama, OpenRouter und Vercel als Launch-Partner gewinnen.

Mozilla hat mit any-llm bereits ein ähnliches Projekt am Start. Das Python-Paket ist eine einheitliche API für viele LLMs und erspart es Entwicklerinnen und Entwicklern, für jedes einzelne LLM einen eigenen Adapter pflegen zu müssen.

Einfacher Umstieg von Responses API auf Open Responses

Um die KI-Interoperabilität zu verbessern, definiert Open Responses ein „gemeinsames Schema und eine Werkzeugschicht, um den Aufruf von Sprachmodellen, das Streaming von Ergebnissen und die Zusammenstellung agentenbasierter Workflows zu vereinheitlichen“. Das soll unabhängig vom Anbieter funktionieren.

Entwicklerinnen und Entwickler, die bereits die Responses API nutzen, können laut OpenAI ohne großen Aufwand auf das neue Format umsteigen. Die Änderungen sollen größtenteils die agentische Argumentation betreffen. Dafür stehen neben encrypted_content (anbieterspezifische geschützte Inhalte) und summary (aus den Reasoning Traces bereinigte Daten) und dem neuen content (Reasoning Traces) nun drei Eingabeparameter zur Verfügung. Letzterer erlaubt es, die Reasoning Traces über die API zugänglich zu machen, was einen Anbieterwechsel leichter macht.

Im Fall des KI-Delta Learnings sehen die Funktionsaufrufe für Open Response im Vergleich zu Responses API folgendermaßen aus:

// Open weight models stream raw reasoning
event: response.reasoning.delta
data: { "delta": "User asked: 'Where should I eat...' Step 1: Parse location...", ... }

// Models with encrypted reasoning send summaries, or sent as a convenience by Open Weight models
event: response.reasoning_summary_text.delta
data: { "delta": "Determined user wants restaurant recommendations", ... }

Wer sich genauer in das agentische Open-Source-Modell einlesen will, findet auf der dessen Webseite eine technische Beschreibung.

(who)

Persistenz ist kein Detail, sondern prägt die gesamte Architektur. In dieser Episode diskutiert Eberhard Wolff den klassischen Mismatch zwischen objektorientierter Domänenlogik und relationalen Datenbanken, die Rolle von O/R-Mappern und die Bedeutung unter anderem von Aggregates und Domain-driven Design.

Er vergleicht relationale mit NoSQL-Ansätzen wie Dokumenten-Datenbanken und zeigt, warum unterschiedliche Persistenztechnologien zu unterschiedlichen Architekturen führen.

Lisa Maria Schäfer malt dieses Mal keine Sketchnotes.

Livestream am 23. Januar

Die Ausstrahlung findet am Freitag, 23. Januar 2026, live ab 13 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zu den Folgen finden sich auf der Videocast-Seite.

(mdo)