In the thick of it, not just along for the ride
I’m Alex, and I joined the team at Fischer & Consultants at the end of March. Before that, I served as a staff soldier in the military for nine years before beginning my retraining as a software developer, which I successfully completed last year.
Some onboardings take weeks filled with reading documentation and shadowing colleagues. For me, it was different. After just about a month, a production project was placed on my desk—along with full responsibility for it: the further development of an existing print service that populates report templates with data and renders them as PDFs. Specifically, it was about switching from a pull to a push approach: moving away from direct database connections towards supplying data via request payloads in JSON format.
Previous method (Pull)
New method (Push)
It sounds like a technical detail operation, and in principle it is—but the implications run deep: The print service is decoupled from the data model, multi-tenancy becomes cleaner, and the caller determines what gets printed, no longer the renderer.
Being trusted with this step so early on was a massive vote of confidence for me—and my biggest motivator right from the start.
Think first, type later
We started in classic fashion: brainstorming with all stakeholders, gathering requirements, and sketching out the architecture live. From those bullet points, we drafted a technically non-specific Product Requirements Document (PRD) that answered the question of what should be built—deliberately leaving out the how for the moment. Only after the PRD was established did we create a detailed development plan, in which every sub-step was clearly defined and demarcated from the others.
At this point at the latest, Claude Code came into play as a sparring partner. Not as a code generator, but as a precision tool: Every item in the development plan was scrutinized, refined, and given clear edges. Unclear transitions between sub-tasks are the most common cause of drift later on—deviations that nobody consciously decided on, but that simply happen. That was precisely what we wanted to avoid.
This form of critical dialogue—both with a colleague and with the AI—was one of the biggest learning experiences for me: A second perspective almost always leads to better, more pragmatic solutions.
PRD and development plan—two documents with clear roles
The Product Requirements Document (PRD) answers two questions: what should be built and why. It describes the problem, the affected stakeholders, the functional requirements, the non-functional constraints (performance, security, multi-tenancy), the acceptance criteria—and just as importantly: what is not included. The PRD is intentionally technology-agnostic. It must not anticipate how a requirement will be implemented, because doing so suffocates the exact discussion that should take place in the next phase. In our case, the PRD stated that data must be supplied via request in the future, that the renderer should be decoupled from the data model, and which multi-tenant guarantees the new behavior must fulfill—not, however, what the JSON schema looks like or which endpoint receives which contract.
The development plan answers the next question: How can the PRD be implemented concretely. Here, technology comes into play for the first time: Which components will be touched, which interfaces will change, what migration steps are needed, what sequence is mandatory, which sub-tasks can run in parallel, and—most importantly—where are the clean boundaries between sub-tasks? A good development plan makes every step clear enough to have a defined input and output behavior. It is precisely this boundary that later determines whether a sub-step can be reviewed, tested, and processed by AI in isolation.
Why you shouldn’t throw the two together has a very practical reason: As soon as requirements and implementation are mixed in a single document, every technical discussion suddenly turns into a functional debate—and vice versa. If someone asks, “Do we really need Endpoint X?”, nobody knows anymore whether the requirement itself is being questioned or just the implementation. With two separate documents, this question can be cleanly assigned: If the PRD doesn’t change, it’s purely an implementation issue. If the PRD changes, it’s a stakeholder topic.
“Planning just takes up time”—actually, it doesn’t
In theory, everyone knows that good planning is the key to a successful product. Nevertheless, I constantly hear that in practice, hardly any resources are allocated for this crucial part. “Let’s just get started” might work in a small spike setup, but rarely in a production refactor with a multi-tenant background.
The fact that planning was given the importance it deserves here, and that communication took place as equals—even between a career entrant and an experienced developer—was not something I took for granted, but a consciously positive difference from what I knew from previous stations.
Responsibility—with a safety net
The implementation was then largely up to me, in close coordination with an experienced colleague serving as reviewer and sparring partner. This setup—self-directed, but not alone—is precisely the environment where you learn the most without taking on more than you can handle.
And this is where the investment in the plan truly paid off for the first time: Because the sub-tasks were so granular and cleanly separated, many of them could be prepared or executed almost entirely by AI. This is a point that often gets lost in current discussions: AI does not compensate for poor planning—it multiplies the effectiveness of good planning. If you give the AI a vague task, you get vague code back. If you give it a clearly outlined step with defined input and output, you get a reliable result that fits seamlessly into the surrounding code.
Where the plan did hit limits—due to dependencies that were difficult to estimate beforehand—we didn’t simply drift off course. Every deviation was explicitly discussed: Is this truly necessary, or are we just trying to bypass an inconvenience? This brief reflection ensured that the final result still matched what was described in the PRD.
When the tool becomes a black box
Things got interesting when a third-party rendering engine didn’t behave the way its documentation promised. Suddenly, there were blank documents where content should have been, and behaviors that weren’t even mentioned in the official docs. We had to introduce additional checks to the data query to catch these edge cases—for example, preventing empty datasets from entering the renderer in the first place.
It is precisely at points like these that a second, often underestimated value of modern AI tools shines: When the official documentation lacks necessary depth, focused web research followed by synthesis via a suitable AI is worth its weight in gold. Out of ten Stack Overflow fragments, three GitHub issues, and a few blog posts, a coherent picture of what is actually happening inside the black box emerges in minutes. It doesn’t replace clean documentation—but it bridges the gaps surprisingly well.
What remains
What I take away from this first project can be summarized in three points:
Third: Being given responsibility early on, with the right safety net behind you, is the best thing that can happen when starting a new career. Being part of a real product from day one changes your perspective on everything that follows.ete, 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.
First: Good planning is not a bottleneck; it is an accelerator. It makes the actual implementation faster, calmer, and more predictable—and it is often the prerequisite for AI to contribute meaningfully to code in the first place.
Second: AI is not a replacement for thinking; it is a multiplier. It amplifies whatever was there before—clean structures just as much as unclear ones. Anyone who understands this gains significant leverage in the coming years.
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.
