Wenn GPT dich zum Experten macht

Veröffentlicht am 2. Juli 2024 - ⏱️ Ca. (wird berechnet) min. Lesezeit

Immer häufiger liest man von einer scheinbar unausweichlichen Entwicklung: Künstliche Intelligenz, speziell GPT-Modelle, sollen menschliche Fachkräfte nicht nur unterstützen, sondern in vielen Fällen direkt ersetzen. Besonders in der Softwareentwicklung wird dieser Gedanke immer offensiver formuliert.

Doch was bedeutet es, wenn Führungspersonen anfangen, GPT nicht mehr als Werkzeug, sondern als Alternative zum Entwickler zu betrachten? Und was passiert, wenn Entscheidungen über Architektur, Code oder Technologieeinsatz durch externe Impulse oder Tools getroffen werden, ohne Rückbindung an die Realität des Systems?

Die Illusion von Expertise

Wer hat es nicht schon selbst erlebt: Ein paar Stunden schreiben mit GPT und plötzlich fühlt man sich als Arzt, Anwalt oder Software Ingenieur. Die KI ist scheinbar allwissend. Verstärkt wird der Eindruck noch durch typische "Prompts". "Du bist ein Experte in XY", "Agiere als Dr. House" und so weiter. Die LLM formuliert darauf hin ganz nach ihrem Training die wahrscheinlichsten Antworten. Selbstbewusst, provokant: Es ist niemals Lupus. Solchen Antworten neigt man schnell zu vertrauen. Die KI scheint ja zu wissen, wovon sie redet.

Auch Führungskräfte sind davor natürlich nicht gefeit. Das perfide: Sehr oft gibt die KI schliesslich wertvolle Impulse. Mag sein, dass es viele mahnende Stimmen gibt, die sagen GPT würde halluzinieren und man muss alles prüfen. Wenn es aber doch schon einige Male so gut geklappt hat. Wie schlimm können diese Halluzinationen denn dann schon sein?

Ich möchte hierfür gerne mal ein Beispiel anführen, dass gerade für nicht Techniker einfacher zu verstehen ist. Warum Halluzinationen die kleinere Gefahr und fehlender Kontext bzw. Verständnis das echte Problem sind.

Vergleich: Der Entwickler im Vertrieb

Ich darf vorstellen: Hans. Hans ist ein Entwickler und unzufrieden in seiner Firma. Zum wiederholten Male wurde sein Gesuch um eine Gehaltserhöhung mit einem Verweis auf die schwierige wirtschaftliche Lage abgelehnt. Dabei macht Hans selbst - zumindest seiner Meinung nach - einen hervorragenden Job. Er konsultiert GPT, warum die Firma in einer so schlechten Lage ist: "Antworte als weltweit bekannter top Unternehmensberater".

Kurze Zeit später scheint die Situation glasklar. Mithilfe seines KI-Beraters weis Hans nun, dass die Schwächen der Firma im Vertrieb zu finden sind. Die Abhängigkeit von einem Grosskunden ist der Kern des Problems, warum er nicht mehr Gehalt bekommt.

Hans lässt das nicht auf sich sitzen. Mit seinen neuen Erkenntnissen sucht er das Gespräch mit dem CEO, Michael. Er schildert ihm sachlich seine Analyse: Der Vertrieb sei zu abhängig von einem Kunden, die Strategie zu passiv, und es brauche dringend neue Massnahmen. Michael hört geduldig zu, bedankt sich und erklärt dann ruhig, dass die Realität komplexer sei. Es gebe langjährige Absprachen, stille Beteiligungen, strategische Verflechtungen, die Hans naturgemäss nicht kennen könne. Er bittet ihn, sich weiterhin auf die technische Weiterentwicklung zu konzentrieren. Vertrieb sei Sache der Geschäftsleitung.

Doch Hans fühlt sich übergangen. In seinem Selbstverständnis als Systemdenker sieht er es als seine Pflicht, aktiv zu werden. Also wird er es. Ohne Rücksprache, ohne Kontext. Er schreibt dem Key Account des Grosskunden eine E-Mail, höflich, aber mit klarer Kritik: Die derzeitige Zusammenarbeit schade der Skalierbarkeit, und das Unternehmen müsse sich strategisch neu aufstellen. Der Kunde reagiert irritiert, es entsteht Verunsicherung, interne Absprachen werden infrage gestellt. Michael wird von der Situation überrascht und ist fassungslos.

In einem internen Krisenmeeting wird das ganze Ausmass sichtbar. Hans hatte weder Einsicht in die vertraglichen Regelungen noch Kenntnis über geplante Umstrukturierungen, die intern längst beschlossen, aber noch nicht kommuniziert waren. Durch sein eigenmächtiges Handeln hat er das Vertrauen des wichtigsten Kunden beschädigt und einen strategischen Schaden angerichtet, der nicht nur finanziell, sondern auch kulturell nachwirkt.

Die Moral von der Geschichte

Was Hans getan hat, ist sofort nachvollziehbar problematisch: Er hat sich in ein Gebiet eingemischt, dessen Abhängigkeiten, Hintergrundstrukturen und implizite Vereinbarungen er weder kannte noch einordnen konnte. Der Fehler liegt nicht in seinem Engagement, sondern in der fehlenden Rollenklarheit. Und genau hier wird der Bogen zur Softwareentwicklung sichtbar.

Denn immer häufiger sind es heute Führungskräfte, Manager oder Produkt Owner, die mithilfe von GPT beginnen, Architektur- oder Entwicklungsentscheidungen vorzudenken. Sie tun das oft aus einem nachvollziehbaren Wunsch heraus: Mitreden, verstehen und beschleunigen. Doch GPT kennt den Kontext nicht. Und kann ihn auch nicht kennen.

Tokenlimits, fehlender Zugang zu interner Codebasis, nicht sichtbare Trade-offs: All das sorgt dafür, dass GPT immer nur auf Basis wahrscheinlicher Aussagen antwortet. Es kennt keine Systemgrenzen, keine historische Evolution der Codebasis, keine impliziten Architekturregeln oder kulturellen Prägungen des Teams. Und damit trifft es Entscheidungen, denen das Fundament fehlt.

Was bei Hans wie ein klarer Rollenkonflikt erscheint, wird im umgekehrten Fall häufig nicht als solcher erkannt. Doch wer GPT nutzt, um Entscheidungen zu ersetzen, nicht zu reflektieren, schafft genau das gleiche Problem: eine Einmischung ohne Verantwortung, ohne Systemverständnis und mit potenziell fatalen Konsequenzen. Wenn Entscheidungen dort getroffen werden, wo weder Kontext noch Verantwortung vorhanden sind, entsteht Architektur im Blindflug. GPT wird dann nicht zum Werkzeug, sondern zum unbeabsichtigten und unqualifizierten Autor.

Warum der Mensch unersetzlich bleibt

Eines kann GPT heute noch nicht: Sich erinnern. Nicht im menschlichen Sinne. Es kennt keine impliziten Entscheidungen, keine Projektgeschichte, keine unausgesprochenen Prinzipien, die sich in einem Codebasiskörper über Jahre hinweg sedimentieren. Und genau das unterscheidet es von einem Entwickler.

Wer Software wirklich versteht, erinnert sich – bewusst oder unbewusst – an frühere Entscheidungen, an Systemgrenzen, an Performance-Trade-offs, an kulturelle Muster im Team. Dieses „Gedächtnis“ ist nicht dokumentiert, nicht promptbar, nicht aus einer JSON-API extrahierbar. Es ist kontextuelles Verstehen, das eine LLM aktuell nicht erreichen kann. Selbst wenn es in Zukunft möglich wird ein komplettes Softwareprojekt mit aber tausenden bis millionen von Zeilen Code in ein LLM zu laden. Selbst dann bräuchte es immer noch einen Entwickler, der das LLM steuert und beaufsichtigt. Ein Produkt Owner kann der nicht. Er versteht nicht die Entscheidungen und Hintergründe, die die Architektur prägen.

Deshalb ist GPT auch nicht in der Lage, Architektur zu gestalten. Es kann Architektur beschreiben, reproduzieren, vielleicht sogar simulieren, aber nicht durchdringen. Und schon gar nicht verantworten. Wer das Menschliche aus dem Entwicklungsprozess entfernt, verliert genau das, was Software heute am meisten braucht: Urteilskraft.

Wie KI in Entwicklungsprozesse eingebettet werden kann

Der eigentliche Fehler liegt selten im Tool, sondern im Modus seiner Einführung. Wenn GPT als Wunderwaffe propagiert wird, die Produktivität explodieren lässt, entsteht Druck, nicht Orientierung. Aussagen wie „Ihr müsst nur richtig prompten“ sind kein Enablement, sondern ein Missverständnis: Sie machen aus Entwicklern Befehlsempfänger und aus GPT einen Ersatz für Urteilskraft.

Man stelle sich erneut Hans vor, wie er Michael erklärt, er müsse nur besser prompten, um die Firma aus der Abhängigkeit vom Grosskunden zu führen. Für Michael wäre das nicht nur fachlich absurd. Es wäre auch ein Angriff auf seine Rolle, sein Wissen und seine Verantwortung. Genau diese Erfahrung machen heute viele Entwickler.

Ihnen wird nicht vorgeworfen, Fehler zu machen, sondern „nicht KI genug“ zu sein. Ihre Arbeit wird entwertet, ihr Tempo infrage gestellt, ihre Architekturentscheidungen durch Prompt-Effizienz ersetzt. Kein Wunder, dass viele sich zurückziehen, verweigern oder GPT bewusst ignorieren. Aus einer strategischen Ressource wird so ein kulturelles Problem.

Der produktive Umgang mit GPT beginnt nicht mit Promptoptimierung, sondern mit Rollenklarheit. Statt GPT als Ersatz für Fachwissen zu begreifen, lohnt sich ein anderer Gedanke: GPT aus einer Rolle heraus zu nutzen. Ein Junior-Entwickler, um sich Code erklären zu lassen. Ein Architekt, um seine Entscheidungen zu challengen. Ein Teamlead, um Kommunikationsmuster zu analysieren. So entsteht kein Ersatz, sondern eine Verstärkung. Kein Kontrollverlust, sondern ein Werkzeug mit Wirkung.

GPT in der Rolle: Junior Developer

Für viele Einsteiger in die Softwareentwicklung fühlt sich Code oft wie eine fremde Sprache an. Voller Abkürzungen, impliziter Konventionen und unsichtbarer Erwartungen. GPT kann hier ein mächtiges Werkzeug sein. Nicht als Ersatz für Mentorenschaft, sondern als immer erreichbare Reflexionshilfe.

Ein Junior, der sich fragt, warum ein bestimmter Hook überhaupt existiert, kann GPT bitten, es in einfachen Worten zu erklären, inklusive Beispiel. So entsteht ein Dialog, der das nächste Code-Review verständlicher macht. Der Junior agiert dabei nicht blind, sondern mit Neugier: Er stellt Fragen, prüft Aussagen, lernt den kritischen Umgang mit Vorschlägen. GPT wird zum Sparringspartner.

Was GPT nicht kann: Kontext aus der Codebasis rekonstruieren, implizite Entscheidungen erkennen oder langfristige Architekturziele vermitteln. Genau deshalb bleibt der menschliche Austausch im Team unersetzlich. Aber GPT kann helfen, ihn besser vorzubereiten.

Wer GPT aus der Rolle eines Junior-Entwicklers nutzt, nutzt es als Lernhilfe. Nicht als Autorität, der man blind folgt, sondern als Gesprächspartner auf Abruf. Nicht als Antwortmaschine. Und das verändert alles. Das fatalste, was ein Junior Entwickler machen kann, ist sich selbst zum Prompt-Generator zu degradieren, indem er nur noch mit GPT chattet: Lös dieses Problem. Es funktioniert nicht, warum? Fix das. Mach den Button grün und grösser.

Der Junior Entwickler ist das Bindeglied zwischen dem Lehrling/Studenten und dem erfahrenen Entwickler. Seine Aufgabe ist es zu letzterem zu werden. Wer sagt, er kann Junior Entwickler durch AI ersetzen: Der handelt nicht nur zutiefst unmoralisch. Er offenbart, dass ihm nicht an Ausbildung, sondern nur an billiger Arbeitskraft gelegen ist. Solches Denken sägt zudem an dem Ast, auf dem unsere Branche sitzt: Ohne Ausbildung und Nachwuchs verödet das Ökosystem.

Was bleibt

Der Umgang mit GPT ist kein Toolproblem, sondern eine Frage der Haltung. Und der Rolle. Ein Junior nutzt GPT anders als ein Architekt. Ein Teamlead stellt andere Fragen als ein Testentwickler. Und genau das ist der entscheidende Punkt: GPT entfaltet seine Wirkung nur dann sinnvoll, wenn klar ist, wer es wozu einsetzt.

Nicht um sich zu ersetzen, sondern um sich zu verbessern. Um eigene Lücken zu erkennen. Um Muster zu hinterfragen. Um als Mensch in Verantwortung zu bleiben, nicht im Prompt zu verschwinden. Und nicht um einfach nur schneller irgendetwas zu produzieren, dass unter einem kritischen Blick gar keinen Bestand hat.