Mittendrin statt nur mitlaufen
Ich bin Alex und seit Ende März Teil des Teams von Fischer & Consultants. Davor war ich neun Jahre Soldat im Stab, bis ich meine Umschulung zum Fachinformatiker für Anwendungsentwicklung begonnen habe und im letzten Jahr erfolgreich abschließen konnte.
Manche Onboardings dauern Wochen, in denen man Dokumentationen liest und Kollegen über die Schulter schaut. Bei mir war das anders. Nach gut einem Monat lag ein produktives Projekt auf dem Tisch — und damit auch die Verantwortung dafür: die Weiterentwicklung eines bestehenden Print-Services, der Report-Vorlagen mit Daten befüllt und als PDF rendert. Konkret ging es um die Umstellung vom Pull- auf das Push-Verfahren: weg von der direkten Datenbank-Anbindung, hin zu Daten, die per Request als JSON mitgeliefert werden.
Bisheriges Verfahren (Pull)
Neues Verfahren (Push)
Klingt nach einer technischen Detailoperation, ist es im Prinzip auch — aber die Konsequenzen reichen tief: Der Print-Service wird vom Datenmodell entkoppelt, Multi-Tenancy wird sauberer, und der Aufrufer entscheidet, was gedruckt wird, nicht mehr der Renderer.
Dass mir dieser Schritt so früh zugetraut wurde, war für mich ein Vertrauensvorschuss — und von Anfang an der größte Motivator.
Erst denken, dann tippen
Wir starteten klassisch: Brainstorming mit allen Beteiligten, Anforderungen zusammentragen, die Architektur live in einer Skizze festhalten. Aus den Stichpunkten entstand anschließend ein technisch-unspezifisches Product Requirements Document, das die Frage beantwortete, was gebaut werden soll — bewusst noch ohne wie. Erst aus dem PRD wurde ein detaillierter Entwicklungsplan, in dem jeder Teilschritt klar definiert und gegen die anderen abgegrenzt war.
Spätestens hier kam Claude Code als Sparringspartner ins Spiel. Nicht als Code-Generator, sondern als Werkzeug zur Präzision: Jeder Punkt im Entwicklungsplan wurde hinterfragt, geschärft, mit klaren Kanten versehen. Unklare Übergänge zwischen Teilaufgaben sind später die häufigste Ursache für Drift — also für Abweichungen, die niemand bewusst entschieden hat, sondern die sich einfach so ergeben. Genau das wollten wir vermeiden.
Diese Form des kritischen Dialogs — sowohl mit einem Kollegen als auch mit der KI — war für mich einer der größten Lerneffekte: Der zweite Blickwinkel führt fast immer zu besseren, praktikableren Lösungen.
PRD und Entwicklungsplan — zwei Dokumente mit klarer Rollenverteilung
Das Product Requirements Document (PRD) beantwortet zwei Fragen: Was soll gebaut werden und warum. Es beschreibt das Problem, die betroffenen Stakeholder, die fachlichen Anforderungen, die nichtfunktionalen Rahmenbedingungen (Performance, Sicherheit, Multi-Tenancy), die Akzeptanzkriterien — und genauso wichtig: was nicht dazugehört. Das PRD ist bewusst technologie-agnostisch. Es darf nicht vorwegnehmen, wie eine Anforderung umgesetzt wird, weil sonst genau die Diskussion erstickt wird, die in der nächsten Phase stattfinden soll. In unserem Fall stand also dort, dass Daten künftig per Request mitgeliefert werden müssen, dass der Renderer vom Datenmodell entkoppelt sein soll und welche Multi-Tenant-Garantien das neue Verhalten erfüllen muss — nicht aber, wie das JSON-Schema aussieht oder welcher Endpoint welchen Vertrag bekommt.
Der Entwicklungsplan beantwortet die nächste Frage: Wie lässt sich das PRD konkret umsetzen. Hier kommt zum ersten Mal Technik ins Spiel: Welche Komponenten werden angefasst, welche Schnittstellen ändern sich, welche Migrationsschritte braucht es, welche Reihenfolge ist zwingend, welche Teilaufgaben können parallel laufen, und — fast am wichtigsten — wo sind die sauberen Schnittkanten zwischen den Teilaufgaben? Ein guter Entwicklungsplan macht jeden Schritt so klar, dass er ein definiertes Eingangs- und Ausgangsverhalten hat. Genau diese Kante ist es, die später entscheidet, ob ein Teilschritt isoliert reviewbar, testbar — und auch durch KI bearbeitbar — ist.
Warum man die beiden nicht zusammenwerfen sollte, hat einen sehr praktischen Hintergrund: Sobald Anforderungen und Umsetzung in einem Dokument vermischt sind, wird jede technische Diskussion plötzlich zur fachlichen Diskussion — und umgekehrt. Wenn jemand fragt „Brauchen wir wirklich Endpoint X?“, weiß niemand mehr, ob die Anforderung infrage gestellt wird oder die Umsetzung. Mit zwei getrennten Dokumenten lässt sich diese Frage sauber zuordnen: Wenn sich das PRD nicht ändert, ist es eine reine Umsetzungsfrage. Ändert sich das PRD, ist es ein Stakeholder-Thema.
„Planung kostet doch nur Zeit“ — eben nicht
Dass gute Planung der Schlüssel zu einem erfolgreichen Produkt ist, weiß im Prinzip jeder. Trotzdem höre ich immer wieder, dass gerade für diesen wichtigen Teil in der Praxis kaum Ressourcen bereitgestellt werden. „Wir fangen einfach mal an“ funktioniert in einem kleinen Spike-Setup vielleicht, in einem produktiven Refactor mit Multi-Tenant-Hintergrund eher nicht.
Dass Planung hier den Stellenwert bekommt, den sie verdient, und dass die Kommunikation auf Augenhöhe stattfindet — auch zwischen Berufseinsteiger und erfahrenem Entwickler — war für mich keine Selbstverständlichkeit, sondern ein bewusst positiver Unterschied zu dem, was ich aus früheren Stationen kenne.
Verantwortung — mit Sicherheitsnetz
Die Umsetzung lag dann weitgehend bei mir, in enger Abstimmung mit einem erfahrenen Kollegen als Reviewer und Sparringspartner. Diese Konstellation — eigenverantwortlich, aber nicht allein — ist genau die, in der man am meisten lernt, ohne sich zu verheben.
Und hier zahlte sich die Investition in den Plan zum ersten Mal richtig aus: Weil die Teilaufgaben so granular und sauber abgegrenzt waren, ließen sich viele davon fast vollständig durch KI vorbereiten oder erledigen. Das ist ein Punkt, der in der aktuellen Diskussion oft untergeht: KI macht keine schlechte Planung wett — sie multipliziert die Wirkung einer guten. Wer der KI eine schwammige Aufgabe gibt, bekommt schwammigen Code zurück. Wer ihr einen klar umrissenen Schritt mit definiertem Input und Output gibt, bekommt ein verlässliches Ergebnis, das in den umgebenden Code passt.
Wo der Plan trotzdem an Grenzen stieß — bei Abhängigkeiten, die sich vorher schwer abschätzen ließen — wurde nicht einfach abgewichen. Jede Abweichung wurde explizit diskutiert: Ist das wirklich notwendig, oder umgehen wir hier eigentlich nur eine Unbequemlichkeit? Diese kurze Reflexion sorgt dafür, dass das Endergebnis noch das ist, was im PRD beschrieben war.
Wenn das Werkzeug zur Black Box wird
Spannend wurde es, als sich die verwendete Render-Engine eines Drittanbieters nicht so verhielt, wie es die Dokumentation versprach. Plötzlich gab es leere Dokumente, wo Inhalte stehen sollten, und Verhaltensweisen, die in der offiziellen Doku nicht einmal erwähnt waren. Wir mussten an der Datenabfrage zusätzliche Prüfungen einziehen, um genau diese Sonderfälle abzufangen — etwa, dass leere Datenmengen gar nicht erst in den Renderer wandern.
Genau bei solchen Punkten zeigt sich ein zweiter, oft unterschätzter Mehrwert moderner KI-Werkzeuge: Wenn die offizielle Dokumentation nicht in die nötige Tiefe geht, ist eine fokussierte Web-Recherche mit anschließender Synthese durch eine geeignete KI Gold wert. Aus zehn Stack-Overflow-Fragmenten, drei GitHub-Issues und ein paar Blog-Posts wird in Minuten ein nachvollziehbares Bild dessen, was in der Black Box wirklich passiert. Das ersetzt keine saubere Doku — aber es überbrückt deren Lücken oft erstaunlich gut.
Was bleibt
Was ich aus diesem ersten Projekt mitnehme, lässt sich in drei Punkten zusammenfassen:
Erstens: Eine gute Planung ist kein Bremsklotz, sondern der Beschleuniger. Sie macht die eigentliche Umsetzung schneller, ruhiger und vorhersehbarer — und sie ist oft die Voraussetzung dafür, dass KI im Code überhaupt sinnvoll mitarbeiten kann.
Zweitens: KI ist kein Ersatz für Denken, sondern ein Multiplikator. Sie verstärkt, was vorher da war — saubere Strukturen genauso wie unklare. Wer das verstanden hat, hat in den nächsten Jahren einen spürbaren Hebel.
Und drittens: Verantwortung früh übertragen zu bekommen, mit dem richtigen Sicherheitsnetz dahinter, ist das Beste, was einem im Berufseinstieg passieren kann. Vom ersten Tag an Teil eines echten Produkts zu sein verändert die Perspektive auf alles, was danach kommt.
