Code war nie das Produkt:
was bleibt, wenn Betriebe selbst bauen

Was mit dem Programmieren als bezahlter Arbeit passiert

Programmieren heißt in diesem Zusammenhang: die Arbeit zwischen der fertigen Beschreibung und der laufenden Seite. Felder anlegen, Rechenregeln hinterlegen, Eingabemasken bauen, alles miteinander verbinden. Was diese Arbeit wert war, hing an zwei Dingen. Sie war schwer, und wenige konnten sie. Beides gilt so nicht mehr.

Wer genau beschreiben kann, was er braucht, hat das fertige Ergebnis heute in der Zeit, die früher allein das Angebot gekostet hat. So ist der Stand heute, und er gilt auch für schwierige Sachen: eine mehrstufige Preisberechnung, eine Verbindung zur Warenwirtschaft, ein Konfigurator, bei dem eine Auswahl die nächste einschränkt, ein kompletter Shop mit Bestellvorgang, Versandberechnung und Zahlung. All das entsteht, sobald jemand die Regeln vollständig hinschreibt. Schwierig ist heute das Hinschreiben.

Zwei Betriebe, dasselbe Werkzeug, zwei Ergebnisse

Ein Geschäftsführer, der seine Kalkulation, seine Rabattstufen und seine Kunden kennt, baut in einer Woche etwas, das ihm vorher niemand richtig hinbekommen hat. Ein Geschäftsführer, der nicht genau sagen kann, wie seine Preise zustande kommen, baut jetzt schneller das Falsche und merkt es später. Dasselbe Werkzeug verstärkt beides. Es entscheidet also, wie gut jemand sein eigenes Geschäft kennt. Früher entschied an dieser Stelle, wie gut jemand programmieren konnte.

Für den Markt heißt das: Das Fachwissen über die Branche zählt jetzt auf der Seite dessen, der bestellt, und nicht mehr auf der Seite dessen, der baut. Bisher musste ein Betrieb sein Wissen an einen Dienstleister übergeben, der es in ein Programm übersetzte. Genau bei dieser Übergabe ging am meisten verloren und wurde am meisten bezahlt. Warum Software ohne dieses Wissen nicht funktioniert, behandelt der Beitrag zu Branchenwissen als Fundament der Entwicklung. Die Übergabe fällt jetzt weg, weil der Betrieb selbst baut.

Drei Berufe, die es schon einmal getroffen hat

Das ist nicht das erste Mal, dass eine Technik einen ganzen Berufsstand aus einer Branche herauslöst. In der Drucksachenherstellung ist genau das passiert. Wer früher eine Anzeige brauchte, beauftragte drei Fachleute mit drei Ausbildungen: Ein Schriftsetzer setzte den Text, ein Layouter entwarf die Anordnung, eine Reinzeichnerin baute daraus die Vorlage, die in die Druckerei ging.

Als der Satz auf Rechnern möglich wurde, übernahmen die Betriebe alle drei Tätigkeiten selbst. Wer eine Anzeige brauchte, machte sie selbst. 1998 wurde der Ausbildungsberuf Mediengestalter für Digital- und Printmedien eingeführt und löste die getrennten Satz- und Reproberufe ab. Die Arbeit gab es weiter, den Berufsstand nicht mehr.

Wer beurteilt, wann etwas fertig ist

Die Betriebe hatten jetzt das Werkzeug. Damit mussten sie auch selbst entscheiden, wann eine Drucksache fertig ist. Vorher hat das jemand beurteilt, der dafür ausgebildet war und den ganzen Tag nichts anderes gemacht hat. Danach entschied das derjenige, der die Datei gebaut hatte.

Dieselbe Frage stellt sich jetzt wieder, diesmal bei Websites und Shops. Das Werkzeug hat der Betrieb. Offen ist, wer ihm sagt, ob das Ergebnis taugt.

Wo Selberbauen heute gut geht

Es geht gut, solange eine Anwendung nur wenige Fälle kennt und ein Fehler sofort auffällt. Ein Anfrageformular mit eigener Logik gehört dazu, so wie das Formular mit den vierzehn Varianten. Ebenso Rechner und Konfiguratoren, deren Regeln der Betrieb ohnehin jeden Tag anwendet.

Am deutlichsten zeigt es sich bei internen Werkzeugen, für die nie Geld da war: eine Maschinenbelegung, die bisher an einer Tafel hing. Ein Prüfprotokoll auf Papier. Eine Liste, wer welches Leihgerät hat. Diese Sachen waren nie groß genug für ein richtiges Projekt und im Alltag trotzdem lästig. Sie entstehen jetzt nebenbei, und man sieht sofort, was sie bringen, weil die gesparte Zeit im eigenen Haus anfällt.

Alle diese Fälle haben drei Dinge gemeinsam. Es fließt kein Geld durch die Anwendung. Es sind keine Daten fremder Personen im Spiel. Und ein Fehler fällt der Person auf, die damit arbeitet. Sobald eines dieser drei Dinge nicht mehr stimmt, sieht die Lage anders aus.

Sieben Stellen, an denen es schiefgeht

Schwierig wird es überall dort, wo eine Entscheidung Folgen hat, die man am Bildschirm nicht sieht. Keiner der folgenden sieben Punkte ist ein technisches Problem. Es sind Entscheidungen, für die jemand geradestehen muss.

1. Eine Zahlung hat mehr Zustände, als der Shop anzeigt

Zwischen Bestellung und Geldeingang liegen mehrere Stationen: Das Geld ist reserviert, aber noch nicht abgebucht. Es ist abgebucht. Es ist nur zum Teil abgebucht, weil nur ein Teil geliefert wurde. Die Bestellung wurde storniert. Ein Teilbetrag wurde erstattet. Die Lastschrift kam zurück. Ein Shop, der nur „bezahlt“ und „offen“ kennt, funktioniert bis zur ersten geteilten Lieferung. Danach passen die Zahlen des Zahlungsanbieters und die der Buchhaltung nicht mehr zusammen, und niemand kann die Differenz einer Bestellung zuordnen.

2. Die Steuer im Auslandsgeschäft ist eine Entscheidung, kein Schalter

Welcher Steuersatz gilt, hängt davon ab, wohin geliefert wird, ob der Käufer Unternehmer oder Privatperson ist, um welche Warengruppe es geht und welche Sonderregeln für Verkäufe an Privatkunden im EU-Ausland greifen. Ein KI-Werkzeug erklärt Ihnen jede dieser Regeln richtig. Welche in Ihrem Fall gilt, ergibt sich aus Ihrem Geschäft, und geprüft wird das beim Steuerberater.

3. Barrierefreiheit wird am fertigen Ergebnis gemessen

Seit Juni 2025 müssen viele digitale Angebote an Privatkunden barrierefrei sein. Das steht im Barrierefreiheitsstärkungsgesetz. Barrierefrei heißt: Die Seite lässt sich auch ohne Maus bedienen und auch von jemandem nutzen, der sie sich vorlesen lässt. Ein automatisch erzeugter Entwurf sieht danach aus, weil er die üblichen technischen Angaben mitbringt. Ob man mit der Tabulatortaste in sinnvoller Reihenfolge durch das Formular kommt, ob eine Fehlermeldung dem richtigen Feld zugeordnet ist und ob die Farben genug Kontrast haben, zeigt erst ein Test mit Tastatur und Vorleseprogramm.

4. Beim Umzug alter Daten geht am häufigsten etwas kaputt

In gewachsenen Systemen stehen Dinge an Stellen, an denen sie niemand vermutet und die nirgends aufgeschrieben sind. Im Preisfeld steckt seit Jahren ein Rabatt drin. Im Bemerkungsfeld steht die Versandklasse. Die siebte Stelle der Artikelnummer sagt, ob ein Artikel lagernd ist. Beim Umzug in ein neues System füllt das Werkzeug solche Lücken auf, statt sie zu melden. Hinterher sieht der Datenbestand vollständig aus. Die einzige Prüfung, die hilft, ist eine Stichprobe: einzelne Artikel im neuen System gegen das alte nachrechnen.

5. Haften müssen Sie, nicht das Werkzeug

Für Impressum, Preisangaben, Einwilligungen und die Richtigkeit der Rechnung haftet der Betreiber der Seite. Das war auch früher so, ein Dienstleister hat dafür nie gehaftet. Was er getan hat: Er hat die Fragen gestellt, weil er sie aus anderen Projekten kannte. Diese Fragen muss sich jetzt jeder selbst stellen.

6. Eine Sicherheitslücke sieht man der Anwendung nicht an

Das ist der Punkt, an dem das Selberbauen am gefährlichsten wird, weil nichts darauf hinweist. Die Seite läuft. Bestellungen kommen an. Alles sieht richtig aus, und trotzdem steht die Tür offen.

Vier Beispiele dafür, wie so etwas aussieht. In der Adresszeile steht nach der Bestellung eine Nummer, etwa /bestellung/1042. Wer diese Nummer von Hand in 1043 ändert, sieht die Bestellung eines fremden Kunden samt Anschrift, weil niemand geprüft hat, ob der Aufrufer dazu berechtigt ist. Oder: In ein Suchfeld schreibt jemand statt eines Suchbegriffs einen Befehl, den die Anwendung an die Datenbank weiterreicht, und liest damit die Kundentabelle aus. Oder: Über ein Feld zum Hochladen von Dateien lädt jemand statt eines Bildes ein kleines Programm hoch, das danach auf dem Server läuft. Oder: Die Zugangsdaten zum Zahlungsdienst stehen direkt im Programmtext und lassen sich über die Seite abrufen.

Keiner dieser Fehler fällt beim Benutzen auf. Sie fallen auch bei der Abnahme nicht auf, denn geprüft wird, ob eine Bestellung durchläuft. Erkennen kann solche Lücken nur jemand, der weiß, wonach er sucht, und der die Anwendung dabei absichtlich falsch bedient. Das ist eine eigene Fachkenntnis, und sie ist mit einer Beschreibung der gewünschten Funktion nicht abgedeckt.

Dazu kommt eine Eigenheit der Werkzeuge. Ein KI-Werkzeug baut, was Sie beschreiben. Sicherheit beschreibt fast niemand, weil man dafür aufschreiben müsste, was alles nicht passieren darf. Ohne diese Angabe entsteht eine Anwendung, die genau das tut, was gewünscht war, und daneben vieles, was niemand wollte.

7. Nach dem Bauen kommt der Betrieb

Eine Anwendung, die läuft, muss gepflegt werden. Aktualisierungen einspielen. Bekannt gewordene Sicherheitslücken in mitverwendeten Bausteinen schließen. Dafür sorgen, dass die Seite erreichbar bleibt. Sicherungen anlegen und ausprobieren, ob man sie zurückspielen kann. Dieser Aufwand verteilt sich über Jahre, und im Moment des Bauens sieht man ihn nicht.

Sieben Fälle, in denen der Shop richtig rechnet und Geld verliert

Die folgenden sieben Fälle haben eines gemeinsam: Das System rechnet in jeder Zeile korrekt, und das Ergebnis ist trotzdem falsch. Bei einem Testkauf merkt man nichts, weil ein Testkauf den Normalfall abbildet. Auffallen tut es in der Quartalsauswertung, wenn die Marge fehlt und niemand sagen kann, wo.

1. Der Mengenrabatt gilt auch für den Druck

Wer mehr abnimmt, zahlt pro Stück weniger. Das gilt für die Ware. Für die Veredelung, also Druck, Gravur oder Beschichtung, gilt es nicht, denn dieser Aufwand bleibt pro Stück gleich. Wird der Rabatt trotzdem auf den Gesamtpreis gerechnet, steigt der Nachlass mit jeder Stufe, die Veredelungskosten bleiben gleich. Ab einer bestimmten Menge liegt der Verkaufspreis unter dem, was der Betrieb selbst bezahlt hat. Je größer der Auftrag, desto größer der Verlust.

2. Der Aufschlag für kleine Bestellungen kommt zweimal

Viele Betriebe berechnen bei kleinen Bestellungen einen Zuschlag, weil sich der Aufwand sonst nicht lohnt. Der Zuschlag hängt am Bestellwert. Wird die Bestellung geteilt, weil ein Artikel erst später lieferbar ist, prüft das System beide Lieferungen einzeln. Beide liegen unter der Grenze, beide bekommen den Zuschlag. Der Kunde zahlt zweimal für eine Bestellung, die ursprünglich darüber lag, und reklamiert zu Recht. Die Regel, die das verhindert, lautet: Der Zuschlag gehört zum Auftrag, die einzelne Lieferung übernimmt ihn nur.

3. Preise mit und ohne Mehrwertsteuer im selben Shop

Ein Betrieb, der sowohl an Händler als auch an Privatkunden verkauft, braucht für denselben Artikel zwei Preisanzeigen: einmal ohne Mehrwertsteuer für den Geschäftskunden, einmal mit für den Privatkunden. Diese Umschaltung darf nicht davon abhängen, was der Besteller anklickt, sondern davon, ob sein Konto geprüft als Geschäftskunde hinterlegt ist. Hängt sie an einem Häkchen im Bestellvorgang, kaufen Privatkunden zu Nettopreisen ein. Die Mehrwertsteuer schuldet der Betrieb trotzdem, und er zahlt sie aus der eigenen Marge.

4. Sperrgut wiegt wenig und kostet viel

Versandkosten aus dem Gewicht zu berechnen, funktioniert bis zum ersten sperrigen Artikel. Ein langes, leichtes Teil kostet im Versand ein Vielfaches eines schweren, kompakten Pakets, weil die Transporteure Länge und Umfang berechnen. Wer im Artikelstamm nur das Gewicht hinterlegt und weder Maße noch ein Kennzeichen für Sperrgut, zahlt bei jeder solchen Sendung drauf. Gerade diese Artikel werden gern einzeln bestellt.

5. Die Schutzgebühr fürs Muster wird nie verrechnet

Muster gehen gegen eine kleine Gebühr heraus, die abgezogen werden soll, sobald der Kunde bestellt. Dafür müssen zwei Vorgänge verbunden werden, die Wochen oder Monate auseinanderliegen und für das System zunächst nichts miteinander zu tun haben. Fehlt diese Verbindung, bleibt die Gebühr stehen, der Kunde beschwert sich, und der Innendienst gleicht von Hand aus, was die Anwendung nicht kann.

6. Der Abzug für schnelle Zahlung taucht nirgends auf

Skonto ist der Abzug, den ein Kunde vornehmen darf, wenn er innerhalb einer kurzen Frist zahlt, oft zwei oder drei Prozent. Der Shop kennt den Rechnungsbetrag am Tag der Bestellung. Den Abzug nimmt der Kunde drei Wochen später vor. Beim Verkauf auf Rechnung entsteht dadurch eine Lücke zwischen dem Umsatz, den der Shop meldet, und dem Geld, das tatsächlich eingeht. Pro Auftrag ist sie klein, über ein Jahr wird sie groß.

7. Die Auswertung zeigt Umsatz, gebraucht wird der Rohertrag

Jede automatisch erzeugte Übersicht fängt beim Umsatz an, weil dieser Wert im System steht. Was ein Betrieb wirklich braucht, ist der Rohertrag pro Position, also das, was nach Abzug von Einkaufspreis, tatsächlichen Versandkosten und Zahlungsgebühren übrig bleibt. Dafür müssen alle diese Werte am selben Auftrag stehen. Wer nach Umsatz steuert, bewirbt zuverlässig die Artikel, an denen er am wenigsten verdient, und nimmt die aus dem Programm, die ihn tragen.

Was KI-Werkzeuge Ihnen nicht sagen

Wer täglich mit diesen Programmen arbeitet, kennt drei Eigenheiten, die in keiner Ankündigung stehen.

Die erste: Das erste Ergebnis sieht fast immer richtig aus. Ob es richtig ist, steht damit nicht fest. Zwischen „sieht plausibel aus“ und „ist geprüft“ liegt die eigentliche Arbeit.

Die zweite: Diese Programme melden keine Lücke, sie schließen sie. Fehlt in Ihrer Beschreibung der Zuschlag für kleine Bestellungen, bekommen Sie ein Formular ohne diesen Zuschlag, und niemand fragt nach. Fehlt beim Datenumzug ein Wert, wird einer eingesetzt, der zum Rest passt. Das liegt daran, wie diese Programme arbeiten: Sie setzen einen Text so fort, wie er am wahrscheinlichsten weitergeht. Eine leere Stelle behandeln sie als etwas, das gefüllt gehört.

Die dritte: Der Aufwand ist ein anderer geworden. Früher steckte er im Bauen, heute steckt er im Prüfen. Und prüfen kann nur, wer weiß, wie das richtige Ergebnis aussieht. Dieses Wissen bekommen Sie nicht von demselben Programm, dessen Ergebnis Sie prüfen wollen. Wie stark die Art der Bedienung über die Qualität entscheidet, ordnet der Beitrag Warum KI nicht bei jedem gleich gut funktioniert anhand der Forschungslage ein.

Genau sagen können, was man braucht

Die Fähigkeit, um die es hier geht, hat keinen eingeführten Namen. Gemeint ist: eine Aufgabe aus dem eigenen Betrieb so genau beschreiben zu können, dass niemand mehr nachfragen muss. Mit Geschmack hat das nichts zu tun und mit Computerkenntnissen wenig. Sie besteht aus drei Teilen.

Erstens: Man kennt den Fall vollständig, auch die Ausnahme. Der Betriebsleiter aus dem Beispiel wusste, dass Variante sieben einen eigenen Mengenrabatt braucht. An dieser einen Ausnahme hängt, ob das ganze Formular brauchbar ist. In keinem Lastenheft steht sie, weil sie demjenigen, der sie kennt, selbstverständlich erscheint.

Zweitens: Man kann sagen, was eine Festlegung später auslöst. Was passiert mit dem Zuschlag, wenn eine Bestellung geteilt geliefert wird? Wer diese Frage vorher stellt, baut den Fehler gar nicht erst ein.

Drittens: Man verwirft die naheliegende Lösung, wenn sie den Fall nur halb trifft. Genau daran scheitern die meisten Beschreibungen, weil die halbe Lösung schneller fertig ist und im Test funktioniert.

Diese Fähigkeit ist ungleich verteilt

Abschluss und Berufsjahre sagen nichts darüber aus. Entscheidend ist, wie genau jemand sein eigenes Geschäft durchschaut und wie diszipliniert er es aufschreiben kann. Kein Werkzeug erzeugt sie. Werkzeuge verstärken nur, was an Klarheit schon da ist. Wie sich der Beruf des Entwicklers dadurch verändert, behandelt der Beitrag Vom Code-Schreiber zum Code-Verantwortlichen.

Acht Fragen, bevor Sie selbst anfangen

Diese Fragen klären, ob ein Vorhaben in die Kategorie fällt, die Sie selbst erledigen, oder in die, bei der Sie jemanden dazuholen sollten. Sie gehören an den Anfang, nicht ans Ende.