Software on demand.
Responsibility remains.

In “KI kopiert jede Software, und jetzt?”, Arnie describes a future in which people ask to edit a photo or understand their sales, and receive a small application inside the conversation. The application grows as they ask for changes. He presents this as a direction with an uncertain timeline and acknowledges current bugs and technical hurdles.

In “Vibe Coding hat sich verändert”, Niklas Steenfatt describes a progression from autocomplete to whole functions, packages and increasingly architectural decisions. He also describes his role as product owner: deciding which features to develop and which to leave out.

COMMENTARY

A person can describe what they need, try a first version and adapt it. A comparison tool for one decision or a small dashboard for a recurring question can be worth creating even when a conventional software project would have felt disproportionate.

The user does not have to begin with the ambition to develop software. They can begin with the task. A tool might appear within a conversation, become a saved application, or disappear when it has served its purpose. Its scope can stay close to the problem instead of expanding into a large product.

My own experiments have changed my sense of what is worth trying. I am more willing to build a small tool when I can examine the result and change it quickly. My website is one example. The first local version came together quickly. Further work shaped the version I was prepared to publish.

I expect this to change some software buying decisions. The useful comparison becomes the fit, reliability and ongoing effort of an existing product versus a tailored tool. How far that shifts the market remains open. The immediate change is that creating an application becomes a practical option for more situations.

ChatGPT Sites brings building and hosting into one workflow. Its documentation describes creating a site from a request, reviewing it, refining it and choosing who can visit. Supported features include durable records, uploaded files and sign-in. These capabilities can remove separate setup steps for a compatible application.

The documentation states that application authorization belongs in server-side code. A successful sign-in identifies a visitor. The application still needs rules for which records and actions that person may access.

COMMENTARY

Hosting, persistence and identity are part of what makes software usable. Bringing them closer to the conversation lowers another barrier between a useful idea and something people can actually open and use.

I expect tools to keep simplifying operational work too. The amount a person must configure manually can shrink substantially. A useful question is what the platform manages, what the application still has to enforce and how to check that the combination meets its intended use.

The convenience also makes the platform part of the dependency chain. Before relying on a tool, its access model, practical limits and options for keeping or moving the data need examination. Those choices become more consequential as a personal experiment becomes shared infrastructure.

OWASP’s Web Security Testing Guide treats security testing as work across definition, design, development, deployment and maintenance. Its operational phase includes reviewing how the application and infrastructure are managed, checking their security over time and verifying changes after deployment.

OpenAI’s Codex best practices recommend writing or updating tests when needed, running the relevant suites, using lint, formatting or type checks, and reviewing the result. The documentation explains that verification guidance can come from the prompt or AGENTS.md.

COMMENTARY

Dependable operation remains a distinct responsibility. Getting a tool online provides something to use and evaluate. Relying on it for an ongoing process requires evidence about what happens when people make mistakes, a dependency fails or the application changes.

Verification needs to be defined and checked for each project. It should be clear which checks actually ran and what they cover. A green result supports conclusions about the aspects those checks examine. Access rules, recovery and the behavior of connected services need clear acceptance criteria and evidence too.

Responsibility for reviews includes planning and initiating them, defining their scope and funding the tokens they use. I share Steenfatt’s view on this. That responsibility does not mean personally reading every line of code. Selective Review refers here to focusing human attention on consequential changes, uncertainty and gaps in the evidence, while retaining required checks and approval boundaries.

The assurance sought should reflect the consequences. A temporary calculator using example data needs less assurance than a shared application holding confidential records. For the latter, suitable evidence would include tested access rules, protected credentials, appropriate checks of code and dependencies, a way to notice failures, and a demonstrated way to recover important data. Maintenance and incidents also need a clear owner.

Resilience includes being able to recover from a bad update and keep a useful path forward when a service is unavailable. Those expectations are worth defining before the tool becomes essential. A managed provider can supply parts of that capability. It still needs to be established which parts are covered and whether they work for this application.

These checks and operating tasks can themselves be automated or assisted by AI. What matters is their coverage and results, and who acts when something falls outside them. An application built with AI also needs ordinary software security. Additional model-specific controls become relevant where it actually uses an AI model.

Creating the first version becomes more accessible, and the platform can absorb more of the technical work. Clear requirements, suitable data access and evidence of reliable behavior become central to deciding where the result belongs in everyday use.