Deutsch ist keine Programmiersprache

Im Zeitalter von Agentic Development wird menschliche Kompetenz(bündelung) zum Zünglein an der Waage.TippaPatt | shutterstock.com



Ein paar Stichworte mit Ideen in ein Chatfenster kopiert, und kurz darauf erzeugt Codex, Claude Code oder ein anderer Agent mit Programmierfähigkeiten eine lauffähige Anwendung. Das ist sehr vereinfacht dargestellt, hat aber einen wahren Kern: Wer heute Software entwickelt, kann zunehmend größere Teile des Codes von Agenten erzeugen lassen. Erste lauffähige Versionen entstehen so inzwischen in Stunden, nicht in Tagen oder Wochen.



Jahrzehntelang war Code zu schreiben einer der wesentlichen Engpässe der Softwareentwicklung. Das ändert sich gerade: Zwar bleibt es eine Herausforderung, gute Software zu entwickeln, aber unter anderen Vorzeichen. Denn wenn Programmieren mit deutlich geringerem Aufwand möglich ist, gewinnt die Frage „Was sollen wir überhaupt bauen?“ eine viel größere Bedeutung. Um die Antwort darauf zu finden, müssen in Projekten vor allem zwei Fähigkeiten zusammenkommen: Verständnis und Präzision.



Die Grundlagen für Agentic Development



Verständnis meint, das Fachproblem wirklich zu durchdringen. Einige Fragen sind in fast allen Projekten ähnlich. Etwa: Wie sieht ein Warenkorb aus? Wie läuft eine Anmeldung ab? Ein Agent kann für solche Grundfunktionen auf bekannte technische Muster zurückgreifen.



Für andere Fragen findet das Unternehmen individuelle Antworten – zum Beispiel, ab ein Kunde als langjährig gilt, welcher Rabatt ohne Freigabe erlaubt ist oder wann Tempo Vorrang vor vor Sicherheit hat. Die Antworten auf diese Fragen kennt kein Modell von sich aus. Sie stecken im Geschäft, im Erfahrungswissen und in konkreten Vorgängen. Manchmal sind sie in definierten Prozessen festgehalten, manchmal stehen sie nur zwischen den Zeilen oder existieren lediglich in den Köpfen der Beteiligten.



Der Agent mag aus seinen Trainingsdaten die Muster tausender Schnittstellen erkennen. Aber dass Großkunde X nie automatisch gemahnt wird, weil die Geschäftsführung das persönlich abklärt, kann er nicht automatisch aus dem Trainingskorpus ableiten. An dieser Stelle unterscheidet sich Agentic Development kaum von klassischer Softwareentwicklung: Dieses unternehmensspezifische Wissen muss ins Projekt einfließen, nur dann können Entwickler und Agent auch damit arbeiten.



Tiefgehendes Verständnis war schon immer wichtig, um exzellente Software zu entwickeln – und gewinnt nun weiter an Bedeutung.



Weniger diskutiert wird der zweite Aspekt: die Präzision in der Sprache. Präzision meint hier nicht die Eindeutigkeit einer Programmiersprache. Nicht das Semikolon am Zeilenende, nicht die exakt gesetzten Klammern. Diese Eindeutigkeit ist angesichts der Fähigkeiten von Agenten immer seltener nötig. Präzision meint vielmehr, sich um Klarheit zu bemühen. Die Beteiligten müssen Anforderungen strukturieren, Annahmen aussprechen, Grenzen ziehen, das Wesentliche vom Beiläufigen trennen.



Wer das Ziel eines Projektes in Worte fasst, lässt zwangsläufig Spielraum für Interpretation. Und hier spielen Agenten ihre Stärke aus: In ihren Trainingsdaten finden sie die Grundlagen, um natürliche Sprache zu deuten, diesen Spielraum zu füllen und auf dieser Basis Code zu schreiben. Das erspart den Beteiligten, jedes Detail buchstabieren zu müssen. Diese Stärke hat jedoch auch eine Kehrseite. Ob der Agent den Spielraum im Sinne des Projektziels füllt oder lediglich auf Grundlage wahrscheinlicher Muster, ist ungewiss.



Die Beteiligten müssen es deshalb prüfen. Genau darum kommt klaren Formulierungen in der agentischen Welt so viel Bedeutung zu. Eine gute Entwicklerin oder ein guter Entwickler ist ein Korrektiv für mangelnde Präzision: Sie erkennen Lücken und hinterfragen diese. Ein Agent kann das Gegenteil sein: ein Verstärker. Im ungünstigen Fall erkennt er die Lücke nicht als Lücke, fragt nicht nach, sondern baut einfach. Das Risiko ist dann nicht eine Software mit Bugs, sondern eine Software mit Annahmen, die so niemand getroffen hat. Die Anwendung mag technisch sauber laufen, die fachliche Abweichung fällt vielleicht erst viel später auf.



Was klingt wie der Ratschlag eines Lehrers im Deutschleistungskurs, wird deshalb zur wichtigen Kompetenz in der agentischen Softwareentwicklung. Und genau hier greifen viele Unternehmen zu kurz. Sie reduzieren KI-Kompetenz auf den Umgang mit Werkzeugen und behandeln sie wie die Einführung einer neuen Software: Mitarbeitende lernen Funktionen kennen, üben typische Fälle und setzen sich mit den Regeln für Datenschutz und Sicherheit auseinander.



Das ist nötig, bildet aber nur einen Teil ab. Der Umgang mit KI in der Softwareentwicklung erfordert mehr. Unternehmen müssen dabei jedoch nicht bei null anfangen. Viele Rollen, die seit Jahren zwischen Fachlichkeit und Technik vermitteln, bringen genau diese Fähigkeit mit. Dazu gehören Requirements Engineers, Business-Analysten, Product Owner oder Softwarearchitekten.



Sie durchdringen von Haus aus unscharfe Anliegen, sprechen Annahmen aus und machen Zielkonflikte sichtbar. Genauso wichtig sind erfahrene Fachleute – die Menschen, die wissen, warum ein Prozess an einer bestimmten Stelle anders läuft als im Handbuch. Heute ist diese Kompetenz über einzelne Köpfe und Projekte verstreut. Sie zu bündeln und zu einer Stärke der Organisation zu machen, darn besteht die eigentliche Aufgabe.



3 Wege, Präzision zu organisieren



Die Beschreibung war schon immer eine Grundlage der Softwareentwicklung. Im HInblick auf Agentic Development wird sie zusätzlich zu einem eigenständigen Artefakt: Sie ist Teil des Materials, aus dem die Anwendung entsteht, und beeinflusst unmittelbar, was der Agent baut. Ihre Qualität dürfen Unternehmen deshalb nicht dem Sprachgefühl einzelner Menschen überlassen.



Es geht nicht um formale Eindeutigkeit, sondern darum, Klarheit zu einer wiederholbaren Leistung der Organisation zu machen. Das können Verantwortliche auf drei Wegen organisieren.



1. Die Beschreibung als gemeinsame Aufgabe anlegen



Anforderungen sind keine Vorarbeit, die ein Fachbereich formuliert und anschließend über den Zaun zur IT wirft. Eine belastbare Beschreibung entsteht gemeinschaftlich: Der Fachbereich kennt Ziel und fachliche Regeln. Die IT kennt technische Abhängigkeiten. Die Architektur sieht die Folgen für das Gesamtsystem. Compliance und Datenschutz setzen Grenzen. Der Betrieb kennt die Anforderungen an Stabilität und Wartbarkeit.



Jede Perspektive schärft dabei einen anderen Teil der Beschreibung.



2. Standards für Beschreibungen schaffen



Unternehmen brauchen ein gemeinsames Verständnis davon, was eine tragfähige Beschreibung enthält: das Ziel, den fachlichen Kontext, die relevanten Daten, die Regeln und Grenzen, dazu Beispiele und Gegenbeispiele und die Kriterien, an denen sich ein gutes Ergebnis erkennen lässt.



So wird aus dem Sprachgefühl Einzelner ein wiederholbarer Prozess. Dabei geht es nicht darum, jede Unschärfe zu tilgen, sondern darum, das Anliegen so klar zu fassen, dass der Agent den Rest verlässlich ergänzen kann. Dafür brauchen Verantwortliche eine Art “Unternehmensgrammatik”. Keine neue formale Sprache, sondern gemeinsame Strukturen, mit denen aus einem unscharfen Anliegen ein klarer Arbeitsauftrag wird.



3. Beschreibungen so ernst nehmen wie Software



Eine Beschreibung ist gut, wenn das erzeugte Ergebnis im vorgesehenen Kontext funktioniert. Ob das gelingt, zeigt sich an der laufenden Anwendung: Was hat der Agent falsch verstanden? Wo fehlte eine Information? Welche Regel war mehrdeutig? Erkenntnisse aus dieser Prüfung fließen zurück in eine bessere Beschreibung.



Unternehmen sollten Beschreibungen deshalb behandeln wie Code: Testen, versionieren, verbessern und wiederverwenden. Dazu gehören klare Verantwortlichkeiten: Wer entscheidet über fachliche Annahmen? Wer gibt das Ergebnis frei? Wer trägt die Verantwortung, wenn eine plausible Annahme fachlich falsch war? So entsteht mit der Zeit eine Fähigkeit, die dem Unternehmen bleibt, statt mit dem Projekt zu verschwinden.



Es bleibt festzuhalten: Deutsch ist keine Programmiersprache, aber wer sein Fachproblem nicht präzise genug versteht und beschreibt, bekommt vom Agenten präzise das Falsche geliefert. (fm)



Dieser Beitrag wurde im Rahmen des deutschsprachigen Experten-Netzwerks von Foundry veröffentlicht. Lust mitzumachen? Jetzt bewerben!