Ein Manifest aus losen Thesen kann man teilweise teilen und teilweise verwerfen — jede Position für sich. Ein Axiomensystem nicht: wer hier widersprechen will, muss ein Axiom benennen. Damit wird Diskussion nicht beliebig, sondern fokussiert.
Wir setzen fünf nicht weiter rückführbare Annahmen, definieren fünf Begriffe, und leiten daraus zehn operative Sätze ab. Jeder Satz trägt seine Herleitung (⊢ aus A.X, D.Y) und sein Korollar (Wenn / Dann).
Das ist kein akademischer Anspruch. Es ist ein Werkzeug: Wenn wir im Alltag streiten, ob etwas zu tun ist, gehen wir zurück bis zur Quelle und prüfen, welches Axiom uns hier bindet.
Jede Regel der Softwareherstellung ist Antwort auf eine historische Knappheit. Endet die Knappheit, endet die Bindungskraft der Regel.
UI-Zwang, Lizenzlogik, Wartungsdogma, Demo-Glaube — alles entstand, weil Code teuer, Verteilung schwer und Anpassung mühsam war. Diese Bedingungen verschwinden. Wir setzen: Wer eine alte Regel verteidigen will, muss zeigen, dass ihre Knappheit noch besteht.
Software ist die Übersetzung von Absicht in ausführbares Verhalten. KI verbilligt die Übersetzung — nicht die Absicht.
Code ist Sprache, kein Mysterium. Wer programmiert, übersetzt. KI macht diesen Schritt billig, schnell, zugänglich. Aber die Absicht muss von einem Menschen formuliert worden sein, bevor sie übersetzt werden kann. Der Engpass ist nicht mehr die Tastatur — der Engpass ist die Entscheidung. Wir setzen: Denken bleibt teuer. Entscheiden auch.
Software hat keinen Eigenwert. Sie existiert in Bezug auf ein Problem, das außerhalb ihrer liegt. Endet der Bezug, endet ihre Berechtigung.
Eine App ist kein Selbstzweck. Sie ist Werkzeug für etwas, das ohne sie schwerer wäre. Wenn das Problem stirbt, der Prozess wechselt oder der Nutzen ausläuft, hat die Software ihre Existenzgrundlage verloren. Wir setzen: Software lebt mit ihrem Problem.
Software realisiert sich erst im Gebrauch. Was nicht gebraucht wird, hat keinen Wert — unabhängig davon, ob es funktioniert.
Eine Demo ist Möglichkeit. Ein Feature ist Behauptung. Ein Pitch ist Versprechen. Wirkung entsteht erst, wenn ein Mensch oder eine Maschine die Software tatsächlich benutzt und dadurch etwas in der Welt anders ist. Wir setzen: Wert ist Gebrauch.
Verantwortung ist an Personen gebunden, nicht an Werkzeuge. Arbeit kann delegiert werden. Verantwortung nicht.
KI ist Werkzeug. Modelle, Frameworks, Plattformen, Lieferanten — alles Werkzeuge. Sie tragen weder Datenschutz noch Sicherheit noch Folgen. Wir setzen: Verantwortung trägt nur, wer ein System in die Welt setzt — und zwar in voller Kenntnis dessen, was es tut.
Aus A.2 folgt: KI übersetzt Absicht in Code. Ohne formulierte Absicht hat sie nichts zu übersetzen — sie rät. Aus A.5 folgt: Die Absicht muss vom verantwortenden Menschen kommen, weil nur er sie auch verantworten kann.
Der Prompt ist nicht der Anfang von Software. Er ist der Moment, in dem Unklarheit sichtbar wird. Wer keine Entscheidung getroffen hat, sollte nicht prompten.
Aus A.2 folgt: Code ist Sprache — also lesbar. Was im Code steht, ist erklärt. Aus A.4 folgt: Doppelte Erklärung erzeugt keine zusätzliche Wirkung. Dokumentation, die wiederholt, was die App selbst zeigen kann, ist Aufwand ohne Gegenwert.
Dokumentation verschwindet nicht. Aber ihre Rolle ändert sich. Sie hält fest, was die App nicht aus sich heraus zeigen kann: Absicht, Entscheidung, Kontext, Grenzen. Wenn Code billig wird, wird Kontext teuer — Code können wir jederzeit neu erzeugen, verlorenes Problemverständnis nicht.
Aus A.3 folgt: Die Form ist Mittel zum Zweck, nie Selbstzweck. Aus D.3 folgt: Fähigkeit ist unabhängig von Erscheinungsform — UI, API, Agent, Artefakt, Workflow können dieselbe Fähigkeit tragen.
Die alte Welt dachte in Screens, weil Menschen die einzigen Nutzer waren. Die neue Welt hat Menschen und Maschinen als Nutzer. Das UI verliert seine Herrschaft. Es ist eine mögliche Form unter mehreren.
Aus A.1 folgt: Lizenzmodelle entstanden, weil Software teuer herzustellen und schwer zu verteilen war. Diese Knappheit verschwindet. Aus A.3 folgt: Was nicht dient, hat keine Berechtigung.
Standardsoftware bleibt sinnvoll, wenn sie echte Standards abbildet, Regulatorik bedient, Netzwerkeffekte trägt oder Skalenökosysteme bereitstellt. Aber der Reflex „kaufen ist professioneller als bauen" ist tot. Jede Lizenz ist Mietzahlung an vergangene Knappheit, bis sie sich begründet.
Aus A.3 folgt: Software hat keinen Eigenwert. Existiert das Problem nicht mehr, fehlt ihr die Existenzgrundlage. Aus A.1 folgt: Der Reflex, Software künstlich am Leben zu halten, stammt aus der alten Knappheit — Migration war teuer, Neubau noch teurer. Diese Knappheit endet.
Wartung, Migration und Legacy-Betrieb sind kein Selbstzweck. Sie sind gerechtfertigt, solange das ursprüngliche Problem noch lebt. Sterben Prozesse, dürfen ihre Werkzeuge sterben.
Aus A.3 folgt: Software lebt nicht länger als ihr Zweck. Aus A.4 folgt: Wirkung tritt im realen Gebrauch ein — nicht in der Erwartung künftigen Gebrauchs. Daraus folgt: Architektur muss zur erwarteten Lebensdauer passen, nicht zur größtmöglichen.
Wegwerfsoftware ist nicht schlecht — sie ist ehrlich zu ihrer Halbwertszeit. Schlecht ist Software, die ihre Lebensdauer verschweigt und Aufwand erzwingt, den ihr Zweck nicht trägt. Wir bauen heute manche Gartenlaube nach den Regeln eines Kernkraftwerks. Vielleicht wird Ersetzbarkeit wichtiger als Wartbarkeit — nicht weil Qualität egal wäre, sondern weil ein guter Blueprint die App jederzeit neu erzeugen kann.
Aus A.3 folgt: Aufwand ist nur durch Zweck gedeckt. Aus A.4 folgt: Mehr Aufwand erzeugt nicht automatisch mehr Wirkung. Qualität ist daher keine Maximierung von Tests, Docs, Architektur oder Tooling — sondern Angemessenheit.
Eine interne Einmal-App braucht andere Qualität als ein produktives Kundensystem. Ein Prototyp andere als eine sicherheitskritische Anwendung. Wer zu viel baut, verfehlt den Zweck genauso wie der, der zu wenig baut — nur teurer.
Aus A.4 folgt: Wert entsteht im Gebrauch. Aus D.4 folgt: Wirkung ist die nachweisbare Veränderung außerhalb der Software. Features sind nur potenzielle Wirkung — eine Behauptung über Möglichkeit. Erst der Gebrauch realisiert sie.
Eine Demo zeigt, dass etwas geht. Eine Feature-Liste zeigt, dass etwas gebaut wurde. Beides verändert noch nichts. Wir liefern keine fertigen Funktionen. Wir liefern veränderte Arbeit.
Aus A.4 folgt: Software realisiert sich erst im Gebrauch. Abnahmeprotokoll, Pitch, Screenshot — alles innerhalb des Projektrahmens; Wirkung beweisen können sie nicht. Aus A.5 folgt: Im Alltag steht eine Person für das System ein — Betrieb ist Verantwortung, kein Anhang.
Beweisen kann sie nur der echte Alltag. Erst dort zeigt sich, ob eine Anwendung trägt: Rechte, Rollen, Daten, Fehler, Kosten, Zuständigkeit, Akzeptanz. Was niemand betreiben will, sollte niemand bauen.
Aus A.5 folgt: Verantwortung kann nicht an Werkzeuge delegiert werden. Aus D.5 folgt: Wer nicht versteht, kann nicht verantworten. Daraus folgt: Wer den Code nicht verstanden hat, hat ihn nicht geprüft. Wer ihn nicht geprüft hat, sollte ihn nicht ausliefern.
KI kann erzeugen, vorschlagen, testen, Muster zeigen. Aber sie entscheidet nicht, was richtig ist. Verantwortung für Datenschutz, Sicherheit, Fairness, Kosten, Fehler bleibt beim Menschen — auch bei kurzlebiger Software, auch bei kleinen Werkzeugen, auch bei internen Apps. Deshalb gilt: Mehr Menschen dürfen Software bauen. Aber nicht planlos. Gute Governance ist eine Werkstattordnung, kein Stoppschild.