Domain-Expertise war schon immer der echte Burggraben
(brethorsting.com)- Die Schwierigkeit von Software lag nie im Eintippen 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
- Agentic AI ermöglicht die Produktion von Software auch ohne Domain-Verständnis und verlagert den Engpass von „Kann man es bauen?“ zu „Kann man beurteilen, ob es richtig ist?“
- Domain-Expert:innen wie Disponent:innen in der Logistik, klinische Kodierfachkräfte oder Versicherungsmathematiker:innen können auch ohne Codekenntnisse beurteilen, ob ein Output zu gesetzlichen, Abrechnungs- und Betriebsregeln passt
- Generalistische Ingenieur:innen können Architektur und Zuverlässigkeit validieren, 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 das Urteilsvermögen, sowohl die Solidität des generierten Codes als auch die Wahrheit des Outputs zu prüfen; für erfahrene Ingenieur:innen wird die Investition in Domain-Expertise wichtiger
Nicht das Schreiben von Code, sondern das Verstehen der Domain ist entscheidend
- Der schwierige Teil der Softwareentwicklung war nicht das Schreiben von Code, sondern zuerst ein Funktionsmodell der Domain im Kopf aufzubauen
- Code war die Transkription dieses Verständnisses, und der Prozess, dieses Verständnis überhaupt erst zu gewinnen, war die eigentliche Arbeit
-
Konkrete Beispiele
- Vor dem Launch eines Lohnabrechnungssystems musste man Lohnpfändungen (garnishment), Vorsteuerabzüge und die Behandlung von Abrechnungszeiträumen verstehen, die sich über Änderungen des Lohnsatzes hinweg erstrecken
- Vor dem Launch einer ÖPNV-App musste man lernen, was ein GTFS-Feed ist, warum sich trip und route unterscheiden und wie ein „pünktlicher“ Bus trotzdem falsch sein kann
Agentic AI kappt die Verbindung
- Agentic AI kappt die Verbindung zwischen Modellbildung und Softwareproduktion und macht es möglich, Software auch ohne Modell zu erstellen
- Damit bricht eine Grundannahme weg, auf der ganze Berufsbilder organisiert waren
- Die Perspektive vom letzten Jahr lautete, dass dieses Tool Senior-Entwickler:innen mit Urteilsvermögen verstärkt; das stimmt, ist aber unvollständig
- Die tatsächlich beobachtete Veränderung ist, dass sich die zentrale Beschränkung von „Kann man es bauen?“ zu „Kann man erkennen, ob es richtig ist?“ verschoben hat
Vergleich zweier Typen
-
Domain-Expert:innen (ohne Software-Hintergrund)
- Disponent:innen in der Logistik, klinische Kodierfachkräfte, Versicherungsmathematiker:innen usw.; sie können keinen Stack Trace lesen und nicht einmal den Unterschied zwischen Hashmap und Liste erklären
- Aber sie erkennen beim Blick auf einen vom Agenten erzeugten Plan sofort, dass kein Fahrer diese Schicht rechtlich zulässig übernehmen kann, oder dass die Abrechnung für diesen Code niemals ausgezahlt wird
- Weil sie seit zehn Jahren in Inputs und Outputs leben, kennen sie den korrekten Output für gegebene Inputs, und der Agent ergänzt genau die bislang fehlende Fähigkeit zur Codeproduktion
- Was sie einbringen, ist die Ground Truth, die ein Agent nicht liefern kann
-
Starke generalistische Ingenieur:innen ohne Domain-Erfahrung
- Sie können alles Mögliche entwerfen und wissen, wie man Zuverlässigkeit, Tests und Systeme sicherstellt, die nicht um 2 Uhr morgens zusammenbrechen
- Werden sie jedoch in der klinischen Kodierung eingesetzt, können sie plausibel wirkende falsche Antworten nicht von richtigen unterscheiden
- Der Agent erzeugt falsche Abrechnungsregeln (billing rules), die kompilieren und die von ihm selbst geschriebenen Tests bestehen, aber subtil und teuer fehlerhaft sind
- Der Ingenieurin oder dem Ingenieur fehlt das Oracle: Er oder sie kann validieren, dass die Software gut gebaut ist, aber nicht, dass sie korrekt ist — weil Korrektheit durch eine Domain definiert wird, die nicht im eigenen Kopf vorhanden ist
Eine Asymmetrie, bei der nur ein Pfad kollabiert ist
- Vor Agenten hatten Ingenieur:innen einen Pfad, den Disponent:innen nicht hatten — sie konnten Expert:innen begleiten, Spezifikationen lesen und Fehler im operativen Betrieb erleben und so langsam ein Domain-Modell aufbauen
- In vielen Feldern war genau dieser Pfad die Karriereleiter, während Domain-Expert:innen keinen gleichwertigen Pfad hatten, um sich über Jahre hinweg verlässlich gute Software-Fähigkeiten anzueignen
- Agentic Tools bringen nur einen dieser beiden Pfade zum Einsturz
- Die Stärke von Ingenieur:innen, ein Domain-Modell in Code zu übersetzen, wird nun billig
- Die Stärke von Domain-Expert:innen, zu wissen, was richtig ist, wird nicht billig und ist per Prompt nicht erreichbar
- Es gibt keine Skill-Datei, die das implizite Wissen (tacit knowledge) einer Person enthält, die Tausende Lohnabrechnungen verarbeitet hat
Menschen, die beide Ebenen validieren können
- In der neuen Welt sind die wertvollsten Personen jene, die beide Fähigkeiten besitzen und auf beiden Ebenen validieren können
- Sie wissen, dass der generierte Code robust ist, und zugleich, dass die Antworten dieses Codes wahr sind
- Weil sie die Regeln kennen, können sie Tests kodieren wie „Ein Fahrer darf 11 Stunden nicht überschreiten“, und weil sie wissen, was getestet wird, können sie beurteilen, dass dieser Test sinnvoll ist
- Der Agent übernimmt die Transkription, der Mensch übernimmt zweifaches Urteilen
Die Wette für erfahrene Ingenieur:innen
- Für erfahrene Ingenieur:innen, die überlegen, worin sie in den nächsten Jahren investieren sollten, ist das die Richtung der Wette
- Die mechanische Fähigkeit, eine klare Idee in sauberen Code zu übersetzen, verliert drastisch an Wert
- Was knapp bleibt, ist ein tiefes, validiertes Modell einer realen Domain — und genau das muss man sich aneignen
- Wähle eine Branche, ein Finanzprodukt, ein Regulierungssystem oder einen physischen Prozess und lerne diese Domain so, wie man früher Programmiersprachen oder Frameworks gelernt hat
- Das ist der Teil, den Agenten nicht ersetzen können, und heute der Teil mit dem größten Wert
7 Kommentare
Ich finde aber, dass das den Code zu sehr geringschätzt.
Auch Softwareentwicklung selbst ist eine eigene Domäne, und sie gut zu beherrschen ist ebenfalls eine Fachkompetenz.
Die von KI erzeugte Software kann funktional zwar Probleme lösen, aber sie kann sie nicht fertigstellen, und es braucht Menschen, die diese Lücke füllen.
Das entspricht derselben Meinung, die in den Hacker-News-Kommentaren geäußert wurde.
Ich habe zu xgurus Meinung eine leicht abweichende Sicht.
Nehmen wir Excel als Beispiel. Im Allgemeinen gibt es ein Niveau, das man für die Arbeit im Unternehmen braucht, und sobald man darüber hinaus ist, wollen die meisten sich gar nicht weiter damit beschäftigen. Es gibt zwar Menschen, die Excel wahnsinnig gut beherrschen, aber das sind wirklich Ausnahmefälle.
Bei Code könnte es ebenfalls so sein — auch wenn das im Moment noch nicht der Fall ist —, dass er sich vielleicht in zwei Richtungen aufspaltet: in eine kleine Gruppe, die wirklich komplexe Produkte baut, und in die große Mehrheit, die ihn so selbstverständlich nutzt wie das Fahrradfahren.
Hm? Menschen, die gut mit Excel umgehen können, werden doch nicht geringgeschätzt.
Aber zu sagen, der Wert des Codens an sich sei gesunken, wirkt für mich eben doch wie eine Geringschätzung.
Ich finde, nur weil man etwas so selbstverständlich nutzt wie Fahrradfahren, sollte man Menschen, die komplexe Produkte bauen, nicht sagen, dass ihr Wert nicht besonders groß sei.
Ich stimme dem von Ihnen genannten Punkt zu,
und es ging darum, dass die Menge an Technologie und Code, die man als komplexe Software bezeichnen kann, abnehmen wird. Wenn mehr Dinge zunehmen, die sich leicht mit AI erstellen lassen.
Um die Formulierung aus der GeekNews-Zusammenfassung zu übernehmen: Der Code, den ein Agent nicht stellvertretend übernehmen kann, wird wohl von Tag zu Tag weniger.
In diesem Bereich ist das implizite Wissen fast verschwunden, und da Top-Domain-Experten Agenten entwerfen und in Modelle einbetten, wird die Bedeutung von Domainwissen zwar derzeit betont, aber ich bin mir nicht sicher, ob man in einem Jahr noch dasselbe behaupten wird. Implizites Wissen wird letztlich nach und nach in Prompts überführt, und die Modelle werden das vom Nutzer dem Prompt hinzugefügte implizite Wissen auswählen und wieder in das Modell einspeisen. Agentenmodelle mit eingebettetem implizitem Wissen werden zwar wertvoll sein, aber selbst das wird meiner Ansicht nach auf dem Markt gehandelt werden. Agenten mit noch deutlich tieferem Domainwissen in diesem Bereich.
Ich vermute, dass in einem Jahr über Orchestrierung hinaus das Agenten-Management (wie bei einem Unternehmen) zum Bewertungskriterium wird.
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