„Sieh die KI als Juniorentwickler“

Beginnen wir mit einer Binsenweisheit: Die künstliche Intelligenz respektive Large Language Models halten überall Einzug. Die Softwareentwicklung ist aber in besonderem Maße betroffen. Als Vertreter der vielseitigen Gründe seien nur zwei genannt: massive Textorientierung des Codes mit strenger Grammtik und Tonnen an Dokumentation für APIs und Frameworks, die es zu wissen gilt. dotnetpro hat Chris­tian Weyer befragt, welchen konkreten Einfluss die KI auf die Softwareentwicklung im Jahr zwei nach ChatGPT hat.

dotnetpro: Christian, bitte erkläre kurz, was deine Firma Thinktecture [1] macht.

Christian Weyer: Thinktecture gibt es seit 2004, ursprünglich gegründet von Ingo Rammer und mir. Wir machen tieftechnisches Consulting für Softwareentwickler und Softwarearchitekten – immer mit dem Blick auf die neuesten Technologien, um mit den Kunden gemeinsam ihre Projekte voranzubringen. Die Kunden sind meist Independent Software Vendors, die ihre eigenen, meistens Branchenlösungen bauen. Früher hat man die in einem Karton auf einer CD vertrieben, heutzutage sind das meistens SaaS-Lösungen. Aber eben auch die Enterprise-Entwickler, die dann Inhouse-Lösungen bauen.

Hast du Angst, dass du künftig, sagen wir mal in zwei bis drei Jahren, weniger Angestellte haben wirst, weil die KI einiges übernimmt?

Christian: Das ist eine philosophisch angehauchte Frage: Ist

es etwas Gutes, dass ich in Zukunft vielleicht nicht mehr so viele Mitarbeiter brauche, oder ist es etwas Schlechtes? Das müssten wir dann ein bisschen größer aufspannen, was quasi der gesamtgesellschaftliche Impact von KI ist.

„Dass sich die Rolle des Entwicklers und dass sich die Rolle der Softwareentwicklung ändern wird und ändern muss, ist vollkommen klar.“

Schneiden wir es etwas kleiner. Würdest du davon ausgehen, dass du künftig weniger Mitarbeiter brauchst, um die gleiche Menge an Projekten zu stemmen?

Christian: Ja. Aktuell sind wir zwölf fest angestellte technische Experten. Wir wachsen vielleicht noch um ein paar mehr. Das war aber auch schon vor dem ganzen KI-Hype unser Ziel. Ganz einfach aus dem Grund, weil wir hoch spezialisierte Experten brauchen, die es entweder schon fertig irgendwo gibt – und die gut zu unserem Mindset passen –, oder sie bringen die notwendige Wissbegierigkeit mit, und wir formen sie zum technischen Consultant.

Wir hatten mal überlegt, das skalierbar zu machen. Das hätte aber viele Umbaumaßnahmen bei uns bedeutet. Und die Art und Weise, wie wir mit unseren Kunden arbeiten, hätte sich auch geändert.

Wir haben uns immer spezielle Themen gesucht, die wir uns dann in aller Tiefe erschlossen, angewendet und vermittelt haben. Nach Remoting und WCF in den Anfangsjahren waren wir die SPA- und Angular-Experten. Zudem haben wir sehr viel Security und Identity gemacht und sehr viel Azure und Cloud Native.

Künftig werden beispielsweise Neuerungen von Angular 24 auf Angular 25 aber immer unwichtiger werden. Trotzdem wird es noch Tiefenexperten brauchen, wenn es um robuste, wirklich sichere und performante Software geht. Aber ein Großteil unserer Aktivität wird durch KI-basierte Ansätze unterstützt werden.

„In jedem Projekt, das ich bislang gesehen habe, war die Dokumentation sofort veraltet, sobald der Entwickler auf ‚Save‘ gedrückt hat.“

Darf man das so interpretieren, dass auch deine eigene Produktivität größer wird, weil du jetzt einfach nicht mehr so viel tippen musst? Weil du schneller irgendeine Funktion aus der KI geliefert bekommst.

Christian: Ich fühle mich informationstechnisch so jung wie schon lange nicht mehr. Nach 26 Jahren im Beruf war nichts mehr da, was mich so richtig gepackt hätte. Ob Rust, Java,

.NET, ob Angular, Vue oder React, Azure, AWS oder GCP: alles irgendwie das Gleiche. Und dann kam Cline [2], ehemals ClaudeDev, als Plug-in für Visual Studio Code. Zusammen mit einem Kunden haben wir ein GenAI-basiertes Projekt mit ­Cline gebaut. Das Projekt ist in Dogfooding-Manier entstanden. Es war unfassbar. Für das Proof-of-Concept-Projekt (POC) hatten wir drei Wochen veranschlagt, aber mithilfe von Cline war ich nach viereinhalb Tagen fertig. Das Pro­blem war dann vielmehr, die Zeit für die Abstimmung mit dem Kunden zu finden.

Das hat so gut funktioniert, weil ich viel Erfahrung habe, weil ich Softwarearchitektur kann, weil ich Software Engineering kann, weil ich schon alle möglichen Herausforderungen gesehen habe. Unterstützt durch die GenAI-Tools konnte ich mehr machen.

Du warst also produktiver?

Christian: Ja, auf jeden Fall. Produktiver zu werden fühlt sich einfach gut an. Das Perverse ist ja, dass du beinahe nichts mehr tippst– vielleicht noch deine Prompts und deine Requirements, aber du kannst es genauso gut mit Spracheingabe ­machen.

Aber neben der Produktivitätserhöhung war ein wichtiger Aspekt das Mehr an Kreativität. Ich habe Dinge ausprobiert, die ich vorher nicht mal mit spitzen Fingern angefasst hätte.

Nenne bitte ein Beispiel, was du ausprobiert hast.

Christian: Extensive Frontend-Arbeit. Ich habe zwar jahrelang SPA und Angular gemacht, aber ich war nie der Designer. UI und UX – um Himmels Willen. Das noch gepaart mit CSS und dessen Ablegern, das muss ich nicht haben. Und dann habe ich dem Kunden im POC-Projekt ein Frontend gebaut, das, gewürzt mit seiner Corporate Identity, genau das war, was er haben wollte. Oder Dinge, die kein Must-have sind, sondern die man normalerweise später angeht. Von diesen Non-Goals habe ich auch welche eingebaut. Ganz einfach, weil ich viel krea­tiver sein konnte. Das hat mich total geflasht.

Man merkt deine Begeisterung …

Christian: Ja, aber wir sind ja immer noch ganz am Anfang dieser Entwicklung.

Hast du neben Cline noch andere KI-Tools für das Projekt verwendet?

Christian: Normalerweise bleibe ich mittlerweile komplett innerhalb der IDE, weil ich mit dem Ding diskutieren kann, als wäre ich innerhalb des Browsers in ChatGPT oder Claude AI.

Was hältst du von Tools wie Bolt.new [3]?

Christian: Ich habe das Tool noch nicht selbst ausprobiert. Aber was ich bislang gemacht habe, war quasi Architektur und Coding innerhalb der IDE. Das geht mit Cline oder Cursor [4] oder wie sie ­alle heißen. In diesen Tools hast du einen Modus, um zu planen. Dann verwenden sie ein Reasoning Model dahinter, zum Beispiel o1 oder o3 von Open­AI oder R1 von DeepSeek, die sich auf Reasoning verstehen. Oder du sagst Act, dann ist es quasi Code-Generierung – mithilfe von GPT-4o oder Claude Sonnet als Coding Assistance.

Worauf du anspielst, sind Prototyping Tools und Prototyping Assistance, mit denen du mehr oder weniger End-to-End-Anwendungen bauen kannst. Dazu gehören v0 [5], Bolt.new oder Lovable [6]. Damit kannst du basierend auf einem Requirements-schwangeren Prompt eine Anwendung bauen, also von Frontend mit UI/UX-Aspekten bis hin zum API-­Layer mit Backend-Implementierung. Das ist natürlich superinteressant. Ob du vorne Angular oder React hast – und das mag jetzt für den ein oder anderen wirklich markerschütternd sein –, ist im Prinzip egal.

Über die Jahre hinweg werden diese Basistechnologien weiter Commodity werden, und wir müssen uns mit anderen Herausforderungen auseinandersetzen, zum Beispiel mit den Tools, die du erwähnt hast.

Welchen Einfluss werden diese Tools haben?

Christian: Am Ende des Tages werden wir einen großen Schritt brauchen, über den wir wahrscheinlich schon seit 20 Jahren reden, nämlich die Abstraktionsebene zu erhöhen. Wir sprechen ja immer noch über C#-Typen und über Java-APIs, über Frameworks und darüber, ob ich jetzt Angular Signals verwende oder irgendwelche anderen Technologien. Damit wird die Softwarewelt aber nicht produktiver und effizienter. Das heißt, wir brauchen irgendwie eine andere Abstraktionsebene, sprich all das, was seit circa 20 Jahren rund um Low Code und No Code kreucht und fleucht. Wenn die zwei Themen, nämlich Generative-AI-assisted Coding und Low Code oder vielleicht sogar No Code, wirklich einmal zusammenkommen, dann wird es explodieren. Ich vermute, dass irgendeiner von den Großen bereits daran arbeitet. Das hebt die Abstraktions­ebene, die wir eigentlich brauchen, damit wir uns nicht mehr mit Details befassen müssen.

Angesichts dieser Prognose: Hast du dann nicht Angst um deinen Job oder um die Jobs der vielen anderen Entwickler?

Christian: Dass sich die Rolle des Entwicklers und dass sich die Rolle der Softwareentwicklung ändern wird und ändern muss, ist vollkommen klar. Das heißt aber nicht, dass mein Job weg ist. Ich glaube nicht, dass jeder Hinz und Kunz oder jeder in der Requirements-Abteilung seine eigene Anwendung baut. Dazu gehört ein bisschen mehr, wie zum Beispiel Unternehmensrahmenbedingungen, funktionale und nichtfunktionale Aspekte.

Das heißt also, dass man vieles AI-assistiert wird erstellen können, aber nicht alles. Das kann jedoch in zwei Jahren ganz anders aussehen. Wenn wir in zwei Jahren wieder darüber sprechen, kann es sein, dass ich sage: „Tilman, ich glaube, ich muss meine Rente vorziehen.“ Vielleicht gibt es dann nichts mehr zu tun. (grinst)

Hört sich schlüssig an. Allerdings scheint sich der Punkt, an dem Entwickler überflüssig werden, nach hinten geschoben zu haben. Nach dem Benchmark SWE-Lancer [7], der 1400 echte Freelance-Aufgaben aus Upwork [8] verwendet, sind die aktuellen LLMs nicht in der Lage, vernünftige Lösungen zu finden [9}.

Christian: Das ist, glaube ich, nur ein temporärer Effekt. Die Modelle werden besser. Allein wenn man sich ansieht, was mit DeepSeek passiert ist, dass man keine Multimillionen-Data-Center braucht, um ein LLM zu bauen.

Die Basismodelle werden besser werden, die Patterns oben drüber werden noch besser. Die Erfahrungen mit der Art und Weise, wie wir den Input gestalten, wird besser, und dann ein Schritt hin zu Multiagenten, die quasi eine Teamstruktur simulieren und abbilden können.

Welchen Einfluss hat die KI auf die technischen Schulden?

Christian: Ich weiß nicht, ob es die KI ist, die den Effekt mit sich bringt, oder das Heben der Abstraktion. Die technischen Schulden, die ich in den letzten 25 Jahren gesehen habe, waren Frame­work-Themen beziehungsweise Architekturfehlentscheidungen. Die passieren immer, weil es nicht die eine Architektur gibt. Die Tools werden wahrscheinlich erst einmal mit ein paar Templates starten, die dann mehr oder weniger gut passen. Aber die tatsächlichen technischen Schulden kommen oftmals durch Frameworks rein, also durch Lower-Level-Frameworks, weil man sie nicht verstanden hat, weil man sie nicht richtig einsetzt oder weil man sie nicht upgraden kann oder upgraden darf. Irgendwie hängt man dann hinterher, weil es nur um Features, Features, Features geht, und unten kommt man nicht mehr nach, die Schulden zu tilgen.

Ich kann mir vorstellen, dass es bestimmte KI-basierte Methodiken gibt, die technische Schulden aufdecken und Mi­gra­tionspfade aus diesem Schlamassel heraus aufzeigen.

Aber ich glaube auch, dass ein besseres Vorgehen wäre, die Abstraktion zu erhöhen, auf der wir Software denken und Software entwickeln. Es muss sich wirklich keiner mehr die Frage stellen, ob er jetzt Angular Signals oder Observables oder was auch immer verwendet. Für uns Techies ist das zwar cool, aber das bringt die Software nicht weiter und hilft nicht denen, die die Software brauchen.

„Schaut euch diese integrierten KI-Entwicklungstools an, und ja – ihr könnt euch langsam von dem Dinosaurier Visual Studio verabschieden.“

Was sagst du zu Tests beziehungsweise Unit-Tests und KI?

Christian: Das finde ich ein spannendes Thema. Ich bin jetzt nicht so der Verfechter von Unit-Tests. Für mich sind tatsächlich die End-to-End-Tests viel wichtiger. Am Ende des Tages muss es End-to-End funktionieren, und so viel Business-Logik gibt es oftmals nicht, sondern es sind viel mehr CRUD-Operationen. Dafür sind die Tools extrem gut. Hier kann ich meine Rahmenbedingungen formulieren: Das ist der Input und das muss der Output sein, und dann erzeugt das Tool die Tests. Das ist natürlich schon extrem sexy.

Viele haben sich immer gescheut, Tests selbst zu schreiben und sie dann – und jetzt kommt der wichtige Teil – auch nachzuziehen und upzudaten. Denn irgendwann wurden sie rot, und dann hat man das Feature abgeschaltet. Aber die KI-basierten Tools können die Tests automatisch nachziehen oder darauf hinweisen: „Du hast jetzt die Architektur geändert, und die Tests sind rot. Hier sind meine Vorschläge, wie du das fixen kannst.“

Brownfield und KI: Ist KI Segen oder Fluch?

Christian:(lacht) Wir haben Legacy-Migrationsprojekte bei drei Kunden: Einmal eine uralte datenbankzentrierte Technologie und Anwendung, einmal von einem Framework A zu Framework B und einmal ein Projekt, bei dem das Backend in Java geschrieben ist, aber nie ein Java-Backend-Entwickler verfügbar ist. Bei allen drei Projekten haben wir KI-Tools verwendet – entweder innerhalb der Entwicklungsumgebung oder indem wir ein kleines Kommandozeilen-Tool geschrieben haben, das das OpenAI-SDK nutzt, um Migrationsaspekte beziehungsweise Integrationsaspekte komplett zu automatisieren. Wir haben damit niemanden gebraucht, der uns die Architektur erklärt. Das Tool hat uns das alles erklärt, was übrigens ein Super-Power-Feature der KI ist. Ob das jetzt nur APIs sind oder ein Datenbankschema ist oder eben eine komplette Code-Basis – das ist Magie.

Bei „erklären lassen“ fällt einem sofort die technische Dokumentation ein.

Christian: Ein wichtiger Punkt. In jedem Projekt, das ich bislang gesehen habe, war die Dokumentation sofort veraltet, sobald der Entwickler auf „Save“ gedrückt hat. Und keiner hat sie mehr nachgezogen. Das kann man jetzt komplett neu denken. Man könnte einen eigenen AI-Agenten bauen, der die Dokumentation automatisch nachzieht und mir dann nur noch Pushes gibt, um Feedback einzuholen. Oder noch radikaler: Für was brauche ich Entwicklerdokumentation? Ich frage einfach das System, und es gibt mir immer den aktuellen Blick darauf. Das ist schon richtig toll. Und das funktioniert mit einem komplexen, Microservice-basierten Ansatz End-to-End mit vielen fachlichen, nichtfachlichen, synchronen, asynchronen Aspekten, in puncto Security, verschiedene Frontend-Technologien und, und, und. Das ist der Wahnsinn.

Gibt es Nachfrage von euren Kunden, die KI in ihre Anwendungen einzubauen?

Christian: Ja. Wir sind tief in generativen KI-Technologien mit Embeddings, Small und Large Language Models, on Premises, in der Cloud und so weiter, um den Kunden zu zeigen, was jenseits von Hype und Bullshit Bingo tatsächlich funktio­niert und was nicht funktioniert. Kunden, die neu zu uns kommen, wollen immer etwas mit GenAI haben und nichts mehr mit Standardtechnologien, Architektur oder Frameworks.

Da tränt dein WCF-Auge, oder?

Christian: Na, das ist aber schon lange her. Da waren alle Haare noch schwarz. Aber wir müssen in die Zukunft schauen, neue Ansätze verwenden und neue Technologien, um zu evaluieren, was sinnvoll für das jeweilige Projekt oder Produkt ist. Wie baut man es dann ein? Denn streng genommen sind wir immer im Brown­field unterwegs. Greenfield existiert quasi nur für Demos, Konferenzen und Workshops. Aber im echten Leben ist es nun mal Brownfield. Selbst wenn wir nur auf der existierenden Datenbank aufsetzen, ist es ja schon etwas Existierendes.

Die Kunden wollen dann die Unwissenheit und die Unsicherheit wegbekommen, wollen also wissen, was geht, was nicht geht und wie es mit diesen Halluzinationen ist.

Ziel ist dann herauszufinden, wie mögliche Use Cases aussehen können, also das, was über einen Chatbot über der Dokumentation hinausgeht. Aber man kann natürlich viel mehr machen, wenn man an das Potenzial von Language Models denkt. Menschliche Sprache quasi zum First Class Citizen zu machen oder über agentenbasierte Denkweisen eine Teil­automatisierung von Arbeitsabläufen hinzubekommen.

Momentan liegen Large Language Models sehr im Trend. Sind wir dadurch blind für andere KI-Entwicklungen?

Christian: Ja, Punkt. Na klar, das Spotlight der Scheinwerfer ist komplett auf LLMs, also auf diesen Transformer-basierten Architekturen. Wenn du aber schaust, was die Experten so veröffentlichen, wie zum Beispiel Yann LeCun [10], Chief AI Scientist von Meta, der sagt, es ist zwar alles geil, was hier gerade passiert, aber Transformer sind Kindergarten. Die werden uns nicht wirklich weiterbringen. Am Ende des Tages sind die auch nicht AI, sondern super clevere, statistische, mathematische Modelle, die im Trainingsprozess mit unglaublich vielen Daten gespeist wurden.

Die forschen natürlich an anderen Ideen, die darüber hinausgehen, und das fliegt dadurch aktuell komplett unterm Radar. Das ist aber auch ganz okay, weil wir uns über die Large Language Models und über die Embedding-Modelle ganz gut dieser Problematik und Thematik nähern können, ohne dass es gleich komplett abgedreht wird.

Wir können uns die ersten Jahre ein bisschen warm machen mit künstlicher Intelligenz. Menschliche Sprache rein, menschliche Sprache raus oder strukturierte Informationen rein, strukturierte Informationen raus. Von daher finde ich das gar nicht so schlecht, dass das Spotlight darauf liegt – aber es ist auf jeden Fall nicht das Ende der Fahnenstange.

Welche Tipps würdest du Entwicklern geben, die durch die KI vielleicht etwas verunsichert sind?

Christian: Ich würde das empfehlen, was ich auch meinem Sohn gesagt habe. Der ist jetzt achtzehneinhalb und hat mit dem Studium für Angewandte KI an einer Online-Uni angefangen. Da ist das Curriculum noch relativ klassisch, aber natürlich passiert sehr viel über Teams und über Online-Tools und so weiter.

Ich habe ihm geraten: Versuch mal, sowohl die klassischen Challenges so zu machen, wie sie es dir sagen, und dann aber auch GenAI-assisted, also innerhalb der IDE, um ein Gespür dafür zu bekommen, was sinnvoll und was nicht sinnvoll ist. Wo hast du wirklich mehr Power und wo weniger? Wo bist du wirklich produktiv, wo weniger? Wo bist du kreativer? Das heißt, mein Tipp ist tatsächlich: Schaut euch diese integrierten KI-Entwicklungstools an, und ja – ihr könnt euch langsam von dem Dinosaurier Visual Studio verabschieden. Denn da wird wahrscheinlich absehbar nichts Innovatives passieren. Der ganze Mojo passiert eher in Visual Studio Code.

Entweder gibt es Plug-ins innerhalb des Editors, oder sie forken Visual Studio Code, um dann ihre eigene IDE zu machen, wie zum Beispiel bei Cursor.

Das heißt, guckt euch so ein Tool wie Cursor oder Cline an und baut etwas damit. Entweder ein privates Projekt oder einen Proof of Concept innerhalb der Firma. Behandelt die KI aber nicht als allwissende, mächtige Instanz, sondern als Junior Developer, dem du alles genau erklären musst und dessen Output du immer überprüfen musst. Mit dem du aber Pair Programming und Pair Architecting machen kannst. Der vor allem nie schlecht gelaunt, immer verfügbar, aber leider dement ist. Denn wenn du eine neue Sitzung beginnst, ist das Kontextfenster weg. Dann gibt es natürlich entsprechende Verständnisprobleme.

Aber du kannst immer mit diesem Junior arbeiten, und dieser Junior hat zusätzlich Zugriff auf das ganze Wissen, das du ihm zur Verfügung stellst. Das ist ein ganz wichtiger Punkt.

Ich finde diese Large-Language-Model-basierten Ansätze vor allem deswegen so sensationell, weil sie Konzepte und Sprache verstehen, und nicht notwendigerweise, weil sie Wissen haben. Denn dieses Wissen ist vielleicht überholt. Zum Beispiel musst du an einem Projekt mit der neuesten Angular-Version arbeiten, aber der Knowledge Cut Off des Large Language Models war vielleicht vor eineinhalb Jahren. Dann erzählt dir das Modell irgendeinen Blödsinn. Du sagst beispielsweise: „Gib mir mal etwas mit Angular Signals“, und dann halluziniert dir das Modell das Blaue vom Himmel he­runter. Deshalb ist es wichtig, dass du Tools verwendest, in denen du der KI Leitplanken geben kannst. Sprich, du kannst in Tools wie Cursor die aktuellste Angular-Dokumentation oder deine Coding Guidelines dazupacken. Das hilft, den Kontextbezug zu formalisieren und zu konkretisieren und ebendiesen Hang zu Halluzinationen fast zu eliminieren. Nimm also ein Tool, aber sieh es als Junior, der dir hilft, schneller, besser, kreativer und produktiver zu werden.

Der Blick in die Glaskugel: Wie wird dein Beruf, wie wird dein Job, dein Alltag in zwei Jahren aussehen?

Christian: Ich muss dich enttäuschen. Das kann ich echt nicht sagen. Vor zweieinviertel Jahren wusste ich nicht, dass ich heute hier sitze und genau das erzähle, was ich jetzt erzähle. Wir leben in einer Zeit, die man so noch nicht erlebt hat. Es ist eine Art industrielle Revolution, die gerade passiert.

Von daher wage ich keine Projektion nach vorne, und vor allem will ich mich lieber überraschen lassen. Wöchentlich kommt so viel Interessantes, Spannendes, Sensationelles raus, dass man sich diese Art der Freude der Weiterentwicklung auch nicht nehmen lassen sollte.

Ein wichtiger Punkt ist vielleicht noch: Ich arbeite nicht an den Basistechnologien und an den Forschungsergebnissen ganz unten, sondern wir setzen auf dem API-Layer auf. Daher lese ich natürlich immer wieder mal die Weekly Top Papers aus der Forschung oder lasse sie mir von der KI zusammenfassen. Und ich schaue natürlich auch links und rechts über den Tellerrand. Ich kann dir nicht sagen, was passieren wird, aber was wir machen können: Wir verabreden uns für den 25. Februar 2027 zu einem Folgeinterview.

[1] Thinktecture

[2] Cline

[3] Bolt.new

[4] Cursor

[5] v0

[6] Lovable

[7] SWE-Lancer

[8] Upwork

[9] OpenAI Researchers Find That Even the Best AI Is ­Unable To Solve the Majority of Coding Problems

Yann LeCun