Dreißig Jahre lang gab es eine stille Übereinkunft darüber, wer Software macht: der, der tippt.
Was sich verschoben hat
Ausgesprochen wurde diese Übereinkunft selten; sie stand einfach in den Organigrammen, in den Stellenprofilen, in jeder Schätzung. Wer die Sprache beherrschte, in der die Maschine antwortet, hielt den Schlüssel zur Werkstatt. Alles davor — zuhören, klären, aufschreiben — hieß Vorarbeit. Nützlich. Aber nicht der Ort, an dem etwas entstand.
Diese Übereinkunft hatte einen guten Grund, und der Grund war Zeit. Zwischen einer Idee und etwas Laufendem lagen Wochen. Wochen sind teuer, also lag der Engpass dort, wo die Wochen vergingen: beim Bauen. Fast jede Methode der letzten drei Jahrzehnte ist eine Antwort auf genau diesen einen Engpass — Wiederverwendung, Frameworks, Automatisierung, kürzere Zyklen. Alle drehen an derselben Schraube.
Die Wochen sind weg. Wer einem Agenten heute einen sauberen Auftrag gibt, hat wenige Minuten später etwas, das startet, das Tests mitbringt und das man auseinandernehmen kann. Nicht bei jeder Aufgabe, nicht in jedem gewachsenen System, nicht ohne jemanden, der das Ergebnis liest. Aber bei genug Arbeit, dass die Rechnung kippt.
Daraus folgt nicht, dass Entwicklerinnen und Entwickler überflüssig werden, und das ist keine Höflichkeitsformel. Architektur bleibt schwer. Ein Fehler, der nur unter Last und nur im Zusammenspiel dreier Systeme auftritt, bleibt schwer. Die Entscheidung, welche Abhängigkeit man sich für die nächsten fünf Jahre einhandelt, bleibt schwer. Was aufgehört hat, ist etwas Engeres, aber Folgenreiches: Allgemeines Programmieren ist nicht mehr der Engpass. Es ist reichlich vorhanden, es ist schnell, und es wartet.
Ein Engpass verschwindet nie, er wandert. Dieser ist eine Station nach vorn gewandert: zu dem, was in den Auftrag hineingeht. Ein Agent verstärkt die Qualität seiner Vorlage — nach oben wie nach unten, und beides mit derselben Geschwindigkeit. Wie das im Einzelnen wirkt, steht in KI-getriebene Entwicklung beginnt vor dem Prompt. Hier geht es um die Folge daraus, und die ist unbequemer. Wenn die Vorlage entscheidet, dann entscheidet der Satz.
Nicht das, was du gemeint hast. Das, was dasteht.
Der Satz als Werkstück
Ein Satz in einer Mail ist ein Signal an einen Menschen. Er darf ungefähr sein, weil am anderen Ende jemand sitzt, der nachfragen kann, der den Kunden seit vier Jahren kennt und die letzten drei Termine im Kopf hat. Ungefähr reicht, weil ein Mensch die Lücke füllt, meist ohne es zu bemerken. Genau deshalb fällt niemandem auf, wie viele Lücken es sind.
Ein Satz, aus dem gebaut wird, ist ein anderer Gegenstand. Er trägt drei Dinge mit sich, die der Mailsatz nicht hat. Eine Herkunft: wer das verlangt hat, und in welchem Zusammenhang. Einen Umfang: was dazugehört und was ausdrücklich nicht. Einen Zustand: ob er Entwurf ist, in Prüfung, genehmigt oder geliefert. Erst mit diesen drei Angaben hört er auf, eine Meinung zu sein, und wird zu etwas, das weitergegeben werden kann, ohne dass sein Autor mitgeht.
WIE ES ANKOMMT
„Das Rechnungsmodul muss flexibler werden.“
WIE ES BAUBAR WIRD
„Buchhaltung stellt für einen Kunden mit mehreren Projekten eine Sammelrechnung je Quartal, mit Einzelnachweis je Projekt.“
Der Unterschied zwischen den beiden Fassungen ist nicht die Länge, und er ist auch keine Frage des Stils. Die erste beschreibt ein Gefühl über eine Software. Die zweite nennt jemanden, der etwas tut, eine Lage, in der er es tut, und ein Ergebnis, das man ansehen kann. Damit kann die zweite falsch sein — und das ist ihr eigentlicher Wert. Ein Satz, der falsch sein kann, ist ein Satz, aus dem sich bauen lässt. Die erste Fassung kann nicht falsch sein; sie kann nur enttäuschen, drei Monate später, im Review.
„Flexibler“ ist kein Mangel an Fleiß. Es ist die ehrliche Zusammenfassung von etwas, das jemand noch nicht zu Ende gedacht hat — und die Arbeit, es zu Ende zu denken, ist die Arbeit, um die es hier geht; sie besteht aus zwei Rückfragen, fünf Minuten am Telefon und der Bereitschaft, sich festzulegen. Dieselben zwei Rückfragen kosten in der Umsetzung zwei Tage, weil dann schon jemand geraten hat. Ein Agent rät schneller und überzeugender als jeder Mensch.
Am schwersten fällt dabei die zweite Hälfte des Umfangs: das ausdrückliche Nicht. Kein Mensch schreibt gern auf, was nicht dazugehört, weil es sich nach Kleinlichkeit anfühlt und weil jede Verneinung eine Entscheidung ist, die man später verteidigen muss; sie ist trotzdem der wirksamste Satz im ganzen Dokument. „Ohne Teilzahlungen, ohne Fremdwährung, ohne Storno über Quartalsgrenzen“ verhindert drei Wochen Arbeit, die niemand bestellt hat — und drei Wochen, die heute nicht mehr in Wochen anfallen, sondern in einem Nachmittag, an dem alles davon gebaut wurde.
Was daraus folgt
Diese Arbeit hat nie einen guten Namen gehabt. „Requirements Engineering“ klingt nach Formularen. „Anforderungsmanagement“ klingt nach jemandem, der Listen pflegt. Beides beschreibt eine Zuarbeit, und beides ist der Grund, warum die Tätigkeit dreißig Jahre lang unterhalb der Stelle stattfand, an der entschieden wurde.
Was sie tatsächlich ist, hat einen älteren Namen: Autorschaft. Jemand entscheidet, was dasteht. Neu daran ist nicht die Tätigkeit, neu ist ihre Lage. Zum ersten Mal steht sie auf dem kritischen Pfad — nicht davor. Was du aufschreibst, wird gebaut, ziemlich genau so, und ziemlich schnell.
Das verlangt drei Dinge, und keines davon ist Fleiß. Erstens Genauigkeit statt Vollständigkeit: Zwanzig scharfe Sätze schlagen zweihundert weiche. Zweitens die Bereitschaft, sich festzulegen — wer keinen Satz schreibt, der falsch sein könnte, hat nichts geschrieben. Drittens die Herkunft mitzuführen: Ein Satz ohne die Frage „Wer wollte das, und warum?“ ist nach dem nächsten Personalwechsel Müll, weil niemand mehr entscheiden kann, ob er noch gilt. Woran man merkt, dass diese Kette gerissen ist, steht in Warum Anforderungen scheitern.
Es verlangt auch etwas Unangenehmeres. Wer Autor ist, ist verantwortlich. „So war das nicht gemeint“ verliert seine Kraft, wenn das Gebaute exakt das ist, was dastand. Diese Verschiebung ist der Preis der neuen Stellung, und sie ist ihr Beweis: Verantwortung trägt nur, wer etwas zu entscheiden hat.
Und es ist erlernbar. Es hat Werkzeug, es hat wiederkehrende Fehlerbilder, es hat Übung, die wirkt. Deshalb steht am Anfang dieses Textes das Wort Handwerk und nicht das Wort Talent. Wie sich das an einem gewöhnlichen Arbeitstag anfühlt, statt als Methode gelesen zu werden, steht in Ein Tag als Product Owner.
Und was noch nicht existiert
Im Bau Drei Dinge, die zu diesem Argument gehören, gibt es in angajuu heute nicht, und es ist ehrlicher, sie zu nennen, als sie zu umschreiben. Abnahmekriterien als eigene Daten: Ein Satz kann heute beschreiben, woran man seine Erfüllung erkennt, aber nur als Fließtext in seiner Beschreibung — nicht als geprüfte, einzeln abhakbare Bedingung. Die Übergabe an eine Entwicklungsumgebung über MCP, also ein Zugang, über den ein Agent die Anforderungen live liest, statt eine Kopie zu bekommen: nicht gebaut, keine Zeile davon. Und die Änderungs-Propagation: Wenn du heute eine Kundenanforderung umschreibst, passiert mit den daran hängenden Produktanforderungen nichts — sie werden nicht markiert, niemand wird benachrichtigt, und die Abdeckung rechnet weiter mit den Verknüpfungen, nicht mit dem Text. Das sind die drei Stellen, an denen die Idee dieses Textes weiter reicht als das Werkzeug.
Was es gibt, ist der Anfang derselben Linie: ein Ort, an dem der Satz einmal steht — mit seiner Herkunft und seinem Zustand — und eine Schranke, die ihn nicht weiterlässt, solange die Herkunft fehlt oder die Beschreibung zu dünn ist. Das ist wenig, gemessen an dem, was kommen muss. Es ist viel, gemessen an einer Tabelle mit dem Dateinamen „final_v2“.
Die Übereinkunft der letzten dreißig Jahre war nicht falsch; sie war eine vernünftige Antwort auf knappe Zeit beim Bauen. Diese Zeit ist nicht mehr knapp. Knapp ist jetzt der Satz, der genau genug ist, dass man ihn bauen kann — und die Person, die ihn schreibt, macht Software. Auch wenn sie nicht tippt.