Es wird Zeit für ein Update für die Arbeitsweise mit AI. Der letzte Artikel dazu ist jetzt gut 2 Monate her. Es ist immer wieder erstaunlich, wie schnell sich die IT-Welt wandelt. Derzeit wandelt sich nicht weniger als große Teile der Arbeit von Entwicklern. Klingt nach clickbait, ist aber tatsächlich ein sehr großer Umbruch. Was ändert sich? Bislang haben Entwickler selbst Programmcode geschrieben. Händisch Programmcode schreiben ist anspruchsvoll und man muss sich stark konzentrieren, zumindest einen Teil der Zeit. Es war ein bisschen konzipieren, ein bisschen runtercoden was man sich vorher ausgedacht hat, ein bisschen Tests schreiben, ein bisschen (oder oftmals ein bisschen mehr) Tests debuggen, ein bisschen dokumentieren. Soweit so gut. Aber diese Arbeitsweise ist obsolet. Und das ist kein Scherz und keine Ironie. Programmcode schreiben macht man ab jetzt nur noch wenn es sehr kleine Änderungen sind, die man schneller selbst implementiert hat, als dass man einen prompt eingetippt hat. Aber wie sieht dann die neue Normalität ganz konkret im Detail aus?
Entwickler entwickeln nicht mehr selbst, sie lassen von der AI entwickeln. Entwickler prüfen den Code von AI mittlerweile nur noch mehr oder weniger intensiv. In de Theorie macht man natürlich für sämtlichen Code reviews im Pullrequest, klar. Ist ja sonst unverantwortlich, das produktiv zu setzen. Aber ich belüge ja weder mich noch andere: In der Praxis überfliegt man den Code und prüft nur auf Plausibilität: Sind die Erwarteten Funktionsaufrufe an den erwarteten Stellen enthalten? Gibt es Tests für die “kritischen” Funktionen im neuen Feature? Und dann schaut man sich nochmal an, ob die Kernlogik richtig implementiert wurde. Der sonstige overhead wird nur überflogen. Und das funktioniert erstaunlich gut. Ich muss dazu sagen: Derzeit funktioniert claude erstaunlich gut. Wenn claude programmiert, wirkt das, als ob ein senior-dev entwickelt. claude achtet nicht nur drauf, ein Feature zu entwickeln oder einen Bug zu fixen, sondern claude achtet auch drauf, dass hinterher insgesamt ein sinnvolles und brauchbares Ergebnis raus kommt. claude passt selbstständig etwaige andere Stellen sinnvoll an, die aufgrund der gegebenen Aufgabe auch von den nun getätigten Änderungen betroffen sind. Man kann immer diskutieren, ob das “I” in “AI” wirklich für Intelligenz steht. Aber ich sage mal so: Die Änderungen von claude haben oft mehr Grips als die von vielen Entwicklern, das muss man einfach anerkennen. (Nicht zuwechseln mit anderen AIs, die sich eher so anfühlen, als ob ein Azubi entwickelt. Ist nicht abwertend gemeint, mir geht es nur um die Verdeutlichung des Erfahrungsgrades. Da wird dann eine Funktion wie beschrieben implementiert, aber ohne zu hinterfragen ob das sinnvoll oder nötig ist oder was sonst noch angepasst werden muss. Das kann sich in Zukunft aber natürlich ändern.) claude macht das alles. claude setzt derzeit Maßsstäbe. Das bislang erreichte Niveau von claude beweist, dass man diskutieren muss, wie Entwickler in Zukunft arbeiten. Weil code mit AI scheiben lassen ist mittlerweile signifikant schneller und qualitativ mindestens genau so gut wie von senior-devs geschriebener Code. Und nochmal fürs Protokoll: Ich rede hier von dem Marktführer claude. Mit anderen AIs kann man in vielerlei Hinsicht schlechtere Erfahrungen machen, aber darum geht es hier in diesem Artikel nicht.
Die Rolle von Entwicklern verändert sich damit dahingehend, dass man mehr zum stakeholder wird. Ich als Entwickler soll ein feature entwickeln und das heißt: Ich schreibe was gemacht werden soll, und ggf. auch grob wie das umgesetzt werden soll. Die AI macht den Rest. Es klingt einfach. Es gibt im Detail aber natürlich Sachen zu beachten und ein paar Stolpersteine, aber die sind klein. Im Prinzip ist es tatsächlich wirklich so leicht. Aber: Der code von AI muss auch immer geprüft werden, bevor er produktiv geht, selbst wenn diese Prüfung in der Praxis nicht immer sehr detailliert und intensiv ist. (Aber seien wir mal ehrlich: Bevor es AI gab hat man auch nicht immer alles im Detail und maximalintensiv geprüft und trotzdem ist alles mögliche produktiv gegangen, ggf. mit den entsprechenden Folgen.) Was bleibt Entwicklern also? Bei manchen Implementierungsfragen hat die AI technische Nachfragen. Die muss man als Entwickler fundiert beantworten und das erfordert natürlich auch etwas IT-Wissen. Das Thema ist aber auch weiterhin: Man muss den Code auch zumindest reviewn können. Sonst kann man nicht verifizieren, dass das auch funktioniert, was die AI da generiert hat. Und selbst wenn es funktioniert, dann darf es nicht nur funktionieren, weil essentielle Sicherheitsmechanismen fehlen, was einem reviewer ja auffallen sollte. Es kann sein, dass 95% des codes richtig ist, den die AI generiert (fühlt sich tatsächlich so an). Aber eben für die genau die 5% übrigen code, die nicht korrekt generiert wird, ist es wichtig, dass man da drüber schaut und dann wie auch immer sicherstellt, dass das korrigiert wird. Um das zu machen kann man Entwickler nicht vollständig wegrationalisieren (sonst könnte ja der Product-manager direkt prompten und das Ergebnis einfach blind übernehmen). Aber: Man braucht heute deutlich weniger Entwickler für die gleiche Aufgabe. Oder man schafft deutlich mehr in der gleichen Zeit. Das ist eine Tatsache. Man liest noch oft viele skeptische Stimmen, die sagen, dass AI zu viel halluziniert oder schlechte Qualität liefert. Aber das sind dann wahrscheinlich Erfahrungen aus 2024. Heute in 2026 ist das tatsächlich anders.
Dann gibt es ja schon seit einiger Zeit sogenannte “Skills”. Das ist eigentlich technisch nicht so spannend, aber es ist wichtig, um den unten stehenden Text zu verstehen. Ein Skill ist eine Text-Datei, in der man beschreibt, wie man irgendwas machen kann, damit die AI diese Information dann nutzen kann, wenn sie das braucht. Man kann diesen Text auch einfach manuell in den chat schreiben, aber das macht ja Tipp-Arbeit. Und dazu ist das nette bei den skills: Die AI lädt nur eine kurze Beschreibung aller skills, aber aus Performance-Gründen nicht den ganzen ausführlichen Skill-Text. Aber die AI kann autonom entscheiden, wann sie welchen Skill benutzt und dann wird das nachgeladen. Sie nutzt einen bestimmten Skill typischerweise bei der Arbeit, wenn sie irgendein entsprechendes Problem lösen möchte, und die Beschreibung so klingt, als ob der Skill gerade eine brauchbare Lösung für das Problem anbietet. Oder die AI nutzt den Skill alternativ schlicht dann, wenn man sie per Prompt oder durch den Text in einem anderen Skill dazu auffordert. Das fühlt sich dann mehr wie ein Funktionsaufruf an. In jedem Fall ist es praktisch. Letztendlich wird der gesamte Skill-Text bei Benutzung des Skills dann als prompt der AI gegeben und die AI macht das. Das funktioniert schon recht gut und zuverlässig. Mit diesen Skills kann man nun beliebig kreativ werden, um der AI neue Sachen beizubringen, die sie dadurch “lernt”, bei Bedarf zu benutzen.
Jetzt wird es spannend: Was gerade nicht ganz zu unrecht viral geht ist der grill-with-docs-skill von Matt Pocock. (Hier kann man mehr dazu lesen.) Es ist einfach ein Text-Dokument in dem steht: “Run a /grilling session, using the /domain-modeling skill.” Ok, “grilling” und “domain-modelling” haben auch noch etwas Text, der dann aufgerufen wird, da wird also schlicht auf 2 andere Skills verwiesen. Aber im Wesentlichen ist es dann schon das vom “grilling”-skill bekannte Pnizip: “Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering. If a fact can be found by exploring the codebase, look it up rather than asking me. The decisions, though, are mine — put each one to me and wait for my answer. Do not enact the plan until I confirm we have reached a shared understanding.” Das sagt man der AI. Was heißt das? Man macht anschaulich gesagt sowas ähnliches wie requirements engineering mit der AI zusammen, und zwar lange vor dem Implementieren einer neuen Funktion. Man benutzt die AI hier nicht, um eine Funktion zu entwickeln, sondern um mit ihr über ein neues Feature zu diskutieren. Das ist quasi eine neue Methodik. Die Diskussion geht dann so lange bis die AI und der Mensch die gleiche Vorstellung über ein zu implementierendes Feature haben und Kombinieren ihr Wissen und ihre Ideen zur Umsetzung. Sozusagen synchronisieren Mensch und AI mit dieser Methodik ihr Verständnis darüber, was und wie bei dem Feature gemacht werden soll. Und dann? Dann kann man der AI sinngemäß sagen: “Jetzt schreib mir eine User-story daraus.” Dann schreibt die AI vereinfacht gesagt einmal sauber runter, was wie warum gemacht werden soll. Und die AI kann sowas dann durchaus sehr sauber, ohne viele Halluzinationen und unter Berücksichtigung aller nötigen technischen Umstände, stakeholder-interessen usw., weil man hat ja vorher das Verständnis darüber mit der AI synchronisiert. Das kann dahingehend ein gutes Ergebnis liefern, dass man selbst seine ganzen Vorstellungen, Bedingungen usw. einbringen kann, aber die AI auch ihr Wissen einbringt, sodass das beste von beiden Welten in der finalen Feature-Beschreibung landet. Und fertig ist für ein bestimmtes Feature sowas ähnliches wie, was früher ein Lastenheft war, inkl. Nennung aller Bedingungen die bei der Implementierung eingehalten werden müssen.
Und jetzt wird es abgefahren. Und es muss schon echt viel passieren, damit ich das Wort “abgefahren” verwende. Jetzt sagt man einfach der AI im nächsten Schritt: “Hier ist ein fertig ausgearbeitetes Feature (Im Sinn von: Die Anforderungen sind vollständig und detailliert genug, sodass man da alles stehen hat, was man wissen muss, um das zu implementieren): Implementier das.” Das war es. Und das kann dann von der AI unbeaufsichtigt entwickelt werden. Die Korrekturen hinterher sind höchstens minimal, wenn man in der grilling-session vorher gut mit der AI diskutiert hat. Und das ist crazy, weil: Es funktioniert tatsächlich. Der letzte Schritt ist dann relativ trivial: Man kann den ganzen Prozess dahingehend automatisieren, dass man der AI sagt: “Hier ist deine sandbox-Umgebung, implementier da nach und nach alle fertig definierten User-stories auf einem eigenen Branch mit eigenem Pull-request.” Und dann implementiert die AI nach und nach ohne menschliche Interaktion die ganzen Features (oder ggf. auch Bug-fixes, nicht funktionale Anforderungen, etc.), und zwar auf eine Art und Weise, dass hinterher tatsächlich ein wirklich brauchbares Ergebnis raus kommt. Der AI noch zu sagen “Stell hinterher sicher, dass der Code kompiliert und alle Testfälle grün sind, fix etwaige Fehler dabei und dokumentier alles sauber”, ist dabei ziemlich trivial. Und damit ist die Tätigkeit des reinen Entwickelns vollständig weg-rationalisiert.
Fazit:
Das alles ist eine verrückte Entwicklung, die man noch vor 5 Jahren nicht für denkbar gehalten hat. Die technischen Fortschritte sind enorm. Und mit genau diesen neuen Möglichkeiten, extrem effizient und schnell neue Software zu entwickeln wird die Geschwindigkeit, in der sich Technologie weiter entwickelt, bestimmt in nächster Zeit auch nicht geringer werden. Das heißt jetzt aber nicht, dass alle Entwickler arbeitslos werden. Die Tätigkeit verändert sich aber stark. Das Ausarbeiten von Anforderungen (z. B. mit der Methodik der grilling-session) kann zuweilen sehr technisch sein. Bei dieser Diskussion können Entwickler oftmals wesentlich besser beurteilen können, was in die richtige Richtung geht und was nicht. Auch das reviewn vom Code ist etwas, was zumindest heute noch Menschen machen sollten. Auch diese Aussage ist aber nur eine Momentaufnahme. Wenn man sich aber vor Augen hält, wie viel AI mit brauchbarer Qualität in kurzer Zeit entwickeln kann, scheint es zumindest so zu sein, dass der ehemalige Google CEO Eric Schmidt mit folgender Aussage nicht ganz Unrecht hat: “If you’re writing code traditionally, stop. It’s over.”