Entwicklung & Code
Team und Softwarearchitektur im Einklang – ein soziotechnisches System
Scheinbar geht es bei Softwarearchitektur nur um die Strukturierung von Software und die Umsetzung von nicht funktionalen Anforderungen. Aber in Wirklichkeit ist die Software für Menschen da und Menschen schreiben die Software. Daher ist es notwendig, sie als ein soziotechnisches System zu begreifen. Das hat Auswirkungen auf das Verständnis von Softwarearchitektur.
Weiterlesen nach der Anzeige
(Bild: Eberhard Wolff )
Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-driven Design und Microservices.
Der Begriff Soziotechnisches System steht für eine organisierte Menge von Menschen und mit diesen verknüpfte Technologien, die in einer bestimmten Weise strukturiert sind, um ein spezifisches Ergebnis zu produzieren. Er geht auf Forschung unter anderem im Steinkohlebergbau in Großbritannien in den 1950er-Jahren zurück. Die Idee von soziotechnischen Systemen ist somit nicht neu und schon gar keine Mode. Eine Kernerkenntnis ist, dass der Erfolg eines Unternehmens davon abhängt, wie es als soziotechnisches System funktioniert, nicht einfach als ein technisches System mit ersetzbaren Individuen, die hinzugefügt werden und sich anpassen müssen.
Die Bezeichnung sagt bereits, worum es geht: Das System besteht aus einer technischen Komponente (etwa Maschinen) und einer sozialen Komponente (Mitarbeiterinnen und Mitarbeiter, die technische Komponenten bedienen und nutzen). Beide lassen sich nur gemeinsam betrachten, da sie eng miteinander verknüpft sind. Deswegen muss man auch menschliche Kommunikation neben der Mensch-Maschine-Kommunikation betrachten.
Dieser Ansatz ist für Softwareentwicklung und -architektur gleich aus mehreren Gründen interessant: Erstens wird Softwareentwicklung oft als eine rein technische Aufgabe begriffen und betrieben. Das ist sie aber nur scheinbar. Software als soziotechnisches System zu behandeln, birgt die Chance, wesentliche Verbesserungen zu erreichen. Zweitens löst die meiste Software keine rein technischen Probleme, sondern muss für Anwenderinnen und Anwender sowie andere Stakeholder einen wirtschaftlichen Nutzen haben.
Damit steht die Software in einem wichtigen Verhältnis zu dieser Personengruppe, da der Wert der Software sich an dem wirtschaftlichen Nutzen für diese Gruppe orientiert. Dieser soziale Aspekt ist zentral für den Erfolg eines Softwareentwicklungsprojekts. Und schließlich wird Software in Teams implementiert. Auch bei der Entwicklung gibt es also ein soziales Geflecht, das es zu verwalten gilt. Wenn man diese Aufgabe besonders gut erfüllt, wird man effektiv und effizient entwickeln.
Tatsächlich steht Softwarearchitektur in einem engen Zusammenhang mit beiden sozialen Systemen – Entwickler und User (siehe Abbildung 1). Softwarearchitektur muss eine technische Lösung finden, die Nutzerinnen und Nutzer ausreichend unterstützt. Dabei sind Qualitäten der Software wie Benutzerfreundlichkeit, Performance, Skalierbarkeit oder Sicherheit zu betrachten. Dieser Teil der Architektur ist daher nur im Zusammenspiel mit diesem sozialen System bewertbar. Eine Architektur lässt sich nur daran messen, ob sie ausreichende Qualitäten für die Benutzergruppe mit sich bringt. Was für einige Personen subjektiv unmöglich zu benutzen ist, kann für andere akzeptabel oder gar ideal sein – man denke nur an die Auseinandersetzungen zu Editoren wie Vim oder Emacs.

Softwarearchitektur bietet für Developer eine Strukturierung des Codes und muss für User die Einhaltung der Qualitäten garantieren (Abb. 1).
Die Aufteilung eines Systems in Module dient dazu, die Komplexität des Systems beherrschbar zu machen. Damit ist die Modularisierung nur im Zusammenspiel mit dem jeweiligen Entwicklungsteam bewertbar. Auch eine scheinbar gute Modularisierung kann für das Team schwer verständlich sein und zu geringer Produktivität führen. Beispielsweise kann ein Team ein System ohne eine gute Übergabe von einem anderen Team übernommen haben, sodass das neue Team es trotz guter Modularisierung schwer verstehen und ändern kann.
Weiterlesen nach der Anzeige
Es ist auch denkbar, dass das System zwar schlecht strukturiert ist, aber das Team sich über einen längeren Zeitraum an diese Struktur gewöhnt hat und daher das System ausreichend gut ändern kann. Dann kann das Team die Software schwerlich abgeben, weil ein neues Team Schwierigkeiten hätte, sie zu verstehen. Das ist weniger ein technisches Problem, sondern lässt sich als ein soziales Problem auffassen.
Das Gesetz von Conway
Das Gesetz von Conway besagt, dass eine Organisation ein System entwickeln wird, dessen Design die Kommunikationsstrukturen der Organisation kopiert. Für die Softwareentwicklung bedeutet das beispielsweise: Wenn zwei Teams zwei Aufgaben haben und darüber bei Bedarf miteinander kommunizieren, werden sie in der Software zwei Module aufbauen, die eine Schnittstelle haben. Klassisch hat man das Gesetz von Conway eher als ein Hindernis begriffen: Wenn Teams in einer bestimmten Art organisiert sind, können sie nur bestimmte Architekturen erstellen. Sind ein UI- und ein Backend-Team vorhanden, werden auch ein UI und ein Backend in der Architektur entstehen.
Dabei wird jedoch das Organigramm mit Kommunikation verwechselt. Aber Menschen und Teams kommunizieren auch dann, wenn sie im Organigramm keine offensichtlichen Beziehungen besitzen. Zwar kann das Organigramm einen wesentlichen Einfluss auf die Kommunikation ausüben, aber es ist nicht deckungsgleich. Das ist auch eine gute Nachricht: Während das Organigramm statisch ist, kann jede involvierte Person die Kommunikationsflüsse im Projekt beeinflussen.
Aus dem Zusammenhang zwischen Kommunikation und Architektur ergibt sich ein weiteres Problem: Wenn die Kommunikation nicht mehr effektiv ist oder zusammenbricht, leidet die Architektur des Systems darunter. Gerade bei großen Projekten ist es schwierig, eine gute Kommunikation zu bewahren. Daher kann es insbesondere hier dazu kommen, dass zunächst die Kommunikation schwierig und dann die Architektur in Mitleidenschaft gezogen wird.
Solche Probleme hat Melvin Conway schon 1967 im ursprünglichen Paper zu seinem Gesetz beschrieben. Wenn Softwarearchitektinnen und -architekten die Qualität der Architektur erhalten oder gar verbessern wollen, müssen sie auf die Kommunikation im Projekt Einfluss nehmen und gewährleisten, dass sie funktioniert.
Durch das Inverse Conway Maneuver (siehe Abbildung 2) hat sich im Rahmen der Microservices-Bewegung das Verständnis für das Gesetz von Conway gewandelt: Statt es als Hindernis zu verstehen, will man es nun für die Gestaltung der Architektur nutzen. Wenn Teams definiert werden und jedes eine bestimmte Verantwortung erhält, werden diese Teams voraussichtlich jeweils ein Modul oder einen Microservice implementieren, der ihrer Verantwortung entspricht. Das Aufstellen der Organisation auf eine bestimmte Weise definiert somit indirekt die Architektur. Das Inverse Conway Maneuver versteht Software demnach als soziotechnisches System und wirkt durch Maßnahmen auf der sozialen Seite auf die technische ein.

Inverse Conway Maneuver: Die Organisation bestimmt die Architektur (Abb. 2).
Entwicklung & Code
Apple-Studie: Nutzer wollen transparente KI-Agenten statt Black-Box-Systeme
Apple-Forscher haben in einer zweiphasigen Studie untersucht, wie Nutzer mit KI-Agenten interagieren möchten. Das Ergebnis ist überraschend: Menschen bevorzugen weniger leistungsstarke, sondern eher transparente Agenten gegenüber leistungsstarken Black-Box-Systemen. Die im Februar 2026 veröffentlichte Studie „Mapping the Design Space of User Experience for Computer Use Agents“ identifiziert vier zentrale Kategorien für das UX-Design und analysiert neun bestehende Systeme wie Claude Computer Use Tool, OpenAI Operator und Googles Project Mariner.
Weiterlesen nach der Anzeige
Die Forscher untersuchten in Phase 1 ihrer Studie neun kommerzielle KI-Agent-Systeme und führten Interviews mit acht UX- und KI-Praktikern aus großen Technologieunternehmen. In Phase 2 testeten sie ihre Erkenntnisse mit 20 Teilnehmern in einem sogenannten Wizard-of-Oz-Experiment. So wird ein Versuch bezeichnet, bei dem ein Mensch (Proband) annimmt, mit einem autonomen (im Sinne der künstlichen Intelligenz) System zu kommunizieren, in Wirklichkeit aber mit einem Menschen interagiert. Die Probanden sollten Aufgaben wie Ferienwohnungsbuchungen oder Online-Shopping erledigen, während ein Forscher im Nebenraum die Agent-Aktionen simulierte. Die Teilnehmer konnten den vermeintlichen Agenten jederzeit mit einem Interrupt-Button stoppen. Die aufgezeichneten Videos und Chat-Logs lieferten Einblicke in die tatsächlichen Nutzererwartungen.
Transparenz wichtiger als Automatisierung
Ein zentrales Ergebnis: Nutzer wollen Einblick in Agent-Aktivitäten, aber kein Mikromanagement. Zu viel Kontrolle würde bedeuten, dass sie die Aufgaben gleich selbst erledigen könnten. Besonders wichtig ist den Probanden Transparenz bei unbekannten Bedienoberflächen. Dort wünschen sie mehr Zwischenschritte, Erklärungen und Bestätigungspausen – selbst bei Szenarien mit geringem Risiko. Bei Aktionen mit echten Konsequenzen wie Käufen, Kontoänderungen oder Kontaktaufnahmen mit anderen Menschen fordern Nutzer mehr Kontrolle.
Das Vertrauen in KI-Agenten bricht schnell zusammen, wenn das System stille Annahmen trifft oder Fehler macht. Bei mehrdeutigen Wahlmöglichkeiten bevorzugen Nutzer, dass der Agent pausiert und nachfragt, statt zufällig zu wählen. Besonders deutlich wird dies bei Entscheidungen, die zu falschen Produktauswahlen führen könnten.
Bestehende Systeme erfüllen Erwartungen nur teilweise
Die neun analysierten Systeme, darunter Claude Computer Use Tool von Anthropic, OpenAI Operator und Googles Project Mariner, erfüllen die Nutzererwartungen laut den Forschern nur teilweise. Die Studie zeigt auch kontextabhängige Erwartungen: Nutzer wollen unterschiedliches Agent-Verhalten, je nachdem ob sie Optionen erkunden oder eine bekannte Aufgabe ausführen. Die Erwartungen ändern sich auch basierend auf der Vertrautheit mit einer Schnittstelle. Die gesammelten Erkenntnisse könnten direkten Einfluss auf Apples geplante Siri-Überarbeitung haben. So kündigte der iPhone-Hersteller im Sommer 2024 an, dass der Sprachassistent künftig appübergreifend Aufgaben erledigen soll. Die Veröffentlichung verzögerte sich jedoch. Aktuell wird erst in den nächsten Monaten damit gerechnet.
Weiterlesen nach der Anzeige
Apple verfolgt bei KI-Agenten einen deutlich konservativeren Ansatz als Konkurrenten wie OpenAI, Google und Meta. Während diese Unternehmen Milliarden in große, allgemeine Sprachmodelle investieren, konzentriert sich Apple auf gezielte, datenschutzorientierte Features mit Schwerpunkt auf On-Device-Verarbeitung.
Für rechenintensive Aufgaben evaluiert Apple externe Modelle, insbesondere Googles Gemini, plant aber, eine angepasste Version auf eigenen Servern zu betreiben. Persönliche Daten und Geräte-Kontext bleiben bei Apples eigenen In-House-Modellen. Die aktuelle Studie spielt Apple in die Hände: Nutzer akzeptieren lieber später startende, aber besser konzipierte Systeme als schnell eingeführte Black-Box-Lösungen.
(mki)
Entwicklung & Code
Spotify-Co-CEO: Top-Entwickler schreiben dank KI keinen Code mehr
Dieser Satz von Spotify-Co-CEO Gustav Söderström sorgt für Diskussionen: „Wenn ich mit meinen erfahrensten Ingenieuren spreche, den besten Entwicklern, die wir hatten, sagen sie, dass sie seit Dezember keine einzige Zeile Code mehr geschrieben haben. Sie generieren nur noch Code und überwachen ihn.“ Die Aussage aus der Analystenkonferenz zu den jüngsten Geschäftszahlen stößt im Netz auf gemischte Reaktionen: Während die einen fasziniert davon sind, wie stark Spotify die KI-Transformation in seinem Unternehmen vorangetrieben hat, womit Söderström vermutlich auch werben sollte, nehmen andere daran Anstoß. Das sei doch ein Kontrollverlust und kein Qualitätsmerkmal, kommentieren Kritiker.
Weiterlesen nach der Anzeige
Tatsächlich soll aber gerade die Kontrolle in der Softwareentwicklung bei Spotify bedeutsamer denn je geworden sein. Mit seiner Aussage in der Analystenkonferenz (Transkript bei Seekingalpha) wies Söderström auf einen fundamentalen Wandel in der Arbeitsweise hin. Und nicht ohne Grund stellte er vermutlich heraus, dass es gerade die besten Entwickler sind, die keinen Code mehr schreiben.
Vom Spieler zum Trainer
KI übernimmt in dieser Neuordnung die aktive Programmierung, während Entwickler – um es mit der Sportart Fußball zu vergleichen – zunehmend vom Spieler zum Trainer werden. Über Sieg oder Niederlage entscheiden Strategie und Vorbereitung der Spieler, nicht die Fähigkeit, den Ball selbst über den Platz zu bewegen. Und der Trainer muss während des Spiels alles im Auge behalten. Mit Einwechselungen und Zurufen nimmt er Einfluss auf das Spielgeschehen. Bezogen auf die Entwicklung wäre dies das Feedback an die KI, das Festlegen von Prioritäten und Reihenfolgen und das Beurteilen ihrer Leistung. Auch vor dem Einsatz agentischer KI haben erfahrene Entwickler architektonische Entscheidungen getroffen – mit der KI verlagert sich der Fokus noch mehr.
Spotify nutzt hierfür ein selbst entwickeltes System namens „Honk“ zur Beschleunigung von Coding und Produktentwicklung. Als technische Basis hierfür kommt Claude Code von Anthropic zum Einsatz. Entwickler können per Slack vom Smartphone aus Änderungen an der App beauftragen und etwa Bugfixes oder neue Funktionen hinzufügen. Das Ergebnis bekommen sie als Testversion zurückgespielt und geben der KI Feedback, bis der gewünschte Reifegrad erreicht ist.
Umfangreiche Infrastruktur aufgebaut
Spotifys Erfolg mit KI-gestützter Entwicklung basiert nicht primär auf Claude Code selbst, sondern auf jahrelanger Infrastruktur-Arbeit. Seit dem Jahr 2020 nutzt Spotify „Backstage“, ein Portal, das als zentrale Anlaufstelle dient. Jeder im Unternehmen kann dort nachvollziehen, welches Team welchen Code verantwortet und wie die Abhängigkeiten zwischen verschiedenen Komponenten aussehen.
Darauf aufbauend entwickelte Spotify ab 2022 „Fleet Management“ – ein Framework, das Code-Änderungen über hunderte oder tausende Repositories gleichzeitig durchführen kann. Die Integration des Claude Agent SDK erfolgte erst im Juli 2025.
Weiterlesen nach der Anzeige
Spotify-Co-CEO: Erst der Anfang
Spotify gehört zu einer kleinen Elite: Laut einer Deloitte-Studie von 2025 nutzen nur 11 Prozent der Organisationen Agentic AI in der Produktion. 30 Prozent explorieren das Thema, 38 Prozent betreiben Pilotprojekte.
Söderström sieht den aktuellen Stand nicht als Endpunkt: „Wir sehen dies nicht als Ende der Entwicklung bei KI, sondern erst als Anfang.“ Spotify plane weitere KI-Integration in Entwicklungsprozesse. Unklar bleibt freilich, ob sich das am Ende nicht doch auch auf die Job-Sicherheit der Entwickler auswirkt. Gespart werden könnte hier vor allem an Nachwuchskräften, denen die Erfahrung fehlt, die KI zu steuern. In Deutschland zeichnet sich ein solcher Trend bereits ab. Kritiker befürchten indessen, dass Entwickler zunehmend ihre praktischen Coding-Kenntnisse verlieren.
(mki)
Entwicklung & Code
Eclipse Theia 1.68: KI-Agenten lernen Skills und erledigen To-do-Listen
EclipseSource hat die Veröffentlichung von Eclipse Theia 1.68 bekanntgegeben, einer quelloffenen Entwicklungsplattform für Web- und Cloud-basierte Tools. Das aktuelle Release erlaubt das Verwenden von GitHub Copilot out-of-the-box und lässt KI-Agenten – noch als Alpha-Feature – Skills verwenden. Neben zahlreichen KI-bezogenen Updates gibt es auch weitere Neuerungen, unter anderem zur Verbesserung der Accessibility.
Weiterlesen nach der Anzeige
Aufgabenplanung zum Mitverfolgen
KI-Agenten können in Eclipse Theia durch das neue Tool todo_write den Fortschritt mehrstufiger Aufgaben visuell darstellen: Sie können To-do-Listen erzeugen, die im Chatfenster angezeigt und aktualisiert werden. Die Aufgaben erhalten, ihrem Status entsprechend, Icons für „noch nicht erledigt“, „in Arbeit“ oder „erledigt“. Um das Feature nutzen zu können, muss der neue Agenten-Modus „Agent Mode (Next)“ aktiviert sein. Dieser soll sich dadurch auszeichnen, dass er Coding-Aufgaben effektiver, zuverlässiger und autonomer durchführt.
Das Entwicklungsteam zeigt ein Beispiel: Ein Prompt fordert den KI-Agenten auf, eine To-do-Liste für das Kochen einer Mahlzeit zu erstellen und so zu tun, als würde er die dafür nötigen Schritte ausführen.

Der KI-Agent arbeitet eine virtuelle To-do-Liste ab.
(Bild: EclipseSource)
GitHub Copilot in Eclipse Theia 1.68
Entwicklerinnen und Entwickler mit aktivem GitHub-Copilot-Abo können dieses nun direkt innerhalb der Theia IDE sowie in mit Theia AI erstellten Tools verwenden. Sie benötigen dafür weder zusätzliche API-Keys noch Abos. Dahinter steht technisch das neue Package @theia/ai-copilot, das GitHub Copilot als Language-Model-Anbieter in Eclipse Theias KI-Framework integriert, mitsamt Authentifizierung per OAuth.
Weiterlesen nach der Anzeige
Wie der Authentifizierungsvorgang aussieht, demonstriert das EclipseSource-Team:

GitHub Copilot lässt sich direkt aus Eclipse Theia 1.68 heraus nutzen.
(Bild: EclipseSource)
Skills für KI-Agenten
Als Alpha-Feature können KI-Agenten in Eclipse Theia nun Agent Skills nutzen. Diese bestehen aus wiederverwendbaren Anweisungen und Domänenwissen, die Agenten aus SKILL.md-Dateien beziehen. Unter anderem können Agenten im Verzeichnis ~/.theia/skills/ vorhandene Skills automatisch entdecken, spezifische Skills per Entwickleranweisung mithilfe des Befehls /skillName nutzen oder Skills nach Bedarf laden. Für Letzteres dient die Variable {{skills}}, die Entwicklerinnen und Entwickler in Agenten-Prompts einfügen können.
Das Erstellen von Skills mithilfe des CreateSkill-Agenten befindet sich ebenfalls im Alpha-Status. Um projektspezifische Skills festzulegen, dient das KI-Chat-Interface. Dort können Developer den gewünschten Skill beschreiben, und der Agent wird eine korrekt strukturierte SKILL.md-Datei mitsamt entsprechendem YAML-Frontmatter und Markdown-Inhalt erstellen.
Updates für Accessibility und VS-Code-Kompatibilität
Für eine verbesserte Barrierefreiheit sind im Chat nun Fokusnavigationsbefehle verwendbar, um per Tastatur zwischen Input und Antworten zu navigieren (Strg/Cmd+oben/unten). Auch sind alle Chat-Buttons jetzt per Tastatur zugänglich, und für Screenreader stehen umfassende ARIA-Attribute bereit.
Daneben wurde die Kompatibilität mit Erweiterungen für Visual Studio Code auf die API-Version 1.108.0 erhöht und das Theia-Team hat einige Bugs behoben, wie der Blogeintrag zur Ankündigung aufführt.
(mai)
-
Entwicklung & Codevor 3 MonatenKommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
-
Künstliche Intelligenzvor 2 MonatenSchnelles Boot statt Bus und Bahn: Was sich von London und New York lernen lässt
-
Apps & Mobile Entwicklungvor 3 MonatenHuawei Mate 80 Pro Max: Tandem-OLED mit 8.000 cd/m² für das Flaggschiff-Smartphone
-
Apps & Mobile Entwicklungvor 3 MonatenFast 5 GB pro mm²: Sandisk und Kioxia kommen mit höchster Bitdichte zum ISSCC
-
Social Mediavor 3 TagenCommunity Management zwischen Reichweite und Verantwortung
-
Entwicklung & Codevor 2 MonatenKommentar: Anthropic verschenkt MCP – mit fragwürdigen Hintertüren
-
Datenschutz & Sicherheitvor 2 MonatenSyncthing‑Fork unter fremder Kontrolle? Community schluckt das nicht
-
Social Mediavor 2 MonatenDie meistgehörten Gastfolgen 2025 im Feed & Fudder Podcast – Social Media, Recruiting und Karriere-Insights
