Dieses Wochenende habe ich Rufbereitschaft. Das bedeutet: keine Familienausflüge, keine langen Einkaufstouren, keine großen Bauprojekte im Garten - ich muss im Zweifel schnell am Rechner sein, falls das Telefon klingelt.

Oft klingelt es nicht. Und das ist auch gut so. Im Haus gibt es immer etwas zu tun, und manchmal öffnen sich genau dadurch kleine Zeitfenster, in denen man ein Projekt wirklich von Anfang bis Ende durchziehen kann.

So wie an diesem Wochenende. In genau so einem Fenster ist meine 40 EURO Web-GUI entstanden: ein Web-Interface für die Control Plane von Cells for NetBSD - einem NetBSD-nativen Isolations- und Betriebsmodell für Workloads.

Konkret geht es um Betriebsaufgaben wie Cells und Hosts auflisten, Soll- und Ist-Zustand vergleichen, Reconcile (apply) auslösen sowie Backup- und Restore-Aktionen steuern. Umgesetzt in Go, als Standalone-Binary, cross-buildfähig für NetBSD, inklusive Authentifizierung und sauberem Tag/Nacht-Theme - für etwa 40 Euro Extra-Tokenkosten.

Entwickelt wurde das Programm auf Linux und dann für NetBSD cross-compiliert. Webserver und statische Assets sind direkt im Binary eingebettet. Ergebnis: ein rund 9 MB großes Standalone-Binary, all-inclusive. Genau so baut man heute self-contained Services.

Diese Zahl ist kein Beweis dafür, dass Entwicklung “nichts mehr wert” sei. Sie ist ein Anlass, ruhiger und ehrlicher auf den Wert von Entwicklung zu schauen.

Die Frage hinter den 40 Euro

Was ist Softwareentwicklung heute noch wert, wenn eine Web-GUI plötzlich 40 Euro kostet?

Die naheliegende Antwort wäre: “Dann ist alles austauschbar geworden.” Die aus meiner Sicht treffendere Antwort lautet: “Es kommt darauf an, welcher Teil von Entwicklung gemeint ist.”

Was sichtbar an Wert verliert:

• Boilerplate- und CRUD-Fließbandarbeit
• austauschbares Controller- und DTO-Geklebe
• visuelle Standardoberflächen ohne Domänenverständnis

Was gleichzeitig eher an Wert gewinnt:

• Systemgrenzen und tragfähige Architekturentscheidungen
• belastbare Integrationsverträge
• Betriebsfähigkeit, Sicherheit und Evolvierbarkeit

Qualität zeigt sich im Betrieb, nicht in der Demo

2026 gilt mehr denn je: Eine Oberfläche, die “gut aussieht”, ist noch keine ausreichende Qualitätsmetrik.

Qualität zeigt sich, wenn es unbequem wird:

• unter Last
• bei Fehlerfällen
• bei Versionierung und Migration
• bei Sicherheitsanforderungen
• im echten Betrieb nach Monaten, nicht im Showcase nach Stunden

Deshalb sind Senior Developer nicht überflüssig, sondern zentral. Nicht als teure Code-Maschinen, sondern als Entscheidungsinstanz für Fragen, die KI nicht verantworten kann: Wo liegen die Grenzen? Welche Schicht darf was wissen? Welche IPC ist auf Dauer stabil? Welche Abkürzung wird in sechs Monaten teuer?

Zwei Geschäftsmodelle im Wandel

Wenn man diese Verschiebung ernst nimmt, geraten zwei klassische Modelle unter Druck.

1. Entwickler in Masse verkaufen

Das reine Stundenpaket-Modell verliert an Zugkraft, sobald große Teile repetitiver Implementierung automatisierbar sind. Wer primär Austauschbarkeit verkauft, konkurriert nicht mehr nur mit anderen Dienstleistern, sondern direkt mit Automatisierung.

2. Einmal bauen, dann teuer kopieren

Auch das Modell “vor Jahren gebautes Standardprodukt plus teurer Wartungsvertrag plus Consultingpaket für ein paar Anpassungen” wird hinterfragt.

Wenn ein Anbieter 2026 im Kern noch 2014 geschriebene Software zu Premiumpreisen verkauft, obwohl sie erst durch zusätzliches, kostspieliges Consulting beim Kunden lauffähig wird, stellt sich für Kunden zurecht eine einfache Frage:

Warum nicht bedarfsgerecht neu bauen lassen - unter Aufsicht eines erfahrenen Architekten, mit KI-Unterstützung, auf verbreiteten Standardframeworks, für die auch bei Personalfluktuation jederzeit wieder Fachleute verfügbar sind?

Hinzu kommt: KI kann heute auch bei der Einarbeitung in fremden Code helfen - oft strukturierter als manche “Übergabe”, die in Projekten traditionell als Wissenssicherung galt.

Warum die 40 EURO Web-GUI so günstig entstehen konnte

Die GUI war nicht deshalb billig, weil Frontends plötzlich irrelevant sind. Sie war billig, weil die Architektur darunter sauber war.

Im Projekt Cells for NetBSD - konkret in der Control Plane - wurde früh auf eine klare IPC an der scriptbaren Business-Logik geachtet.

Gerade für API und Web-GUI ist der Entwicklungsweg von cellmgr entscheidend. cellmgr begann als Shellscript-CLI. Später kam im selben Command-Dispatch-Pfad ein schlankes IPC-Protokoll dazu - einfach textbasiert, aber deterministisch.

Darauf aufbauend entstand zuerst cellui, eine TUI in C mit curses. Und heute nutzt die Web-GUI exakt dieselbe IPC - also denselben fachlichen Zugangspfad, statt einen zweiten Backend-Stack nachzubauen.

Screenshots: cellweb im aktuellen Stand

Die ersten drei Screens zeigen den operativen Einstieg (von links nach rechts):

• Login-Maske mit echter, PAM-basierter Authentifizierung
• Systemzustand auf Basis derselben Control-Plane-Daten wie in cellui
• Cell- und Volume-Management mit klarer Feature-Parität zu cellui

Der vierte Screen zeigt den Background-Sampler für Systemmetriken und Diagramme.

Das Ergebnis:

• gleiche Business-Logik, neuer Zugangskanal
• schnelle Iteration statt monatelanger UI-Nachverdrahtung
• Standalone-Webinterface in Go mit Authentifizierung und Theme-Support
• self-contained Service: auf Linux entwickelt, für NetBSD cross-compiliert, mit Webserver und Assets im rund 9 MB großen Binary
• zusätzliche Umsetzungskosten: 40 Euro Token-Budget

Und was ist mit der Kritik an KI-gestützter Entwicklung?

Ja, der cellweb-PoC ist zu großen Teilen mit Hilfe einer KI entstanden. Ob man das enttäuschend findet, hängt stark von der Perspektive ab.

Eine KI ersetzt keine Architekturarbeit. Schichten, Protokolle, Systemgrenzen und die fachliche Richtung entstehen nicht automatisch - sie müssen bewusst entworfen und verantwortet werden.

Was eine KI sehr wohl reduziert, ist viel zeitaufwendige Boilerplate- und Fleißarbeit. Das macht im Zweifel genau den Unterschied zwischen “gute Idee auf Papier” und “funktionierender Prototyp” aus.

Und vielleicht gehört diese Debatte einfach zur normalen technischen Entwicklung: Jede Ingenieursgeneration hatte Werkzeuge, die die vorherige Generation als Abkürzung oder “Cheating” gesehen hat. Die Werkzeuge ändern sich. Die entscheidende Frage bleibt: Was bauen wir damit - und wie belastbar ist das Ergebnis?

Was sich für klassische Web-Entwicklung verändert

Die provokante Frage lautet oft: “Was machen klassische Web-Developer 2026 eigentlich noch den ganzen Tag?” Ich glaube, die konstruktive Variante ist hilfreicher: Welche Tätigkeiten bleiben wirklich wertvoll, und welche werden zunehmend automatisierbar?

Wenn der Kern der Arbeit weiterhin darin besteht, Controller zu verkabeln, DTOs zu mappen und Standardmasken zusammenzubauen, dann wird dieser Anteil zunehmend unter Preisdruck geraten.

Der eigentliche Wert liegt heute woanders:

• Domäne präzise modellieren
• Integrationen robust gestalten
• Sicherheits- und Betriebsanforderungen früh einbauen
• Änderungen billig halten, ohne Qualität zu opfern
• KI als Multiplikator einsetzen, nicht als Denk-Ersatz

Fazit

Softwareentwicklung ist nicht weniger wert geworden. Aber der Markt bezahlt nicht mehr jeden Anteil der Arbeit gleich.

Unter Druck gerät Fließbandarbeit. Aufgewertet wird Engineering mit Verantwortung.

Die 40 EURO Web-GUI ist kein Abgesang auf Entwickler. Sie ist ein Realitätscheck für Geschäftsmodelle, die noch so tun, als wäre 2014.

Wer heute auf saubere Daten- und Integrationsarchitektur setzt, kann schneller liefern, besser automatisieren und trotzdem hohe Qualität sichern. Und wer Software als langfristige Fähigkeit versteht statt als Lizenzfessel, schafft für Kunden den größeren und nachhaltigeren Wert.