PyCologne Treffen Oktober 2026

Datum: Mi, 14.10.2026, 19:00 Uhr
Ort: DVS AG, Schanzenstraße 30, 51063 Köln (Anfahrt)

Pauline stellte Dokumentenautomatisierung mit Python vor, ein kleines Kundentool und die KI-Workflows, mit denen sie es entwickelt hat. Danach ging es in großer Runde darum, wie man Agentic Engineering im Alltag gut aufsetzt.

Pauline am Konferenztisch, hinter ihr auf der Leinwand der Plan für den Umbau auf das src-Layout

Zusammenfassung

1. Rahmen des Abends

Nach einer kurzen Vorstellungsrunde, mit Pizza im Anmarsch und Kuchen von Andreas auf dem Tisch, hielt Pauline den angekündigten Beitrag. Sie arbeitet als freiberufliche Python-Entwicklerin im Daten- und Backend-Bereich und zeigte ihren Code ausdrücklich, um Rückmeldungen zu bekommen. Die bekam sie reichlich: Aus dem Vortrag wurde schnell ein gemeinsames Code-Review, und der zweite Teil über Agentic Engineering lief mit einer Live-Session im Plan-Modus bis weit in den Abend.

2. Hauptbeitrag: CSV rein, PDF raus (Pauline)

Ihr Kunde ist ein kleiner Metallbaubetrieb. Zeiten und Material erfasst er unterwegs in einer selbst gebauten Handy-App und legt sie als CSV in seine Projektordner auf OneDrive. Daraus hat er Angebote, Lieferscheine, Rechnungen und Auftragsbestätigungen bisher von Hand in Word-Vorlagen übertragen. Ein kommerzielles Werkzeug, das Pauline ihm empfohlen hatte, wollte er nicht, er wollte sein eigenes. Seit rund einem Jahr entwickelt sie daran, der Kunde war einverstanden, dass sie es mit Beispieldaten zeigt.

  • Oberfläche mit Streamlit: Eine einzige Seite, Projektnummer eingeben, das Tool findet Ordner und CSV, füllt die Vorlage und legt DOCX und PDF daneben ab, mit Infos, Warnungen und Fehlern als Rückmeldung. Eine native Qt-Anwendung (PySide6) hatte sie durchgeplant und wieder verworfen: Dem Kunden ging es eigentlich nur um eine einfache Einrichtung, und die löst jetzt ein PowerShell-Skript, das uv installiert und den Rest erledigt.
  • Aufbau: app.py für Streamlit und cli.py für die Kommandozeile greifen beide nur über eine kleine öffentliche API in services.py auf das Backend zu. Die Konfiguration kommt aus einer config.json, wird in eine Dataclass geladen und als Parameter durchgereicht, statt global importiert zu werden. Dafür gab es aus der Runde ausdrücklich Lob, denn genau das macht die Funktionen isoliert testbar.
  • Geld richtig rechnen: Angefangen hat sie mit Floats, dann auf Decimal umgestellt und dabei bemerkt, dass Python nicht kaufmännisch rundet. Die Runde ergänzte, dass das CSV-Modul ohnehin Strings liefert, die man direkt an Decimal geben sollte, ohne Umweg über float. Eingelesen wird mit utf-8-sig, das ein von Windows geschriebenes Byte Order Mark wegwirft. Das löste einen kleinen Ausflug zu Magic Bytes und dem Kommando file aus.
  • Zeilen und Summen: Eine CSV-Zeile kann Arbeitszeit und Material zugleich enthalten und wird dann in zwei Rechnungspositionen zerlegt. Die Summen hält eine Dataclass mit frozen=True, damit sie nach dem Berechnen niemand mehr ändert. Ein Hinweis aus kaufmännischer Erfahrung: Den Mehrwertsteuersatz nicht nur global konfigurieren, sondern in jede Rechnung mitschreiben, damit eine Satzänderung wie zu Corona-Zeiten keine alten Belege verändert.
  • Word als Vorlage: python-docx arbeitet mit sogenannten Runs, ein Platzhalter kann über mehrere davon verteilt sein, deshalb gibt es eine eigene Ersetzungslogik. Tipp aus der Runde: Word kennt eigene Seriendruckfelder, für die statischen Teile wäre das eine Alternative zu Text-Platzhaltern.
  • E-Rechnung: Ab einem Vorjahresumsatz über 800.000 Euro ist die E-Rechnung ab 2027 Pflicht, darunter ab 2028. Der Kunde liegt darunter, das Thema steht trotzdem schon auf Paulines Liste. Andreas empfahl xsdata, das aus den XML-Schemata Code erzeugt, nachdem sein Team mit drafthorse nicht glücklich geworden war.

3. Code-Review aus der Runde

  • Abhängigkeiten: In der pyproject.toml stehen nur Untergrenzen. Das ist in Ordnung, solange die Lock-Datei eingecheckt ist und Updates getestet werden. Wer Sprünge auf die nächste Major-Version ausschließen will, setzt zusätzlich eine Obergrenze.
  • Typprüfung: Einen Typechecker gibt es noch nicht. Genannt wurden mypy, Pyright und das neue ty aus dem Hause Astral, noch Beta, aber schnell.
  • Konstanten: Die Spaltennamen der CSV stehen fest im Loader. Vorschlag: als eigene Struktur beschreiben, dann kann der Loader später auch mehrere CSV-Arten.
  • Rückmeldungen ans Frontend: Ein Messages-Objekt sammelt Infos und Warnungen und wird nach oben durchgereicht. Alternativen aus der Runde: ein Objekt mit Methoden wie warn() und error(), das je nach Umgebung in die Oberfläche oder auf die Konsole schreibt, oder gleich das logging-Modul mit eigenem Handler.
  • Das src-Layout: Der Code liegt unter src/, importiert wird aber from src.backend .... Andreas erklärte, warum das am Sinn des Layouts vorbeigeht: Das Projekt gehört per uv pip install -e . ins Virtual Env, dann heißt es import backend und src wird unsichtbar. Dazu passte seine Anekdote, wie ein Agent in Tests sys.path und sys.modules verbogen hatte, bis alles grün war, und damit nicht mehr prüfte, was geprüft werden sollte.

4. Agentic Engineering: Wie arbeitet ihr?

Pauline arbeitet mit Claude Code, meist mit einer einzigen Session pro Projekt, und spricht über die Fernsteuerung oft per Handy, statt zu tippen. Ihr Grundsatz ist Ownership: Der Agent erklärt, bevor er ändert, damit sie den Code versteht.

  • Regeln an der richtigen Stelle: Ihre globale CLAUDE.md verbietet zum Beispiel, Erklärungen für sie selbst als Kommentare in den Produktionscode zu schreiben. Für Dinge, die wirklich nicht passieren dürfen, etwa das Lesen einer Konfiguration mit Kundendaten, empfahl die Runde Hooks statt Prosa: Die laufen deterministisch, bevor das Modell handelt. Sensible Werte gehören außerdem in eine .env, die nicht ins Repo kommt.
  • Kürzere Antworten: Wem der Agent zu ausführlich ist, kann ihn auf ASD-STE100 verweisen, das Simplified Technical English aus der Luft- und Raumfahrt, etwa mit "antworte zu 80 Prozent in diesem Stil".
  • Live im Plan-Modus: Gemeinsam wurde der Umbau des src-Layouts geplant. Dabei zeigte sich, wie viel die Formulierung ausmacht ("richtig aufziehen" sagt dem Modell nicht, was richtig ist, ein konkretes Beispiel schon), dass man mit Shift-Tab die Modi wechselt und mit Strg-G den Plan selbst bearbeiten kann, bevor der Agent loslegt. Die Diskussion, ob app.py als Einstiegspunkt ins Paket gehört oder auf die oberste Ebene, endete bei der Frage, ob das Repository ein Programm ist oder ein Projekt.
  • Skills, ja oder nein: Christian beschrieb, wie sein Team bei DHL Skills in einem eigenen Repository pflegt, mit Wissen über die eigene Infrastruktur, dazu persönliche Coding-Regeln, die er auf jedes Gerät zieht. Genannt wurde grill-me von Matt Pocock, der beim Planen den Spieß umdreht und Fragen stellt. Mehrere warnten davor, Skills in großer Zahl aus dubiosen Verzeichnissen zu laden: lieber lesen, sich inspirieren lassen und das Passende selbst übernehmen. Hendrik verzichtet ganz darauf, weil Skills mit jedem neuen Modell gegen dessen eigene, oft bessere Gewohnheiten arbeiten könnten. Seine Projektvorlagen pflegt er stattdessen mit Copier. Wo ein Skill sich lohnt, zeigte Andreas: Bei ihnen steht dort, dass ein gefangener Fehler immer behandelt oder weitergeworfen wird, weil Agenten gern ein stilles try/except um alles legen.
  • Kontext ist begrenzt: /context zeigt, wie viel vom Kontextfenster Skills, MCP-Server und CLAUDE.md schon belegen, bevor die Arbeit beginnt.
  • Entscheidungen festhalten: Pauline führt bereits ein Log, warum sie was entschieden hat. Die etablierte Form dafür heißt Architecture Decision Records, in der schlanken Variante LADR.
  • MCP-Server: Zum Schluss ging es um das Model Context Protocol, also Dienste, die ein Agent wie eine entfernte Funktion aufrufen kann. Pauline nutzt das bereits mit Notion für die Fragenliste an ihren Kunden, Christian mit Confluence, damit er selbst in Markdown und Git bleiben kann. Die Idee für den nächsten Schritt: das Rechnungstool selbst als MCP-Server anbieten, damit der Kunde seinem eigenen Agenten sagen kann, er möge die Rechnung erstellen.

5. Ausklang

Zum Abschluss lief das fünfminütige Video LGTM auf YouTube, ein Lied über den Alltag mit KI-generiertem Code, das die Runde bestens traf. Es entstanden Fotos von Pauline mit ihrem Code und ein Gruppenfoto.

Gruppenfoto der Runde am U-förmigen Konferenztisch bei der DVS AG

Wir suchen Themen! Wenn Du einen Vortrag halten, eine Demo zeigen oder einen Programmpunkt anmelden möchtest, melde Dich gerne. Auch für spontane Buch- oder Tool-Vorstellungen, Fragen und Coding-Ankündigungen ist Platz, bring einfach mit, was Dich gerade beschäftigt.

Anmeldung läuft unverbindlich und kostenlos über Meetup.