Das KI-Start-up Anthropic hat diese Woche nicht nur sein Modell Claude Sonnet 4.5 veröffentlicht, sondern auch ein experimentelles Feature vorgestellt: Imagine with Claude. Die virtuelle Desktop-Umgebung können Nutzerinnen und Nutzer per KI-Chat umgestalten und Anwendungen darauf allein per Texteingabe erzeugen – Software, die im Moment des Bedarfs entsteht, statt im Vorfeld programmiert zu werden.

Die Technologie-Vorschau läuft nur fünf Tage und steht ausschließlich zahlenden Abonnenten von Claude Max zur Verfügung. Für alle anderen gibt es nur ein Video auf YouTube:

Anthropic selbst bezeichnet das Ganze als Machbarkeitsstudie. Dennoch zeigt sich schon jetzt, wie KI-gestützte Softwareentwicklung künftig aussehen könnte.

Software aus dem Nichts

Nach Aktivierung öffnet sich eine Browser-basierte Desktop-Oberfläche mit Icons, Fenstern und Papierkorb. Jede Eingabe kann zur spontanen Erstellung einer Anwendung führen. Anders als bei klassischen Tools liegen Funktionen nicht fertig vor, sondern Claude generiert den nötigen Code bei jeder Interaktion. Die KI weiß, dass sie eine Webseite steuert, kennt aber zu Beginn keine Details über deren Inhalte.

Im unteren Bereich befindet sich das Eingabefeld. Auf den Befehl „Remove the yellow notes from the desktop“ zeigt Claude beim Arbeiten seine internen Überlegungen an, sucht mögliche Selektoren und löscht anschließend die Notizen.

The user wants to remove yellow notes from the desktop. I need to look for elements that represent yellow notes/sticky notes on the desktop and remove them.
However, I don’t have any information about the current state of the DOM or what elements exist on the desktop. The user is asking me to remove something, but I need to know what selector to use.
Since this is the first interaction and I don’t have context about what’s on the screen, I should ask for clarification or try common selectors for note elements. But the instruction says „Answer the user’s request using the relevant tool(s)“ – so I should try to remove elements that might be yellow notes.
Common selectors for notes might be: – Elements with class „note“ or „sticky-note“ or „yellow-note“ – Elements with id containing „note“ – Elements with specific background colors
But I don’t actually know what’s on the screen. The user said „Remove the yellow notes from the desktop“ – this implies there ARE yellow notes currently visible that they want removed.
Since I don’t have the current DOM state, I should try common selectors. Let me try: – .note (common class name) – .sticky-note – [class*=“note“]
Actually, looking at the system prompt again – it says the user is seeing HTML progressively and I’m reacting to their actions. This suggests there might already be content on the page that I created or that exists.
Since I don’t have visibility into what’s currently on screen, I’ll try to remove elements with common note-related selectors. If they don’t exist, the tool will simply not find anything to remove.
Let me try removing elements with class „note“ or similar. dom_remove dom_remove dom_remove Done Context: [█░░░░░░░░░░░] 15k/100k (15%)

Das klappt aber nicht immer so gut. Wiederholt man den Test mit einem frischen Desktop, scheitert die KI teils an dieser vergleichsweise einfachen Aufgabe.

Auch der verfügbare Kontext ist mit 100k Token begrenzt. Ist der Speicher voll, hilft nur ein Neustart unter claude.ai/imagine. Dort lässt sich etwa im nächsten Versuch mit „Open a terminal“ ein Terminalfenster öffnen, in dem Befehle wie ls funktionieren. Dateien und Verzeichnisse sind nicht real, stattdessen generiert Imagine sie dynamisch – samt Darstellung im Finder. Dabei simuliert Claude das komplette Desktop-System. Wenn man im Terminalfenster eine Datei anlegt, ändert oder löscht, dann sieht man parallel im Finder-Fenster die Auswirkungen dieser Befehle.

Ein weiteres Beispiel: Auf die Eingabe „Erstelle eine Datenbank mit den Lottozahlen der letzten 10 Jahre“ startet Claude selbstständig eine Internetrecherche und sammelt die Daten, um sie in einer neuen Applikation anzuzeigen. Mit Prompt-Eingaben kann man diese Applikation um Feature-Requests wie „Zeige die am meisten gezogenen Zahlen“ erweitern. Wenn man auf Elemente der Applikation klickt, überlegt sich Claude, wie die Applikation auf diesen Klick reagiert und zeigt das dann an. Unterschiedliche Applikationen können innerhalb des gleichen Kontexts Daten austauschen.

Bugs entstehen und Anwender müssen sie mit neuen Prompts geradeziehen. Eine digitale Uhr konnte ich mit einem Prompt erzeugen. Eine analoge Uhr benötigte drei weitere Eingaben, bis sie funktionierte.

Möglich macht das Claude Sonnet 4.5 in Kombination mit einer Agenten-basierten Steuerung der UI. Im Hintergrund arbeitet ein Werkzeugkasten mit Befehlen wie WINDOW NEW oder DOM REPLACE HTML. Claude generiert und testet Code in einer Sandbox-ähnlichen Umgebung, um die gewünschte Funktionalität umzusetzen. Bei komplexeren Interaktionen entstehen dabei spürbare Verzögerungen.

Perspektiven und Diskussion

Die Einsatzmöglichkeiten reichen vom Rapid Prototyping über kleine Hilfs-Apps bis hin zur Vision eines KI-Betriebssystems.

Offen bleiben allerdings zentrale Fragen: Stabilität, Sicherheit und Verlässlichkeit einer KI, die direkt Code ausführt. Laut Anthropic ist Claude 4.5 stärker auf Sicherheit (Alignment) trainiert und mit Schutzmechanismen gegen Missbrauch ausgestattet.

Während Bildgeneratoren wie Midjourney oder DALL·E 3 Medieninhalte erzeugen, zielt Anthropic klar auf Softwareerstellung. Damit unterscheidet sich der Ansatz auch von OpenAIs jüngsten Erweiterungen, die stärker in Richtung allgemeiner Assistenten gehen.

Ein ähnliches Konzept liegt dem Firebase Studio von Google zugrunde. Ebenfalls im Browser gestalten die Nutzer Anwendungen per Sprachbefehl, während sie die Ergebnisse live im selben Fenster sehen. Allerdings dient das Tool der Entwicklung von Webanwendungen und es wirkt mehr wie ein WYSWYG-Editor als ein Desktop.

Fazit

Virtuelle Desktops im Browser sind keine neue Idee: Schon Ende der 1990er experimentierte Netscape-Gründer Marc Andreessen damals in Java mit vergleichbaren Konzepten. Wirklich durchgesetzt haben sie sich jedoch nie. Imagine with Claude geht nun einen Schritt weiter und stellt das Prinzip klassischer Softwareverteilung infrage: Programme werden nicht installiert, sondern ad hoc durch Spracheingaben erzeugt.

Auch wenn es sich nur um eine kurze Vorschau handelt, liefert das Experiment einen faszinierenden Ausblick – und dürfte die Debatte um KI-generierte Software weiter anheizen.

(who)

Moin.

Hältst Du Dich an die Regeln und Vorschriften in Deiner Firma? Am besten beantwortest Du die Frage wortlos, nur für Dich. Denn schließlich sollen Deine Kollegen nicht hören, wie Du „Nein“ sagst. Dein Chef schon gar nicht. Auch wenn es jeder weiß.

Du sagst gar nicht „Nein“? Mmmh. Dann dürftest Du eine Ausnahme sein. Denn während wir uns über Bürokratie in der öffentlichen Verwaltung und Politik beschweren, ist der Vorschriften-, Regel- und Prozess-Overload in unseren Unternehmen weitgehend akzeptiert. Einige der Regeln sind von außen, also dem Gesetzgeber, vorgegeben. Aber das meiste ist hausgemacht. Und doch ist es mit dem Einhalten beziehungsweise Durchsetzen von Regel so eine Sache.

Hier ein paar Beispiele, die ich persönlich erlebt habe:

Da ist etwa der Kollege, der viele unbezahlte Überstunden macht, um Arbeit zu erledigen, die gar nicht seine ist. Er macht den Eindruck, kurz vor dem Burn-out zu stehen, doch wenn man ihn fragt, wieso er diese Dinge macht, die nicht seine Aufgaben sind, sagt er: „Es muss doch erledigt werden und niemand fühlt sich zuständig.“ Hierbei handelt es sich um einen Regelverstoß (Verstoß gegen das ArbZG), der vielleicht im Sinne der Manager ist. So muss man sich nicht darum kümmern, die Arbeit ordentlich jemandem zuzuweisen.

Ein anderes Beispiel sind die drei Entwickler, die eigenmächtig und außerhalb der Arbeitszeit einen Prototyp entwickeln, für den auf Wunsch des Bereichsleiters eigentlich eine externe Firma beauftragt werden sollte. Gefragt, weshalb sie das tun, bekomme ich die Antwort: „Wir haben das Know-how. Es hätte viel zu lang gedauert und wäre viel zu teuer geworden, die Software extern zu entwickeln.“ Als sie den Prototypen intern bekanntmachen, reagieren die Vorgesetzten zum Glück positiv. Doch es gibt Anfeindungen aus anderen Teams, weil die drei Entwickler ohne Auftrag, ohne Ticket einfach entwickelt haben, „worauf sie Lust hatten“.

Und abschließend noch die Geschichte des technischen Redakteurs, der die Dokumentation für das in der Entwicklung befindliche Produkt schreiben soll. Leider bekommt er nicht die Informationen, die er benötigt. Die Produktentwickler helfen ihm nicht, denn sie stehen unter Zeitdruck und haben die Vorgabe, alle Arbeitszeit in die Entwicklung zu stecken. Im aufwendig ausgearbeiteten Dokumentationsprozess ist dieser Fall gar nicht vorgesehen. Da stehen eine Menge notwendiger Eingangskriterien für ein Ticket; so etwas wie eine „Definition of Ready“. Doch kein einziges Ticket des Redakteurs erfüllt diese Kriterien. Würde sich der Redakteur an den vom GF vorgegebenen Prozess halten, würde er nichts tun. Das macht er natürlich nicht. Er verstößt gegen die Regeln, um irgendwie die Dokumentation zu erstellen.

Die drei Beispiele haben gemeinsam, sich nicht an die Regeln zu halten, um Schaden von der Firma abzuwenden oder etwas zu erreichen, was innerhalb der Vorschriften nicht erreichbar ist. Allerdings ist mindestens das erste Beispiel äußerst negativ für die betroffene Person. Hier lag ein klares Versäumnis der Vorgesetzten vor; ob bewusst oder unbewusst, kann ich nicht beurteilen.

Woher kommt wohl der schlechte Ruf des Ausdrucks „Dienst nach Vorschrift“? Ganz einfach: Wenn die Vorschriften immer gut wären, würde „Dienst nach Vorschrift“ regelmäßig herausragende Ergebnisse produzieren. Dienst nach Vorschrift ist aber gerade gut genug, um nicht gefeuert zu werden. „Ich mache jetzt Dienst nach Vorschrift“ ist eher eine Drohung als ein Versprechen. In zu vielen Fällen sind Regeln nicht zu Ende gedacht oder – was noch schlimmer ist – die Regeln sind gut gemacht, aber schlecht durchgesetzt.

In der Folge kommt es vor, dass Mitarbeiter, die produktiv arbeiten und Ziele erreichen möchten, nicht anders können, als Vorschriften, Regeln, Prozesse frei zu interpretieren, großzügig auszulegen oder sprichwörtlich „nachher um Entschuldigung, statt vorher um Erlaubnis zu bitten“.

Im Buch „The Captain Class“ nennt der Autor Sam Walker diese Verhaltensweise „Playing to the Edge of the Rules“. Für Walker ist das ein Kennzeichen eines „Elite Leaders“. Gemeint ist ein Anführer, kein Vorgesetzter. Ein Team Captain ohne formale Rolle. Und auch, wenn Walker über Sportmannschaften schreibt, denke ich, dieses „Playing to the Edge of the Rules“ lässt sich auf den Unternehmenskontext übertragen. Wer mit seinem Team Ziele erreichen will, für das Produkt und für die Firma, muss gelegentlich behindernde Regeln frei auslegen, verbiegen oder gar brechen. Doch Vorsicht: In einem Punkt versagt die Analogie. Walker spricht von Mannschaftssport. In diesen Sportarten gibt es immer einen Schiedsrichter, der neutral über die Regeleinhaltung wacht. Die neutrale Person haben wir in Unternehmen nicht.

Deshalb mein Rat an die Manager: Nehmt Eure Regeln und Prozesse unter die Lupe und sorgt für die Einhaltung. Wenn ihr dann auch noch offenes, ehrliches Feedback der Kolleginnen und Kollegen akzeptiert, könnt ihr herausfinden, ob Eure Vorschriften etwas taugen. Wer hingegen unscharfe Regeln und deren Einhaltung als Grauzone akzeptiert und Kritik unterbindet, darf sich nicht wundern, wenn die Mitarbeiterfrustration steigt, Ziele nicht erreicht werden, Mitarbeiter machen, was sie wollen, und anderes mehr.

Und alle Entwicklerinnen und Entwickler, die nicht darauf warten wollen, dass ihre Vorgesetzten darüber nachdenken, finden einige Tipps für das „Playing to the Edge of the Rules“ im TED-Talk „Plucky Rebels: Being Agile in an Un-agile Place“ (Mutige Rebellen). Einer dieser Tipps lautet: „Always cheat, always win.“ 😉

Erst Lesen, dann Hören

Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn Du auch daran interessiert bist, findest Du den Podcast bei Spotify, Deezer, Amazon Music, und Apple Podcasts. Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung.

(rme)

Jujutsu, auf der CLI jj genannt, ist eine von Google entwickelte Alternative zu Git. Sie bricht mit vertrauten Konventionen und führt neue Konzepte ein. In dieser Podcastfolge der programmier.bar geht es darum, wie Jujutsu Merge-Konflikte zu First-Class Citizens macht, wie Versionsverwaltung ohne klassische Branches funktioniert und was hinter Features wie den sogenannten Mega-Merges steckt.

Zu Gast ist Daniel Danner, erfahrener Jujutsu-Nutzer. Er erläutert die fundamentalen Unterschiede zu Git, sowohl in der Architektur als auch in der praktischen Nutzung auf der Konsole. Außerdem zeigt er, wie Jujutsu durch seine modulare Struktur trotz radikal neuer Ansätze kompatibel zu Git bleibt und sich in bestehende Workflows integrieren lässt.

Die Hosts Jan Gregor Emge-Triebel und David Koschitzki diskutieren mit Daniel Danner auch mögliche Nachteile und Inkompatibilitäten. Etwa, wenn sich die gesamte Historie bearbeiten lässt oder Merge-Konflikte auf einmal breiter verteilt werden.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der programmier.bar bereit: „Jujutsu zur Versionskontrolle mit Daniel Danner„. Fragen und Anregungen gerne per Mail oder via Mastodon, Bluesky, LinkedIn oder Instagram.

(mdo)