Marc-André MoreauHinweis: Dieser lange Beitrag wurde ursprünglich für die Essay-Challenge von The Pragmatic Engineer darüber geschrieben, wie sich Software Engineering verändert.
Oktober 2025. Claude Sonnet 4.5 ist gerade erschienen, und alle bei Devolutions durchlaufen ein KI-Training von Mindstone. Die Botschaft des CEO ist klar: Wir unternehmen alle nötigen Schritte, um das Unternehmen KI-nativ zu machen. Mitarbeiter, die nicht Teil dieses neuen „Devolutions 2.0“ sein wollen, erhalten ein freiwilliges Abfindungspaket. Wer bleibt, muss sich verpflichten und mit dem Rest von uns voll auf KI setzen. Hier ist die Geschichte des tiefgreifenden Wandels bei Devolutions und wie eine große Migration, die ursprünglich auf drei Jahre geschätzt wurde, in nur einem Jahr abgeschlossen wurde.
Devolutions ist ein kanadisches Softwareunternehmen, das aus eigener Kraft gewachsen ist, mit Hauptsitz in Lavaltrie, Québec, und über 250 Mitarbeitern weltweit. Der Name „Devolutions“ steht für „Development Evolutions“, aus der Zeit, als der Gründer David Hervieux Softwareentwicklungsaufträge ausführte, lange vor dem heutigen kommerziellen Erfolg unseres Flaggschiffprodukts Remote Desktop Manager (RDM). RDM ist ein Verbindungsmanager: Er startet Verbindungen mit der Injektion von Anmeldeinformationen für Protokolle wie RDP, SSH, VNC, ARD, PowerShell und weitere. Wenn etwas Anmeldeinformationen akzeptiert und eine Verbindung aufbaut, unterstützt RDM es sehr wahrscheinlich bereits.
Mein Team ist etwas Besonderes: Es umfasst die Entwickler der Niederlassung in Ottawa, aber auch Entwickler in den USA, in Deutschland und in Japan. Intern nennen wir es das „Architektur“-Team, weil wir für den Bau vieler wiederverwendbarer Komponenten verantwortlich sind, die andere Teams nutzen. Die Struktur ist sehr locker, aber alle sind hochgradig autonom, motiviert und verantwortlich. Die meisten Teams bei Devolutions arbeiten vor Ort, nicht remote, im Hauptsitz in Lavaltrie.
Ich selbst bin der CTO von Devolutions. In einem früheren Leben habe ich das FreeRDP-Projekt gegründet. Ich bin Microsoft MVP in den Kategorien Windows und PowerShell. Mein Hauptfachgebiet sind Windows-Protokolle, besonders für RDP und Authentifizierung. Ich habe ein Händchen für Reverse Engineering und dafür, in Systeminterna einzutauchen. Ich experimentiere gern mit Technologie, um Wege zu finden, wie wir die Puzzleteile zusammensetzen und die Produkte bauen können, die wir wollen.
Windows-Desktopanwendungen bleiben in der Welt der KI oft zurück: Die beliebtesten Werkzeuge kamen zuerst ohne Windows-Unterstützung heraus, und als sie endlich kam, war sie unvollständig. Desktopanwendungen sind gegenüber Webanwendungen stark im Nachteil, weil sie sich mit KI viel schwerer automatisch validieren lassen. Trotz dieser Herausforderungen haben wir Remote Desktop Manager, eine riesige .NET-Unternehmensanwendung mit Tausenden von UI-Dialogen, in weniger als einem Jahr auf Avalonia, ein plattformübergreifendes UI-Framework, portiert. Noch überraschender ist, dass die Windows-Migration als Erste 100 % erreichte, vor anderen Plattformen mit weniger technischer Schuld.
Drei Jahre in einem Jahr
Das große Avalonia-Migrationsprojekt
Wir sind Desktop-first und wir wollen großartige Desktopanwendungen bauen. Deshalb sponsern wir Avalonia mit 3 Millionen Dollar über 3 Jahre. Der Grund ist einfach: Wir wollen die Erfahrung einer Desktopanwendung nicht opfern, indem wir eine Webanwendung verwenden, die sich als Desktopanwendung tarnt, wie Electron, aber wir müssen die Entwicklungslast senken, indem wir auf ein plattformübergreifendes UI-Framework in .NET migrieren. Wir haben über die Jahre viel Legacy und viele fortgeschrittene Funktionen angesammelt, deshalb können wir es uns nicht leisten, zwischen zwei Hauptversionen alles auf ein neues UI-Framework umzuschreiben. Vor der KI schätzten wir den Aufwand auf mindestens 3 Jahre. Avalonia gab uns die Mittel für eine teilweise Migration, sodass wir native UI-Elemente mit Avalonia mischen konnten.
Das ist die ehrgeizigste Migration, die bei Devolutions je versucht wurde: über 1.500 WinForms-UI-Elemente, die auf mehr als ein Jahrzehnt Arbeit zurückgehen, allein für RDM Windows. Andere Plattformen haben weit weniger native UI-Elemente. Im Oktober 2025 habe ich untersucht, wie wir KI nutzen könnten, um das zu beschleunigen, denn zu diesem Zeitpunkt war die Migration noch größtenteils manuell. Als Erstes habe ich ein Skript geschrieben, das Quelldateien in unserem Monorepo durchsuchte und die Zahl der plattformspezifischen UI-Elemente zählte, die noch zu migrieren waren, beginnend beim allerersten Commit, in dem Avalonia eingeführt wurde. Diese Zahl wurde unsere Baseline, und jede Plattform musste sie auf null bringen, indem die Elemente entfernt wurden, sobald sie durch Avalonia ersetzt waren.
Die Gesamtzahl für alle Plattformen zusammen lag bei über 5.800 zu portierenden UI-Elementen, und der Fortschritt betrug zu diesem Zeitpunkt für jede Plattform kaum ein paar Prozent.
Die Phase der KI-Slop-Kanone
Frühe Versuche, die Avalonia-Migration zu beschleunigen, führten zu viel KI-Slop, für den ich persönlich größtenteils verantwortlich war. Zum Glück war die Frustration nur vorübergehend, und im Rückblick war es ein nötiger Schritt, um zu lernen. Der eigentliche Wert der Phase der KI-Slop-Kanone war ein Weckruf für die Entwickler, die wussten, was sie taten: Sie begannen, Anweisungen für die KI zu ergänzen und zu verbessern, damit sie weniger Fehler machte.
Das waren die Herausforderungen:
- Ich habe selbst wenig UI gemacht, also wusste ich nicht, was ich tat
- KI-Modelle von vor einem Jahr machten viele Fehler
- Die KI hatte nicht die richtigen Werkzeuge, um Vorher und Nachher zu sehen
RDM unterstützt viele Verbindungseinträge, besonders VPNs, die Benutzer als Abhängigkeit für einen anderen Verbindungseintrag nutzen können. Zum Beispiel kann eine RDP-Verbindung automatisch ein WireGuard-VPN starten, wenn es nötig ist, um den zugehörigen RDP-Server zu erreichen. Ich beschloss, zuerst den VPN-Verbindungseintrag zu portieren, in der Hoffnung, genug Anweisungen zu gewinnen, damit die KI alle anderen VPN-Einträge gut portieren könnte. Es brauchte ein paar Versuche, und ich musste Kollegen bitten, mir auf einem experimentellen Branch Dinge zu reparieren. Danach habe ich die Anweisungen aktualisiert, indem ich das LLM auf die Commits zeigte, damit es daraus lernte. Nach ein paar solchen Iterationen waren die Anweisungen gut genug, dass ich ein paar weitere VPN-Eintragstypen automatisch portieren konnte, aber sie brauchten weiterhin viel Nacharbeit.
Der Prozess wurde halbmanuell: Ich startete eine Sitzung, in der ich den Agenten anwies, die nächsten einfachsten VPN-Eintragstypen zu analysieren und aufzulisten, die ich als Nächstes portieren konnte. Ich machte sie in Stapeln von 10, startete dann RDM manuell, machte Screenshots davor und danach und fügte sie wieder in den KI-Agenten ein. Die Screenshots allein halfen sehr, das Visuelle richtig hinzubekommen, aber viele Probleme zeigten sich erst durch Klicken und Ausprobieren. Viele Elemente verlangten die Erkennung bestimmter VPN-Software, die installiert und nutzbar sein musste, deshalb war es nicht leicht, alles zu testen. Ich habe auf diese Weise etwa hundert Verbindungseinträge migriert. Nach meinem besten Wissen funktionierte das, aber viele kleine Probleme rutschten durch, und andere mussten Zeit aufwenden, um sie zu beheben.
An dem Punkt habe ich pausiert, denn mein Ziel war, den KI-Migrationsprozess in Gang zu bringen: Eine einzelne Markdown-Datei mit 5.000 Zeilen WinForms-zu-Avalonia-Anweisungen, geschärft in diesen frühen Versuchen, wurde nun von ein paar Entwicklern erfolgreich genutzt. Die Migration lief nicht in halsbrecherischem Tempo, aber sie lief schneller als zuvor. Tief im Inneren wusste ich, dass wir nur Monate davon entfernt waren, dass die richtige Person das Tempo aufnahm, nachdem sie vollständig verstanden hatte, wie man den Prozess effizient optimiert, um die meiste Zeit mit Review und schnellen Korrekturen zu verbringen, während die große Mehrheit der Ausführung von der KI erledigt wird. Stellen Sie sich jemanden vor, der im QA-Stil testet, Hunderte von UI-Dialogen durchgeht, um Dinge zu validieren, und zugleich das Vertrauen hat, den Code zu reparieren, statt einfach ein Ticket zu öffnen. Zum Glück ist genau das schließlich passiert!
Die Beschleunigung der Avalonia-Migration
Anfang April 2026 erreichte RDM Windows 25 % Abschluss der Avalonia-Migration. Ende desselben Monats war der Meilenstein von 50 % erreicht.
Über den Sommer wurden erhebliche Fortschritte gemacht, bis wir Anfang September den Meilenstein von 100 % in RDM Windows erreichten:
Das ist ein deutlicher Bruch mit dem Tempo der frühen Migration. Was hat sich geändert?
- Viele gemeinsame, wiederverwendbare Avalonia-Komponenten wurden hinzugefügt, um die Migration zu erleichtern
- Leute, die wussten, was sie taten, nahmen sich die Zeit, die KI-Anweisungen zu verbessern
- Eine Handvoll Personen ging Hunderte von UI-Komponenten auf einmal durch
Die ursprünglichen KI-Migrationen, die Slop einführten, halfen auch, eine Liste von Problemen sichtbar zu machen, die saubere Grundlagenarbeit brauchten. Zum Beispiel gab es noch keine plattformübergreifende Dateiauswahl-Komponente, also wurde eine richtige gebaut, und die KI-Anweisungen wurden aktualisiert, damit sie diese nutzen. Sonst hätte die KI plattformspezifische Dateiauswahlen oft hinter bedingter Kompilierung versteckt und das mehrfach ohne Wiederverwendung wiederholt. Wir mussten zuerst Zeit darauf verwenden, diese nötigen, komplexeren Bausteine zu bauen, bevor wir versuchten, schneller zu werden.
Diese Arbeit wurde dann von anderen aufgenommen, die die Gewinne „einforderten“, indem sie die neu freigeschalteten Komponenten geringerer Komplexität migrierten und sie in großen Stapeln validierten. Das ist wichtig: Selbst wenn Sie theoretisch hundert UI-Komponenten haben, die migriert werden können, ist die Arbeit erst erledigt, wenn die ursprünglichen Quelldateien entfernt sind. Sonst können Sie sich des tatsächlichen Fortschritts nie sicher sein.
Wenn Sie die anderen Plattformen genau ansehen, fällt Ihnen vielleicht ein starker Prozentanstieg zwischen den Meilensteinen von 50 % und 100 % bei RDM Windows auf, besonders bei RDM Linux, das von 12,7 % auf 94,3 % stieg. Viele der aus WinForms in RDM Windows migrierten Komponenten konnten nun unverändert in RDM Linux wiederverwendet werden. Das allein reichte nicht, sonst hätten wir RDM Linux früher bei 50 % (oder mehr) gesehen. Der Wechsel geschah, als die RDM-Linux-Entwickler begannen, die Gewinne aggressiv einzufordern, indem sie Hunderte der ursprünglichen Linux-Komponenten durch die neuen Avalonia-Komponenten ersetzten und sie in großen Stapeln validierten.
Wie sich die Softwareentwicklung verändert hat
Änderungen vornehmen, bei denen Sie sich nicht wohlfühlen
Bei meinen frühen Versuchen, WinForms mit KI nach Avalonia zu migrieren, habe ich nicht wirklich verstanden, was ich tat. Ich bin kein UI-Entwickler, war es nie und werde es wahrscheinlich nie sein (ohne KI). Es mag kontraintuitiv sein, aber es steckt viel Wert darin, Änderungen vorzunehmen, bei denen Sie sich nicht wohlfühlen. Bei der Avalonia-Migration war die Absicht, genug KI-Anweisungen zu schärfen, um den Großteil der Fleißarbeit zu automatisieren und dem Entwickler das manuelle Review und die Korrekturen nach der Migration zu überlassen.
2025 hat Devolutions PowerShell Universal übernommen, und der Schöpfer des Produkts, Adam Driscoll, kam in mein Team. Kurz darauf stellten wir einen weiteren Entwickler für das Produkt ein und verdoppelten damit praktisch die Größe des ursprünglichen Ein-Personen-Teams. PowerShell Universal (PSU) ist eine in C# geschriebene ASP.NET-Anwendung, mit der ein IT-Administrator Skripte in voll funktionsfähige Webanwendungen verwandeln kann, die Endbenutzern bereitgestellt werden. Sie kann Skripte auch auf einem entfernten Rechner über einen Agenten ausführen.
Devolutions hatte bereits einen Agenten mit fortgeschritteneren Funktionen, darunter Fähigkeiten zur entfernten Ausführung. Es dauerte nicht lange, bis wir planten, den ursprünglichen, in C# geschriebenen PSU-Agenten durch den vorhandenen, in Rust geschriebenen Devolutions Agent zu ersetzen. Die Herausforderung war, dass die PSU-Entwickler kein Rust konnten und die Entwickler des Devolutions Agent kein PSU kannten. In der Theorie war es eine einfache Integration. In der Praxis sah ich keinen echten Fortschritt, nur Mockups und Demos, keine Pull Requests, die uns näher an etwas gebracht hätten, das wir ausliefern könnten.
Ich bat die C#-Entwickler, etwas zu tun, wobei sie sich nicht wohlfühlten: Machen Sie einfach Vibe Coding und schreiben Sie im Rust-Code nach bestem Wissen das, was Sie brauchen, weil Sie wissen, wie Sie es in PowerShell Universal nutzen wollen. Die Absicht zählt: Wir wussten, dass die Änderungen dem entsprechen würden, was sie wollten, auch wenn wir die Form durch mehrere Anpassungen wahrscheinlich noch ändern würden. Der Ausgangspunkt war ein funktionierender Build des Devolutions Agent, von dem wir wussten, dass er dem entsprach, was für PowerShell Universal gewünscht war. Kein Mockup, keine Designspezifikation!
Ich half beim Review der Umsetzung, und es gab viel Hin und Her zwischen den C#- und den Rust-Entwicklern, bis wir die Form festlegten, wie sich der Devolutions Agent mit PowerShell Universal verbinden und als Remote-Ausführungshost für PowerShell-Skripte konfiguriert werden würde. Das ist einer meiner stolzesten Momente: Entwicklung beschleunigen, indem Entwickler Code ändern, den sie nicht verstanden, weil sie die Absicht besser verstanden als diejenigen, die ihn später reviewen würden.
Warum funktioniert das? Weil Entwickler bei vielen Integrationen oft nur ihren eigenen Teil gut kennen, aber kein tiefes Wissen über das haben, womit sie integrieren. Dieser Ansatz macht es beiden Seiten leichter, am echten Code zu iterieren, bis ein Konsens erreicht ist. Egal wie gut Ihr Mockup ist, der echte Code ist immer besser.
Den agentischen Feedback-Kreislauf schließen
KI verändert vieles, aber einige Grundregeln bleiben. KI ist nur so gut wie die Werkzeuge, mit denen sie arbeiten kann. Wenn Ihre KI keine Augen hat, sieht sie keine kaputten visuellen Layouts: Sie vermutet nur, dass sie das Richtige getan hat. Wenn Ihre KI keinen Debugger nutzen kann, instrumentiert sie den Code mit Logging, um herauszufinden, welche Codepfade genommen werden. In vielen Fällen ist die mangelnde Effizienz nicht wichtig, solange sie die Dinge schließlich selbst herausfindet oder ein Mensch in der Schleife ist, um zu validieren.
Wenn es eine Lektion gibt, die Sie sich aus diesem Jahr merken sollten, dann diese: Sie sollten darin investieren, den agentischen Feedback-Kreislauf der KI zu schließen, um den größten Nutzen zu ziehen. Der Kreislauf war für die Avalonia-Migration von RDM nicht vollständig geschlossen, aber das wurde dadurch ausgeglichen, dass Entwickler die Änderungen schnell validierten und iterierten.
Anfang dieses Jahres haben wir das Open-Source-Projekt UniGetUI übernommen. UniGetUI ist eine Benutzeroberfläche über mehrere Paketmanager wie WinGet, Chocolatey, PowerShell, npm, pip und weitere. Das Projekt war ursprünglich nur für Windows, geschrieben in C# mit WinUI. Es ist jetzt mit Avalonia vollständig plattformübergreifend, und Sie können es mit Homebrew unter macOS oder mit distributionsspezifischen Paketmanagern unter Linux nutzen. Diese Migration brauchte mehrere Versuche bis zum ersten Erfolg und wurde ganz anders gemacht als die für RDM.
Ich habe den Deal zur Übernahme von UniGetUI persönlich vermittelt. Dadurch gingen Wartung und Eigentum am Projekt an Devolutions über, ohne dass der ursprüngliche Autor beteiligt war. Ich habe die gesamte Anfangsarbeit für den Übergang gemacht, bis wir dem Projekt einen Vollzeitentwickler zuwiesen. Ich habe zwei Versuche unternommen, UniGetUI automatisch nach Avalonia zu migrieren. Beide scheiterten, weil die LLMs nicht herausfanden, wie die Avalonia-APIs korrekt aufzurufen sind, und weil ich nicht das richtige Werkzeug hatte, um den Feedback-Kreislauf mit dem KI-Agenten zu schließen, indem ich ihm Augen auf das Ergebnis gab.
Beim dritten Versuch habe ich den Avalonia Build MCP konfiguriert, der dem LLM erlaubte, die API-Dokumentation effizient abzurufen, und ich habe die Anwendung so instrumentiert, dass sie mit dem Avalonia DevTools MCP nutzbar war. Ich hatte nun eine korrekte Nutzung der Avalonia-APIs, aber wichtiger: Das LLM konnte die Avalonia-Anwendung starten, mit ihr interagieren und das visuelle Ergebnis auf eine Weise prüfen, die dem Playwright-MCP-Server für Webanwendungen sehr ähnlich ist. Ich ließ es über 24 Stunden allein laufen und sagte GitHub Copilot im Grunde nur, es solle weitermachen. Am Ende hatte ich eine erste funktionierende, nutzbare Version von UniGetUI in Avalonia, die der ursprünglichen WinUI-Version nahe genug kam.
Das habe ich dem neuen Entwickler übergeben, den wir Vollzeit für UniGetUI eingesetzt hatten. Mit ein paar weiteren Wochen an Feinschliff und Korrekturen durch jemanden, der besser mit Avalonia umgehen konnte als ich, haben wir endlich etwas Anständiges erreicht. Da Benutzer auf den Wechsel des UI-Frameworks besonders empfindlich reagieren, dauerte es etwa zwei Monate, bis wir die ursprüngliche WinUI-Version löschen und nur noch beim neuen Avalonia-Frontend bleiben konnten.
Technische Schulden abbauen
Devolutions Server ist eine ASP.NET-Anwendung, die SQL Server ohne ORM nutzt. So ist es von Anfang an, und weil es viel Legacy gibt, können wir nicht einfach Unterstützung für eine andere Datenbank wie PostgreSQL „eben mal“ hinzufügen. Erschwerend kommt hinzu, dass die eine Person im Unternehmen, die diesen heiklen Teil der Anwendung kennt, kurz vor dem Ruhestand steht (er ist unser früherer CTO). Als Fable 5 am 9. Juni veröffentlicht wurde, sah ich die perfekte Gelegenheit, die PostgreSQL-Migration zu versuchen, denn bald wäre das spezialisierte Wissen über diese technische Schuld nicht mehr verfügbar.
Ich habe in GitHub Copilot mit Fable 5 sorgfältig einen Plan erstellt und dann den Agenten gestartet. Innerhalb der ersten 24 Stunden habe ich es auf ein minimal funktionsfähiges Niveau gebracht. Dann habe ich eine erschöpfende Lückenanalyse gemacht, um Löcher zu finden, die behoben werden mussten, einen neuen Plan mit mehr Testabdeckung erzeugt und mehr End-to-End-Tests ergänzt. Ich ließ GitHub Copilot seine Browser-Canvas nutzen, um die Webanwendung zu laden, sich mit einem Testbenutzer anzumelden, herumzuklicken und zu validieren, dass es wirklich funktionierte. Ich ließ es sogar Tests durchlaufen, bei denen auf geplante Aufgaben gewartet werden musste. Am Abend des 12. Juni, als eine US-Exportkontrollrichtlinie Anthropic zwang, Fable 5 für alle zurückzuziehen, nur drei Tage nach der Veröffentlichung, hatte ich den Großteil der Arbeit abgeschlossen.
Auch ohne tiefes Verständnis von Datenbanken und diesem Teil der Anwendung hatte ich zu diesem Zeitpunkt meine Fähigkeit geschärft, große und komplexe Migrationen mit KI durchzuführen. Ich nutzte eine detaillierte, erschöpfende Lückenanalyse, um herauszufinden, was zu tun war, was repariert werden musste und was sich nicht wie das Original verhielt. Ich erzeugte Pläne, um Unit-Tests hinzuzufügen, aber auch Integrationstests, und kombinierte das mit End-to-End-Tests, bei denen der KI-Agent mit der Anwendung interagierte. Was ich produzierte, war nützlich und bis zu einem gewissen Grad als funktionsfähig nachgewiesen, aber noch nicht tiefgehend gereviewt.
Hier wird es interessant: Ich hatte mit unserem früheren CTO noch nie so viel Spaß wie im vergangenen Jahr. Er war vom Fortschritt sehr beeindruckt und begann, Dinge, die er finden konnte, mit Claude Code zu reparieren. Ich übergab ihm meinen Branch, nachdem ich ihn auf das Niveau gebracht hatte, das ich erreichen konnte, und er führte ihn von dort weiter, mit einer Perspektive, die ich nicht hatte. Es dauerte ein paar Wochen, bis wirklich alle verbliebenen subtilen Probleme gefunden waren, aber wir waren ein sehr gutes Team und haben es geschafft.
Meine Empfehlung beim Abbau technischer Schulden in Hochrisikobereichen des Codes lautet: Geizen Sie nicht bei den Tokens. Nutzen Sie die größten Modelle und starten Sie viele fokussierte Reviews, um verschiedene Arten von Problemen sichtbar zu machen, von denen Sie befürchten, dass sie auftreten. Es ist sehr leicht, Dinge zum Laufen zu bringen, aber es braucht viel mehr Zeit und Aufwand, sie richtig hinzubekommen.
Wie sich Code-Reviews verändert haben
Reviewen Menschen jede einzelne Codezeile? Nein, denn das skaliert nicht. Niemand kann einen ständigen Strom riesiger Pull Requests reviewen und dabei konzentriert genug bleiben, um alle Probleme zu finden. Die gute Nachricht: Ein KI-Agent wird nie müde, Probleme zu finden. Code-Reviews bei Devolutions bestanden oft darin, einem Kollegen die Änderungen zu erklären, und er stellte Gegenfragen. Mit KI können Sie zuerst ein lokales Review Ihrer Änderungen machen und dann einen weiteren KI-Agenten ein zweites Review durchführen lassen, wenn Sie den Pull Request öffnen.
Hier eine amüsante Geschichte zum Code-Review von GitHub Copilot: Jemand hat sich einmal „beschwert“, dass es auf seinen Pull Requests immer wieder Probleme fand, und weil es legitime Probleme waren, konnte er nicht dagegen argumentieren. Wenn all diese Probleme im Code existieren, warum kann es nicht 50 auf einmal melden, statt 10 nacheinander? Der eigentliche Ärger war die Schleife, bis das KI-Code-Review keine echten Probleme mehr fand, die zu beheben waren.
Bei Änderungen mit einem potenziell großen Wirkungsradius sieht sich normalerweise jemand die Änderungen genauer an. Statt Zeile für Zeile in der GitHub-Weboberfläche zu gehen, fanden wir es viel effizienter, den Branch einfach lokal auszuchecken und der KI die Fragen zu stellen, die Sie dem Autor des Pull Requests normalerweise gestellt hätten. Sie können alle Ihre Bedenken auf einmal abladen und warten, bis die KI prüft, ob die Änderungen Ihren Erwartungen entsprechen. Es ist auch leichter, die KI zu bitten zu erklären, wie Änderungen gemacht wurden, welche Teile der Anwendung sie betreffen und wie. Danach können Sie die KI einfach bitten, die Befunde als Inline-Kommentare am Pull Request einzureichen.
Um Pull Requests nicht „blind abzustempeln“, haben wir derzeit ein Pilotprojekt für automatische Pull-Request-Freigaben durch KI, wenn die Änderungen bestimmte Kriterien erfüllen. Es hat keinen Sinn, auf einen Menschen zu warten, der einen Knopf drückt, wenn der Wirkungsradius nicht kritisch ist.
KI bei Devolutions skalieren
Die Explosion der KI-Werkzeuge
Im Januar 2026 hatten wir intern ein Team von KI-Champions, deren Rolle es war, die KI-Nutzung zu fördern, indem sie ihre eigene Erfahrung mit ihren Kollegen teilten. KI-Anweisungen wurden von ein paar Entwicklern im Monorepo gepflegt. Die Botschaft an alle lautete, die KI-Anweisungen zu aktualisieren, damit sie den Code besser versteht, statt sich der KI zu widersetzen und sich zu beschweren, dass sie zu viele Fehler macht. Intern nutzten die meisten Entwickler Claude Code, kleinere Gruppen GitHub Copilot, Cursor oder Codex. Wir hatten zwei KI-Komitees: ein Lenkungskomitee mit der Führungsebene, um über KI-Initiativen auf höherer Ebene oder grundlegende KI-Projekte zu sprechen, und ein KI-Komitee als „Center of Excellence“ mit den KI-Champions, praxisnäher und operativ.
Die Versuchung ist da, zu standardisieren, welche KI-Werkzeuge wir anbieten, aber wir widerstehen ihr. Entwickler haben eigene Vorlieben, und wir wollen sie nicht zwingen, ein Werkzeug zu nutzen, das sie nicht mögen. Ich selbst mochte Claude Code nie und bin voll auf GitHub Copilot gegangen. Ich kann niemandem widersprechen, der sich in einem Werkzeug produktiv fühlt, das ich selbst nicht nutzen würde, selbst wenn ich es rational nicht erklären kann. Meine Theorie ist, dass der Produktivitätsgewinn von KI-Werkzeugen so groß ist, dass der Vergleich mit den Werkzeugen vor der KI gemacht wird, nicht zwischen KI-Werkzeugen. Sobald sich jemand mit einem KI-Werkzeug erfolgreich fühlt, das zu seinem mentalen Modell und seinem Arbeitsablauf passt, will er dabei bleiben. Ich war vor der KI ein großer Benutzer von VS Code, also bin ich natürlich zuerst zu GitHub Copilot gegangen. Viele Entwickler nutzen Claude Code lieber in einem Terminal neben ihrer Haupt-IDE (Visual Studio oder JetBrains) und sehen VS Code nur als eine weitere IDE neben ihrer bestehenden.
Wir erlebten die erste KI-„Ausfallzeit“, als wir ein monatliches Limit von 5.000 $ erreichten, was uns zwang, unser Konto bei Anthropic hochzustufen, um weiterarbeiten zu können. Ein paar Tage lang wechselten einige Claude-Code-Benutzer vorübergehend zu GitHub Copilot, während das Limit auf unserem Konto geklärt wurde. Diese Zahlen wirkten damals für das ganze Unternehmen groß. Heute ist das einfach das, was ein einzelner intensiver Benutzer leicht verbrauchen kann. GitHub Copilot nutzt noch das Premium-Request-Modell, das es unglaublich günstig machte, wenn man wusste, wie man es effizient einsetzt. Cursor ist teurer, aber wir haben begonnen, es unseren Webentwicklern und der Marketingabteilung anzubieten, wegen seiner fortgeschrittenen integrierten agentischen Browserfähigkeiten.
Eine Nebenwirkung der Explosion neuer KI-Werkzeuge ist, dass unser Lieferantenmanagement schnell zum Engpass wurde. Wenn jeden Tag ein interessantes neues KI-Werkzeug erscheint und die Botschaft des CEO klar ist, dass wir voll auf KI setzen, wuchs die Zahl der Anfragen, neue Produkte verschiedener Anbieter zu prüfen, über das hinaus, was unsere Rechts- und Sicherheitsabteilungen zeitnah bewältigen konnten. Selbst wenn Sie den gesamten Prozess durchliefen und das Werkzeug freigegeben wurde: Was ist mit neuen Funktionen, die wahrscheinlich erneut geprüft werden sollten, etwa Cloud-Sandboxing-Funktionen? Was ist mit neuen KI-Modellen, die herauskommen, aber von einem neuen Inference-Anbieter bereitgestellt werden, der bei der ursprünglichen Prüfung nicht genutzt wurde? Wir haben unseren Prozess gestrafft, aber es ist heute noch ein Problem.
Die großen KI-Markdown-Kriege
Erinnern Sie sich daran, als Agent Skills und AGENTS.md noch keine Sache waren und jedes Werkzeug eine andere Konvention für Markdown-Dateien nutzte? Ich nenne es gern die „großen KI-Markdown-Kriege“: verschiedene Dateinamen, Pfade, Formate und so weiter. Wenn Sie sich nicht auf ein einziges KI-Werkzeug standardisiert hatten, mussten Sie auf Inkompatibilitäten stoßen. GitHub Copilot nutzte .github/copilot-instructions.md, Claude Code nutzte CLAUDE.md, mit möglicher Verschachtelung. Wiederverwendbare „Slash Commands“ und pfadspezifische Anweisungen. Alle waren nur von ihren eigenen Werkzeugen lesbar, bis Claude-Skills zu Agent Skills wurden, die die meisten Werkzeuge übernahmen und aus denselben Pfaden lasen, alle außer Claude. AGENTS.md wurde die neue Norm, die Claude wiederum nicht las und für die stattdessen CLAUDE.md nötig war.
Ursprünglich schrieben wir Skripte, um die Agent Skills und Markdown-Dateien für die Kompatibilität in unserem Monorepo zu synchronisieren und anzupassen, mit einem CI-Job, der bei jeder Änderung einer der Dateien lief. Das machte es schwer, Anweisungen lokal iterativ zu aktualisieren. Schließlich wechselten wir zu Git-Symlinks, die unter Windows ein echter Schmerz sind, weil Symlinks eine spezielle Konfiguration brauchen, um richtig aktiviert zu sein. Wir begannen, Anweisungen aus der primären AGENTS.md/CLAUDE.md in kleinere Markdown-Dateien zu verschieben und wiederverwendbare Workflows in eigene Agent Skills auszulagern. Erinnern Sie sich an diese riesige Markdown-Datei mit 5.000 Zeilen für Avalonia-Migrationen? Sie wurde in viele kleinere Agent Skills aufgeteilt, und plattformspezifische Konventionen wurden in eigene Markdown-Dateien ausgelagert.
Neue Skills kommen weiter ins Haupt-Monorepo von Devolutions: Mehr als 25 allein betreffen spezifische Aufgaben rund um Avalonia. Agent Skills wurden hinzugefügt, um Übersetzungsdateien zu bearbeiten. Die ursprüngliche Version dieser Skills veranlasste das LLM naiv, sehr große .resx-Dateien zu lesen, nur um eine Zeile zu ändern. Sie wurden später umgeschrieben und optimiert, um ein Hilfsskript zu nutzen, wodurch die Kosten einer Bearbeitung von 1 $ auf ein paar Cent sanken, weil das LLM nicht mehr die ganze Datei lesen musste, nur die Zeile, die es ändern wollte.
Der Hackathon für Agent Skills
Die meisten Agent Skills wurden dennoch von einer Handvoll Personen im Unternehmen geschrieben, ein wiederkehrendes Thema in unseren KI-Komitees. Unsere Lösung war, im März einen unternehmensweiten Hackathon für „KI-Agent-Skills“ für Entwickler zu organisieren. Wir hatten in der Vergangenheit viele Hackathons abgehalten, aber das Interesse war in den letzten Jahren gesunken, mit weniger Teilnehmern. Es war Zeit für etwas Neues mit einem anderen Format, um die „Hackathon-Müdigkeit“ zu durchbrechen, die sich eingestellt hatte.
Ich nahm mir die Zeit, ein eigenes Repository für Agent Skills aufzusetzen, das Entwickler einfach klonen und im Werkzeug ihrer Wahl öffnen konnten, mit einer README.md und ein paar vorhandenen Agent Skills zum Einstieg. Ich schrieb eine gute AGENTS.md mit maßgeblichen Referenzen für das Verfassen von Agent Skills und mit Anweisungen, plattformübergreifende PowerShell-Skripte neben SKILL.md als Hilfsskripte zu nutzen. Die IT hatte PowerShell 7 auf allen Rechnern vorinstalliert, damit Benutzer von macOS, Linux und Windows diese Agent Skills von Anfang an nutzen konnten.
In den Wochen vor dem Hackathon machten wir verschiedene Ankündigungen, um die Teilnehmer anzuregen, sich zu überlegen, was sie tun wollten, und ihren Namen und ihre Projektidee vorab in einem Slack-Canvas einzutragen, den alle sehen konnten. Am Tag des Hackathons starteten wir mit einem kurzen Konferenzanruf, in dem ich das zu nutzende Git-Repository vorstellte, ein paar Beispiel-Agent-Skills zeigte, wie man anfängt und wo detailliertere Anweisungen zu finden sind. Das Ziel war einfach: Dieses Repository klonen, einen Agent Skill für alles schreiben, was Sie wollen, und einen Pull Request einreichen, wenn Sie fertig sind. Machen Sie sich keine Sorgen, den besten oder den komplexesten Agent Skill zu bauen. Konzentrieren Sie sich darauf, mindestens einen fertigzustellen. Am Ende des Hackathons sollte sich jeder wohl dabei fühlen, eigene Agent Skills zu schreiben. Keine Ausreden mehr. Agent Skills, die in einem bestimmten Projekt liegen mussten, um zu funktionieren, konnten in einem anderen Repository entwickelt werden, solange eine Kopie im dedizierten Hackathon-Git-Repository für die Pull-Request-Einreichung lag.
Dieser Ansatz mit einem einzigen Git-Repository für den Hackathon half wirklich, das Gefühl zu erzeugen, dass alle gemeinsam an derselben Sache arbeiteten, statt dass jeder in seinem eigenen getrennten Projekt saß. Im Slack-Kanal des Hackathons war viel los, Teilnehmer teilten Links zu ihren eigenen Pull Requests oder stellten Fragen. Es war bei Weitem der erfolgreichste Hackathon, den wir seit Jahren hatten, und am Ende waren 60 Agent Skills beigetragen worden.
KI über die Entwicklung hinaus ausweiten
Der Erfolg des „Entwickler“-Hackathons war so groß, dass er im Mai zu einem „No-Code“-Hackathon führte. Wir passten das Format etwas an, besonders bei den Werkzeugen, die zu ChatGPT oder Claude wechselten, und akzeptierten Custom GPTs und andere Arten benutzerdefinierter KI-Agent-Anweisungen, die in Chatbots am besten funktionieren. Konferenzräume waren für den Tag reserviert, mit Organisatoren, die sich zur Unterstützung bereithielten. Viele Nicht-Entwickler genossen es sehr, dass sich ein Experte die Zeit nahm, ihnen zu helfen, Dinge zu erreichen, von denen sie nicht einmal wussten, dass sie dazu fähig waren.
Vergessen wir nicht, dass selbst in einem Softwareunternehmen ein großer Teil des Geschäfts auf Nicht-Entwicklern beruht, und sie müssen ebenfalls Teil der KI-Transformation sein. Als Entwickler ist die Kluft zwischen KI-Werkzeugen für Entwickler und für Nicht-Entwickler für uns offensichtlicher als für Nicht-Entwickler, wenn sie unsere Werkzeuge ansehen. Wenn der Prompt die neue Benutzeroberfläche ist, gibt es einen Weg, Entwicklerwerkzeuge so einzurichten, dass unser Produktmarketing-Team sie nutzen kann? Die Antwort lautet, wie sich herausstellt, ja!
Zum Kontext: Viele interne Anfragen an unser Produktmarketing-Team betreffen Aktualisierungen oder Änderungen der Website, und die Änderungen macht das Web-Marketing-Team. Wir hatten Cursor für die Webentwickler bereits eingeführt, wegen seines integrierten Browsers, der sich anfühlt wie „Element untersuchen“ in Chrome, aber unendlich mächtiger. Ich setzte ein neues Git-Repository auf, ähnlich dem für den Hackathon, und schrieb eine Reihe von Agent Skills, mit denen sich jede Website leicht abrufen und spiegeln ließ, sodass Cursor statische Sites bearbeiten und Mockups erzeugen konnte. Kein Figma mehr mit viel Hin und Her: Sie konnten die echte Website einfach per Prompt bearbeiten, und ich fügte sogar einen Agent Skill hinzu, um die lokal geänderte statische Site in eine einzelne .htm-Datei zu exportieren.
Das ermöglichte viel schnellere Iterationen mit einer Kopie der echten Website, mit der man interagieren konnte. Das fühlt sich ganz anders an als Screenshots oder sogar interaktive Mockups, die die Website simulieren, aber nicht wirklich auf ihr beruhen. Das reduzierte die Zahl der Übergaben und langen Prozesse für Website-Änderungen deutlich. Am besten konnte der Entwickler die exportierte, geänderte statische Site nun in Cursor geben, damit die Änderungen korrekt im Quellcode umgesetzt wurden, aus dem die Website gebaut wird.
Heute ist dieses Team eines unserer fortgeschrittensten bei der KI-Einführung und kann Website-Änderungen auslösen, indem es den Cursor-Bot in einem Slack-Gespräch erwähnt. Die Website wird geändert, gebaut und vorübergehend bereitgestellt, mit einem Link, den Sie einfach öffnen können, um zu sehen, ob die Änderungen gut sind. Wenn sie freigegeben werden, werden sie zusammengeführt und automatisch bereitgestellt. Für Desktop- und Mobilanwendungen wie Remote Desktop Manager wäre das natürlich viel schwieriger. Wenn das, was Sie entwickeln, aber einen Web-Stack nutzt, haben Sie den Vorteil, den Kreislauf in Cloud-Sandbox-Umgebungen viel leichter schließen zu können.
Die neue Ökonomie der Softwareentwicklung
Einstellen, ohne die Belegschaft wachsen zu lassen
Bei Devolutions gab es keine massenhaften KI-Entlassungen. Stattdessen boten wir freiwillige Abfindungspakete an. Im Herbst 2025 entschieden sich nur wenige Mitarbeiter, sie anzunehmen. Wir wollten nicht, dass sich Mitarbeiter in einem „Devolutions 2.0“ gefangen fühlen, das vielleicht nicht mehr zu ihnen passt. 2026 boten wir großzügige Vorruhestandspakete an, die von den meisten berechtigten Mitarbeitern angenommen wurden. Auch wenn das Jahr noch nicht vorbei ist, sind wir auf Kurs, eine ausgeglichene Zahl von Abgängen und Neueinstellungen zu haben, sodass die Gesamtbelegschaft gleich bleibt. Wir haben nicht aufgehört einzustellen, aber wir haben aufgehört zu ersetzen. KI war ein wichtiger Faktor bei der Umverteilung der Belegschaft: Jede Neueinstellung stützt das neue Devolutions, und jeder Abgang entfernt uns weiter vom alten Devolutions.
Neue KI-Projekte am laufenden Band
Allein 2026 habe ich eine große Zahl neuer größerer Projekte von Grund auf erstellt, alle mit der GitHub-Copilot-App. Mein Laptop ist jetzt dauerhaft wach und lässt die meiste Zeit Agenten laufen. Wenn ich nach Hause komme, schließe ich ihn an und starte meine Sitzungen neu. Bevor ich schlafen gehe, stelle ich sicher, dass meine Sitzungen nicht untätig sind, und schicke sie auf Nachtjobs. Wenn ich morgens aufwache, stoße ich sie oft einfach wieder an, und bis ich ins Büro aufbreche, haben sie bereits Fortschritt gemacht. Ich bin sicher, dass andere CTOs dasselbe erleben: Zeit ist eine Währung bei lang laufenden KI-Agenten. All die Ausfallzeit, in der Sie nicht vor dem Computer sitzen, kann plötzlich produktiv werden.
Ich bin mir noch nicht ganz sicher, wie gesund das langfristig ist, aber das ist die neue Realität, an die ich mich anzupassen versuche. Ich hatte immer weit mehr ehrgeizige Ideen, als ich Zeit und Ressourcen hatte, sie umzusetzen, deshalb ist es zugleich sehr aufregend und sehr zehrend. Früher war ich dadurch begrenzt, dass ich kritische Ressourcen nicht einfach abziehen konnte, um nebenbei auf einen Impuls hin ein Seitenprojekt zu bauen. Jetzt kommt es darauf an, wie viel Zeit ich darauf verwenden kann, einen Plan vorzubereiten, um einen Agenten zu starten. Kombiniert mit einem unbegrenzten Token-Budget habe ich in den letzten Monaten mehr Software gebaut als in meinem ganzen Leben.
Hier ist eine kurze Liste von Experimenten, die gut genug funktionierten, dass ich sie für eine richtige Veröffentlichung aufgeräumt habe. Sie werden alle in der Produktion genutzt, entweder als Werkzeuge oder als Komponenten eines unserer Produkte:
- Pinget: C#- und Rust-Ports von winget-cli (C++), plattformübergreifend gemacht. Als NuGet-Paket für die Nutzung in UniGetUI verfügbar.
- psign: plattformübergreifendes Code-Signing-Werkzeug in Rust, das alle Authenticode-Dateiformate unterstützt, mit Unterstützung für Azure Key Vault und Azure Artifact Signing.
- windbg-tool: Kommandozeilenwerkzeug in Rust, das die WinDBG-Engine nutzt und speziell dafür gebaut ist, KI-Agenten Prozessdumps untersuchen zu lassen. Ich habe es genutzt, um BSODs auf meinem Laptop zu untersuchen.
All diese großen Projekte wurden in wenigen Wochen abgeschlossen, zu einem kleinen Bruchteil der Kosten, die sie in der Vergangenheit gehabt hätten. Historisch konnte ich nur wenige dieser Ideen auswählen und die Arbeit über mehrere Monate oder Jahre für andere planen. Ich glaube, deshalb genießen viele Führungskräfte auf C-Level KI so sehr: Wenn Sie gewohnt sind, sehr genau festzulegen, was andere bauen sollen, passend zu Ihren Anforderungen, fühlt sich das Gespräch mit einem KI-Agenten für Sie sehr natürlich an.
Ich verbrauche jetzt mindestens 15.000 $ pro Monat in GitHub Copilot. Das mag viel scheinen, aber es ist immer noch wirklich nichts im Vergleich dazu, diese Art von Arbeit an ein Team von Vollzeitentwicklern zu delegieren. Es ist nicht nur günstiger, Sie können die Machbarkeit meist innerhalb der ersten 24 Stunden einschätzen und zum Scheitern verurteilte Experimente früh abbrechen. Früher waren Ressourcen viel länger gebunden, bevor ein unvorhergesehenes K.-o.-Kriterium auftauchte.
Software für KI bauen, nicht nur mit KI
KI kann schnell viel Code schreiben, aber er sollte erst als gut gelten, nachdem bestätigt wurde, dass er mindestens einmal korrekt ausgeführt wird. Tests sind der einfachste Weg, Code auszuführen und sicherzustellen, dass er dem erwarteten Verhalten entspricht, aber nicht alles ist leicht testbar. Viele Teile einer Anwendung sind schwer zu automatisieren oder brauchen eine bestimmte Live-Umgebung. Die gute Nachricht: KI kann Ihnen jetzt helfen, ein hohes Maß an Testbarkeit viel leichter zu erreichen als früher.
Über Tests hinaus sollten Sie in Werkzeuge investieren, die speziell für einen KI-Agenten gebaut sind. Aus meinen FreeRDP-Tagen erinnere ich mich noch an die langen Stunden, in denen ich eine Änderung machte, baute, einen Befehl ausführte, um mich mit einer Windows-VM zu verbinden, klickte und etwas tippte, um eine bestimmte RDP-Funktion auszulösen, an der ich arbeitete, und sah, ob es funktionierte. Und das immer wieder.
Heute, mit IronRDP, dem geistigen Nachfolger von FreeRDP, geschrieben in Rust statt in C. Das ist eine mehrjährige Anstrengung, die ich bei Devolutions lange vor der KI begonnen habe, in vollem Wissen um den gigantischen Aufwand. Das Projekt ist sehr aktiv, mit vielen internen und externen Mitwirkenden. Angesichts dessen, was KI leisten konnte, machte ich mich daran, einen agentischen RDP-Client zu bauen, mit einem Ziel: Mein KI-Agent sollte den langweiligen, wiederholbaren Teil übernehmen, den ich früher manuell gemacht habe.
Die Strategie ist einfach: ironrdp-agent startet einen Daemon-Prozess für die Remotedesktopverbindung, der durch wiederholte IPC-Aufrufe von der CLI gesteuert werden kann. Der KI-Agent kann dann Screenshots machen, mit dem Desktop durch Klicken und Tippen interagieren, die Zwischenablage nutzen, Skripte ausführen, Dateien kopieren und mehr. Das heißt, ich kann meinen KI-Agenten Stunden damit verbringen lassen, die Fleißarbeit des erschöpfenden Testens von Funktionen zu erledigen, die früher menschliche Interaktion brauchten, während ich schlafe.
Wer wacht nicht gern mit einer langen Liste „manueller“ Testfälle auf, die am Morgen als funktionierend bestätigt sind? So habe ich die Dateisystemumleitung für Windows in IronRDP hinzugefügt. Es kopierte komplexe Strukturen aus Dateien und Verzeichnissen und prüfte Datei-Hashes davor und danach. Es kopierte sogar ein 8-GB-ISO, um zu bestätigen, dass es Dateien über 4 GB übertragen konnte, ohne sie zu beschädigen.
Die neue wirtschaftliche Realität der KI bedeutet, dass der Aufbau von Werkzeugen, die speziell für KI-Agenten gedacht sind, eine sehr hohe Rendite hat. Außerdem ist die Entwicklung dieser Werkzeuge günstiger als früher, deshalb müssen Sie nicht auswählen. Bei traditioneller Entwicklung überstiegen die Kosten für komplexe Entwicklungswerkzeuge oft die Produktivitätsgewinne.
Was als Nächstes kommt
Den Feedback-Kreislauf für Windows-Desktopanwendungen schließen
Die Avalonia-Migration von RDM Windows nutzte keinen vollständigen Feedback-Kreislauf mit dem KI-Agenten, aber das wurde dadurch ausgeglichen, dass Entwickler in der Validierungsphase schnell iterierten. Die Avalonia-Migration von UniGetUI wurde größtenteils mit einem geschlossenen Feedback-Kreislauf mit dem KI-Agenten über 24 Stunden gemacht, gefolgt von ein paar Wochen Korrekturen durch einen Entwickler. Was ich Ihnen nicht gesagt habe: Der einzige wirksame Weg, den Feedback-Kreislauf bei einer Windows-Desktopanwendung derzeit zu schließen, ist, den KI-Agenten die Kontrolle über den Computer übernehmen zu lassen.
Wenn Sie die winapp CLI und die zugehörigen Agent Skills für UI-Automatisierung in der GitHub-Copilot-App installieren, kann der KI-Agent Ihre Anwendung starten und mit ihr interagieren, so wie er es mit einer Webanwendung in Playwright tun würde. Das einzige Problem ist, dass Windows nur eine Anwendung mit Eingabefokus zur gleichen Zeit unterstützt, deshalb können Sie kaum etwas anderes tun, während der KI-Agent den Computer steuert. Deshalb ließ ich lange UI-Validierungsaufgaben oft über Nacht laufen, wenn ich nicht vor dem Computer saß.
Die Herausforderung für das nächste Jahr wird sein, den Feedback-Kreislauf für Windows-Desktopanwendungen so zu schließen, dass KI-Agenten GUIs starten und testen können, ohne irgendetwas zu unterbrechen. Eine vollständige Remotedesktopumgebung könnte funktionieren, braucht aber viele zusätzliche Werkzeuge für Remote-Bereitstellung und -Ausführung. Windows Sandbox ist unter der Haube immer noch RDP, ist aber leider auf eine Verbindung zur gleichen Zeit begrenzt, deshalb wären gleichzeitige Sitzungen nicht möglich.
Mit meinem Status als Microsoft MVP kann ich Microsoft direktes Feedback geben und hoffe, eine Lösung für dieses Problem zu finden, möglicherweise indem ich einen Teil der technischen Lösung mit IronRDP beisteuere. Das wird im nächsten Jahr ein Schwerpunkt sein, angesichts der Produktivitätsgewinne, die es mit KI-Agenten für uns freisetzen würde.
Meine Vorhersagen für das nächste Jahr
Das vergangene Jahr war so voll, dass es sich für mich wie ein Jahrzehnt anfühlte. So vieles, das in jüngerer Erinnerung naiv ehrgeizig wirkte, ist in den letzten Monaten ziemlich leicht erreichbar geworden. Ich glaube nicht, dass wir kurz davor sind, die KI auf einem Plateau zu sehen: Sie beschleunigt einfach weiter in schwindelerregendem Tempo. Kürzlich spürte ich tiefes Unbehagen, nachdem ich in ein paar Stunden etwas fertiggestellt hatte, für das ich eine Schätzung von 4 Monaten Arbeit mit traditionellen Entwicklungsmethoden bekommen hatte.
Agentische Workflows ohne Menschen in der Schleife werden häufiger: Viel mehr Workflows werden automatisch statt manuell ausgelöst und führen mehr Aktionen ohne Menschen in der Schleife aus. Zum Beispiel Dokumentation automatisch aktualisieren, damit sie zum Quellcode eines Produkts passt. Sicherheitsprobleme automatisch finden und einen Pull Request mit einem vorläufigen Fix öffnen. Menschen bleiben oft irgendwo in der Schleife, aber an weniger Stellen.
KI-Ausgaben werden ein dauerhafter, erheblicher Teil des Budgets eines Unternehmens: Vor ein paar Monaten waren wir auf Basis der monatlichen Kosten auf Kurs zu 1 Million Dollar pro Jahr, seither ist es auf 2 Millionen Dollar pro Jahr gewachsen. Wir haben weiterhin keine Pläne, unsere KI-Ausgaben zu kürzen. Bedenken Sie, dass das für ein Unternehmen mit 250 Mitarbeitern gilt, also etwa 8.000 $ pro Mitarbeiter. Ich erwarte, dass diese Zahl nur weiter wächst, selbst wenn wir irgendwann versuchen, die Kosten zu optimieren.
Was gleich geblieben ist
In einer Welt, die sich so schnell ändert, welche Wahrheiten bleiben?
Die richtigen Werkzeuge für die Aufgabe zu finden und zu konfigurieren, zählt weiterhin: Sie wollen Software reverse-engineeren, die in C/C++ geschrieben ist? Nehmen Sie sich die Zeit, Ghidra oder IDA Pro zu installieren und einen MCP-Server zu konfigurieren, der seine Funktionen Ihrem KI-Agenten bereitstellt. Sonst fahren Sie im Wesentlichen ein schnelles Auto mit platten Reifen: Es kommt nirgendwohin, und Sie verschwenden viele Tokens beim Versuch.
Tiefes Wissen über Softwarearchitektur bleibt relevant: Verwechseln Sie nicht, ein Ziel erfolgreich erreicht zu haben, mit dem Umstand, es auf die richtige Weise getan zu haben. KI ist großartig darin, das zu tun, was Sie verlangen, aber wenn Sie nur oberflächliches Verständnis haben, überlassen Sie viele wichtige Entscheidungen dem reinen Zufall. Tiefes Verständnis hilft Ihnen, die KI in die richtige Richtung zu lenken, sodass sie keine Abkürzungen nimmt, die mit Ihren beabsichtigten Anforderungen kollidieren könnten.
Das Haus vor den Fundamenten zu bauen, ist immer noch eine schlechte Idee: Ein guter Teil des Avalonia-Migrationsaufwands floss in den Bau richtiger Komponenten, die an mehreren Stellen wiederverwendet werden konnten. Hätten wir die Migrationen durchgedrückt, die davon abhingen, hätte der KI-Agent viel sehr ähnlichen Boilerplate-Code und Helfer erzeugt. Richtige Fundamente unter ein bereits gebautes Haus zu setzen, ist machbar, kostet aber viele Tokens und viel Zeit.
Gelernte Lektionen
Ich habe im vergangenen Jahr viel gelernt, aber wenn ich es auf eine kurze Liste bringen müsste, ist es diese:
- Die Ausführung ist komprimiert: Es steckt mehr Wert darin zu wissen, was zu tun ist, als es zu tun
- Sie sollten technische Schulden aktiv abbauen, um zuvor verlorene Agilität zurückzugewinnen
- Investieren Sie in Werkzeuge, mit denen KI-Agenten den Feedback-Kreislauf schließen können
- Code-Reviews gibt es weiterhin, sie werden jetzt aber mit KI auf verschiedenen Ebenen durchgeführt
- Änderungen an Code, den Sie nicht verstehen, können die Entwicklung beschleunigen
Ich hoffe, dass meine Erfahrung als CTO von Devolutions in diesem vergangenen KI-Jahr für Ihre Realität vor Ort relevant war und dass Sie etwas daraus gelernt haben. Ich freue mich auf das nächste Jahr auf dieser nie endenden Achterbahn!