“If Claude decides to delete all my files: no big deal — but only inside an isolated VM.”

Anyone who uses Claude Code in the terminal with default settings knows the drill: many commands require approval before Claude Code executes them. You constantly have to weigh whether a given command is safe or not.

“Allow this? Allow once? Allow always?”

You keep checking: is this harmless, or could this command cause problems? Cognitive load from reading command lines.

There are essentially two extremes: either you review every single permission request yourself, or you use the --dangerously-skip-permissions option, which allows everything. In between, there are many gradations. You can define your permissions with fine granularity, but that’s almost as much effort.

How nice would it be if you could simply allow everything while still being certain that nothing unwanted happens on your machine. Then agentic coding could proceed unhindered and you’d get results fast.

That’s exactly what an isolated system promises — one that runs shielded from your actual computer. Such an isolated system reduces the blast radius — the maximum damage a misguided command can cause — immensely. If something goes wrong, you simply restart and return to the last stable state. There are many ways to implement this.

One of them is the /sandbox command built into Claude Code. It activates a sandbox that restricts Claude Code at the OS level — file access and networking. You can let commands run automatically without confirming each one, because the sandbox limits what can happen. But how secure is it really?

And then there’s Cowork in the desktop version of the Claude app. Cowork is aimed more at knowledge workers than developers. It can access folders, create and modify files, install packages — all autonomously. At first glance, it’s not obvious how the protection works. There’s no /sandbox command you’d need to activate. The isolation happens in the background.

I was curious about both: how does the sandbox work in Claude Code? And how does Cowork protect me from unwanted changes on my machine?

I didn’t want to rely on the documentation alone — instead, I examined both systems from the inside. Here’s what I found.

Two Products, Two Audiences, Two Security Models

Before I dive into the technical details, an important distinction:

Claude Code is a terminal tool for developers. It executes commands on your machine — in the same context where you work. The sandbox must be manually activated (/sandbox), making it opt-in. That makes sense: developers need as few restrictions as possible to be productive. They want to run commands that a restrictive sandbox would block. But with great power comes great responsibility. You need to understand what you’re approving.

Cowork is part of the Claude Desktop app and is aimed at users who don’t want to deal with the command line. When someone asks Claude to create an Excel spreadsheet from five PDFs, they expect a result — not a discussion about file permissions. Cowork therefore needs to provide stronger protection, without requiring the user to configure anything.

The result: two different isolation models for two different risk profiles.

Let’s get into the details.

Cowork: A Linux Inside Your Mac

Cowork launches a lightweight Linux VM via Apple’s Virtualization.framework. Not a container, but a real virtual machine with its own kernel.

What does the VM say about itself?

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.5 LTS"

$ uname -r
6.8.0-94-generic

$ uname -m
aarch64

$ nproc
4

$ free -h
              total    used    free
Mem:          3.8Gi   564Mi   1.8Gi
Swap:            0B      0B      0B

$ df -h /
Filesystem      Size  Used Avail Use%
/dev/nvme0n1p1  9.6G  7.2G  2.4G  75%

Ubuntu 22.04 on ARM64, 4 cores, 3.8 GB RAM, a 10 GB disk. No swap. Lean enough for document processing and scripts, but not meant for machine learning training.

On the macOS host, the VM files live at ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/. The root image (rootfs.img) is 10 GB as a sparse file but only occupies about 7.5 GB on disk.

Alongside it sits a compressed backup (rootfs.img.zst, ~2 GB) and a few configuration files: efivars.fd, macAddress, machineIdentifier.

How Three Layers Work Together to Secure the Isolation

The VM alone would already be a solid boundary. But Anthropic stacks three layers on top of each other.

Layer 1: The VM

Apple’s Virtualization.framework provides hardware isolation. The guest has its own kernel. Even an rm -rf / inside the VM leaves the host untouched.

Layer 2: bubblewrap + seccomp

Inside the VM, Claude doesn’t run directly — first comes bubblewrap (short: bwrap). Bubblewrap is a sandboxing tool that uses Linux namespaces to isolate processes from each other — similar to what containers do, but more lightweight.

It restricts what a process can see and do: which files, which network interfaces, which other processes.

In the Cowork VM, bubblewrap is PID 1 — the very first process:

$ cat /proc/1/status | head -2
Name:   bwrap
State:  S (sleeping)

The bwrap command line (readable via /proc/1/cmdline) shows the key restrictions at a glance:

• --unshare-net — separate network namespace, no direct network access

• --unshare-pid — separate PID namespace, other processes invisible

• --ro-bind / / — root filesystem mounted read-only

• --die-with-parent — if the parent process dies, the sandbox dies with it

• --tmpfs /etc/ssh/ssh_config.d — SSH configuration overlaid with an empty tmpfs

Additionally, a seccomp filter is loaded. Seccomp (Secure Computing Mode) is a Linux kernel mechanism that determines which system calls a process is allowed to make. System calls are the interface between a program and the operating system — opening files, establishing network connections, starting processes.

A seccomp filter can selectively block individual system calls, drastically limiting a process’s radius of action.

$ grep Seccomp /proc/self/status
Seccomp:         2
Seccomp_filters: 2

Seccomp: 2 means filter mode — there’s an active allowlist for permitted syscalls. The filter file is called unix-block.bpf and is loaded via a dedicated binary (apply-seccomp).

Layer 3: Network Isolation

No process in the sandbox has direct internet access. All traffic goes through a local proxy:

$ env | grep HTTP_PROXY
HTTP_PROXY=http://localhost:3128

$ env | grep ALL_PROXY
ALL_PROXY=socks5h://localhost:1080

The proxy runs via socat, which tunnels TCP connections into Unix sockets that lead out of the VM. On the host side, an allowlist decides which domains may pass through.

I tested it:

$ curl -s -o /dev/null -w "%{http_code}" https://registry.npmjs.org
200

$ curl -s -o /dev/null -w "%{http_code}" https://pypi.org
200

$ curl -sv https://evil-exfiltration-test.example.org 2>&1 | grep "HTTP/1.1"
< HTTP/1.1 403 Forbidden

$ curl -sv https://evil-exfiltration-test.example.org 2>&1 | grep "X-Proxy"
< X-Proxy-Error: blocked-by-allowlist

npm and PyPI get through. Everything else receives a 403 Forbidden with the header X-Proxy-Error: blocked-by-allowlist. Direct DNS lookups also fail:

$ nslookup google.com
socket(): Operation not permitted
;; no servers could be reached

This is consistent: even if a prompt injection attack were to trick Claude into sending data to an external server — the proxy would block it.

Which Files Does the VM See?

Files enter the VM via VirtioFS — a filesystem protocol designed specifically for communication between a VM and its host. Instead of simulating real hardware, host and guest cooperate deliberately (paravirtualization). This makes file access fast and low-overhead.

$ mount | grep virtiofs
/mnt/.virtiofs-root/shared/Work/.../Marketing on
  /sessions/elegant-adoring-brown/mnt/Marketing type fuse (rw,...)

Only the folder I selected in the Desktop app is mounted. Not my home directory, not my Desktop, not my Downloads — just the one folder I explicitly shared.

Plugins and Skills are additionally mounted via bindfs. Bindfs is a FUSE filesystem that remounts an existing folder at a different location — similar to a symlink, but with the ability to change permissions. This way, Skills can be mounted read-only even though they’re writable on the host. Uploads also land in a separate, read-only mount.

One detail reveals that the VM serves multiple conversations simultaneously: the /sessions/ directory contains different sessions side by side:

$ ls -la /sessions/
drwxr-x--- elegant-adoring-brown  elegant-adoring-brown  ...
drwxr-x--- nobody                 nogroup                awesome-epic-mccarthy
drwxr-x--- nobody                 nogroup                dazzling-vibrant-carson

Each session gets its own Linux user with its own UID. My user is called elegant-adoring-brown (uid 1005). The other sessions are listed under nobody — I can’t read their files.

How Does Claude Code Protect Without a VM?

Claude Code in the terminal uses a different approach on macOS: Apple’s Seatbelt (also known as sandbox-exec). Instead of a VM, a dynamically generated sandbox profile restricts the process at the OS level. Important: the sandbox must be manually activated with /sandbox — without this step, Claude Code runs without OS-level isolation.

The profile starts with (deny default) — everything is forbidden unless explicitly allowed. The sandbox runtime is open source and available on GitHub. I downloaded the npm package @anthropic-ai/sandbox-runtime and analyzed the macos-sandbox-utils.js:

• 59 sysctl entries are made readable (hardware info like CPU count, memory size)

• 14 Mach IPC services on the whitelist (Fonts, Logging, Security Server)

• Mandatory denies for .env, .ssh, .aws, .git/hooks, .git/config — even when the working directory has write access

• Move blocking: file-write-rename and file-write-unlink are blocked for protected paths, preventing circumvention of the denies via mv

The network isolation works the same way as with Cowork: all traffic goes through the same proxy with an allowlist. The difference: with Seatbelt, this happens at the process level (same kernel); with Cowork, at the VM level (separate kernel).

Why Two Models?

Claude Code is aimed at developers who need fast feedback in the terminal. The Seatbelt overhead is in the low single-digit millisecond range — I measured it on the host, no perceptible difference from a command without sandbox. Developers can selectively activate the sandbox when they want to give an agent more autonomy without having to approve every command.

Cowork gives Claude significantly more autonomy: it runs longer, creates files independently, installs packages. And it’s aimed at users who can’t assess (and don’t need to assess) which commands are being executed at the operating system level. The potential damage from an agent with local file access, code generation, and network egress is greater — and users are less able to evaluate it. Full VM isolation is appropriate here.

What I Take Away From This

The isolation is real. Not just on paper, but verifiable.

Three things convinced me in particular:

First, the proxy allowlist with the explicit X-Proxy-Error: blocked-by-allowlist header. This isn’t a silent error message but a deliberate architectural decision. You can immediately see why a connection fails.

Second, the layering. The VM alone would be good. With bubblewrap and seccomp, it gets better. All three together make it significantly harder to break out of the sandbox. An exploit would have to simultaneously bypass the seccomp filter, escape the bwrap namespace, and then break out of the VM — on a system with no direct network access.

Third, the transparency. The sandbox runtime is open source. I downloaded the macos-sandbox-utils.js code — the 59 sysctl entries, the 14 Mach services, and the mandatory denies for .env, .ssh, and .aws are all there in black and white. The Seatbelt profile is dynamically generated, but the generating code is inspectable. The VM architecture can be examined from the inside. You don’t have to take anyone’s word for it — you can look for yourself.

If you want to look for yourself: the sandbox runtime is on GitHub. An npm pack and a look at macos-sandbox-utils.js is all it takes to understand the Seatbelt profile.

What You Can Do Now

If you’re using Claude Code and haven’t tried the sandbox yet: start a session and type /sandbox. That alone significantly reduces the effort of approving commands one by one. For everyday use, that’s often enough.

If you want to go deeper:

• Inspect the sandbox runtime: npm pack @anthropic-ai/sandbox-runtime, unpack, read macos-sandbox-utils.js. There you’ll see exactly what’s allowed and what’s blocked.

• Examine Cowork from the inside: Launch Cowork and ask it to run cat /proc/1/cmdline | tr '\0' '\n'. The bubblewrap flags reveal the isolation in detail.

• Test the network: A curl https://evil-exfiltration-test.example.org inside the sandbox immediately shows you whether the allowlist is working.

What’s Next?

The current state is clear. But one question remains: will it stay this way? Claude Code and Cowork already share the agentic architecture — and there are concrete signals that the security models are converging as well:

• Docker is delivering MicroVM sandboxes with docker-model-runner, specifically designed for AI agents.

• Apple is bringing its own Containerization framework with macOS 26 — native container support on the Mac for the first time.

• Anthropic documents DevContainers as the official path toward stronger isolation in Claude Code.

Three players, three approaches, one goal: agents should be able to do more without being able to cause more damage. In the next article, I’ll examine the pros and cons of each path — and why I consider one of them the most likely.

If you want to be notified when the next article is published:

Jetzt abonnieren

Subscribe to my Substack — free, no spam, just substance.

Sources

• Sandboxing — Claude Code Docs

• sandbox-runtime (GitHub)

• Inside Claude Cowork (Pedro José Pereira Vieito) — Reverse engineering analysis of the VM architecture

• Apple Virtualization Framework

KI-Agenten führen Befehle auf deinem Rechner aus — aber wie gut schützen dich die Sandboxes von Claude Code und Cowork? Beide versprechen Isolation, setzen aber auf unterschiedliche Mechanismen. Ich habe nicht nur die Dokumentation gelesen, sondern beide Systeme mit Linux-Tools von innen untersucht. Das Ergebnis: Die Isolation ist real, nachprüfbar und überraschend durchdacht.

„Falls sich Claude entscheidet, alle meine Dateien zu löschen: Halb so wild. Aber bitte nur innerhalb einer isolierten VM !“

Wer Claude Code im Terminal mit den Standardeinstellungen nutzt, kennt das: Viele Befehle benötigen eine Freigabe, bevor Claude Code sie ausführt.

Immer wieder muss man abwägen, ob der jeweilige Befehl in Ordnung geht oder nicht:

„Allow this? Allow once? Allow always?“

Ständig prüft man: Ist das ungefährlich oder könnte dieser Befehl zu Problemen führen? Cognitive Load durch Kommandozeilen lesen.

Im Grunde gibt es zwei extreme Ansätze: Entweder man prüft jede einzelne Freigabeanfrage selbst oder setzt auf die Option --dangerously-skip-permissions, wodurch alles erlaubt ist. Dazwischen gibt es viele Abstufungen. Man kann seine Permissions feingranular definieren, aber das ist fast genauso aufwendig.

Wie schön wäre es, wenn man einfach alles erlauben könnte und dennoch sicher sein könnte, dass nichts Unerwünschtes auf dem eigenen Rechner passiert. Dann könnte Agentic Coding ungebremst stattfinden und man käme schnell zu Ergebnissen.

Genau das verspricht ein isoliertes System, das abgeschirmt vom eigenen Computer läuft. So ein isoliertes System verringert den Blast Radius — also den Schaden, den ein fehlgeleiteter Befehl maximal anrichten kann — immens. Wenn etwas schief geht, startet man einfach neu und geht zum letzten stabilen Ausgangszustand zurück. Es gibt viele Möglichkeiten, das umzusetzen.

Eine davon ist der in Claude Code eingebaute /sandbox-Befehl. Er aktiviert eine Sandbox, die Claude Code auf OS-Ebene einschränkt — Dateizugriffe und Netzwerk. Man kann Commands automatisch laufen lassen, ohne jedes Mal zu bestätigen, weil die Sandbox begrenzt, was passieren kann. Aber wie sicher ist das wirklich?

Und dann gibt es noch Cowork in der Desktop-Variante der Claude-App. Cowork richtet sich eher an Wissensarbeiter, nicht direkt an Entwickler. Es darf auf Ordner zugreifen, Dateien erstellen und verändern, Pakete installieren — und das alles autonom. Auf den ersten Blick ist dabei nicht ersichtlich, wie die Absicherung funktioniert. Es gibt keinen /sandbox-Befehl, den man aktivieren müsste. Die Isolation passiert im Hintergrund.

Mich hat beides interessiert: Wie funktioniert die Sandbox in Claude Code? Und wie schützt mich Cowork davor, dass ungewollte Änderungen auf meinem Rechner passieren?

Dabei wollte ich mich nicht nur auf die Dokumentation verlassen, sondern ich habe beide Systeme von innen untersucht. Hier ist, was ich gefunden habe.

Zwei Produkte, zwei Zielgruppen, zwei Sicherheitsmodelle

Bevor ich in die Technik gehe, ein wichtiger Unterschied:

Claude Code ist ein Terminal-Tool für Entwickler. Es führt Befehle auf deinem Rechner aus — im selben Kontext, in dem du arbeitest. Die Sandbox muss manuell aktiviert werden (/sandbox), ist opt-in. Das ergibt Sinn: Entwickler brauchen möglichst wenig Einschränkungen, um produktiv zu sein. Sie wollen Befehle ausführen können, die eine restriktive Sandbox behindern würde. Aber mit vielen Rechten kommt viel Verantwortung. Man muss verstehen, was man abnickt.

Cowork ist Teil der Claude Desktop-App und richtet sich an Nutzer, die sich nicht mit der Kommandozeile auseinander setzen wollen. Wenn jemand Claude bittet, eine Excel-Tabelle aus fünf PDFs zu erstellen, erwartet er ein Ergebnis — nicht eine Diskussion über Dateiberechtigungen. Cowork muss daher stärker absichern, und zwar ohne dass der Nutzer das konfigurieren muss.

Das Ergebnis: Zwei unterschiedliche Isolationsmodelle für zwei unterschiedliche Risikoprofile.

Lass uns in die Details gehen.

Cowork: Ein Linux in deinem Mac

Cowork startet eine leichtgewichtige Linux-VM über Apples Virtualization.framework. Kein Container, sondern eine echte virtuelle Maschine mit eigenem Kernel.

Was sagt die VM über sich?

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.5 LTS"

$ uname -r
6.8.0-94-generic

$ uname -m
aarch64

$ nproc
4

$ free -h
              total    used    free
Mem:          3.8Gi   564Mi   1.8Gi
Swap:            0B      0B      0B

$ df -h /
Filesystem      Size  Used Avail Use%
/dev/nvme0n1p1  9.6G  7.2G  2.4G  75%

Ubuntu 22.04 auf ARM64, 4 Kerne, 3,8 GB RAM, eine 10-GB-Disk. Kein Swap. Schlank genug für Dokumentenverarbeitung und Skripte, aber nicht für Machine-Learning-Training gedacht.

Auf dem macOS-Host finden sich die VM-Dateien unter ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/. Das Root-Image (rootfs.img) ist 10 GB groß als Sparse-Datei, belegt aber nur etwa 7,5 GB on-disk.

Daneben liegt ein komprimiertes Backup (rootfs.img.zst, ~2 GB) und ein paar Konfigurationsdateien: efivars.fd, macAddress, machineIdentifier.

Wie drei Schichten zusammen die Isolation absichern

Die VM allein wäre schon eine solide Grenze. Aber Anthropic stapelt drei Schichten übereinander.

Schicht 1: Die VM

Apples Virtualization.framework stellt Hardware-Isolation bereit. Der Gast hat seinen eigenen Kernel. Selbst ein rm -rf / in der VM lässt den Host unberührt.

Schicht 2: bubblewrap + seccomp

Innerhalb der VM läuft nicht direkt Claude, sondern erst bubblewrap (kurz: bwrap). Bubblewrap ist ein Sandboxing-Tool, das Linux-Namespaces nutzt, um Prozesse voneinander zu isolieren — ähnlich wie Container es tun, aber leichtgewichtiger.

Es schränkt ein, was ein Prozess sehen und tun darf: welche Dateien, welche Netzwerkschnittstellen, welche anderen Prozesse.

In der Cowork-VM ist bubblewrap PID 1, also der allererste Prozess:

$ cat /proc/1/status | head -2
Name:   bwrap
State:  S (sleeping)

Die bwrap-Kommandozeile (über /proc/1/cmdline auslesbar) zeigt die wichtigsten Einschränkungen im Überblick:

• --unshare-net — eigener Netzwerk-Namespace, kein direkter Netzzugang

• --unshare-pid — eigener PID-Namespace, andere Prozesse unsichtbar

• --ro-bind / / — Root-Dateisystem read-only eingebunden

• --die-with-parent — stirbt der Elternprozess, stirbt die Sandbox mit

• --tmpfs /etc/ssh/ssh_config.d — SSH-Konfiguration wird mit einem leeren tmpfs überdeckt

Zusätzlich wird ein seccomp-Filter geladen. Seccomp (Secure Computing Mode) ist ein Mechanismus im Linux-Kernel, der festlegt, welche Systemaufrufe ein Prozess machen darf. Systemaufrufe sind die Schnittstelle zwischen einem Programm und dem Betriebssystem — Dateien öffnen, Netzwerkverbindungen herstellen, Prozesse starten.

Ein seccomp-Filter kann gezielt einzelne Systemaufrufe blockieren und damit den Aktionsradius eines Prozesses stark einschränken.

$ grep Seccomp /proc/self/status
Seccomp:         2
Seccomp_filters: 2

Seccomp: 2 bedeutet Filter-Modus — es gibt eine aktive Allowlist für erlaubte Syscalls. Die Filterdatei heißt unix-block.bpf und wird über eine eigene Binary (apply-seccomp) geladen.

Schicht 3: Netzwerk-Isolation

Kein Prozess in der Sandbox hat direkten Internetzugang. Aller Traffic geht durch einen lokalen Proxy:

$ env | grep HTTP_PROXY
HTTP_PROXY=http://localhost:3128

$ env | grep ALL_PROXY
ALL_PROXY=socks5h://localhost:1080

Der Proxy läuft über socat, das TCP-Verbindungen in Unix-Sockets tunnelt, die aus der VM herausführen. Auf der Host-Seite entscheidet eine Allowlist, welche Domains passieren dürfen.

Ich habe es getestet:

$ curl -s -o /dev/null -w "%{http_code}" https://registry.npmjs.org
200

$ curl -s -o /dev/null -w "%{http_code}" https://pypi.org
200

$ curl -sv https://evil-exfiltration-test.example.org 2>&1 | grep "HTTP/1.1"
< HTTP/1.1 403 Forbidden

$ curl -sv https://evil-exfiltration-test.example.org 2>&1 | grep "X-Proxy"
< X-Proxy-Error: blocked-by-allowlist

npm und PyPI kommen durch. Alles andere bekommt ein 403 Forbidden mit dem Header X-Proxy-Error: blocked-by-allowlist. Auch direkte DNS-Lookups scheitern:

$ nslookup google.com
socket(): Operation not permitted
;; no servers could be reached

Das ist konsequent: Selbst wenn ein Prompt-Injection-Angriff Claude dazu bringen würde, Daten an einen externen Server zu senden — der Proxy würde es blockieren.

Welche Dateien sieht die VM?

Dateien kommen über VirtioFS in die VM — ein Dateisystem-Protokoll, das speziell für die Kommunikation zwischen VM und Host entwickelt wurde. Statt echte Hardware zu simulieren, arbeiten Host und Guest bewusst zusammen (Paravirtualisierung). Das macht den Dateizugriff schnell und mit wenig Overhead möglich.

$ mount | grep virtiofs
/mnt/.virtiofs-root/shared/Work/.../Marketing on
  /sessions/elegant-adoring-brown/mnt/Marketing type fuse (rw,...)

Nur der Ordner, den ich in der Desktop-App ausgewählt habe, wird gemountet. Nicht mein Home-Verzeichnis, nicht mein Desktop, nicht meine Downloads — nur der eine Ordner, den ich explizit freigegeben habe.

Plugins und Skills werden über bindfs zusätzlich eingebunden. Bindfs ist ein FUSE-Dateisystem, das einen vorhandenen Ordner an einer anderen Stelle nochmal einbindet — ähnlich wie ein Symlink, aber mit der Möglichkeit, die Berechtigungen zu ändern. So können Skills zum Beispiel read-only eingebunden werden, obwohl sie auf dem Host beschreibbar sind. Uploads landen ebenfalls in einem separaten, schreibgeschützten Mount.

Ein Detail verrät, dass die VM mehrere Conversations gleichzeitig bedient: Im /sessions/-Verzeichnis sitzen verschiedene Sessions nebeneinander:

$ ls -la /sessions/
drwxr-x--- elegant-adoring-brown  elegant-adoring-brown  ...
drwxr-x--- nobody                 nogroup                awesome-epic-mccarthy
drwxr-x--- nobody                 nogroup                dazzling-vibrant-carson

Jede Session bekommt einen eigenen Linux-User mit eigener UID. Mein User heißt elegant-adoring-brown (uid 1005). Die anderen Sessions sind unter nobody gelistet — ich kann ihre Dateien nicht lesen.

Wie schützt Claude Code ohne VM?

Claude Code im Terminal nutzt auf macOS einen anderen Ansatz: Apples Seatbelt (auch bekannt als sandbox-exec). Statt einer VM wird ein dynamisch generiertes Sandbox-Profil erstellt, das den Prozess auf OS-Ebene einschränkt. Wichtig: Die Sandbox muss manuell mit /sandbox aktiviert werden — ohne diesen Schritt läuft Claude Code ohne OS-Level-Isolation.

Das Profil startet mit (deny default) — alles ist verboten, außer es wird explizit erlaubt. Die Sandbox-Runtime ist Open Source und auf GitHub einsehbar. Ich habe das npm-Paket @anthropic-ai/sandbox-runtime heruntergeladen und die macos-sandbox-utils.js analysiert:

• 59 sysctl-Einträge werden zum Lesen freigegeben (Hardware-Info wie CPU-Anzahl, Speichergröße)

• 14 Mach-IPC-Services auf der Whitelist (Fonts, Logging, Security Server)

• Mandatory Denies für .env, .ssh, .aws, .git/hooks, .git/config — auch wenn das Arbeitsverzeichnis Schreibzugriff hat

• Move-Blocking: file-write-rename und file-write-unlink werden für geschützte Pfade blockiert, damit man die Denies nicht per mv umgehen kann

Die Netzwerk-Isolation funktioniert genauso wie bei Cowork: Aller Traffic geht durch denselben Proxy mit Allowlist. Der Unterschied: Bei Seatbelt passiert das auf Prozess-Ebene (gleicher Kernel), bei Cowork auf VM-Ebene (eigener Kernel).

Warum zwei Modelle?

Claude Code richtet sich an Entwickler, die im Terminal schnelles Feedback brauchen. Der Seatbelt-Overhead liegt im niedrigen einstelligen Millisekundenbereich — ich habe es auf dem Host gemessen, kein spürbarer Unterschied zu einem Befehl ohne Sandbox. Entwickler können die Sandbox gezielt aktivieren, wenn sie einem Agenten mehr Autonomie geben wollen, ohne jeden Befehl freigeben zu müssen.

Cowork gibt Claude deutlich mehr Autonomie: Es läuft länger, erstellt eigenständig Dateien, installiert Pakete. Und es richtet sich an Nutzer, die nicht einschätzen können (und nicht einschätzen müssen), welche Befehle auf Betriebssystemebene ausgeführt werden. Der mögliche Schaden eines Agenten mit lokalem Dateizugriff, Codegenerierung und Netzwerk-Egress ist größer — und die Nutzer können ihn schlechter einschätzen. Die volle VM-Isolation ist hier angemessen.

Was ich daraus mitnehme

Die Isolation ist real. Nicht nur auf dem Papier, sondern nachprüfbar.

Drei Dinge haben mich besonders überzeugt:

Erstens die Proxy-Allowlist mit dem expliziten X-Proxy-Error: blocked-by-allowlist Header. Das ist keine stille Fehlermeldung, sondern eine bewusste Architekturentscheidung. Man sieht sofort, warum eine Verbindung scheitert.

Zweitens die Schichtung. VM allein wäre gut. Mit bubblewrap und seccomp wird’s besser. Alle drei zusammen machen es deutlich schwieriger, aus der Sandbox auszubrechen. Ein Exploit müsste gleichzeitig den seccomp-Filter umgehen, aus dem bwrap-Namespace ausbrechen und dann noch aus der VM raus — auf einem System, das keinen direkten Netzzugang hat.

Drittens die Transparenz. Die Sandbox-Runtime ist Open Source. Ich habe den Code der macos-sandbox-utils.js heruntergeladen — dort stehen die 59 sysctl-Einträge, die 14 Mach-Services und die Mandatory Denies für .env, .ssh und .aws schwarz auf weiß. Das Seatbelt-Profil wird dynamisch generiert, aber der generierende Code ist einsehbar. Die VM-Architektur lässt sich von innen inspizieren. Man muss niemandem glauben — man kann nachschauen.

Wer selbst nachschauen will: Die Sandbox-Runtime liegt auf GitHub. Ein npm pack und ein Blick in macos-sandbox-utils.js reichen, um das Seatbelt-Profil zu verstehen.

Was du jetzt tun kannst

Wenn du Claude Code nutzt und die Sandbox noch nicht ausprobiert hast: Starte eine Session und tippe /sandbox. Allein das reduziert den Aufwand, Befehle einzeln freizugeben, erheblich. Für den Alltag reicht das oft schon.

Wenn du tiefer einsteigen willst:

• Sandbox-Runtime inspizieren: npm pack @anthropic-ai/sandbox-runtime, entpacken, macos-sandbox-utils.js lesen. Dort siehst du exakt, was erlaubt und was blockiert wird.

• Cowork von innen ansehen: Starte Cowork und bitte es cat /proc/1/cmdline | tr '\0' '\n' auszuführen. Die bubblewrap-Flags verraten dir die Isolation im Detail.

• Netzwerk testen: Ein curl https://evil-exfiltration-test.example.org in der Sandbox zeigt dir sofort, ob die Allowlist greift.

Wie geht es weiter?

Damit ist der Ist-Zustand klar. Aber eine Frage bleibt: Wird das so bleiben? Claude Code und Cowork teilen sich bereits die agentic Architektur — und es gibt konkrete Signale, dass auch die Sicherheitsmodelle zusammenwachsen:

• Docker liefert mit docker-model-runner MicroVM-Sandboxes, die speziell für KI-Agenten gedacht sind.

• Apple bringt mit macOS 26 ein eigenes Containerization-Framework — erstmals native Container-Unterstützung auf dem Mac.

• Anthropic dokumentiert DevContainer als offiziellen Weg für stärkere Isolation in Claude Code.

Drei Player, drei Ansätze, ein Ziel: Agenten sollen mehr dürfen, ohne mehr Schaden anrichten zu können. Im nächsten Artikel werde ich mir anschauen, was für und gegen jeden dieser Pfade spricht — und warum ich einen davon für den wahrscheinlichsten halte.

Wenn du benachrichtigt werden willst, wenn der nächste Artikel veröffentlich ist:

Jetzt abonnieren

Quellen

• Sandboxing — Claude Code Docs

• sandbox-runtime (GitHub)

• Inside Claude Cowork (Pedro José Pereira Vieito) — Reverse-Engineering-Analyse der VM-Architektur

• Apple Virtualization Framework

Die AI-Diskussion in der Softwareentwicklung dreht sich fast ausschließlich um eine Frage: Wie generieren wir Code schneller? Das ist verständlich – aber es lenkt von dem ab, was gerade wirklich passiert.

Das Bottleneck hat sich verschoben

Vor einem Jahr war “Code schreiben” noch ein limitierender Faktor. Heute kann ein einzelner Entwickler mit den richtigen Agents an einem Tag produzieren, wofür früher eine Woche nötig war.

Klingt nach Fortschritt. Ist es auch – bis man fragt: Wer reviewt das alles? Wer versteht es? Wer verantwortet es?

Die Velocity-Metriken sehen fantastisch aus. Aber die Engpässe sind nicht verschwunden. Sie haben sich verschoben – zum Menschen.

Fünf Fragen, auf die niemand gute Antworten hat

1. Wie bewertest du Arbeit, die du nicht mehr selbst machst?

Engineering Leads haben jahrelang Code-Reviews gemacht. Sie wussten, worauf sie achten mussten, weil sie selbst im Code steckten. Wenn Agents den Großteil des Codes produzieren und Engineers zu “Orchestratoren” werden – nach welchen Kriterien bewerten wir dann? Wie unterscheidest du guten von schlechtem Output, wenn du selbst nicht mehr Zeile für Zeile durchgehst?

2. Wer übernimmt die Verantwortung?

Agent generiert Code. Engineer gibt ihn frei. QA testet. Alles grün. Drei Monate später: Security-Problem, das niemand gesehen hat.

Wer ist verantwortlich? Der Engineer, der den Code freigegeben hat, ohne ihn wirklich zu verstehen? Das Team, das die Guardrails definiert hat? Die Organisation, die keine besseren Review-Prozesse etabliert hat?

In klassischen Strukturen war Verantwortung an Wissen gekoppelt: Wer den Code geschrieben hat, verstand ihn und verantwortete ihn. Diese Kopplung löst sich gerade auf.

3. Wie befähigst du Menschen, Verantwortung zu übernehmen, die sie nicht tragen können?

“Human in the Loop” klingt beruhigend. Aber was bedeutet das konkret?

Ein Mensch, der zehnmal so viel Output überprüfen muss wie vorher, prüft nicht gründlicher – er prüft oberflächlicher. Oder er wird zum Bottleneck, der die gesamte AI-Velocity wieder zunichtemacht.

Wir verlangen von Menschen, dass sie Arbeit verantworten, für die wir sie weder ausgebildet noch ausgestattet haben.

4. Was genau wird verifiziert – und was nicht?

Tests laufen durch. Linting ist sauber. Der Code funktioniert.

Aber: Ist die Architektur-Entscheidung richtig? Passt die Lösung ins Gesamtsystem? Entsteht gerade technische Schuld, die erst in zwei Jahren sichtbar wird?

Agents optimieren lokal. Sie lösen die Aufgabe, die vor ihnen liegt. Die systemischen Auswirkungen sieht niemand – bis es zu spät ist.

5. Was passiert mit den Bereichen, die nicht Engineering heißen?

Code-Generierung ist nur ein Teil des Delivery-Systems. Was ist mit Produktentscheidungen, die jetzt schneller technisch umsetzbar sind – aber nicht schneller durchdacht? Was ist mit Dokumentation, die niemand mehr schreibt, weil der Code sich zu schnell ändert? Mit Onboarding neuer Teammitglieder in eine Codebase, die niemand im Team mehr wirklich versteht?

Wenn Engineering plötzlich zehnmal schneller liefern kann, verschiebt sich der Druck auf Product, Design, QA. Die Friction wandert – sie verschwindet nicht.

Das eigentliche Problem

Wir haben das Code-Schreiben beschleunigt. Aber die Arbeit, die sich nicht beschleunigen lässt – verstehen, bewerten, entscheiden, verantworten – ist immer noch da. Und unsere Organisationen sind nicht dafür gebaut.

Die meisten Unternehmen behandeln AI wie ein Upgrade ihrer Werkzeuge. Schnellere IDE, besserer Copilot, mehr Output pro Kopf.

Aber das Werkzeug hat sich fundamental verändert. Es trifft jetzt eigene Entscheidungen. Und wir haben keine Strukturen, Prozesse oder Rollenbilder, die damit umgehen können.

Kleine AI-native Teams bauen gerade ihre Strukturen um diese Realität herum. Große Organisationen diskutieren noch, welchen Copilot sie lizenzieren. Die Frage ist nicht, ob sich das rächt – sondern wann.

„Ich schreibe kaum noch Code. Und trotzdem baue ich mehr Software als je zuvor.“

Als ich das kürzlich auf LinkedIn schrieb, kam:

„Naja, und wer kontrolliert die Agenten? Wer räumt die technischen Schulden, die sie produzieren, wieder auf?”

Eine Frage, eine berechtigte Frage, mit der ich mich ebenfalls schon beschäftigt hatte.

Eine Frage, die ich nicht mit einem Zweizeiler beantworten kann.

Die Frage hinter der Frage

Wer so fragt, will wissen:

Kannst du dem Output überhaupt vertrauen?

Oder baust du dir gerade ein Kartenhaus, das beim ersten echten Problem zusammenfällt?

Meine Antwort ist unbefriedigend für alle, die ein klares Ja oder Nein wollen: Es kommt darauf an. Und genau dieses „es kommt darauf an” ist der eigentliche Skill, den ich in den letzten Monaten entwickelt habe.

Nicht alles ist gleich kritisch

Der erste Schritt war eine simple Erkenntnis: Nicht jeder Bereich meiner Software verdient dieselbe Aufmerksamkeit.

Ich unterscheide grob nach zwei Kriterien:

1. Wie schnell sehe ich, wenn etwas nicht funktioniert?

2. Wie groß ist der potenzielle Schaden?

Kritische Bereiche sind für mich zum Beispiel:

• Authentifizierung und Login-Flows

• Autorisierungslogik – wer darf was sehen und tun

• Datenbankdesign, insbesondere das Datenmodell

• Row Level Security für Datenbanken

• Alles, was mit Zahlungen oder sensiblen Nutzerdaten zu tun hat

• Alles, von dem viel abhängt

Diese Bereiche haben zwei Eigenschaften gemeinsam:

• Fehler sind nicht sofort sichtbar, und

• wenn sie auftreten, ist der Schaden potenziell groß.

Eine kaputte Authentifizierung merkst du nicht, wenn du die Anwendung durchklickst. Du merkst sie, wenn jemand anderes sie ausnutzt.

Unkritische Bereiche sind für mich:

• Frontend-Darstellung und UI-Komponenten

• Styling und Layout

• Nicht-sicherheitsrelevante Formularvalidierungen

• Hilfsfunktionen und Utilities

Das heisst nicht, dass sie unwichtig sind. Aber wenn hier etwas nicht funktioniert, sehe ich es schnell. Ein Button, der nicht reagiert, eine Liste, die nicht rendert – das fällt beim Testen auf. Und selbst wenn es durchrutscht: Der Schaden ist begrenzt. Kein Nutzer verliert Geld oder Daten, weil ein Schatten an der falschen Stelle sitzt.

Wie ich Agenten einsetze

Für meine Projekte habe ich spezialisierte Subagents aufgebaut, die auf definierte Aufgaben zugeschnitten sind. Manche habe ich selbst konfiguriert, bei anderen greife ich auf vorgefertigte Lösungen zurück. Entscheidend ist nicht das einzelne Tool, sondern wie sie zusammenarbeiten.

Mein Workflow folgt einem Muster, das menschliche Review-Prozesse nachbildet:

Stufe 1: Entwurf. Ein Agent erstellt einen ersten Vorschlag – sei es Code, eine Architekturentscheidung oder ein Datenbankschema.

Stufe 2: Ausarbeitung. Ein anderer Agent nimmt den Entwurf und arbeitet die Details aus. Er kennt den Kontext, aber er hat eine andere Perspektive.

Stufe 3: Prüfung. Ein dritter Agent überprüft das Ergebnis. Er fragt: Was könnte man aus Sicherheitsperspektive verbessern? Wo sind potenzielle Schwachstellen?

Das klingt aufwendiger, als es ist. In der Praxis läuft vieles davon automatisiert. Ich stoße den Prozess an und bekomme am Ende einen Report, den ich durchgehe.

Der entscheidende Unterschied: Wo ich selbst hinschaue

Bei unkritischen Bereichen reicht mir, was die spezialisierten Agenten identifizieren.

Bei kritischen Bereichen ist das Agenten-Review nur die erste Runde. Die zweite Runde mache ich selbst.

Das bedeutet konkret: Ich lese den Code. Ich hinterfrage die Architekturentscheidungen. Ich überlege, welche Edge Cases nicht abgedeckt sind. Ich gleiche ab, ob das, was da steht, zu meinem mentalen Modell des Systems passt.

Das ist der Human-in-the-Loop, von dem alle reden. Nur dass er eben nicht bei jeder Zeile Code greift, sondern gezielt dort, wo es darauf ankommt.

Vorgaben von Anfang an

Ein Bereich, in dem sich der agentenbasierte Ansatz besonders bewährt. Statt Anforderungen nachträglich zu prüfen, bette ich sie von Anfang an in den Entwicklungsprozess ein.

Das funktioniert über Guidelines – Markdown-Dateien, die beschreiben, welche Regeln gelten. Diese Guidelines fließen in die Spezifikations- und Planungsphase ein. Die Agenten kennen sie und berücksichtigen sie.

Anschließend lasse ich spezialisierte Agenten Reviews durchführen und Reports erstellen. Diese Reports gehe ich durch, hinterfrage kritisch, führe meine eigene Analyse durch und gleiche ab. Wenn Probleme auftauchen, lasse ich sie durch die Agenten beheben und stoße dann ein erneutes Review an.

Es ist ein iterativer Prozess. Aber einer, der Compliance by Design ermöglicht, statt sie als nachträglichen Kontrollschritt zu behandeln.

Die Bilanz: Ähnliche Probleme, andere Dynamik

Produzieren Agenten mehr technische Schulden als Menschen? Nach meiner Erfahrung: Nein. Es sind dieselben Probleme – nur schneller sichtbar.

Wenn eine Codebasis wächst, entsteht duplizierter Code. Nicht, weil die Agenten schlecht arbeiten, sondern weil ihnen der Gesamtüberblick fehlt. Ein erfahrener Entwickler, der seit Monaten an einem Projekt arbeitet, weiß implizit, dass es schon eine Utility-Funktion für diesen Fall gibt. Ein Agent sieht nur den aktuellen Kontext.

Das ist kein Argument gegen Agenten. Es ist ein Argument für iterative Zyklen.

Mein Vorgehen: Erst die Funktionalität, dann das Aufräumen. Ich lasse entwickeln, schaue, dass es funktioniert, und starte dann eine neue Runde, in der ich gezielt auf Code-Qualität achte. Dafür nutze ich einen Subagent, der sich auf Refactorings spezialisiert hat – er analysiert, identifiziert Duplikate, schlägt Zusammenführungen vor.

Dieses Vorgehen ist nicht neu. Es ist das, was erfahrene Entwickler schon immer gemacht haben: Erst zum Laufen bringen, dann aufräumen. Wer versucht, von Anfang an hundertprozentig sauberen Code zu schreiben, verzettelt sich und blockiert sich selbst.

Der Unterschied: Mit Agenten passiert beides schneller. Die technischen Schulden entstehen schneller – aber sie werden auch schneller sichtbar und schneller abgebaut.

Was Agenten gut können – und was nicht

Nach Monaten intensiver Arbeit mit diesem Setup habe ich ein klareres Bild davon, wo die Stärken und Grenzen liegen.

Agenten schreiben exzellenten Code im Kleinen. Eine einzelne Funktion, ein Modul, eine Komponente – das bekommen sie auf dem Niveau eines erfahrenen Entwicklers hin. Saubere Struktur, gute Benennung, Best Practices.

Was ihnen fehlt, ist der Systemüberblick. Sie sehen nicht, wie die Teile zusammenhängen. Sie wissen nicht, dass die Entscheidung in Modul A Auswirkungen auf Modul B hat, wenn das nicht explizit im Kontext steht.

Das liegt in der Natur der Sache: Eine KI kann nur aus dem verstehen, was ihr als Kontext gegeben wird. Ein erfahrener Entwickler hat das Gesamtsystem im Kopf – auch die Teile, die er nie explizit aufgeschrieben hat.

Der Skill-Shift

Diese Erkenntnis hat Konsequenzen für die Art, wie ich arbeite.

Früher konnte vieles implizit bleiben. Ich wusste, wie das System funktioniert, und musste es niemandem erklären. Jetzt muss ich es externalisieren – durch Spezifikationen, Guidelines, Architektur-Dokumentation. Was früher im Kopf bleiben konnte, muss jetzt explizit werden.

Das ist mehr Arbeit. Aber es ist bessere Arbeit. Denn was ich für die Agenten aufschreibe, hilft auch anderen Teammitgliedern. Also den Menschen1. Es zwingt mich, meine Entscheidungen zu artikulieren, statt sie vorauszusetzen.

Der Shift, den ich beobachte, ist real:

Weniger „wie schreibe ich diesen Code”, mehr „wie lenke ich die Agenten”. Das bedeutet nicht, dass Programmierkenntnisse unwichtig werden. Es bedeutet, dass sie nicht mehr ausreichen.

Was jetzt zählt:

• Systemdesign auf höherer Ebene: Architektur, Schnittstellen, Datenmodelle

• Sicherheitsdenken: Wo sind die Angriffsflächen, was muss besonders geschützt werden

• Agenten-Orchestrierung: Wie koordiniere ich verschiedene spezialisierte Agenten, wie definiere ich Richtlinien, wie behalte ich die Kontrolle

• Kritisches Prüfen: Wann vertraue ich dem Output, wann schaue ich selbst hin

Die Antwort auf die ursprüngliche Frage

Wer kontrolliert die Agenten? Ich. Aber nicht bei jeder Zeile Code.

Ich kontrolliere durch Struktur: spezialisierte Agenten, die sich gegenseitig prüfen. Ich kontrolliere durch Fokus: menschliche Reviews dort, wo der Schaden am größten wäre. Ich kontrolliere durch Iteration: Entwickeln, prüfen, aufräumen, wiederholen.

Und ich kontrolliere durch Akzeptanz: Die Einsicht, dass kein Prozess perfekt ist – weder mit Agenten noch ohne. Dass technische Schulden entstehen und abgebaut werden müssen. Dass Fehler passieren und gefunden werden müssen.

Der Unterschied ist nicht, dass Agenten fehlerfreien Code produzieren. Der Unterschied ist, dass ich mehr produziere und schneller iteriere. Und dass ich meine Zeit dort einsetze, wo sie den größten Unterschied macht: bei den Entscheidungen, die ein System sicher oder unsicher, wartbar oder unwartbar machen.

Das ist keine Zukunftsvision. Das ist mein Alltag seit Monaten. Und bisher funktioniert es.

Deshalb ist es so spannend sich gegenseitig auszutauschen und zu hören, wie andere konzeptionell an die KI-gestützte Softwareentwicklung herangehen.

Denn letztendlich war es schon immer der richtige Lösungsansatz, der den eigentlichen Mehrwert liefert. Wenn man weiß, wie man ein Problem lösen kann, ist die anschließende Umsetzung fast trivial.

Zudem wird immer deutlicher, dass testgetriebene Entwicklung wichtiger denn je ist:

1. Tests dienen als Leitplanken, die eine Beschreibung des Ziels liefern.

2. Tests dienen als Feedback-Schleife. Agenten können sie eigenständig ausführen und erhalten dadurch Feedback, wie gut sie ihre Aufgaben erfüllt haben.

→ Agenten können autonom und iterativ weiterarbeiten, bis das Ergebnis die Erfolgskriterien erfüllt.

3. Und wie sonst will man bei jeder Iteration die Korrektheit von so viel Code prüfen?

The discussion about agentic coding fluctuates between two extremes: “AI will solve everything” on the one hand, “It’s all just hype” on the other.

Both positions fall short. After months of intensive work with coding agents, I would like to share with you what I have learned in the process – and how my way of working has changed.

The current state of affairs: 7 theses

Before I get to my own specific experiences, here are 7 core theses written by Simon Wardley, which I have supplemented with my own perspective:

Development is not yet engineering. While testing has become a systematic discipline through practices such as TDD, development remains largely intuition-driven. There are patterns, but no consistent system. Agentic coding could be a catalyst for this transformation, if we approach it correctly.

Small, contextual tools beat monoliths with LLM on top. The prevailing approach of simply enriching existing systems with LLM capabilities does not exploit the potential. More effective are combinable tools with clear inputs, outputs, and specific application contexts.

LLMs are coherence machines, not truth machines. They optimize for plausibility, not correctness. This makes them valuable for drafting and exploration, but unreliable for final decisions without human validation.

Code is more than functionality – structure is the real decision. Architectural decisions manifest themselves in code. LLMs can generate functionality, but structural decisions require an understanding of the system.

The key question: Where do humans stand in the decision-making process? It’s not about whether AI is used, but where human judgment remains indispensable. This boundary must be drawn consciously.

Practices are still evolving. What is considered state of the art today may be obsolete tomorrow. Beware of hasty best practices.

Experimentation is fine, but with an awareness of the terrain. Speed without direction is just getting lost quickly.

My approach today

These theories align well with my experiences. However, theory is one thing and daily practice is another. Here’s what works for me.

A deliberately modular setup

I don’t like working with fully integrated solutions. Not on principle, but because they don’t work optimally for my workflow.

My setup consists of three components:

1. An IDE, such as IntelliJ IDEA, which allows me to keep track of the code. I can quickly check where everything is located. Git integration is extremely important here — it makes changes traceable and reversible. IntelliJ can do almost everything I need, including inspecting databases. Unfortunately, with power comes complexity. For smaller projects, I prefer the ZED editor because it’s more streamlined and intuitive.

2. I use the terminal (preferably Ghostty) with my coding agent, which is currently mainly Claude Code. There, I give instructions, observe, and control.

3. I use an LLM chat window for conceptual work. At the beginning of a project, I use it to work through ideas and organize them in a document before writing code.

This three-way split is no coincidence. It corresponds to the principle of specialized tools: each component has its strengths, none tries to be everything.

I use other specialized tools here and there, such as the GitHub Desktop app. But at its core, these three tools are the ones I use.

Sub-agents as the key

Perhaps the most important lesson learned in recent months is that specialized sub-agents deliver significantly better results than general-purpose agents. The reason is simple—the tailored context makes all the difference.

Two examples from my experience:

Quality assurance: A sub-agent exclusively responsible for quality assurance checks against specified guidelines and documentation. It does not advise; it validates. This is essentially TDD thinking at the agent level — explicit standards instead of intuition.

UI design: I achieve significantly better results when designing user interfaces with a specialized design sub-agent. I specify the direction the design should take and which design principles apply. The agent generates designs within these guidelines instead of working in a vacuum.

In both cases, the lever is the specialized context and the focused system prompt of the sub-agent, not the general intelligence of the model.

Validating coherence

Yes, LLM output has misled me before. In fact, it was precisely because it sounded plausible. The coherence was there, but the truth was not.

My validation process is two-stage. First, I verify what I can myself. For everything else, I use specialized sub-agents with internet access that can verify facts. However, it’s crucial to note that ultimately, humans remain responsible. The sub-agents are tools, not decision-makers.

Hallucinations don’t like to stay alone. Where one thing is wrong, other things are often invalid.

Keeping an eye on structure

When does generated code become problematic? Most obviously, when source code files become too large. There are too many lines. Too much functionality in individual functions.

My approach: I let almost everything be generated. If I want to make changes, I let the agent adapt and then check it. Experience shows that this is faster than writing it myself, unless the changes are minor restructuring or corrections. In that case, I intervene directly.

However, I am responsible for the structure. I decide when a file becomes too large, when functionality needs to be split up, and what the architecture and refactorings should look like. I usually define the architecture before coding begins and document it in Markdown files.

The real problem is communication

Ultimately, humans must decide if what has been generated is good enough. Human judgment is indispensable because only humans can determine if they have received what they wanted.

Here lies an uncomfortable truth: Even with AI, the problem is often communication. The question is not “Can AI do that?” but “Can I articulate what I want?” This is not a new insight—anyone who has ever written requirements knows this. But with Agentic Coding, it becomes immediately apparent.

Not balance, but a pendulum

Is there a perfect balance between trying things out quickly and understanding what I’m doing? I don’t think so. It’s more like swinging back and forth.

I try out ideas to see if they lead to reasonable results. At the latest, I need to understand what I’m doing when I’m convinced of the direction and want to check its viability for the future.

That’s more honest than any best practice. Practices are still evolving. Anyone who claims to have found the optimal workflow today will be working differently in six months.

The open question

The core architectural question of our time remains: Where do we place people in the decision-making process?

This is not a technical question. It is a question of organization, responsibility, and design. Every organization must answer it for itself—consciously, rather than implicitly through tool adoption.

As of today, my answer is: People decide on the structure, validate the results, and take responsibility. Agents generate, specialize, and accelerate. The boundary is not fixed; it shifts with every learning experience.

That is precisely what makes this such an interesting time.

Die Diskussion um Agentic Coding schwankt zwischen zwei Extremen: “AI wird alles lösen” auf der einen Seite, “Alles nur Hype” auf der anderen.

Beide Positionen greifen zu kurz. Nach Monaten intensiver Arbeit mit Coding-Agents möchte ich mit euch teilen, was ich dabei gelernt habe – und wie sich meine Arbeitsweise verändert hat.

Der aktuelle Stand: 7 Thesen

Bevor ich zu meinen konkreten, eigenen Erfahrungen komme, hier 7 Kernthesen, zu denen Simon Wardley geschrieben hat und die ich durch meine Perspektive ergänzt habe:

Entwicklung ist noch kein Engineering. Während Testing durch Praktiken wie TDD zu einer systematischen Disziplin geworden ist, bleibt die Entwicklung zum größten Teil intuitions-getrieben. Es gibt Patterns, aber keine durchgängige Systematik. Agentic Coding könnte ein Katalysator für diese Transformation sein – wenn wir es richtig angehen.

Kleine, kontextuelle Tools schlagen Monolithen mit aufgesetztem LLM. Der vorherrschende Ansatz, bestehende Systeme einfach mit LLM-Fähigkeiten anzureichern, nutzt das Potenzial nicht aus. Effektiver sind kombinierbare Tools mit klaren Inputs, Outputs und spezifischem Anwendungskontext.

LLMs sind Kohärenz-Maschinen, keine Wahrheits-Maschinen. Sie optimieren auf Plausibilität, nicht auf Korrektheit. Das macht sie wertvoll für Entwürfe und Exploration, aber unzuverlässig für finale Entscheidungen ohne menschliche Validierung.

Code ist mehr als Funktionalität – Struktur ist die eigentliche Entscheidung. Architektonische Entscheidungen manifestieren sich im Code. LLMs können Funktionalität generieren, aber strukturelle Entscheidungen erfordern Systemverständnis.

Die Kernfrage: Wo stehen Menschen im Entscheidungsprozess? Es geht nicht darum, ob AI eingesetzt wird, sondern wo menschliches Urteil unverzichtbar bleibt. Diese Grenzziehung muss bewusst getroffen werden.

Die Praktiken sind noch im Entstehen. Was heute als State of the Art gilt, kann morgen überholt sein. Vorsicht vor vorschnellen Best Practices.

Experimentieren ja, aber mit Bewusstsein für das Terrain. Geschwindigkeit ohne Richtung ist nur schnelles Verirren.

Wie ich es heute angehe

Diese Thesen decken sich gut mit meinen Erfahrungen. Aber Theorie ist das eine, die tägliche Praxis das andere. Hier ist, was bei mir funktioniert.

Ein bewusst modulares Setup

Ich arbeite ungern mit komplett integrierten Lösungen. Nicht aus Prinzip, sondern weil sie nicht optimal für meinen Workflow funktionieren.

Mein Setup besteht aus drei Komponenten:

1. Eine IDE wie IntelliJ IDEA, weil ich hier den Überblick über den Code behalten kann. Schnell prüfen, wo was untergebracht ist. Die Git-Integration ist dabei eminent wichtig – sie macht Änderungen nachvollziehbar und reversibel. IntelliJ kann nahezu alles (inkl. Datenbanken inspizieren), was ich brauche. Leider kommt mit Mächtigkeit eine gewisse Unübersichtlichkeit. Für kleinere Projekte nutze ich gerne den ZED-Editor, der schlanker und übersichtlicher ist.

2. Das Terminal (am liebsten Ghostty) mit meinem Coding-Agent, aktuell hauptsächlich Claude Code. Hier gebe ich Anweisungen, beobachte und steuere.

3. Ein LLM-Chat-Fenster für die konzeptionelle Arbeit. Gerade am Anfang eines Projekts nutze ich es, um Ideen durchzuarbeiten und in ein Dokument zu bringen, bevor Code entsteht.

Diese Dreiteilung ist kein Zufall. Sie entspricht dem Prinzip der spezialisierten Tools: Jede Komponente hat ihre Stärke, keine versucht alles zu sein.

Hier und da nutze ich noch andere spezialisierte Tools, wie die GitHub Desktop App. Aber im Kern sind es diese drei, die ich benutze.

Sub-Agents als Schlüssel

Das vielleicht wichtigste Learning der letzten Monate: Spezialisierte Sub-Agents liefern deutlich bessere Ergebnisse als ein General-Purpose-Agent für alle Aufgaben. Der Grund ist simpel – der zugeschnittene Kontext macht den Unterschied.

Zwei Beispiele aus meiner Praxis:

Qualitätssicherung: Ein Sub-Agent, der ausschließlich für QA zuständig ist, prüft gegen vorgegebene Richtlinien und Dokumentationen. Er rät nicht, er validiert. Das ist im Grunde TDD-Denken auf Agent-Ebene – explizite Standards statt Intuition.

UI-Design: Bei der Gestaltung von Benutzeroberflächen erziele ich mit einem spezialisierten Design-Sub-Agent wesentlich bessere Ergebnisse. Ich kann Vorgaben machen, in welche Richtung das Design gehen soll, welche Designprinzipien gelten. Der Agent generiert innerhalb dieser Leitplanken, statt im luftleeren Raum zu arbeiten.

In beiden Fällen ist der spezialisierte Kontext und der fokussierte Systemprompt des Sub-Agents der Hebel, nicht die allgemeine Intelligenz des Modells.

Kohärenz validieren

Ja, LLM-Output hat mich schon in die Irre geführt. Tatsächlich gerade weil er plausibel klang. Die Kohärenz war da, die Wahrheit nicht.

Meine Validierung läuft zweistufig: Ich prüfe erst einmal selbst, was ich prüfen kann. Für alles andere nutze ich spezialisierte Sub-Agents mit Internetzugriff, die Fakten verifizieren können. Aber – und das ist entscheidend – schlussendlich bleibt der Mensch verantwortlich. Die Sub-Agents sind Hilfsmittel, keine Entscheider.

Und Halluzinationen bleiben nicht gerne allein. Da, wo eine Sache nicht stimmt, sind oft andere Dinge nicht valide.

Struktur im Blick behalten

Wann wird generierter Code zum Problem? Am offensichtlichsten, wenn Source-Code-Files einfach zu groß werden. Zu viele Zeilen. Zu viel Funktionalität in einzelnen Funktionen.

Mein Ansatz: Ich lasse fast alles generieren. Wenn ich Änderungen will, lasse ich die Agent anpassen und überprüfe anschließend. Die Erfahrung zeigt, dass das schneller geht als selbst zu schreiben – es sei denn, es sind kleinere Umstrukturierungen oder Korrekturen. Da greife ich direkt ein.

Die Struktur aber bleibt meine Verantwortung. Ich entscheide, wann ein File zu groß wird, wann Funktionalität aufgeteilt werden muss, wie Refactorings aussehen sollen und die Architektur sein soll. Gerade die Architektur lege ich meist fest, bevor das Codieren beginnt, und dokumentiere sie in Markdown-Dateien.

Das eigentliche Problem ist Kommunikation

Schlussendlich muss der Mensch die Entscheidung treffen, ob das Generierte gut genug ist. Das menschliche Urteil bleibt unverzichtbar, weil nur der Mensch beurteilen kann, ob er bekommen hat, was er wollte.

Und hier liegt eine unbequeme Wahrheit: Auch mit KI ist das Problem häufig die Kommunikation. Nicht “kann die KI das?”, sondern “kann ich artikulieren, was ich will?”. Das ist keine neue Erkenntnis – jeder, der je Requirements geschrieben hat, kennt das. Aber mit Agentic Coding wird es unmittelbar spürbar.

Keine Balance, sondern ein Pendel

Gibt es eine perfekte Balance zwischen schnell ausprobieren und verstehen, was ich tue? Ich glaube nicht. Es ist eher ein Hin- und Herschwingen.

Manche Ideen probiere ich einfach aus, um zu sehen, ob sie zu einem vernünftigen Ergebnis führen. Verstehen, was ich tue, muss ich spätestens dann, wenn ich von der Richtung überzeugt bin – und prüfen will, ob sie tragfähig für die Zukunft ist.

Das ist ehrlicher als jede Best Practice. Die Praktiken entwickeln sich noch. Wer heute behauptet, den optimalen Workflow gefunden zu haben, wird in sechs Monaten anders arbeiten.

Die offene Frage

Die architektonische Kernfrage unserer Zeit bleibt: Wo platzieren wir Menschen im Entscheidungsprozess?

Das ist keine technische Frage. Es ist eine Frage der Organisation, der Verantwortung, des Designs. Jede Organisation muss sie für sich beantworten – bewusst, nicht durch Tool-Adoption implizit.

Meine Antwort, Stand heute: Der Mensch entscheidet über Struktur, validiert Ergebnisse, trägt Verantwortung. Die Agents generieren, spezialisieren, beschleunigen. Die Grenze ist nicht fix, sie verschiebt sich mit jedem Learning.

Und genau das macht diese Zeit so interessant.

Dann dreht er sich zur Kamera.

Kein Augenkontakt – nur ein schwarzes Antlitz mit ein paar blinkenden Lichtern. Keine Mimik, kein Lächeln, keine Unsicherheit. Nur Absicht.

Ich denke an C-3PO. An seine zappeligen, fast schusseligen Bewegungen, die ihn harmlos machten. An R2-D2, der piepste und gegen Wände fuhr. Figure 03 macht nichts davon. Er ist kompetent. Präzise. Und genau das, gerade das, fühlt sich falsch an.

Faszinierend. Beeindruckend. Und trotzdem irgendwie ... unheimlich. Vielleicht habe ich zu viele dystopische Filme gesehen. Oder mein Instinkt sagt mir etwas, das ich ernst nehmen sollte.

Denn Figure 03 ist nicht der erste humanoide Roboter. Aber er ist der erste, der explizit dafür gebaut wurde, in meinem Zuhause herumzulaufen. Und das macht einen Unterschied.

Der Unterschied: Verletzlichkeit

Warum fühlt sich Figure 03 anders an als all die anderen smarten Geräte, mit denen wir längst leben?

Alexa und Siri hören zu. Sie sammeln Daten, analysieren unsere Gewohnheiten, kennen unsere Stimmen. Aber sie stehen in einer Ecke. Wir wissen, wo sie sind. Wir haben gelernt, damit zu leben — oder es zu verdrängen.

Staubsauger-Roboter bewegen sich durch unsere Wohnungen, tauchen unter Sofas, kartografieren unsere Räume. Aber sie sind offensichtlich dumm. Sie sind simpel und vorhersehbar. Wenn sie gegen die Wand fahren, lachen wir. Keine Bedrohung, weil sie so eindeutig Maschine sind.

Figure 03 ist anders. Er ist autonom und entscheidet selbst, wohin er geht. Er kann eigenständig handeln: Türen öffnen, Dinge greifen, die Umgebung aktiv verändern. Und er ist allgegenwärtig. Er ist nicht nur für das Wohnzimmer gedacht, sondern für alle Räume: Küche, Schlafzimmer, Bad. Dort, wo wir am verletzlichsten sind.

Das Problem ist nicht die Technologie. Das Problem ist, dass Figure 03 in Räumen agiert, in denen wir am verletzlichsten sind: während wir schlafen, streiten, weinen, nackt durchs Bad laufen.

Wir haben keine evolutionären Instinkte dafür, wie man mit einem autonomen, beobachtenden, handlungsfähigen Ding im eigenen Schlafzimmer umgeht.

Wir haben gelernt, damit zu leben, dass Google mehr über uns weiß als unsere Mutter. Dass Social-Media-Plattformen unsere Stimmungen erkennen, bevor wir sie selbst bemerken. Aber das passiert irgendwo da draußen, in der Cloud, abstrakt.

Figure 03 ist nicht abstrakt. Er steht neben deinem Bett. Mit seinem schwarzen Antlitz. Keine Seele dahinter. Und er geht langsam, sehr langsam, zur Tür.

Das eigentlich Beunruhigende

Aber hier kommt das eigentlich Beunruhigende: In fünf, vielleicht zehn Jahren wird das alles normal sein. Figure 03, oder sein Nachfolger, wird so selbstverständlich sein wie heute ein Smartphone. Und genau das sollte uns mehr zu denken geben als die Technologie selbst.

Die Entwicklung beschleunigt sich rasant. Figure 01, 02, 03 – innerhalb kürzester Zeit. Parallel dazu die Sprünge bei Large Language Models: GPT-3, GPT-4 und -5, Claude, Gemini.

Wir haben uns so an exponentiellen Fortschritt gewöhnt, dass wir bereits enttäuscht sind, wenn die nächste Verbesserung ein paar Monate länger braucht oder nicht sofort offensichtlich ist. Die Science Fiction von vor zehn Jahren ist heute Produktankündigung. Und wir zucken kaum noch.

Vor 20 Jahren hätten wir es für absurd gehalten, dass Konzerne unsere Bewegungsprofile haben. Dass sie vorhersagen können, wann wir schwanger sind, depressiv werden oder den Job wechseln.

Heute? Achselzucken: “Was soll man machen?”

Gewöhnung ist jedoch kein neutraler Prozess. Wenn wir uns an Technologie gewöhnen, verlieren wir die Fähigkeit, die grundlegende Frage zu stellen:
„Will ich das wirklich?”

Stattdessen wird die Frage lauten: „Warum hast du noch keinen?”

In zehn Jahren wird jemand, der Figure 03 ablehnt, vielleicht klingen wie jemand, der heute „kein Internet” will – weltfremd, rückständig, irrational.

Es geht nicht nur um Technologie. Es geht um die Frage:

• Wohin wollen wir als Menschen?

• Welche Art von Zuhause wollen wir haben?

• Welche Art von Beziehungen – zu uns selbst, zu anderen Menschen, zu den Dingen, die uns umgeben?

Diese Fragen werden nicht durch Produktankündigungen beantwortet, sondern durch unsere Entscheidungen. Aber nur, wenn wir sie noch stellen, bevor sie irrelevant werden.

Der Hersteller weiß das. Figure 03 hat waschbare Kleidung, sanfte Materialien, wireless charging. Die Design-Entscheidungen sind nicht zufällig. Sie wollen, dass wir ihn als Mitbewohner und nicht als Maschine sehen. Und die Chancen dafür stehen gut, denn der Nutzen ist groß.

Die Frage bleibt

Würde ich Figure 03 in mein Zuhause lassen?

Ehrlich gesagt, weiß ich es nicht.

Die Technologie ist beeindruckend. Die Möglichkeiten sind verlockend. Vielleicht ist mein Unbehagen aber auch nur eine irrationale Reaktion auf zu viele dystopische Filme.

Aber vielleicht ist es auch das Letzte, was uns noch sagt:
„Halt. Warte. Denk nochmal nach.”

Bevor wir es normalisieren. Bevor die Frage nicht mehr lautet, ob wir es wollen, sondern warum wir es nicht haben.

Frag mich in fünf Jahren nochmal – vielleicht finde ich die Frage dann absurd. Vielleicht habe ich mich dann daran gewöhnt, in dieses schwarze Antlitz zu schauen.

Oder es ist längst ein Gesicht. Und das wäre vielleicht noch unheimlicher.

Quelle des Videos: Introducing Figure 03 https://www.figure.ai/news/introducing-figure-03

Verteilung der Arbeitszeit

• Aktives Codieren: Laut einer Analyse von Software.com verbringen Entwickler im Durchschnitt nur etwa 52 Minuten pro Tag mit aktivem Codieren, was etwa 10 % ihrer Arbeitszeit entspricht .

• Anwendungsentwicklung: Eine IDC-Studie aus dem Jahr 2024 ergab, dass Entwickler etwa 16 % ihrer Zeit mit der Entwicklung von Anwendungen verbringen. Der Großteil ihrer Zeit fließt in operative und unterstützende Aufgaben wie CI/CD-Prozesse, Sicherheitsmaßnahmen und Performance-Monitoring .

• Meetings: Eine Studie von Clockwise zeigt, dass Entwickler durchschnittlich ein Drittel ihrer Arbeitszeit in Meetings verbringen. Zusätzlich fallen etwa 6,3 Stunden pro Woche auf fragmentierte Zeit, in der keine konzentrierte Arbeit möglich ist .

• Code-Wartung: Laut einer Umfrage von Tidelift verbringen Entwickler durchschnittlich 30 % ihrer Zeit mit der Wartung von Code, einschließlich der Pflege von Open-Source-Komponenten .

Weitere Tätigkeiten

Neben dem Codieren sind Entwickler mit einer Vielzahl anderer Aufgaben beschäftigt, darunter:

• Debugging: Embedded-Entwickler verbringen etwa 40 % ihrer Zeit mit dem Debuggen von Code .

• Kommunikation: Studien zeigen, dass Entwickler mehr als 50 % ihrer Zeit mit Kommunikation verbringen, während das eigentliche Programmieren nur etwa 10 % bis 15 % ihrer Zeit ausmacht .

• Anwendungsprobleme: Eine Studie von Cisco ergab, dass Entwickler über die Hälfte ihrer Arbeitszeit (57 %) mit der Behebung von Performance-Problemen in bestehenden Anwendungen verbringen .

Fazit

Die Vorstellung, dass Entwickler den Großteil ihrer Zeit mit dem Schreiben von Code verbringen, entspricht nicht der Realität. Vielmehr sind sie in zahlreiche andere Aufgaben eingebunden, die für den Entwicklungsprozess ebenso entscheidend sind. Dies unterstreicht die Bedeutung eines ganzheitlichen Verständnisses von Entwicklerproduktivität, das über das reine Codieren hinausgeht.

Quellen:

• https://www.software.com/reports/code-time-report

• https://www.infoworld.com/article/3831759/developers-spend-most-of-their-time-not-coding-idc-report.html

• https://www.heise.de/news/Softwareentwickler-verbringen-ein-Drittel-ihrer-Arbeitszeit-in-Meetings-7236712.html

• https://www.sonarsource.com/blog/developers-spend-30-of-their-time-on-code-maintenance-our-latest-survey-results-part-3/

• https://en.wikipedia.org/wiki/Software_Peter_principle

• https://ap-verlag.de/entwickler-verbraten-ueber-die-haelfte-ihrer-arbeitszeit-fuer-das-beheben-von-anwendungsproblemen/88394/

Wenn du Verantwortung trägst – als Führungskraft, Designer:in, Produktmensch oder Engineer – und wissen willst, wo es bei euch wirklich klemmt, dann lade ich dich ein:

Mach statt Retro mal ein Value Stream Mapping.

PS: Vielleicht fragt sich jetzt der eine oder andere: "Aber wie genau funktioniert dieses Value Stream Mapping bei Software-Teams?"

Im Kern geht es darum, den kompletten Weg einer Anforderung - vom ersten Gedanken bis zur Nutzung durch den Kunden - zu visualisieren.

Das Besondere: Wir messen nicht nur die aktive Arbeitszeit, sondern auch die Wartezeit zwischen den Schritten.

Bei einem Team zeigte sich: Von 21 Tagen Durchlaufzeit waren nur 3 Tage tatsächliche Arbeitszeit. Der Rest? Warten und Blockaden.

Diese Transparenz verändert vieles.

In diesem 15-minütigen Deep Dive1 geht es darum,

1. welche Probleme die Produktivität in der Softwareentwicklung ausbremsen und

2. was Sie dagegen tun können.

Der Dialog zeigt auf, welche konkreten Schritte Sie unternehmen können, um Herausforderungen wie diesen zu begegnen:

1. Kommunikation & Zusammenarbeit: warum selbst erfahrene Teams in Silos arbeiten

• Silo-Denken zwischen Entwicklung und Operations

• Teams arbeiten in "getrennten Welten"

• Mangelnde Kommunikation führt zu Missverständnissen

• Konflikte zwischen Teams

2. Kultur & Mindset: wie eine Kultur der Schuldzuweisung echtes Lernen und ‘Continuous Improvement’ verhindert und

• Angst vor Fehlern

• Kultur der Schuldzuweisung statt Lernkultur

• Widerstände gegen Veränderungen

• Klammern an alten Gewohnheiten

3. Führung & Kontrolle: warum zu viel Kontrolle die Leistung senkt

• Angst der Führungskräfte vor Kontrollverlust

• Zu viele detaillierte Anweisungen von oben

• Mangelnde Autonomie der Teams

• Fehlendes Vertrauen in Team-Fähigkeiten

4. Performance & Effizienz:

• Langsame Release-Zyklen

• Verzögerungen in der Entwicklung

• Qualitätsprobleme in der Software

• Leistung bleibt hinter Erwartungen zurück

Hören Sie, wie DevOps Coaching diese Herausforderungen angeht - als nachhaltiger Weg zu besserer Zusammenarbeit und besseren Ergebnissen.

Für alle, die verstehen wollen, warum es nichts bringt, einfach nur neue Tools einzuführen, um eine bessere Teamleistung zu erreichen.

A distinction is often not made in everyday language:

This is a complex problem.

It's a complicated system.

Some people use complex as the intensified form of complicated. A complex problem would then be a more complicated problem.

A fundamental difference

The difference between a complex system and a complicated system is of a fundamental nature.

It is not a quantitative difference, but a qualitative one. This is because they behave differently. The complicated system is predictable, the complex system is unpredictable and reacts unexpectedly to changes.

What is complicated?

Complicated is a system that is difficult to get an overview of. Nevertheless, the complicated system can be understood by analyzing the individual parts.

For example, a mixing console is not immediately obvious to the layman. But with the help of a specialist or an instruction manual, you can learn to understand the functions.

Photo by chuttersnap

Complicated therefore has something to do with not knowing and a lack of comprehensibility.

Complexity is the measure of our ignorance. A problem (or: "unignorable event") is complicated because we do not understand it. Because we lack knowledge. This can be remedied by cramming or acquiring knowledge.

Roberto Poli writes:

„Complicated problems originate from causes that can be individually distinguished; they can be addressed piece­-by-­piece; for each input to the system there is a proportionate output; the relevant systems can be controlled and the problems they present admit permanent solutions.“

Solutions can be found for complicated systems that will work again and again and deliver the same effect. The solutions are reproducible.

Teilen

Complex

Complexity means unpredictability. Complexity is the measure of the number of surprises you have to reckon with.

There is no simple cause-and-effect relationship. The influencing factors can influence or even reverse each other through interactions and feedback effects.

Complex means:

Outputs are not proportional or linear to inputs; small changes in one part of the system can cause unexpected outputs in other parts of the system or a system-wide reorganization.

Photo by H Shaw

Complex systems such as organizations can behave completely differently despite the same measures. The same solution that worked for one system may fail completely elsewhere. Solutions are not transferable.

Complexity is like the weather. There is nothing wrong with it. It's just bad not to be prepared for it. — »Komplexithoden«

Examples for complex systems:

• the earth's global climate

• social and economic organizations (such as companies and cities)

• Ecosystems

Roberto Poli adds:

„Complex problems and systems result from networks of multiple interacting causes that cannot be individually distinguished; must be addressed as entire systems, that is they cannot be addressed in a piecemeal way; they are such that small inputs may result in disproportionate effects; the problems they present cannot be solved once and for ever, but require to be systematically managed and typically any intervention merges into new problems as a result of the interventions dealing with them.“

Surprisingly, most systems are complex in nature. Only complicated systems are the exception.

Various solution approaches

The solution to a complex problem cannot be approached in the same way as the solution to a complicated problem. They require different solution strategies.

Complicated systems can be analyzed and predictions can be made about the behavior of the system. Experts can help with this. Solutions can be reused.

Complex systems, on the other hand, defy an understanding of the overall relationships, as the factors influence each other.

„The distinction between complicated and complex systems is of immense importance, yet it is often overlooked. Decision-makers commonly mistake complex systems for simply complicated ones and look for solutions without realizing that ‘learning to dance’ with a complex system is definitely different from ‘solving’ the problems arising from it.“

If you handle complex things as if they were complicated, you are doomed to failure.

Complexity means that there can be a certain degree of control; but it is not complete control, the situation is not fully controllable. By recognizing patterns, some relationships can be understood.

In a complex environment, you cannot expect a comprehensive plan or strategy to work as intended. An approach of trying, learning and adapting is more likely to get you further. Mistakes can be made and risks can be taken.

However, you shouldn't make big bets on large projects or invest too much in comprehensive plans, but instead constantly learn in small steps and make appropriate adjustments.

Jetzt abonnieren

— Martin Gross

Ich habe es definitiv.

Doch die Animation von Beau Janzen zeigt, dass es tatsächlich geht und ist beeindruckend. Ich konnte mir vorher nicht vorstellen, wie das gehen könnte.

Aber schaut erst einmal selbst:

@reason4mathDrilling a triangular hole. Yes, I know there logistical issues is making this work, but this is intended as a fun geometric breakdown. I’m creating all this work on my own, so if you like my content and would like to see more, I’d appreciate your support. In my bio, you can leave a tip in my Linktree. Thanks! #drill #triangle #hole #geometry #geometryart #math #maths #engineering #satisfying #satisfyingvideo #originalanimation #mathtok #stemtok

Tiktok failed to load.

Enable 3rd party cookies or use another browser

Um besser zu verstehen, warum diese Animation — neben der Tatsache, dass sie das Bohren eines dreieckigen Lochs zeigt — so faszinierend ist, habe ich sie mir mehrfach angeschaut.

3 Dinge wurden mir erneut bewusst.
3 Dinge, die ich in Zukunft mehr in meine Tätigkeit integrieren möchte:

1. Wir beschränken unser Denken auf das Vertraute, das wir kennen und täglich sehen. Bis uns jemand etwas unvorhergesehenes Neues zeigt. Und dass das, was wir für unmöglich hielten, doch möglich ist.

2. Gute Visualisierungen sind ein hervorragendes Mittel, um neue Problemlösungsansätze für jedermann verständlich zu machen.

3. Anstatt nur die endgültige Lösung zu präsentieren, ist es viel besser, die Menschen von der Machbarkeit einer Lösung zu überzeugen, indem man ihnen den Denkprozess zeigt, der zu dieser Lösung führt.

Lasst euch inspirieren:
Welche 'unmöglichen' Probleme begegnen euch in eurem Alltag oder Beruf?

Wie wäre es, wenn ihr euch heute die Zeit nehmt, eines davon aus einer völlig neuen Perspektive zu betrachten. Zeichnet es auf, diskutiert es mit anderen oder sucht nach unkonventionellen Lösungsansätzen im Internet.

Vielleicht findet ihr euer eigenes 'dreieckiges Loch' und beweist, dass das, was unmöglich erschien doch möglich ist.

Teilt gerne eure Erkenntnisse in den Kommentaren und inspiriert uns, über den Tellerrand zu schauen.

Denn manchmal ist die kreativste Lösung nur einen ungewöhnlichen Ansatz entfernt.

Einen Kommentar hinterlassen

Systematische fehlerhafte Neigungen beim Wahrnehmen, Erinnern, Denken und Urteilen. Sie bleiben meist unbewusst.

Dazu weiss man am Anfang einfach noch viel zu wenig. Wie wird sich das System weiterentwickeln? Was sind zukünftige Nutzerwünsche?

Jetzt abonnieren

1. Anforderungsänderungen
   Während der Entwicklung kann ein neues Geschäftsszenario oder eine neue Benutzeranforderung auftreten, die eine signifikante Änderung der Softwarearchitektur erfordert. Beispielsweise kann eine Änderung, die eine höhere Skalierbarkeit erfordert, Auswirkungen auf die gesamte Systemstruktur haben.

2. Unvorhergesehene technologische Einschränkungen
   Die ursprüngliche Architektur könnte auf Technologien basieren, die sich später als ungeeignet für die Anforderungen erweisen. Dies könnte bedeuten, dass wir die Architektur neu bewerten und möglicherweise stark modifizieren müssen.

3. Unerkannte Interaktionen zwischen Komponenten
   Manchmal kann die Art und Weise, wie verschiedene Teile eines Systems interagieren, unerwartete Probleme verursachen. Dies kann dazu führen, dass wir die Architektur ändern dürfen, um diese Probleme zu beheben.

4. Sicherheitslücken
   In der Softwarearchitektur können unerkannte Sicherheitsprobleme auftreten, die zu schwerwiegenden Sicherheitslücken führen können. Die Behebung solcher Sicherheitslücken kann eine umfassende Überarbeitung der Architektur erfordern.

5. Neue Technologien oder Plattformen
   Die rasche Entwicklung neuer Technologien oder Plattformen kann dazu führen, dass die aktuelle Softwarearchitektur veraltet oder ungeeignet ist und angepasst oder überarbeitet werden muss.

6. Unerwartete Performance-Probleme
   Trotz bester Planung und Testverfahren können Leistungsprobleme auftreten, die schwer vorhersehbar waren, wie z.B. Engpässe unter bestimmten Lastbedingungen.

Nur anpassungsfähige Architekturen sind langfristig überlebensfähig.

Stichwort: Unknown unknowns.

“…there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know.”

– Donald Rumsfeld

Umgebungssysteme verändern sich und wir müssen die Architektur an die veränderten Bedingungen anpassen. Alles andere wird obsolet.

Die " unknown unknowns " zeigen eindrucksvoll, wie unvorhersehbare Elemente die gesamte Softwarearchitektur beeinflussen können. Hier wird deutlich, dass es entscheidend ist, stets die gesamte Architektur im Auge zu behalten. Und nicht nur das, wir müssen uns auf Veränderungen und Unsicherheiten einstellen, die während des gesamten Lebenszyklus der Software auftreten werden.

In der Welt der Softwareentwicklung bedeutet Stillstand Rückschritt. Die uns umgebenden Systeme ändern sich ständig und verlangen von uns, dass wir uns ständig anpassen.

Die Alternative? Unsere Arbeit verliert an Relevanz, wird obsolet.

Zum Glück gibt es Wegweiser, die uns zeigen, wie wir uns in dieser sich ständig verändernden Landschaft bewegen können. Einer dieser Wegweiser ist das Buch "Building Evolutionary Architectures" von Neal Ford und Rebecca Parsons.

Hier einige besonders prägnante Gedanken:

1. Evolutionäre Architektur sieht den Wandel kommen. Es ist unmöglich zu sagen, wann oder wie, aber eines ist sicher: Der Wandel wird kommen, und wir müssen bereit sein.

2. Ein System ist evolutionär, wenn es leicht zu verstehen und sicher zu verändern ist. Das ist leichter gesagt als getan, denn Verständlichkeit bedeutet nicht immer, dass Änderungen einfach umzusetzen sind.

3. Microservices sind eine Möglichkeit, aber nicht die einzige. Auch ein Monolith kann evolutionär sein, wenn er gut strukturiert ist und klar definierte und abgegrenzte Kontexte hat.

4. Conway's Law bietet uns eine Denkweise, wie wir Menschen, Kommunikation und Organisationen zielgerichtet gestalten können.
   Die Architektur passt sich den Kommunikationsstrukturen der Organisation an, daher sollten wir die Organisation an die gewünschte Architektur anpassen. Es ist wichtig, dass wir alle an einem Strang ziehen und das gleiche Zielverständnis haben.

Unabhängig davon, welche Architektur wir entwickeln, sollten wir auf Veränderungen vorbereitet sein. Und das geht nur, wenn das System einfach zu verstehen ist. Microservices sind dafür keine Voraussetzung.

Was wirklich zählt, ist, dass wir alle das gleiche Ziel verfolgen und das gleiche Verständnis haben. Dann können wir sicher navigieren, auch wenn die "unknown unknowns" auf uns zukommen.

Technical debt is often ignored, but it can put your business at risk.

Technical debt seems "to be a key factor in why Southwest Airlines couldn’t return to business as usual. More than 15,000 of its flights were canceled starting on Dec. 22, including more than 2,300 canceled this past Thursday — almost a week after the storm had passed."

Outdated software and technical debt were the main factors in Southwest Airlines' widespread flight cancellations after a winter storm in December 2022, according to an opinion column in The New York Times.

In software development, technical debt is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. (Wikipedia)

Or as the article says "software can be written in a rapid and shoddy way, rather than in a more resilient manner that makes it more dependable and easier to fix or expand. As you might expect, the former is cheaper and quicker."

The cancellations, which stranded hundreds of thousands of passengers, were caused by Southwest's failure to modernize its systems, the column argues.

Photo by DeepMind on Unsplash

There are many signs of an agile company culture, both obvious and subtle. The subtle ones are harder to spot, of course.

When you assess the 5 characteristics, you'll get a better understanding of an organization's level of agility.

And as so often in life, better understanding starts with asking better questions.

Now let's start with the 5 characteristics.

Agile companies ...

1. embrace fast failures.

2. value distributed decision making.

3. create joy in the workplace.

4. release products frequently.

5. inspect and adapt through retrospectives.

Okay, let's delve a little deeper into the details. 👇

Fast failures

Agile Organizations celebrate fast failures. Experiments are small.

They encourage teams to try something new to delight customers and share what they’ve learned with the rest of the organization.

The learning from any failures isn’t hidden but shared openly.

Distributed decision making

The ability to make decisions and respond to rapidly changing customer needs.

If you are dependent upon leadership to make all decisions you will be slow and sluggish. And typically, the larger the organization, the slower the response.

Self-organizing agile teams are empowered to make decisions day-to-day in alignment with the strategic direction. These teams have regular contact with real customers, enabling them to learn about changing customer needs and react quickly.

Joy in the workplace

People who create value directly for customers and work at a sustainable pace, really enjoy the way they work.

These organizations have teams that are deeply connected to the impact their product has on their customers.

Releasing products frequently

Customer-facing value: The more frequently you release products, the more opportunities you have to impress customers and receive feedback.

Frequent releases allow an organization to sense and respond to changing customer needs, and deliver the right product at the right time.

Inspect and adapt

All members have a voice in how the work is organized. Team retrospectives have actionable results that the team builds into the next sprint. When retrospectives are done correctly, teams try something new each sprint in order to work in a better way.

Retrospectives are valuable at an organization-level as well. Agile cultures inspect and adapt how they are organized.

And agile organizations aren’t just doing retrospective theater. They listen to team feedback and make real, actionable changes to improve collaboration and maximize outcomes.

Summary

Agile organizations prioritize fast failures, distributed decision-making, joy in the workplace, frequent product releases, and continuous improvement through retrospectives.

They encourage teams to experiment and learn from failures, empower teams to make decisions in alignment with the organization's strategy, foster a positive work culture, regularly release products to gather feedback and respond to changing customer needs, and actively listen to and implement feedback to improve team experiences and maximize business outcomes.

Next time you want to check how agile a company really is, you can use these criteria as a guide.

Asking the right questions

If you are interested in the questions you can ask for a better understanding of the agile mindset of the organization:

Can you tell me some stories of team and product failures and how the organization responded?

How are decisions about products made at the team level? What leadership approvals are required and why?

What are your company's mission, vision, and values? What does team communication look like to get to know each other as people, not just about work?

Do your teams release working software/products to your customers in every sprint? If not, how often and why?

What experiments are your teams trying in this sprint to improve their collaboration? How has your organizational design changed based on feedback from your people?

Auch zwischen Softwareentwicklern und Betrieb (auch bekannt als Ops) kommt es da schnell zu Kommunikationsproblemen, weil man jeweils eigene Terminologien verwendet. Man redet aneinander vorbei. Missverständnissen sind die Folge.

Deshalb ist es so wichtig, dass man sich regelmäßig austauscht, um zu verstehen, was die Anderen für Aufgaben zu bewältigen haben und was sie eigentlich meinen, wenn sie etwas sagen.

Auch das ist DevOps-Kultur.

Denn am Schluss zählt das erfolgreiche Produkt, egal ob man im Betrieb, in der Softwareentwicklung oder auf Business-Seite arbeitet.

• Was für Probleme lösen wir für unsere Kunden?

• Wie lösen wir diese Probleme konkret?

• Was unterscheidet uns von unseren Mitbewerbern?

• Wie können wir unsere Vertrauenswürdigkeit unter Beweis stellen?

• Wie ist die finanzielle Performance unseres Unternehmens im Vergleich zu den anderen Unternehmen unserer Branche?

• Warum entscheiden sich unsere Kunden für unser Produkt oder unsere Dienstleistung und nicht für andere Optionen?

Wenn man die geschäftlichen Zusammenhänge nicht versteht, riskiert man in Initiativen zu investieren, die letztlich keinen Mehrwert bringen.