Vom Coder zum Context Manager
Über eine Verschiebung in der täglichen Arbeit, die erst bei einer Tagesrückschau auffällt.
Wer heute Software baut, tippt immer weniger Code und schreibt immer mehr Kontext, weil sich die Rolle von Entwicklern gerade von der Syntax zum System verschiebt.
Daniel hat das an sich selbst bemerkt. Ein ganzer Arbeitstag, produktiv, aber kaum eine Zeile Code. Stattdessen: Textdateien, Kontextbeschreibungen, Anweisungen für die KI. Welche Dateien relevant sind. Was die bestehende Architektur ist. Was auf keinen Fall angefasst werden darf. Früher hätte er das alles selbst runtergetippt. Heute beschreibt er es, und die KI baut.
Das fühlt sich als Entwickler erst mal falsch an, weil man denkt: Wenn ich nicht code, arbeite ich nicht richtig. Aber das stimmt nicht. Man verlagert die Kompetenz. Du brauchst immer noch technisches Verständnis, du musst wissen, wie Datenbanken funktionieren, wie APIs aufgebaut sind, was eine Race Condition ist. Ohne das kannst du der KI keinen brauchbaren Kontext liefern. Du tippst es nur nicht mehr selbst in den Editor.
Drei Dinge haben sich bei Daniel bewährt. Erstens: Die KI nie direkt losbauen lassen. Erst erstellt sie einen Plan, eine Art Spec mit den geplanten Schritten, den betroffenen Dateien, der Vorgehensweise. Das liest er durch, korrigiert wenn nötig und gibt es dann frei. Das klingt nach mehr Aufwand, spart aber Zeit, weil Fehler vor dem ersten Commit auffallen.
Zweitens: Negativ-Anweisungen. „Ändere nichts an der Navigation." „Fass die Datenbank-Logik nicht an." Das klingt banal, reduziert aber die Nacharbeit massiv, weil KI-Agenten ohne klare Grenzen dazu tendieren, alles anzufassen, was sie finden.
Drittens, und das ist der Punkt, den die meisten überspringen: Den Code lesen. KI-generierter Code sieht oft sauber aus, aber Error Handling fehlt, Edge Cases werden ignoriert, Logging existiert nicht. Daniel baut Best Practices direkt in seine Prompts ein. „Jede Funktion braucht Error Handling." „Logge jeden API Call." Zehn Sekunden beim Prompten. Das vermeidet Spaghetti-Code nach dem zehnten Feature.
Die Diskussion unter dem Post hat einen Nerv getroffen. Und eine Trennlinie, die sich durch fast alle Antworten zieht, zwischen denen, die sagen „Ich orchestriere jetzt Architektur" und denen, die warnen „So verlernt man alles." Beide haben einen Punkt. Und beide liegen allein genommen daneben.
Die Wahrheit ist unbequem. KI ist ein Beschleuniger, der deinen Output skaliert. Wenn der vorher gut war, wird er besser. Wenn er mittelmäßig war, bekommst du mittelmäßigen Code in zehnfacher Geschwindigkeit. Wer nie ohne KI gearbeitet hat, wird nicht lernen, Probleme zu erkennen und zu lösen, weil ihm die Grundlage fehlt, auf der KI aufbauen kann. Wer sich weigert, mit KI zu arbeiten, verliert an Geschwindigkeit. Der Hebel liegt im Verständnis von dem, was du baust.
Stimmen aus der Diskussion
Sie denke nicht mehr in Zeilen, sie denke in Systemen: Welche Komponenten existieren, wie sie zusammenhängen, wo die Grenzen liegen. Richtig eingesetzt ersetze KI nicht den Coder, sondern mache den Architekten schneller. Wer das System verstehe, könne in einer Geschwindigkeit bauen, die vorher nicht möglich war. Wer es nicht verstehe, gebe Kontrolle ab. Zwischen diesen beiden Gruppen liege ein riesiger Unterschied.
KI sei wie ein Mitarbeiter, den man führen müsse. Zu strikte Anweisungen, und er kann nicht arbeiten. Zu wenig Struktur, und er driftet ab. Kein Feedback, und er driftet auch ab. Die Rolle von Entwicklern verschiebe sich Richtung Softwarearchitekt und darüber hinaus, weil die Ausführung zunehmend delegierbar werde.
So verlerne man alles, schreibt sie. Gerade als CTO sollte man Code lesen nicht verlernen. Die Sorge ist real und berechtigt als Warnung.
Takeaway
Die neue Kernkompetenz in der Softwareentwicklung heißt nicht Prompting. Sie heißt: dem System erklären können, was du willst, warum du es willst und was auf keinen Fall passieren darf. Kontext schlägt Syntax, aber nur, wenn du die Syntax mal verstanden hast.