The discussion around AI-assisted development is often reduced to speed and cost. One concrete example is a web interface for the control plane of Cells for NetBSD - a NetBSD-native isolation and operating model for workloads.
The prototype covers operational tasks such as desired/actual state comparison, reconcile (apply), and backup/restore control.
Implementation cost was about 40 EUR in token budget.
Concretely, this covers operational tasks such as listing cells and hosts, comparing desired and actual state, triggering reconcile (apply), and controlling backup and restore actions.
Implemented in Go, as a standalone binary, cross-buildable for NetBSD, including authentication and a clean day/night theme - for about 40 EUR in extra token costs.
The program was developed on Linux and then cross-compiled for NetBSD. Web server and static assets are embedded directly into the binary. Result: an all-inclusive standalone binary of around 9 MB. This is exactly how self-contained services are built today.
That number is not proof that development is “worth nothing” now. It is a reason to look more calmly and more honestly at the value of development.
The question behind the 40 euros
What is software development still worth today if a web GUI suddenly costs 40 euros?
The obvious answer would be: “Then everything has become interchangeable.” The more accurate answer, in my view, is: “It depends on which part of development we mean.”
What visibly loses value:
- Boilerplate and CRUD assembly-line work
- interchangeable controller and DTO glue code
- generic visual interfaces without domain understanding
What tends to gain value at the same time:
- system boundaries and durable architectural decisions
- reliable integration contracts
- operability, security, and evolvability
Quality shows up in operations, not in the demo
In 2026, this is truer than ever: an interface that “looks good” is still not a sufficient quality metric.
Quality shows up when things get uncomfortable:
- under load
- in failure scenarios
- in versioning and migration
- under security requirements
- in real operations after months, not in a showcase after hours
That is why senior developers are not obsolete, but central. Not as expensive code machines, but as the decision instance for questions AI cannot take responsibility for: Where are the boundaries? Which layer is allowed to know what? Which IPC will stay stable over time? Which shortcut becomes expensive in six months?
Two business models under pressure
If you take this shift seriously, two classic models come under pressure.
1. Selling developers at scale
The pure hourly-package model loses traction once large parts of repetitive implementation can be automated. If your main offer is interchangeability, you no longer compete only with other service providers, but directly with automation.
2. Build once, copy expensively forever
The model of “a standard product built years ago, plus expensive maintenance contract, plus consulting package for a few adjustments” is also being questioned.
If a provider in 2026 still relies on heavily aged software and practical usability only emerges through substantial additional consulting, customers are justified in asking a direct question:
Is a needs-based reimplementation on established frameworks - guided by experienced architecture work and AI-assisted delivery - the more sustainable long-term option?
Another point: AI can now also help with onboarding into foreign codebases - often more structured than some “handover” processes that projects traditionally considered knowledge transfer.
Why the 40 EUR Web GUI could be built so cheaply
The GUI was not cheap because frontends suddenly became irrelevant. It was cheap because the architecture underneath was clean.
In the Cells for NetBSD project - specifically in the control plane - we focused early on a clear IPC around scriptable business logic.
Cells for NetBSD deliberately separates kernel isolation, runtime, and control plane:
secmodel_cell: isolation and policy enforcement in the kernelcellctl: runtime-near operations such as create/destroy/execcellmgr: control plane for desired/actual state, reconcile (apply), backup/restore, and automation
The role of cellmgr is central: it is the stable layer between business logic and different user interfaces.
For API and web GUI work in particular, the development path of cellmgr is crucial.
cellmgr started as a shell-script CLI. Later, a lean IPC protocol was added in the same command-dispatch path - simple text-based, but deterministic.
Based on that, cellui was built first, a TUI in C with curses. And today the web GUI uses exactly the same IPC - the same domain access path, instead of rebuilding a second backend stack.
The program was developed exclusively with OpenCode and the OpenAI Codex model. I implemented only very little myself.
The AI received, as domain reference, essentially the source code of cellmgr and cellui.
In addition, I provided a textual description of how I wanted the GUI to look and behave - and the web GUI emerged along the same architecture.
Screenshots: current state of cellweb
The first three screens show the operational entry points (left to right):
- Login screen with real PAM-based authentication
- System state based on the same control-plane data used by
cellui - Cell and volume management with clear feature parity to
cellui
The fourth screen shows the background sampler for system metrics and charts.
The result:
- same business logic, new access channel
- fast iteration instead of months of UI rewiring
- standalone web interface in Go with authentication and theme support
- self-contained service: developed on Linux, cross-compiled for NetBSD, with web server and assets in a roughly 9 MB binary
- additional implementation cost: 40 EUR token budget
And what about criticism of AI-assisted development?
Yes, the cellweb PoC was built to a large extent with the help of AI.
Whether you find that disappointing depends heavily on perspective.
AI does not replace architecture work. Layers, protocols, system boundaries, and domain direction do not emerge automatically - they need conscious design and accountability.
What AI absolutely does reduce is time-consuming boilerplate and diligence work. That can be exactly the difference between “good idea on paper” and “working prototype”.
And maybe this debate is simply part of normal technical evolution: Every engineering generation had tools that the previous generation saw as shortcuts or “cheating”. The tools change. The key question remains: What do we build with them - and how robust is the result?
What changes for classic web development
The provocative question is often: “What do classic web developers even do all day in 2026?” I think the constructive version is more useful: Which activities remain truly valuable, and which become increasingly automatable?
If the core of the work still consists of wiring controllers, mapping DTOs, and assembling standard forms, that part will increasingly come under price pressure.
The real value today is elsewhere:
- model the domain precisely
- design integrations robustly
- build security and operational requirements in early
- keep change cheap without sacrificing quality
- use AI as a multiplier, not as a substitute for thinking
Conclusion
Software development has not become less valuable. But the market no longer pays every part of the work equally.
Assembly-line work comes under pressure. Engineering with accountability is being revalued.
The web GUI built with a 40 EUR token budget is not an obituary for software development. It rather shows that value creation is shifting toward architecture quality, integration quality, and operational reliability.
Those who invest in clean data and integration architecture today can deliver faster, automate better, and still secure high quality. And those who treat software as a long-term capability instead of a licensing trap create greater and more sustainable value for customers.