Ich bin Timo Felderhoff und beschäftige mich schon lange mit IT und Softwareentwicklung. Dabei war für mich ziemlich früh klar, dass ich nicht mein gesamtes Berufsleben aus derselben Perspektive auf Software schauen möchte. Mich hat nicht nur interessiert, wie man ein Programm schreibt. Ich wollte verstehen, was davor passiert, was danach passiert und was andere Menschen mit dem Ergebnis meiner Arbeit anfangen müssen.
Das hat dazu geführt, dass ich Software im Laufe meines beruflichen Weges aus sehr unterschiedlichen Blickwinkeln kennengelernt habe. Entwicklung gehört natürlich dazu, aber ebenso Testing, Helpdesk, Betrieb, Consulting und Vertrieb. Rückblickend waren gerade diese Wechsel für meine heutige Arbeitsweise mindestens genauso wichtig wie die verschiedenen Programmiersprachen, Frameworks und technischen Plattformen, mit denen ich gearbeitet habe.
Heute kommt eine weitere Perspektive hinzu. Ein Teil der Arbeit, die ich früher selbst durchgeführt habe, wird inzwischen von KI übernommen. ChatGPT hilft mir dabei, Ideen zu durchdenken und Anforderungen zu entwickeln. Codex setzt Konzepte um, arbeitet in meinen Projekten, administriert Systeme und übernimmt immer mehr konkrete Aufgaben. Dabei verändert sich gerade nicht nur mein Werkzeugkasten. Es verändert sich die Frage, was meine eigene Aufgabe als Entwickler überhaupt noch ist.
Ich wollte nie nur Code schreiben
Softwareentwicklung hat einen offensichtlichen Reiz: Am Anfang existiert eine Idee, irgendwann läuft daraus ein echtes Programm. Dazwischen liegen Architektur, Datenmodelle, Benutzeroberflächen, Schnittstellen, Fehlerbehandlung und sehr viel Detailarbeit.
Wenn man lange genug programmiert, kann man sich allerdings leicht daran gewöhnen, Software hauptsächlich aus Sicht des Entwicklers zu betrachten. Eine Funktion ist dann fertig, wenn sie technisch korrekt umgesetzt wurde. Ein Fehler ist behoben, wenn er nicht mehr auftritt. Eine Oberfläche ist verständlich, weil man selbst schließlich weiß, wie sie funktioniert.
Spätestens außerhalb der Entwicklung merkt man, wie begrenzt diese Perspektive sein kann.
Ein Tester schaut nicht darauf, wie elegant eine Funktion programmiert wurde. Er versucht herauszufinden, unter welchen Umständen sie nicht funktioniert. Genau diese Denkweise spielt heute wieder eine große Rolle bei meinen automatisierten Tests mit KI.
Im Helpdesk interessiert niemanden, dass eine Funktion nach Spezifikation korrekt arbeitet, wenn der Benutzer nicht versteht, was er damit machen soll. Dort bekommt man sehr unmittelbar mit, an welchen Stellen Entwickler Dinge für selbstverständlich halten, die für einen normalen Anwender überhaupt nicht selbstverständlich sind.
Im Betrieb verändert sich die Perspektive erneut. Eine Anwendung muss nicht nur auf dem Entwicklungsrechner funktionieren. Sie muss zuverlässig laufen, aktualisierbar sein, Fehler überstehen und sich im Ernstfall wieder in einen definierten Zustand bringen lassen.
Im Consulting steht wiederum zunächst eine andere Frage im Vordergrund: Welches Problem soll überhaupt gelöst werden? Eine technisch beeindruckende Lösung ist wenig wert, wenn sie am tatsächlichen Bedarf vorbeigeht.
Und spätestens im Vertrieb kommt noch eine unbequeme Wahrheit hinzu: Technische Qualität allein sorgt nicht dafür, dass jemand ein Produkt versteht, haben möchte oder bereit ist, dafür Geld auszugeben.
Diese verschiedenen Blickwinkel haben meine Vorstellung davon geprägt, was gute Software eigentlich ist. Software endet für mich deshalb schon lange nicht mehr beim letzten Commit.
Technik war für mich nie das einzige Ziel
Ich wollte mich beruflich immer weiterentwickeln, aber Weiterentwicklung bedeutete für mich nie nur, die nächste Programmiersprache oder das nächste Framework zu lernen.
Natürlich gehört technische Entwicklung dazu. IT verändert sich ständig, und viele Technologien, die irgendwann selbstverständlich wirkten, spielen einige Jahre später kaum noch eine Rolle. Gleichzeitig tauchen Konzepte immer wieder in neuer Form auf. Manchmal steckt hinter einer vermeintlich völlig neuen Idee erstaunlich viel von dem, was man schon vor Jahren unter einem anderen Namen gesehen hat.
Mindestens genauso wichtig war mir deshalb die fachliche und persönliche Weiterentwicklung. Ich wollte verstehen, warum andere Abteilungen bestimmte Anforderungen haben, warum ein Tester anders denkt als ein Entwickler, warum der Betrieb bestimmte Änderungen kritisch sieht oder weshalb eine fachlich sinnvolle Funktion aus Sicht des Vertriebs trotzdem schwer vermittelbar sein kann.
Das bedeutet nicht, dass jeder Entwickler irgendwann alle diese Berufe ausüben sollte. Mir hat es aber geholfen, Software nicht mehr als isoliertes technisches Produkt zu betrachten.
Diese Haltung beeinflusst heute auch meine Arbeit mit KI. Wenn Codex eine Funktion technisch korrekt implementiert, ist das für mich noch lange nicht das Ende der Aufgabe. Ich möchte wissen, ob die Funktion verständlich ist, ob sie sich sinnvoll betreiben lässt, ob sie getestet wurde, wie sie sich bei Fehlern verhält und ob sie überhaupt das Problem löst, wegen dem sie gebaut wurde.
Dann kam KI und plötzlich änderte sich die Arbeit selbst
Der nächste große Wechsel besteht für mich nicht in einer neuen Programmiersprache, sondern darin, wie Software überhaupt entsteht.
Ein älteres Projekt wie Sara ist noch weitgehend auf klassische Weise entstanden. Anforderungen überlegen, Architektur entwerfen, Code schreiben, ausprobieren, Fehler suchen und weiterentwickeln. Heute arbeite ich bei Projekten wie Kosmos und Linea zunehmend anders. Gerade der Vergleich zwischen Sara, Kosmos und Linea zeigt ziemlich deutlich, wie stark sich meine Arbeitsweise inzwischen verändert hat.
Bei größeren Themen beginnt die Arbeit heute oft nicht einmal mehr in der Entwicklungsumgebung.
Ich starte mit einer Idee in ChatGPT.
Dabei möchte ich normalerweise nicht sofort eine Lösung haben. Im Gegenteil. Bei größeren Konzepten lasse ich mir teilweise sehr viele Fragen stellen. Was genau soll das Produkt können? Was passiert in Sonderfällen? Welche Entscheidungen habe ich noch gar nicht getroffen? Welche Abhängigkeiten entstehen? Was darf das System ausdrücklich nicht tun? Wie soll sich eine Funktion bei Fehlern verhalten?
Aus diesem Gespräch entsteht nach und nach eine Spezifikation. Erst wenn die Idee ausreichend durchdacht ist, lasse ich daraus eine Markdown-Datei erzeugen, die anschließend an Codex geht. Wie aus einer zunächst groben Idee auf diese Weise ein konkreter Entwicklungsauftrag wird, ist inzwischen ein zentraler Bestandteil meiner Arbeitsweise.
Das Entscheidende daran ist für mich nicht, dass KI schneller Code schreiben kann. Der größere Unterschied liegt darin, dass ich einen erheblichen Teil des Denkens vor die eigentliche Implementierung verschoben habe.
ChatGPT und Codex haben dabei unterschiedliche Aufgaben
Ich benutze ChatGPT und Codex nicht als austauschbare Werkzeuge.
ChatGPT ist für mich vor allem der Ort, an dem ich Ideen entwickle, Varianten diskutiere, Widersprüche suche und Entscheidungen treffe. Dort kann ein Gespräch sehr lange dauern, bevor überhaupt eine Zeile Code entsteht.
Codex befindet sich dagegen näher an der konkreten Arbeit. Dort liegt das Repository, dort kann vorhandener Code analysiert werden und dort wird aus einem Konzept eine technische Umsetzung.
Diese Trennung ist für meine heutige Arbeitsweise ziemlich wichtig. ChatGPT und Codex erfüllen bei mir deshalb bewusst unterschiedliche Rollen.
Inzwischen geht der Prozess sogar noch weiter. Aus größeren Konzepten entstehen Aufgaben in Kosmos.Agenda. Dort kann ich festlegen, welche Arbeit tatsächlich ausgeführt werden darf. Codex übernimmt freigegebene Aufgaben, setzt sie um und soll die Ergebnisse anschließend testen.
Mein etwas überspitztes Ziel dafür ist der Gartenstuhl-Test: Wenn ein Konzept sauber vorbereitet wurde, möchte ich irgendwann vom Smartphone aus eine Aufgabe freigeben können und anschließend hauptsächlich dabei zusehen, wie das Codex-Kontingent kleiner wird.
Ganz so einfach funktioniert es noch nicht. Gerade die offenen Probleme finde ich aber mindestens genauso interessant wie die Dinge, die bereits funktionieren.
Nicht alles ist bereits gelöst
Eines der größten Themen ist für mich aktuell das Testing.
Heute kann Codex bereits Tests erzeugen und mit einem spezialisierten Tester-Agenten versuchen, Fehler in seiner eigenen Arbeit zu finden. Die Grundidee dahinter gefällt mir: Der Tester soll nicht beweisen, dass die Software funktioniert. Er soll versuchen nachzuweisen, dass sie nicht funktioniert.
Trotzdem bleibt ein grundsätzliches Problem. Wenn dieselbe KI-Technologie sowohl entwickelt als auch testet, können beide Seiten dieselbe falsche Annahme teilen. Eine Funktion kann falsch interpretiert, falsch implementiert und anschließend mit einem Test geprüft werden, der genau dieselbe falsche Interpretation verwendet.
Dann ist alles grün und trotzdem falsch.
Langfristig möchte ich Entwicklung und Prüfung deshalb stärker voneinander trennen. Wie genau diese unabhängige Kontrolle aussehen soll, ist für mich noch nicht abschließend geklärt.
Ähnlich sieht es bei paralleler Arbeit aus. Mehrere KI-Arbeiter können grundsätzlich gleichzeitig Aufgaben übernehmen. Sobald sich ihre Änderungen aber überschneiden, entstehen dieselben Koordinationsprobleme, die man aus menschlichen Entwicklerteams kennt. Teilweise entstehen sie sogar schneller, weil die einzelnen Arbeiter wesentlich mehr Änderungen in kürzerer Zeit produzieren können.
Auch das automatische Deployment gehört zu den Punkten, die ich weiter ausbauen möchte. Codex darf aus meiner Sicht durchaus eine fertige Version ausrollen. Der Schritt in eine produktive Umgebung soll aber bewusst eine menschliche Freigabe behalten.
Ich möchte hier deshalb nicht den Eindruck vermitteln, dass ich eine fertige Methode für vollautomatische Softwareentwicklung gefunden habe. Ich entwickle diese Arbeitsweise gerade selbst weiter.
Codex bleibt bei mir längst nicht mehr im Quellcode
Dabei wird die Grenze dessen, was ich mit KI mache, zunehmend unscharf.
Codex verändert bei mir nicht nur Software. Ich habe damit bereits an echter Hardware gearbeitet, lasse Linux-Systeme administrieren und beschäftige mich damit, Netzwerkhardware über denselben Ansatz zu konfigurieren. Auch beim Aufbau und bei der Weiterentwicklung meines Unternehmens kommen ChatGPT und Codex an vielen Stellen zum Einsatz.
Dadurch verschiebt sich meine eigene Arbeit immer stärker von der konkreten Bedienung zur Beschreibung von Zielen und Randbedingungen.
Früher lautete eine typische technische Frage vielleicht:
„Welchen Befehl brauche ich dafür?“
Heute lautet sie häufiger:
„So soll sich das System verhalten. Finde heraus, welche Änderungen dafür notwendig sind, setze sie um und prüfe anschließend das Ergebnis.“
Das bedeutet nicht, dass technisches Wissen unwichtig wird. Eher das Gegenteil. Wenn ich nicht beurteilen kann, ob das Ergebnis sinnvoll ist, habe ich lediglich einen sehr schnellen Weg gefunden, Fehler zu produzieren.
Warum ich darüber schreibe
Genau deshalb gibt es diesen Wissensbereich.
Ich möchte hier nicht erklären, dass KI alle bisherigen Methoden überflüssig macht, und ich möchte auch keine Sammlung vermeintlich magischer Prompts aufbauen.
Mich interessiert vielmehr, was tatsächlich passiert, wenn man KI zunehmend in reale Entwicklungs- und Arbeitsprozesse integriert. Was funktioniert gut, was funktioniert überraschend schlecht, welche Aufgaben kann ich inzwischen abgeben und an welchen Stellen möchte ich weiterhin selbst entscheiden?
Mich beschäftigt, wie sich Testing verändert, wenn Code praktisch auf Knopfdruck entstehen kann. Ebenso interessant finde ich die Frage, was mit Scrum, Wasserfall und anderen klassischen Entwicklungsprozessen passiert, wenn Planung, Implementierung und Dokumentation plötzlich andere Kosten haben.
Und letztlich stellt sich für mich eine noch grundlegendere Frage: Was wird eigentlich aus der Rolle des Entwicklers, wenn ein immer größerer Teil der konkreten Umsetzung von einer KI erledigt wird?
Auf manche dieser Fragen habe ich bereits praktische Antworten. Bei anderen bin ich selbst noch mitten in der Suche.
Genau diesen Weg möchte ich hier dokumentieren. Nicht erst rückblickend, wenn irgendwann alles fertig und sauber sortiert ist, sondern während es passiert.