Ich bin Jonas. DER Software Engineer.

Dann das Holz. Meine erste Automatisierung, und ich muss keine Bäume mehr abbauen. Mehr Zeit. Also die nächste Automatisierung. Und die übernächste. Irgendwann macht der Roboter einfach alles. Und jetzt? Was mache ich mit der ganzen Zeit? Plugins. Minecraft-Plugins, in Java. Mein erstes Mal mit objektorientierter Programmierung, und ehrlich gesagt: Ich hab fast nichts verstanden. Bis ich im Schullandheim (komisches Wort, wenn ich's so aufschreibe, gemeint ist ein Wochenendausflug mit der Schule) das erste Buch zu Java und den Grundlagen der Programmierung gelesen habe. Auf einmal: Ah. Datentypen. Das ergibt ja Sinn.

KI, wie wir sie heute kennen, gab es damals noch nicht. Dafür gab es die Typen aus Indien in den YouTube-Videos, mit englischem Akzent und Audioqualität wie im Call-Center. Vibes. Das Beste daran: Sie helfen mir bis heute.

Dann das Berufskolleg als IT-Assistent, und danach die Ausbildung zum Fachinformatiker. Ich sitze in der Berufsschule, und zum x-ten Mal kommt das Beispiel: Objektorientierung und der Bauplan eines Hauses. Die Klasse ist der Bauplan, das Objekt ist das Haus. Ein Bauplan, beliebig viele Häuser. Mit Fenstern, Türen, einem Dach, vielleicht noch einem Schornstein mit Rauch obendrauf. Bitte nicht schon wieder das Haus. Das hätte mein Roboter in Minecraft längst gebaut, Block für Block, nach Plan. Ich müsste nur Enter drücken.

In der Ausbildung dann zum ersten Mal ein richtig großes Projekt: eine ERP-Software mit tausenden Funktionen, mehreren Entwicklern, echten Kunden. Entwickelt in C# mit dem .NET Framework und WinForms, dazu eine relationale Datenbank mit Microsoft SQL Server. Organisiert haben wir uns mit Scrum. Und ich mittendrin. Am Anfang kleine Änderungen und Skripte. Erst mal verstehen, wie alles zusammenhängt. Dann größere Anpassungen, mehr Verantwortung und die ersten Schnittstellen. Mal zu einem Hochregallager, mal zu anderen Systemen. Manchmal auch einfach eine Datei auf einem FTP-Server. Nicht alles muss spektakulär sein. Es muss funktionieren und dem Kunden die Arbeit leichter machen.

Parallel dazu mein Minijob, den ich während der Ausbildung angefangen habe. Dort habe ich an einer älteren Repricing-Software für den B2B-Bereich mitgearbeitet, geschrieben in Python und Perl. Preise automatisch anpassen statt von Hand. Mein Lua-Roboter in Minecraft hat mir das Bäumefällen abgenommen. Diese Software nahm den Kunden die manuelle Preisanpassung ab. Andere Aufgabe, gleicher Gedanke. Auf einmal war Python keine Schlange mehr, sondern eine Programmiersprache. Und das Kamel? Perl.

Ausgelernt. Zumindest auf dem Papier. In der Realität lernt man in diesem Beruf nie aus. Kaum hat man etwas verstanden, steht die nächste Frage vor der Tür. Genau das mag ich daran. Die Berufsschule fiel weg, dafür warteten im Entwicklerteam die richtig großen Änderungen auf mich. Mehr Verantwortung, mehr Zusammenhänge, die ich verstehen musste. Der Hausbauplan hatte endlich ausgedient. Das Lernen nicht.

Und heute? Über zehn Projekte in vier Jahren. Mein aktuelles Werkzeug: TypeScript mit Node.js, SQL, n8n und Python. Je nachdem, was die Aufgabe braucht. Vieles dreht sich dabei um Automatisierung: Daten zwischen Systemen austauschen, Abläufe verbinden, manuelle Arbeit abnehmen. Im Grunde macht mein Roboter von damals immer noch weiter. Nur fällt er heute keine Bäume mehr, sondern spart Menschen die immer gleichen Handgriffe.

Backend Engineer, Data Engineer, Automation Engineer. Such dir was aus, Jonas. Gar nicht so einfach, wenn man am liebsten überall mitbauen würde. Aber ein Schwerpunkt musste her. Meiner liegt heute im Backend und in der Automatisierung. Also: Backend & Automation Engineer.

Beim Eisberg wäre das der Teil unter Wasser. Daten verarbeiten, Systeme verbinden, Abläufe am Laufen halten. Alles, was im Hintergrund funktionieren muss, damit oben jemand auf einen Knopf drücken kann und das Richtige passiert. Manchmal tauche ich auch auf und entwickle im Frontend mit. Früher mehr, mittlerweile weniger. Ich weiß trotzdem gern, was über der Wasseroberfläche passiert.

Mein Blick geht dabei weniger auf UI und UX und mehr auf DX: Developer Experience. Also darauf, wie gut andere Entwickler mit dem arbeiten können, was ich baue. Ist die Schnittstelle verständlich? Hilft die Fehlermeldung weiter? Oder sitzt da jemand und denkt sich: Was hat Jonas denn hier gemacht?

Ich mag es, wenn es einfach funktioniert. Wenn Unit- und Integrationstests „alle“ Testfälle abdecken. Zumindest die, an die ich gedacht habe. Wenn das Frontend sich auf das Backend verlassen kann. Und wenn Änderungen über eine CI/CD-Pipeline automatisch getestet und ausgerollt werden, statt bei jedem Deployment dieselben Schritte von Hand durchzugehen.

Und die KI? Die musste ja irgendwann kommen. Mit ihr arbeiten musste ich allerdings erst lernen. Am Anfang war sie eher wie ein übereifriger Minion. Hoch motiviert, schnell unterwegs, und ich musste ständig aufpassen. Was machst du da? Nein. Nicht die Datei. Bitte erst fragen.

Mit der Zeit habe ich gelernt, ihr nicht nur Aufgaben zu geben, sondern auch den Kontext dazu. README-Dateien, die das Projekt erklären. Skills und Commands für wiederkehrende Abläufe. Agenten mit klar abgegrenzten Aufgaben. Und vor allem: nicht alles auf einmal. Kleine Schritte, testen, prüfen, nachbessern. Eigentlich ziemlich agil.

Heute kann die KI mit Claude Code und solchen Abläufen schon viel übernehmen. Ich gebe die Richtung vor, prüfe die Ergebnisse und entscheide, was bleibt. Mit n8n, Python und LLMs automatisiere ich außerdem das, was sich ständig wiederholt und Zeit kostet. Meine eigene und die von anderen.

Derselbe Trick wie damals mit dem Holz. Wer nicht mehr jeden Baum selbst abbauen muss, hat Zeit für den nächsten Bau. Bei mir heißt das: Was wirklich Fokus braucht, bekommt auch Fokus. Der Rest läuft von allein. Und wenn alles läuft? Dann bleib ich dran. Und halte es am Laufen.