Es war Anfang 2025.
Die Standard-Code-Vervollständigung in GitHub Copilot hat sich fest etabliert. ChatGPT ersetzte die Google-Suche bei der Suche nach Code-Referenzen – und machte sogar ziemlich nützliche Vorschläge für Code-Blöcke –, aber wir haben über KI-gestütztes Programmieren meist nur geschmunzelt, weil es entweder zu simpel war, der offensichtliche Code-Kontext fehlte oder es lächerlich überkonstruiert war.
All das änderte sich im Frühjahr 2025, als umfangreiche Verbesserungen an den Grundmodellen KI-Codier-Tools wie Cursor, GitHub Copilot Agent, Windsurf, Claude Code und Cline deutlich praxistauglicher machten. Unsere Kritik schien keinen Bestand mehr zu haben, und wenn wir nicht mitmachten, würden wir am Ende die Dummen sein.
Bei Bitly Engineering wurde uns klar, dass wir entweder den Sprung wagen mussten oder sonst den Anschluss verlieren würden.
Im Mai 2025 haben wir eine Weiterbildungsinitiative für die Bitly-Entwickler ins Leben gerufen. Das Ziel: Unsere 60 Ingenieure so schnell wie möglich von der Autovervollständigung durch GitHub Copilot auf eine vollständig durch KI-Agenten unterstützte Programmierpraxis umzustellen.
Wir wussten, dass wir die Welt nicht einfach anhalten und alle zur Schulung schicken konnten, und tatsächlich gab es damals noch gar keine formellen Schulungen, also beschlossen wir, unsere eigene zu entwickeln.
Unser Ansatz bestand darin, ein Programm zum Thema „KI im Ingenieurwesen“ zu entwickeln, das eine Mischung aus strukturierten Elementen, informeller Bildung, Experimenten und Bewertungen bot – und dabei davon ausging, dass wir den Prozess im Laufe der Zeit schrittweise weiterentwickeln würden. Wir müssten die Straße asphaltieren, während wir darauf fahren.
Das ist unsere Geschichte – was funktioniert hat, was nicht und was wir dabei gelernt haben.
Auswahl von KI-Tools
Unsere Auswahlkriterien für KI-Tools waren ganz einfach: Stell Ingenieuren modernste Werkzeuge zur Verfügung. Mit den besten Tools konnten wir Möglichkeiten ausloten, gemeinsam dazulernen und schnell neue Ansätze ausprobieren. Wir haben Tools ausgewählt, die ein ausgewogenes Verhältnis zwischen Reife und Benutzerfreundlichkeit bieten und unseren Entwicklungszyklus möglichst wenig beeinträchtigen. Auf der Auswahlliste standen:
- Cursor (Business-Ebene mit erzwungenem Datenschutzmodus)
- ChatGPT (Team-Tarif für einen Allzweck-KI-Chat)
- Claude Code (wurde mitten im Programm hinzugefügt, da er sich als vielversprechende Programmieroption herausstellte)
Datenschutz war nicht verhandelbar. Wir haben uns strikt an unsere Datenschutzgrundsätze gehalten, darunter die SOC2-Konformität als zwingende Voraussetzung, den erzwungenen Datenschutzmodus in Cursor, um sicherzustellen, dass keinerlei Daten gespeichert werden, und die Bestätigung, dass Eingabedaten nicht für das Modelltraining verwendet werden.
Die Markteinführung
Wir haben im Mai 2025 losgelegt und uns folgende Ziele gesetzt:
- Fördern Sie den Umgang mit KI im gesamten Team – jeder sollte wissen, wie man KI-Programmierwerkzeuge in seinen Arbeitsabläufen einsetzt
- Erfahrungen austauschen und bewährte Verfahren dokumentieren
- Die Auswirkungen kontinuierlich bewerten
- Schaffe eine Kultur des Lernens und des Experimentierens
Eine frühe Stärke: „Über-die-Schulter“-Sitzungen
Eine unserer effektivsten Methoden war die Einführung von „Over the Shoulder“-Sitzungen (OTS) – Arbeitssitzungen, in denen Ingenieure ihren Bildschirm freigaben und praktische KI-Programmierabläufe in Echtzeit vorführten.
Wir haben Freiwillige, die bereits KI-Agenten nutzen, gebeten, uns einen Einblick in ihre Arbeit zu geben – von der Einrichtung der Tools über Eingabeaufforderungen und Regeln bis hin dazu, wie sie die Ergebnisse optimiert haben, wenn mal was schiefgelaufen ist. In den ersten zwei Wochen haben wir täglich Sitzungen in verschiedenen Zeitzonen weltweit und regional abgehalten. Als die Teilnehmerzahl wuchs, gingen wir zu wöchentlichen und später zu monatlichen Treffen über.
Das waren echte Arbeitssitzungen an konkreten Projekten wie der Entwicklung neuer Funktionen, Refactorings, Tests und Fehlerbehebung – keine aufpolierten Demos. Wir haben versucht, in diesen Sitzungen eine Atmosphäre der Offenheit und Verletzlichkeit zu schaffen, indem wir die ersten Sitzungen von erfahrenen Ingenieuren leiten ließen, die selbst noch keine Erfahrung mit den KI-Programmierwerkzeugen hatten. Das trug dazu bei, einen sicheren Raum zu schaffen, in dem sich die Menschen öffentlich mit Unsicherheiten auseinandersetzen konnten. Das hat eine wichtige Erkenntnis bestätigt: Hier gibt es noch keine Experten, sondern nur Lernende.
Was wir gelernt haben: Das Gute
Die Gewinner-Tools:
- Cursor wurde wegen seiner nahtlosen IDE-Integration, dem vollständigen Kontext der Codebasis und der Chat-Funktion direkt in der Entwicklungsumgebung beliebt.
- ChatGPT wurde zur ersten Wahl für architektonische Diskussionen, Dokumentation und technisches Schreiben – und als Alternative, wenn andere Tools „ins Stocken gerieten“.
- GitHub Copilot hat sich bei der Überprüfung von Pull-Requests als nützlich erwiesen, da es kleinere Probleme aufspürt, die menschlichen Prüfern vielleicht entgehen würden. Im Laufe der Weiterentwicklung des Programms fügte Copilot „Agent Tasks“ und fortgeschrittenere Modelle hinzu und stellte damit seine anhaltende Leistungsfähigkeit und Relevanz unter Beweis.
- Claude Code entwickelte sich später zu einer erstklassigen Wahl für diejenigen, die es einsetzten, und zeichnete sich durch seine Fähigkeit aus, komplexe Probleme zu durchdenken.
Wir haben auch mit ChatGPT Codex experimentiert und waren von seinem Potenzial begeistert, aber da es keine benutzerdefinierten Bilder gab, war es für unsere Zwecke unbrauchbar. OpenAI, wir warten gespannt…
Wo die KI besonders gut abgeschnitten hat:
- Routineaufgaben und Such- und Ersetzungsvorgänge in umfangreichen Codebasen
- Testabdeckung für bestehenden Code generieren
- Arbeiten mit unbekannten Bereichen des Quellcodes
- Dokumentation und technisches Schreiben
- Brainstorming und architektonische Diskussionen
- Backend-Unit-Tests nach bewährten Mustern
Einem Entwickler ist es gelungen, im Rahmen eines einzigen Hackweek-Projekts 275 Dateien zu überarbeiten. Zwei weitere haben mithilfe von KI innerhalb einer Woche den Entwurf für ein komplettes internes Dashboard für Administratoren erstellt. Das waren keine unbedeutenden Produktivitätssteigerungen. In manchen Fällen erwiesen sie sich als bahnbrechend.
Allerdings hat diese Erfahrung auch einige Herausforderungen deutlich gemacht.
Was wir gelernt haben: Das Schlechte
Es lief nicht immer alles reibungslos, aber die Hindernisse haben uns genauso viel gelehrt wie die Erfolge.
Schon früh traten Qualitätsprobleme auf. KI konnte zwar schnell Code generieren, aber ein Großteil davon musste umfassend überarbeitet werden, um unseren Standards zu entsprechen. Ingenieure verbrachten oft genauso viel Zeit mit der Überprüfung und Korrektur, wie sie gebraucht hätten, um den Code selbst zu schreiben.
Muss von einem Menschen überprüft werden. Von KI generierter Code sollte nicht zur Überprüfung eingereicht werden, ohne dass er zuvor von einem menschlichen „Autor“ geprüft wurde.
Die Kontextbeschränkungen waren nervig. Die Tools verloren häufig den Überblick über lange Unterhaltungen, was Neustarts oder wiederholte Erklärungen erforderlich machte – ein echtes Hindernis bei komplexen Änderungen.
Die Arbeit am Frontend war schwieriger. Die KI neigte dazu, Lösungen zu überkomplex zu gestalten, Code zu wiederholen und UI-Standards zu missachten, während sie bei Backend-Aufgaben besser abschnitt.
Was wir gelernt haben: Das Ungewisse
Abgesehen von den technischen Problemen stießen wir auf kulturelle Reibungspunkte.
Manche Menschen fühlten sich unter Druck gesetzt, KI einzusetzen, und hatten Angst, ersetzt zu werden. Andere sahen in dem Programm eher eine „erzwungene“ Übernahme als eine Erkundung. Einige Ingenieure befürchteten, den Bezug zu ihrem Handwerk zu verlieren, vor allem Nachwuchskräfte, die noch dabei sind, sich grundlegende Fähigkeiten anzueignen.
Für Nicht-Entwickler, insbesondere für QA-Ingenieure und Analysten, waren die Anweisungen unklar. Wie sollte ein QA-Ingenieur KI-Codierungstools einsetzen? Und was ist mit Datenanalysten? Der Wissensaustausch war schwieriger als erwartet. Selbst heute ist der Strom an Anleitungen und Best Practices noch nicht ganz da, wo wir ihn gerne hätten.
Aber wir haben eine Metapher gefunden, die uns geholfen hat: Stell dir KI wie einen fähigen Ingenieur am Anfang seiner Karriere vor. Schnell, manchmal falsch, muss immer noch überprüft werden. Das ist hängen geblieben. Es hat die richtigen Erwartungen geweckt und den Fokus von „Ersatz“ auf „Zusammenarbeit“ verlagert.
Die Herausforderung, Erfolg zu messen
Es ist schwer, die Auswirkungen von KI-Codierungstools zu messen. Basiert das auf Vorher-Nachher-Vergleichen der geschriebenen Codezeilen? Wie viele PRs? Anzahl der Commits? Team-Velocity?
Wir wissen, dass es Auswirkungen gibt, sind uns aber nicht sicher, wie groß diese sind. Zu sagen: „30 % unseres Codes werden jetzt von KI geschrieben“, vermittelt ein trügerisches Gefühl der Gewissheit. Bei der Bewertung haben wir einen gemischten Ansatz gewählt und subjektive mit objektiven Bewertungen kombiniert.
Wir haben Ingenieure subjektiv zu den Themen Genauigkeit, Geschwindigkeit, Vertrauen in unbekannten Code, kognitive Belastung und allgemeine Zufriedenheit befragt. Wir haben vor und nach dem Programm nach der Einstellung gegenüber KI gefragt.
Objektiv betrachtet betrachten wir alle oben genannten Faktoren sowohl vor als auch nach der Einführung von KI, wobei wir uns bewusst sind, dass dies eher als Orientierungshilfe und nicht als endgültige Feststellung zu verstehen ist.
Produktivitätssteigerungen zu messen ist schwierig – zu viele Variablen, zu wenige verlässliche Daten. Im Moment sind Richtungstrends und die Stimmung im Team unsere besten Indikatoren.
Sechs Monate sind vergangen…
Das Werkzeug-Rennen
Nach sechs Monaten gibt es im Wettstreit um die besten Tools immer noch keinen eindeutigen Sieger. Verschiedene Tools eignen sich für unterschiedliche Aufgaben, und viele Ingenieure nutzen mehr als ein Tool. Ich persönlich bevorzuge Claude Code für umfangreiche Programmierarbeiten und Cursor, wenn ich Code auswerten und eine übersichtliche Ausgabe erhalten möchte.
Es sind auch neue Tools entstanden. Codex wurde veröffentlicht, GitHub Copilot Agent Tasks wurden veröffentlicht, und die Landschaft verändert sich weiterhin unter unseren Füßen. Bis heute zögern wir, uns auf Jahresverträge für KI-Codierungstools festzulegen, aus Angst, dass sich ein anderes Tool als klarer Sieger herauskristallisiert.
Regelsätze
Wir arbeiten an Regelwerken – das sind Konfigurationsdateien, die der KI unsere Programmierstandards, Architekturmuster und häufige Fallstricke beibringen. Wir entwickeln Regelsätze sowohl für interne Programmierstandards als auch für bestimmte Aufgaben, wie zum Beispiel die Bewertung von Jira-Tickets oder die Durchführung einer Art „manueller Qualitätssicherung“ auf der Grundlage von Codeänderungen.
Erwartungen klären
Außerdem formulieren wir unsere Erwartungen jetzt klarer. Während der Einsatz von KI anfangs zwar gefördert, aber nicht vorgeschrieben war, entwickeln wir uns als Unternehmen dahingehend weiter, dass der Umgang mit KI zu einer erforderlichen Kompetenz für alle Ingenieure – und alle Mitarbeiter – wird.
Ständige Anpassung
Bis August 2025 hatten sich KI-Tools ganz unauffällig von einem „Sonderprojekt“ zu einem festen Bestandteil unserer Arbeitsweise gewandelt – vor allem, weil sie sofort einen Mehrwert brachten, sobald die Leute sich erst einmal daran gewöhnt hatten, sie zu nutzen.
Ein gutes Anzeichen dafür war, dass jemand, dem die Premium-Anfragen in einem Programmier-Tool ausgingen, plötzlich das Gefühl hatte, seine Arbeit nicht mehr so effektiv erledigen zu können. Natürlich haben wir noch keine flächendeckende Einführung erreicht, aber mittlerweile nutzen fast 95 % der Bitly-Entwickler regelmäßig KI-Codierungstools.
Wir haben aufgehört, KI-Codierungstools als experimentell zu betrachten, und haben begonnen, sie in unsere täglichen Entwicklungsabläufe zu integrieren: Planung, Programmierung, Refactoring, Selbstanalyse, Dokumentation und Code-Review. Das Ziel ist jetzt nicht, die Einführung von KI-Programmierwerkzeugen „abzuschließen“, sondern sich gemeinsam mit ihnen weiterzuentwickeln. Jetzt geht es darum, sich ständig anzupassen.
Wie geht’s weiter?
Wir haben uns für den Ansatz „Lernen durch Praxis“ entschieden, und in diesem Sinne lernen wir immer noch dazu.
Wir müssen uns mit Kostenaspekten auseinandersetzen. Wir sind ein relativ kleines Entwicklerteam, aber langfristig gesehen ist es keine gute Lösung, für drei Tools zu bezahlen, die sich inhaltlich überschneiden. Wir rechnen damit, bald etwas abzuschlanken.
Als Nächstes konzentrieren wir uns darauf, unsere Fähigkeiten zu vertiefen und das Gelernte zu verankern. Das bedeutet, formelle Schulungen für diejenigen zu entwickeln, die mehr praktische Anleitung wünschen, Regelwerke zu verfeinern, um Standards festzuschreiben, und die Art und Weise zu verbessern, wie wir die Wirkung messen.
Dazu gehört auch, bei den Produktivitätssteigerungen neue Maßstäbe zu setzen:
- Wie lassen sich mehrere Agent-Sitzungen am besten gleichzeitig verwalten?
- Wie schaffen wir einen Ausgleich zwischen der Leistung von KI-Codierungsagenten und der Überprüfbarkeit?
- Wie können wir mehrere Agenten kombinieren, um parallele Aufgaben zu koordinieren?
- Wie viel Autonomie können wir unseren KI-Programmieragenten einräumen?
Früher habe ich mich über die Ergebnisse von KI-Codierungstools lustig gemacht. Meistens bin ich verblüfft (und nur manchmal spöttisch).
Ob es dir gefällt oder nicht, das ist die neue Realität in der Softwareentwicklung, und die Tools werden von nun an nur noch leistungsfähiger werden. Für mich stellt sich nicht die Frage, ob man KI-Programmierwerkzeuge einführen soll – sondern wie man sich gemeinsam mit ihnen weiterentwickelt und ihren Nutzen maximiert.
