Skip to main content

Wie aus einer Aufgabe Produktion wird

Wie ich 2026 tatsächlich arbeite: Jede Aufgabe durchläuft zuerst zwei Filter — lässt sich Handarbeit ganz vermeiden und lässt sich das Schreiben beschleunigen — und erreicht erst dann den Code. Unten die ganze Kette, Schritt für Schritt.

Vorbedingung — Eigentümer oder AusführerDer Filter funktioniert nur, wenn ich meinen Bereich besitze

Promova hat mein Denken umgebaut: nicht nur Entwickler sein, sondern jede Aufgabe validieren, die mich erreicht. Nicht „Wie baue ich das?“, sondern „Was bringt das dem Business?“. Dieser Filter funktioniert allerdings nur unter einer Bedingung.

Ich besitze meinen Bereich

Die Aufgabe läuft sofort durch den Filter. Ich stehe für das Ergebnis gerade, also habe ich das Recht zu sagen „das sollte gar nicht gebaut werden“ oder „das sollte nicht ich bauen“.

Ich bin Ausführer

Kein Filter. Es gibt eine Aufgabe, eine Deadline und die Lieferung. Nichts Falsches daran — es ist einfach eine andere Vereinbarung.

Der Unterschied ist nicht das Können, sondern das Mandat. Eine unabhängige Einheit, die ihren Bereich voll besitzt, kostet das Unternehmen weniger als ein Ausführer — weil sie das Unnötige nicht baut.

Vor dem Code

  1. Eine Aufgabe kommt rein

    Ich fange nicht mit „Wie baue ich das?“ an. Die erste Frage ist, was es dem Business bringt; die zweite, ob es überhaupt von mir und von Hand gebaut werden muss.

  2. Filter eins — lässt sich Handarbeit komplett vermeiden?

    Drei Auswege, und alle drei beantworten eine Frage: wer das ab jetzt macht. Nimmt die Aufgabe einen davon, ist sie nicht mehr meine — und meine Kapazität bleibt für Arbeit frei, die wirklich einen Entwickler braucht.

    Ausgänge aus der Pipeline
    • Agent macht's

      Einmal eingerichtet und es landet nie wieder bei irgendjemandem. Ab dann läuft ein Agent und erledigt es komplett allein, ohne jede Beteiligung.

      Automatisches Code-Review · Analytics landen direkt in einem eigenen Slack-Channel, statt Logs von Hand zu ziehen

    • Auftraggeber macht's

      Die Aufgabe erreicht mich gar nicht. Wer sie braucht, macht sie selbst zusammen mit KI — mein Teil ist, den Weg einmal zu bauen.

      Outreach-Mailing · Influencer-Plattform

    • Team macht's

      Ein Feature oder Plugin, ins System eingenäht, über das das Team selbst Änderungen vornimmt — ohne Ticket, ohne Entwickler.

      CMS-Redirect-Plugin in der Hand des SEO-Teams

  3. Filter zwei — das Schreiben selbst beschleunigen

    Die Aufgabe hat Filter eins überlebt, also ist sie meine. Nächste Frage: Ist das Routine im Code-Sinn? Wiederholt sich das Muster — Button-Styles, eine wiederkehrende Struktur — schreibe ich zuerst einen Skill dafür und erst dann den Code. Einmal länger, danach jedes Mal schneller.

Entscheidung

  1. Plan mode — Analyse vor der ersten Zeile

    Ich muss diesen Code durchleben, nicht bekommen. Der Plan entscheidet, wer ihn schreibt.

    Ich kenne diesen Code nicht
    Ich schreibe ihn selbst.
    Ich kenne diesen Code
    Der Agent tippt, ich prüfe jeden Diff — hier weiß ich, wie korrekter Code aussieht.
    Kannte ihn nicht, aber der Plan hat's klargemacht
    Jetzt kenne ich ihn. Der Agent tippt, ich gleiche Zeile für Zeile mit dem Plan ab.

Auslieferung

  1. Umsetzung

    Wer vom Plan bestimmt wurde, fängt an zu schreiben — ich oder der Agent. So oder so geht nichts weiter, bevor ich den Diff gelesen habe.

  2. Checks im Dev — automatisiert

    Der Agent führt die Checks: Er treibt den Flow durch Playwright oder liest Fehler direkt vom Next.js-Dev-Server über MCP. Das läuft unbeaufsichtigt — ich lese, was er meldet, und entscheide, was daraus folgt.

  3. Checks im Build-Modus

    Dev lügt. Andere Chunks, andere Optimierungen, anderes Verhalten. Etwas, das im Dev läuft und im Build stirbt, ist ein Klassiker — also bekommt der Build seinen eigenen Durchlauf, wieder vom Agenten getrieben und wieder von mir gelesen.

  4. Unit-Tests + Playwright

    Erst wenn es wirklich funktioniert. Unit-Tests für die Logik, Playwright für den Flow — vom Agenten entworfen, dann von mir geprüft und korrigiert.

  5. Staging — mein eigener Durchgang

    Ein bewusster Durchgang von Hand, bevor es jemand anderes sieht. Lokal nur, wenn die Aufgabe heikel ist. Dann geht es zur QA — in dieser Reihenfolge, nicht umgekehrt.

  6. Pull request

    Geprüft von Agenten mit den Skills, die für diese Zone des Projekts zuständig sind: eine Performance-Änderung wird gegen Performance-Regeln geprüft, eine Zahlungs-Änderung gegen Zahlungsregeln.

  7. Production

    Release.

  8. Finaler Check

    QA auf Production. Hält es — fertig.

Fundament
  • OOP
  • SOLID
  • DRY
  • KISS
  • YAGNI
  • CI/CD

Wer die Architektur-Praktiken kennt und die Reihenfolge der Schritte hält, kann Code schnell und gut zugleich schreiben. Tempo kommt aus der Abfolge, nicht aus schnellerem Tippen.

Expertise in einer konkreten Technologie bringt immer besseren Code — das steht nicht zur Debatte. Aber sie überträgt sich nicht: Wechselst du den Stack, fängst du von vorn an. Das Verständnis vom Entwicklungs-Flow, von Architektur und von Prinzipien überträgt sich vollständig. Genau das macht es möglich, in einer Codebase zu arbeiten, die du noch nicht kennst: Plan mode (Schritt 04) zeigt, wie dieses konkrete Projekt aufgebaut ist, und beurteilen, ob eine Lösung die richtige ist, kannst du ohnehin schon.