Domain-Expertise war schon immer der echte Burggraben
(brethorsting.com)- Die Schwierigkeit in der Softwareentwicklung lag nicht im Eingeben von Code, sondern darin, reale Regeln wie Gehalt oder Verkehr zu verstehen und daraus ein Domain-Modell zu bilden; der Code war das Ergebnis dieses Verständnisses
- Agentische KI macht Softwareproduktion auch ohne Domain-Verständnis möglich und verschiebt den Engpass von „Kann man es bauen?“ zu „Kann man beurteilen, ob es richtig ist?“
- Domain-Expert:innen wie Logistik-Disponent:innen, klinische Kodierfachkräfte oder Versicherungsmathematiker:innen können auch ohne Codekenntnisse beurteilen, ob Ausgaben zu gesetzlichen, Abrechnungs- und Betriebsregeln passen
- Generalistische Ingenieur:innen können Architektur und Zuverlässigkeit prüfen, aber in Bereichen wie klinischer Kodierung, in denen die richtige Antwort an Domain-Wissen gebunden ist, können sie plausibel wirkende Fehler übersehen
- Die wertvollste Fähigkeit ist Urteilsvermögen: zugleich die Solidität des generierten Codes und die Wahrheit der Ausgabe zu validieren; für erfahrene Ingenieur:innen wird die Investition in Domain-Expertise wichtiger
Der Engpass in der Softwareentwicklung verschiebt sich von der Implementierung zur Validierung
- Der schwierige Teil beim Schreiben von Software war nicht das Tippen von Code selbst, sondern zuerst ein Domain-Modell im Kopf aufzubauen
- In einem Gehaltssystem stecken Lohnpfändungen, Vorsteuerabzüge und die Behandlung von Abrechnungszeiträumen, wenn sie den Zeitpunkt einer Lohnänderung überschneiden
- In einer Verkehrs-App sind GTFS-Feeds, der Unterschied zwischen trip und route und die Gründe abgebildet, warum ein „pünktlicher“ Bus trotzdem noch falsch sein kann
- Code war das Ergebnis der Übertragung dieses Verständnisses, und das eigentliche Arbeiten bestand darin, dieses Verständnis zu erwerben
- Agentische KI schwächt die Verbindung zwischen Domain-Verständnis und Softwareproduktion
- Jetzt kann man Software produzieren, ohne selbst direkt ein Domain-Modell zu erstellen
- Damit gerät eine Grundannahme ins Wanken, auf der ganze Softwareberufe beruhten
- Wie in der Perspektive vom letzten Jahr beschrieben, stimmt die Erklärung, dass solche Tools urteilsstarke Senior-Entwickler:innen verstärken, aber sie reicht nicht aus
- Die konkretere Veränderung ist, dass sich der Engpass von „Kann man es bauen?“ zu „Kann man beurteilen, ob es richtig ist?“ verschoben hat
Wer agentische Tools gut nutzt
-
Domain-Expert:innen können die richtige Antwort erkennen, auch ohne Code zu kennen
- Menschen wie Logistik-Disponent:innen, klinische Kodierfachkräfte oder Versicherungsmathematiker:innen können vielleicht keinen Stack Trace lesen und den Unterschied zwischen hash map und list nicht erklären
- Aber wenn sie einen vom Agenten erzeugten Plan sehen, wissen sie sofort, welcher Fahrer diese Schicht rechtlich nicht übernehmen darf
- Sie können auch erkennen, dass ein Versicherungsanspruch mit einer bestimmten Code-Kombination nicht erstattet wird
- Sie haben zehn Jahre mit Ein- und Ausgaben verbracht und kennen deshalb die korrekte Ausgabe für gegebene Eingaben
- Was der Agent ihnen liefert, ist die Fähigkeit zur Codeproduktion, die ihnen fehlte; was sie dem Agenten bringen, ist der Ground Truth-Maßstab, den ihm fehlt
-
Generalistische Ingenieur:innen können gut gebaute Software mit korrekter Software verwechseln
- Starke generalistische Ingenieur:innen verstehen Architektur, Zuverlässigkeit, Tests und wie man verhindert, dass ein System um 2 Uhr nachts zusammenbricht
- Aber in Domains wie klinischer Kodierung können sie plausible, aber falsche Antworten womöglich nicht von richtigen unterscheiden
- Ein Agent kann Code erzeugen, der kompiliert und die Tests besteht, die sich Ingenieur:innen ausgedacht haben, und trotzdem subtile, teure Fehler in Abrechnungsregeln produzieren
- Ingenieur:innen können validieren, ob Software gut gebaut ist, aber wenn Korrektheit vollständig durch eine Domain definiert wird, die sie nicht im Kopf haben, ist Genauigkeit schwer zu prüfen
-
Vor Agenten gab es für Ingenieur:innen einen vorteilhaften Lernpfad
- Ingenieur:innen konnten Expert:innen begleiten, Spezifikationen lesen, im Betrieb Fehler machen und die Domain langsam lernen
- In vielen Bereichen war dieser Prozess ein zentraler Teil der Karriereleiter
- Für Domain-Expert:innen gab es keinen symmetrischen Pfad
- Zu lernen, wie man verlässliche Software baut, dauert Jahre und war für sie praktisch ein schwer zugänglicher Weg
-
Agentische Tools haben nur eine Seite dieses Pfads eingerissen
- Die Fähigkeit von Ingenieur:innen, Domain-Modelle in funktionierenden Code zu übersetzen, ist billig geworden
- Die Fähigkeit von Domain-Expert:innen zu wissen, was richtig ist, ist nicht billig geworden
- Diese Fähigkeit lässt sich nicht einfach per Prompt erwerben, und es gibt keine skill file, die das implizite Wissen von jemandem enthält, der tausende Gehaltsabrechnungen korrekt abgewickelt hat
-
Am wertvollsten sind Menschen, die auf beiden Ebenen validieren können
- Am wichtigsten werden jene, die wissen, ob generierter Code solide ist, und zugleich, ob die Antworten dieses Codes wahr sind
- Dass man einen Test wie „Ein Fahrer darf 11 Stunden nicht überschreiten“ schreiben kann, liegt daran, dass man die Regel kennt
- Dass man beurteilen kann, ob dieser Test selbst sinnvoll ist, liegt daran, dass man weiß, was überhaupt getestet wird
- Der Agent übernimmt das Übertragen; der Mensch übt auf der Code- und auf der Domain-Ebene Urteilsvermögen aus
- Für erfahrene Ingenieur:innen ist die wichtigste Investition, ein tiefes und validiertes Modell der realen Domain zu erwerben
- Der Wert der mechanischen Fähigkeit, eine klare Idee in sauberen Code zu übersetzen, ist stark gesunken
- Weiterhin knapp ist tiefes Verständnis realer Branchen, Tools, regulatorischer Systeme und physischer Prozesse
- Man sollte eine Domain auswählen und sie so lernen, wie man früher Programmiersprachen oder Frameworks gelernt hat
- Der Teil, den Agenten nicht ersetzen können und dessen Wert jetzt am stärksten steigt, ist Domain-Expertise
Möchten Sie weitere kuratierte Tech-Themen erhalten?
Folgen Sie dem Telegram-Kanal. @GeekNewsDE
1 Kommentare
Hacker-News-Kommentare
Ich weiß nicht, wie viele langatmige Abhandlungen es noch braucht, bis man anerkennt, dass niemand weiß, wie man AI auf individueller Ebene einsetzen sollte
Erst hieß es, es reiche, ein guter Entwickler zu sein und den Umgang mit AI zu lernen, dann war es plötzlich die Fähigkeit zur Architekturplanung, dann wiederum sollte Geschmack alles entscheiden, und jetzt heißt es, nur Domänenexperten seien wichtig
Solange Verbesserung oder Stagnation von AI nicht in einen stabilen und vorhersagbaren Zustand übergehen, sind solche Deutungen weiterhin bedeutungslos und werden größtenteils wahrscheinlich falsch sein
Sie machen es schwieriger, weil sie die Messlatte dessen, was möglich ist, massiv anheben. Einzelne Entwickler können dadurch viel anspruchsvollere Projekte übernehmen, und die eigentliche Einschränkung war am Ende immer die Zeit; AI hilft dabei, in der gegebenen Zeit mehr zu schaffen
Aber genau das, was man in dieser Zeit schaffen kann, ist selbst viel schwieriger geworden. Man muss viel mehr verstehen und sich deutlich weiter aus der vertrauten Komfortzone der Zeit vor AI herauswagen
Früher war es akzeptabel, einige Tage damit zu verbringen, ein Codebase zu refaktorieren oder ein kleines Feature für den Release vorzubereiten, weil es um einen ungewohnten Systembereich ging oder man erst eine neue Library lernen musste
Dank Coding-Agenten kann man diese Lernkurve viel schneller erklimmen, aber man muss sie immer noch selbst erklimmen. Und die Menge an Informationen, die auf einen einströmt, ist viel größer
Wenn du Angst hast, dass dir nichttechnische Vibe-Coder den Job wegnehmen, ist die richtige Antwort, deutlich bessere Software zu bauen als sie. Dafür braucht man mehr Können, mehr Ehrgeiz und mehr Erfahrung, und das ist nicht leicht
Die passendste Analogie dafür ist für mich bisher der Vergleich zwischen einem modernen Akku-Bohrschrauber und alten Geräten wie Schraubendreher oder Handbohrer
Im Vergleich zu den alten Werkzeugen kann man in sehr kurzer Zeit erstaunliche Ergebnisse erzielen
Zum Beispiel sind dann erstaunliche Geschichten möglich wie: „Ich habe die Befestigung des Bodens, die sonst den ganzen Tag gedauert hätte, in einer Stunde erledigt und zwischendurch sogar mehrmals eine geraucht.“ Mit einer Nagelpistole wäre es vielleicht in der halben Zeit gegangen, aber später ließe sich der Boden dann nur schwer wieder anheben, und es hätte womöglich doppelt so viel gekostet
Ich nutze auch mehrere On-Premises-LLMs und habe Zugriff auf andere Modelle, daher werde ich diese Analogie irgendwann wohl noch auf Markenunterschiede ausweiten
Aber ich glaube nicht, dass ich mir deshalb einen neuen Job suchen muss. Ein Akku-Bohrschrauber ist weder Zimmermann noch Bauarbeiter, und ohne Menschen ist er nutzlos
Ich gehe davon aus, dass wir in 20 Jahren den gemeinsam mit Claude erzeugten Müll aufräumen werden
https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
2018 habe ich gesehen, wie jemand ohne jede Coding-Erfahrung allein deshalb ein Tool baute, das ziemlich gutes Geld einbrachte, weil diese Person einen bestimmten Nischenmarkt kannte und einen Monat lang daran programmierte
Die Person zeigte mir einen Teil des Codes; er war fast so chaotisch wie mein erstes Programm, aber er löste ein echtes Problem
Zum Beispiel sagen sie: „Um gut in Sport zu sein, braucht man perfekte Symmetrie, und die korreliert stark mit stabiler Entwicklung im Mutterleib. Je symmetrischer, desto perfekter die Entwicklung.“
Ein paar Jahre später hört man dann, dass Bruce Lee ein Bein hatte, das deutlich kürzer war als das andere, und Usain Bolt eine ähnliche asymmetrische Entwicklung aufweist
Dann reden sie sich heraus, das seien Ausnahmefälle und änderten nichts an der allgemeinen Regel, und decken damit ihre ursprüngliche Behauptung zu
Man kann auch einfach etwas Interessantes bauen, und vielleicht wird es erfolgreich
Ich habe kürzlich eine App geprüft, die fast vollständig per Vibe Coding gebaut worden war. Der Eigentümer meinte, sie sei praktisch releasebereit und brauche nur noch einen kurzen Check
Beim Durchsehen stellte sich heraus, dass das Datenbankdesign ein Desaster war. Manche Funktionen liefen, andere nicht. Ich erklärte, was fehlte und warum bestimmte Dinge kaputtgingen. Wie im ursprünglichen Beitrag war diese Person ein Domänenexperte
Allein im letzten Monat wurden Milliarden von Tokens verbraucht, und die Tools werden schnell besser. Aber nur weil man einem Domänenexperten AI gibt, braucht man nicht plötzlich keine Softwareingenieure mehr
Domänenexperten können mit AI Software bauen, und Softwareingenieure können mit AI die Domäne lernen. Beide bringen unterschiedliche Fachlichkeit mit
Es geht darum, Guardrails, Validierung, Prompt-Bibliotheken, Agenten und manuelle Reviews zu bauen, die Domänenexperten absichern, wenn sie anfangen, Coding-Agenten einzusetzen
Das ist ein bisschen wie interner T2/T3-Kundensupport oder Support Engineering. Man löst nicht unbedingt 100 % der Alltagsprobleme selbst, sondern fängt riskante Stellen und seltsame Grenzfälle ab und prüft, ob alles korrekt eingerichtet ist
Natürlich befasst man sich dabei auch mit vielen bereichsübergreifenden Themen
Als Werkzeug, um neue Ideen schnell auszuprobieren und tiefer zu verfolgen, sind sie allerdings großartig. Wenn man neugierig ist, können sie sogar ein hervorragender Lernbeschleuniger sein
Ich nutze den ganzen Tag Claude Code (Opus 4.6, Einstellung „maximaler Aufwand“) und verstehe trotzdem nicht, wie das möglich sein soll. Mich würde auch interessieren, ob sich dieser Verbrauch tatsächlich auszahlt
Wahrscheinlich übersehe ich etwas, aber ich verstehe wirklich nicht, wie das zustande kommt
Ich habe kürzlich ein sehr gutes Beispiel dafür erlebt
Ich war auf einem Angelausflug und fragte den Kapitän, ob er sich meine kostenlose App ansehen wolle, an der ich arbeite (https://oceanconnect.ca), um zu sehen, ob sie ihm bei der Arbeit helfen könnte
Ich weiß nicht besonders gut, wie Menschen auf See Meeresdaten nutzen. Ich weiß nicht genau, was sie wissen wollen oder warum. Es kamen nur so Fragen und Informationen darüber heraus, wie Menschen Daten verwenden und was wir mit Daten machen können, und ich war darauf überhaupt nicht vorbereitet; diese Perspektive zu bekommen, war wirklich großartig und interessant
Es hat mich wieder daran erinnert, dass ein Modell nicht dasselbe ist wie das System, das es abstrahiert, und dass das Wissen, ein Modell zu entwickeln, fast nichts mit dem Wissen zu tun hat, es zu benutzen
Dieser Mensch hatte ein enormes Wissen darüber, wie man auf dem Wasser Wetterdaten nutzt. In gewisser Weise kannte er die Daten besser als ich, und auch wenn ihm das vielleicht nicht bewusst war oder er die digitale Darstellung nicht verstand, hätte er, wenn er nur programmieren könnte, wahrscheinlich viel bessere nützliche Apps für Leute wie sich selbst bauen können
Ich dachte, dass solche Menschen mit einem LLM vor sich wirklich Großartiges bauen könnten, wenn sie ihre Ideen auf den Bildschirm bringen. Wenn ich irgendwann Finanzierung habe, würde ich gern Menschen interviewen, die jeden Tag aufs Meer hinausfahren, um das Produkt zu verfeinern. Dieses Domänenwissen ist sehr speziell, und Menschen, die jahrzehntelang in komplexen Domänen gelebt haben, wissen Dinge, auf die man niemals kommen würde
Auch der in diesem Artikel beschriebene Software-Generalist hat Domänenexpertise. Diese Domäne ist Software
Wenn man heute ein herausragender generalistischer Softwareingenieur ist, springt man nicht einfach in irgendeine zufällige Domäne, nur um AI zu vermeiden. Software ist die eigene Domäne, und man bleibt darin, während sich diese Domäne erweitert und verändert
Vielleicht ist die gute Nachricht, dass selbst der beste Spreadsheet-Kunsthandwerker unter den Buchhaltern im Westen am Ende doch ein gewisses Maß an Programmiererfahrung braucht, um Dinge zu validieren
Man kann ein LLM fragen: „Was macht dieser Code, und gilt bei Y immer X?“, aber das verschachtelt nur ein Verifikationsproblem in ein anderes Verifikationsproblem
Der Kern war von Anfang an nicht der Code
Ich baue seit fünf Jahren Software für Venture-Capital- und Private-Equity-Firmen, und dieser Artikel hat bei mir wirklich einen Nerv getroffen. Code schreiben ist mit Abstand der einfachste Teil meiner Arbeit; der schwierige Teil ist Financial Engineering und der feine Kontext, die nötig sind, um zu verstehen, was die Kundenunternehmen tatsächlich brauchen
Wir scherzen oft, dass wir, wenn möglich, lieber einen Senior-Fondsbuchhalter einstellen und ihm das Programmieren beibringen würden. Das Problem ist, dass es solche Leute kaum gibt. Es ist auch schwer, einem Ingenieur die Details der Fondsbuchhaltung so weit beizubringen, dass er sie in Software umsetzen kann
Tatsächlich bestand etwa die Hälfte meiner Karriere darin, Dinge aufzuräumen, bei denen „genug Domänenwissen vorhanden war, um Tickets oder Epics zu schließen, am Ende aber viele technische Schulden hinterlassen wurden“
Selbst mit Domänenwissen machen Menschen zum Beispiel Fehler, kennen keinen besseren Weg, nehmen Feedback nicht auf oder, schlimmer noch, prüfen nicht noch einmal nach, was ein Coding-Agent geschrieben hat; deshalb musste ich PRs sehr gründlich reviewen
Ich habe auch viel Zeit damit verbracht, Dinge zu refaktorieren, die „technisch korrekt waren, aber so miserabel geschrieben, dass sie Timeouts verursachten oder Manager/DBA zum Schreien brachten“
Ein wirklich guter Softwareingenieur hat die Fähigkeit und den Willen, die Domäne zu lernen, aber es muss auch einen Weg geben, sie zu lernen. Ich war in Firmen, Teams und mit Kollegen, die das ermöglicht haben, und in anderen, wo alle nur behaupteten, es sei wichtig, man es am Ende aber nur aus JIRA und aus den Bemerkungen von Nicht-IT-Abteilungen in Meetings erraten sollte
Der große Paradigmenwechsel der letzten fünf Jahre ist meiner Meinung nach, dass die meisten Unternehmen erwarten, dass Menschen bis an ihre Grenzen arbeiten, und dadurch paradoxerweise gerade die Zeit für wichtige Gespräche verhindern
Kultur ist ein großer Faktor. Es gab zumindest Orte, an denen man sich kurz mit jemandem austauschen oder leicht ein Meeting ansetzen konnte, und andere, wo man das Gefühl hatte, man müsste eine Petition auf change.org starten, um Zeit für eine ordentliche Diskussion zu bekommen
Trotzdem stimmt der Kern. Am Ende sind Anforderungen wichtiger als Code. Ich habe auch erlebt, dass alle Anforderungen erfüllt waren und das Team die Designentscheidungen abgesegnet hatte, nur damit jemand, der während der gesamten Implementierung abwesend war, zurückkam und eine Funktion verzögerte, weil ihm die Art der Umsetzung nicht gefiel
Und irgendwann merkt man dann, dass ein „Batch-Prozess“ %numberOfRecord%*10 Inserts ausführt, wegen eines schlecht entworfenen Datenmodells noch zusätzliche Lookups macht und SQL-Upserts auf die denkbar falscheste Weise ausführt. Also zuerst aus der DB holen und dann, falls nichts da ist, den einzufügenden Datensatz hinzufügen. Und statt die Query-Patterns der Datenschicht neu zu durchdenken, macht man unter dem Label „Performanceverbesserung“ immer fragwürdigere Dinge. Ich habe das in meiner Laufbahn mehr als einmal gesehen
Jedes Mal, wenn ich einen sehr allgemeinen Text lese, der wie Ratschläge zum Umgang mit AI wirkt, denke ich daran, dass die Softwareindustrie der Bauindustrie ähnelt
Sie wird nie vollkommen aufgeräumt sein, nie vollständig optimiert, und sie wird immer in gewisser Weise maßgeschneidert bleiben müssen. Denn sie muss sich an eine Realität anpassen, in der Geschmack, Kontext und Regionalität extrem stark variieren
Gelegentlich können gute Werkzeuge oder Rohmaterialien auftauchen
Ich dachte, der echte Burggraben von Software liege gerade darin, dass man dafür praktisch kein breites Wissen oder Erfahrung sowohl über Systeme als auch über die Domäne benötigt
Geschmack und Netzwerkeffekte zu replizieren ist viel schwerer. Tatsächlich war es schon vor Vibe Coding selten, dass venturefinanzierte Startups mit viel Talent und Ressourcen sich wirklich im Markt festsetzen konnten
Deshalb konnten Leute in ihren Zwanzigern mit Experten aus vielen Bereichen konkurrieren. Ich glaube, der aktuelle Backlash ist die Geburt der in anderen reifen Industrien üblichen Leute mit „X Jahren Branchenerfahrung“
Ich arbeite als Analyst, und in unserer Gruppe haben etwa 20 % der Analysten starke technische Fähigkeiten, also Software-Engineering-Fähigkeiten, der Rest sind traditionelle Analysten oder Domänenexperten
Im letzten Jahr habe ich gesehen, wie nichttechnische Analysten AI-Modelle für den Entwicklungsanteil nutzen und dadurch bei der Entwicklung interner Tools produktiver werden
Früher wurde fast alles in Tableau entwickelt. Das war die zugänglichste Methode, mit der Nicht-Entwickler funktionierende Tools bauen konnten
Noch vor ein paar Tagen hat ein Analyst aus unserer Gruppe ein Tool vorgestellt, an dem er gearbeitet hatte; im Grunde war es ein Port eines Tableau-Reports in eine flexiblere App
Ich glaube, diese BI-Firmen werden in große Schwierigkeiten geraten. Besonders Firmen wie Tableau, die es fast unmöglich machen, selbst etwas Einfaches wie ein Histogramm zu zeichnen, trifft es meiner Meinung nach noch stärker
Mein Freund ist Elektroingenieur und hat kürzlich die Marke von 2000 FIDE-Elo überschritten. Er spielt seit 30 Jahren Schach und hat schon in der Highschool einen Schachclub gegründet. An der Universität hat er mit Mikrocontrollern gearbeitet und dabei ein wenig Programmieren gelernt
Ich bin eher ein Infrastruktur-/Admin-Allrounder mit Informatikabschluss und programmiere seit 30 Jahren als Hobby. Mein Lichess-Rating liegt selbst an guten Tagen bei 1000
Wir haben einen Schachbot-Wettbewerb gemacht. Es war Open Book, man durfte mit AI programmieren und auch Eröffnungsbücher, Endgame-Tablebases oder was auch immer verwenden — ein völlig freier Wettbewerb. Ich habe ihn komplett dominiert, aber im echten Brettschach habe ich ihn in 20 Jahren nur zweimal geschlagen
Er würde in der realen Welt wohl 99 % aller zufälligen Spieler schlagen, ich vielleicht nur etwa 20 %
Ich weiß nicht genau, worauf ich hinauswill, aber es fühlt sich inzwischen so an, als wäre Domänenwissen vielleicht nicht mehr alles. Oder vielleicht hat sich die Domäne selbst verändert
Du hast ihn zu einem Programmierwettbewerb herausgefordert, und du als deutlich erfahrenerer Programmierer hast gewonnen. Selbst wenn man AI verwenden durfte, war hier dein Domänenwissen meiner Ansicht nach der entscheidende Faktor