Blog - Hannes Pries - Webdeveloper Blog - Entwicklung mit Shopware, PHP, HTML5 und JavaScript

Jira-Tickets und AI-Prompts

Warum gute Kommunikation in beiden Welten zählt

In den letzten Monaten habe ich gemerkt: Wer saubere Jira-Tickets schreiben kann, hat auch Vorteile im Umgang mit AI-Agents wie Gemini-CLI, JetBrains AI oder ChatGPT. Klingt erstmal komisch – ist aber logisch. Denn am Ende des Tages geht es in beiden Fällen um das Gleiche: klare Kommunikation.

Jira-Ticket schreiben: Was gehört rein?

Ein Ticket ist nicht einfach nur ein To-do. Es ist eine handlungsfähige Anweisung an jemanden im Team. Damit es wirklich „ready“ ist, braucht es bestimmte Bestandteile. Zunächst sollte es einen prägnanten Titel geben, der die Aufgabe auf den Punkt bringt – beispielsweise „Implementiere User-Login mit JWT“. Danach folgt eine Beschreibung des Ziels oder Zwecks: Warum ist die Aufgabe wichtig und was soll damit erreicht werden? Zusätzlich ist es hilfreich, Kontext bereitzustellen, etwa Links zu Architektur-Dokumentationen, Business-Entscheidungen oder verwandten Tickets.

Ein gutes Ticket enthält außerdem klare Akzeptanzkriterien, die definieren, wann die Aufgabe als erledigt gilt. Ebenso gehören technische Details hinein, also welche Module oder Bibliotheken betroffen sind und angepasst werden müssen. Constraints wie Performance-Limits, Sicherheitsanforderungen oder bestimmte Architekturvorgaben dürfen ebenfalls nicht fehlen. Abgerundet wird das Ganze durch Beispiele, zum Beispiel konkrete Input- und Output-Werte, User Stories oder Skizzen, sowie durch Referenzen auf Dokumentationen, Guidelines oder APIs. Wenn ein Ticket so aufgebaut ist, kann es auch ein Junior-Entwickler umsetzen, ohne zehnmal nachzufragen.

Praxis-Anekdote: Ich erinnere mich noch an ein Ticket, das ich vor Jahren an einen neuen Kollegen geschrieben habe. Ich dachte, die Aufgabe sei selbsterklärend – aber ohne klare Akzeptanzkriterien hat er einen halben Tag damit verbracht, ein Feature zu bauen, das komplett an der Anforderung vorbeiging. Seitdem schreibe ich in jedes Ticket, woran man erkennt, dass es „fertig“ ist. Das spart Zeit und Nerven.

AI-Prompt schreiben: Fast das Gleiche

Das Lustige ist: Ein guter Prompt für eine AI braucht nahezu die gleichen Elemente. Nur dass man hier statt mit Menschen mit einer Maschine kommuniziert. Diese versteht nichts zwischen den Zeilen, also muss man noch klarer und expliziter sein.

Ein Prompt könnte zum Beispiel mit einem kurzen Titel starten: „Schreibe eine Python-Funktion zur JWT-Validierung.“ Danach folgt die Erläuterung des Zwecks, etwa: „Die Funktion wird im Auth-Flow eines FastAPI-Backends genutzt.“ Um die AI nicht im Dunkeln zu lassen, sollte man auch den Kontext beschreiben, zum Beispiel: „Wir nutzen fastapi, pyjwt und haben bereits ein User-Model.“

Genauso wichtig sind Akzeptanzkriterien, etwa: „Die Funktion soll ein JWT validieren und den User zurückgeben, oder eine Exception werfen.“ Bei den technischen Details kann man spezifizieren, welche Bibliothek genau eingesetzt werden soll, etwa: „Verwende bitte pyjwt.decode und unser Secret aus settings.py. Kein anderes JWT-Paket!“ Constraints dürfen nicht fehlen, zum Beispiel: „Muss synchron laufen, da es im Request-Lifecycle genutzt wird.“ Schließlich helfen konkrete Beispiele – wie Input-Token und erwarteter Output – sowie Links zu relevanten Dokumentationen wie der PyJWT-Doku. Im Prinzip ist das ein Jira-Ticket, nur dass der Empfänger diesmal ein AI-Agent ist.

Praxis-Anekdote: Neulich habe ich einem AI-Agenten genau so einen Prompt gegeben. Ich war in Eile und habe die Constraint „synchron“ weggelassen. Was kam zurück? Eine perfekt funktionierende, aber komplett asynchrone Implementierung. Für mein Projekt unbrauchbar. Genau dieser Moment hat mir gezeigt: Ein Prompt ohne vollständige Infos ist wie ein Ticket ohne DoR – das Ergebnis ist selten das, was man wirklich braucht.

Unterschiede: Mensch vs. Maschine

Natürlich gibt es Unterschiede. Menschen haben oft implizites Wissen über Teamkonventionen und können Dinge zwischen den Zeilen verstehen. Eine AI kennt nur das, was man ihr explizit mitteilt. Auch die Feedback-Schleife läuft anders: Mit einem Junior-Entwickler kann ich direkt reden und Fragen beantworten, während ich bei einer AI iterativ über Prompts verfeinern muss. Außerdem ist die Detailtiefe bei AI oft höher, weil sie keine impliziten Kontexte versteht.

Praxis-Anekdote: Ich hatte mal eine Situation, in der ein Junior-Entwickler einfach kurz an meinem Schreibtisch stand und fragte: „Meinst du jetzt wirklich die neue API oder die alte?“ – Problem sofort geklärt. Bei einer AI muss ich diesen Kontext von vornherein im Prompt mitliefern, sonst produziert sie Ergebnisse, die mich später doppelt Arbeit kosten.

Aber die Basis ist die gleiche: klare, strukturierte Kommunikation.

Mein Fazit

Ja, man kann es so sagen: Wer gute Jira-Tickets nach Definition of Ready schreiben kann, schreibt auch gute AI-Prompts. Denn beide verlangen Klarheit statt vager Ansagen. Sie verlangen Kontext und Ziel statt eines bloßen „mach mal“. Sie profitieren von Struktur und Nachvollziehbarkeit. Und sie brauchen ein gemeinsames Verständnis, wann etwas wirklich „fertig“ ist.

Für mich bedeutet das: Prompt Engineering ist nichts Exotisches. Es ist einfach die Weiterentwicklung einer Fähigkeit, die wir als Senior Devs sowieso jeden Tag nutzen – nämlich Aufgaben so zu formulieren, dass andere sie umsetzen können. Und ganz ehrlich: Wenn ich es schaffe, dass ein Junior nach einem Ticket sofort loslegen kann, dann kann auch eine AI ziemlich gute Ergebnisse liefern.

Praxis-Anekdote: Mittlerweile nutze ich dieselbe innere Checkliste für beides. Wenn ich ein Ticket schreibe, frage ich mich: Könnte auch eine AI damit etwas anfangen? Und wenn ich einen Prompt schreibe, frage ich mich: Könnte auch ein Junior-Dev das verstehen? Diese Haltung sorgt dafür, dass meine Kommunikation klarer wird – egal, ob ich mit Menschen oder Maschinen zusammenarbeite.

KI ist jetzt!

Psychologische Sicherheit im IT-Team

Warum Führungskräfte von Vertrauen mehr profitieren als von Kontrolle
Viele Führungskräfte in der IT stehen unter enormem Druck. Stakeholder erwarten Ergebnisse, Deadlines sind knapp, Budgets begrenzt. In dieser Situation liegt die Versuchung nahe, Kontrolle zu verstärken und bei Fehlern mit Druck oder harschen Worten zu reagieren. Doch genau hier beginnt eine Abwärtsspirale: Unsichere Führungskräfte neigen schneller dazu, Fehler auf Mitarbeitende abzuwälzen. Das mag kurzfristig Entlastung verschaffen, führt aber langfristig zu Angst, Rückzug und Fluktuation.

Eine ganz andere Dynamik entsteht, wenn Führungskräfte psychologische Sicherheit schaffen. Darunter versteht man ein Klima, in dem Mitarbeitende keine Angst haben müssen, für Fehler bloßgestellt zu werden, sondern offen über Probleme sprechen können. Wer so führt, erlebt nicht nur weniger versteckte Fehler und Konflikte, sondern auch mehr Engagement und Innovationskraft. Denn Mitarbeitende, die sich sicher fühlen, investieren ihre Energie nicht in Selbstschutz, sondern in Zusammenarbeit und Qualität.

Besonders im IT-Bereich ist Klarheit ein zentraler Hebel. Ticket-Systeme wie Jira helfen, Aufgaben nachvollziehbar zu dokumentieren, Abhängigkeiten sichtbar zu machen und Missverständnisse zu vermeiden. Mit einer klaren Definition of Ready wissen Teams genau, was von ihnen erwartet wird. Dadurch sinkt die Unsicherheit, Fehler werden seltener und Konflikte mit anderen Abteilungen oder Stakeholdern reduzieren sich deutlich. Auch Führungskräfte profitieren: Sie müssen nicht alles im Kopf behalten, haben jederzeit einen Überblick und können Entscheidungen auf einer stabilen Datenbasis treffen. Die eigene Unsicherheit und der damit verbundene Stress nehmen ab.

Doch Prozesse und Tools sind nur eine Seite der Medaille. Entscheidend ist, wie Führungskräfte mit unvermeidbaren Fehlern umgehen. Wer in diesen Momenten Ruhe bewahrt, systemische Ursachen in den Blick nimmt und Mitarbeitende unterstützt, zeigt Stärke. Wer hingegen laut wird oder Schuldige sucht, schwächt nicht nur sein Team, sondern auch sich selbst. Denn ein verunsichertes Team gibt Unsicherheit zurück: Kommunikation stockt, Vertrauen bricht weg, Fehler werden verschwiegen – und am Ende steht die Führungskraft unter noch größerem Druck.

Das Gegenteil ist ebenfalls wahr: Ein sich sicher fühlendes Team gibt Sicherheit zurück. Mitarbeitende, die offen über Probleme sprechen, schaffen Transparenz und entlasten damit die Führung. Ein Klima, in dem Ideen wertgeschätzt und Fehler als Lernchancen behandelt werden, stärkt die Resilienz des gesamten Systems. Führungskräfte, die Vertrauen schenken, bekommen Loyalität, Offenheit und Verlässlichkeit zurück. So entsteht ein Kreislauf gegenseitiger Rückendeckung: Die Leitung gibt Sicherheit ins Team – und das Team gibt diese Sicherheit zurück.

Für IT-Unternehmen ist dieser Unterschied entscheidend. Während eine Kultur der Angst auf Dauer Kosten, Fluktuation und Qualitätsprobleme erzeugt, sorgt psychologische Sicherheit dafür, dass Talente bleiben, Software zuverlässig ist und Innovation möglich wird. Wer als Führungskraft Verantwortung übernimmt, nicht nur für Aufgaben und Deadlines, sondern auch für das Klima im Team, legt den Grundstein für nachhaltigen Erfolg.

Am Ende lässt es sich einfach zusammenfassen: Unsicherheit nach unten weiterzugeben, schwächt alle. Sicherheit vorzuleben und zu ermöglichen, stärkt alle. Führungskräfte, die diesen Unterschied verstehen, profitieren selbst am meisten.

Praktisches Fazit für Führungskräfte
Wenn Sie psychologische Sicherheit in Ihrem Team fördern möchten, können Sie sofort damit beginnen: Sprechen Sie über Fehler offen und nutzen Sie sie, um Prozesse zu verbessern, statt Schuldige zu suchen. Machen Sie Anforderungen und Ziele durch klare Tickets und Definition of Ready transparent, sodass Unsicherheit reduziert wird. Ermutigen Sie Mitarbeitende, Fragen zu stellen, und nehmen Sie jede Stimme ernst – auch die leisen. Zeigen Sie selbst Verletzlichkeit, indem Sie eigene Fehler eingestehen und daraus lernen. Und vor allem: Reagieren Sie in Stresssituationen so, dass Ihr Team merkt, dass Sie hinter ihm stehen.

So schaffen Sie ein Umfeld, in dem Ihre Mitarbeitenden sich sicher fühlen, ihre beste Arbeit leisten und Ihnen diese Sicherheit zurückgeben. Am Ende gewinnen nicht nur Sie und Ihr Team – sondern das gesamte Unternehmen.

Firebird Driver unter Linux für PHP installieren

In diesem kurzen Tutorial zeige ich euch, wie ihr den Firebird-Treiber für PHP in einem Docker-Container problemlos installieren könnt.

Voraussetzungen
* Docker-Umgebung
* PHP-Container

Installationsschritte

1. Systemaktualisierung
Zuerst aktualisieren wir das Paketverzeichnis, um sicherzustellen, dass wir die neuesten Versionen erhalten:

apt-get update

2. Firebird und Abhängigkeiten installieren
Installieren wir nun die notwendigen Pakete, einschließlich des Firebird-Entwicklungspakets und weiterer Hilfsmittel:

apt-get install -y firebird-dev libib-util apache2-utils

3. PHP PDO-Firebird-Erweiterung aktivieren
Abschließenden kompilieren und installieren wir die PDO-Firebird-Erweiterung für PHP:

docker-php-ext-install pdo_firebird

Ergebnis
Diese einfache Befehlsfolge ermöglicht es euch, den Firebird-Treiber erfolgreich in eurem Docker-PHP-Container zu integrieren. Die Installation wurde erfolgreich mit PHP-Version 2.5.9 getestet und funktioniert ohne Probleme.

Fazit
Mit nur wenigen Zeilen Code habt ihr volle Unterstützung für Firebird-Datenbanken in eurer PHP-Anwendung. Der Prozess ist unkompliziert und schnell erledigt – perfekt für Entwicklungs- und Produktionsumgebungen!

erster Test mit eternalai.org als Unterstützung beim Schreiben

Willkommen im Zeitalter der Cloud – Schluss mit E-Mail-Pingpong!

Es gibt Dinge, die einfach nicht sterben wollen. Faxgeräte zum Beispiel. Oder die gute alte Tradition, Word- und Excel-Dateien per E-Mail an eine Verteilerliste zu schicken, die länger ist als die Zutatenliste auf einer Tiefkühlpizza.

Das Ritual läuft meist so ab:

* Jeder bekommt die Datei, jeder trägt irgendwo seine Änderungen ein – mal mit, mal ohne Kommentar.
* Manche schicken ihre Version nach fünf Minuten zurück, andere nach drei Wochen (inklusive „Sorry für die Verspätung“).
* Am Ende sitzt eine arme Seele da und darf Sherlock Holmes spielen: „Wer hat jetzt eigentlich was geändert, warum steht hier plötzlich 42 und wieso ist die Schrift Comic Sans?“

Das Ergebnis? Chaos mit Ansage.

Cloud statt Chaos

Und dann kam die Cloud. Eine einzige Datei, die geteilt wird. Alle arbeiten gleichzeitig darin – in Echtzeit! Keine E-Mail-Anhänge mehr, keine 15 Versionen im Postfach mit kryptischen Dateinamen wie Budget_final_final_reallyfinal_v3_neu.xlsx.

Stattdessen:

* Jeder sieht sofort, was die anderen tun (ja, auch die Tippfehler in Echtzeit).
* Änderungen werden automatisch dokumentiert – ganz ohne Excel-Krimi.
* Kommentare lassen sich direkt anfügen und lösen. Mit Benachrichtigung! Niemand kann mehr sagen: „Das hab ich gar nicht gesehen.“

Der Aha-Moment

Das Beste daran: Man muss es den Kollegen nur einmal zeigen. Einmal live erlebt, wie man in einer Cloud-Datei gleichzeitig tippt, löscht und diskutiert – schon will niemand mehr zurück zur altmodischen E-Mail-Schleuder.

Kurz gesagt: Cloud-Arbeit ist wie der Sprung vom Walkman zu Spotify. Wer einmal den Unterschied erlebt hat, fragt sich: „Warum haben wir uns das früher eigentlich angetan?“

Tickets sind wichtig!

AI: Entwickeln mit AI ist nicht immer Vibe-Coding!

Wenn man sagt, man würde mit AI entwickeln, denken viele sofort, dass man einfach Vibe-Coding betreibt. Dass man ein paar Prompts eingibt, auf das Ergebnis schaut und hofft, dass dabei etwas Sinnvolles herauskommt. Das ist aber ein Trugschluss. AI-gestütztes Entwickeln erfordert genau wie klassische Softwareentwicklung Struktur, Planung und Präzision. Man kann sich nicht einfach zurücklehnen und darauf vertrauen, dass die AI schon die richtigen Entscheidungen treffen wird. Im Gegenteil: Man muss sich ständig rechtfertigen können, warum bestimmte Vorschläge der AI übernommen werden und andere nicht.

Ein entscheidender Unterschied liegt dabei in der Vorbereitung. Bevor die AI überhaupt an den Code geht, steht die Erstellung einer fundierten requirements.md. Diese Datei enthält alle Vorgaben, die Akzeptanzkriterien, die Use-Cases und konkrete Beispiele. Die Erstellung dieser Dokumentation dauert leicht zwei Stunden oder mehr, weil jedes Detail klar definiert sein muss. Erst wenn die AI genau weiß, welche Aufgabe sie erfüllen soll, welche Bibliotheken genutzt werden dürfen und welche Funktionen zum Einsatz kommen sollen, kann sie effizient arbeiten. Ziel ist nicht, dass die AI kreativ wird, sondern dass sie genau das umsetzt, was man selbst tun würde – nur schneller und mit Unterstützung von Tests und Dokumentation.

Ein großer Vorteil der AI liegt in ihrer Geschwindigkeit. Während man selbst Stunden damit verbringen könnte, Boilerplate-Code, Dokumentation und Unit-Tests zu schreiben, generiert die AI diese Elemente in einem Bruchteil der Zeit. Doch auch hier gilt: Die AI denkt sich die Tests nicht selbst aus. Jede Überprüfung, jedes erwartete Ergebnis ist genau vorgegeben. Dadurch bleibt die Kontrolle beim Entwickler, und die Qualität des Codes wird nicht dem Zufall überlassen.

Vibe-Coding funktioniert anders. Hier konzentriert man sich auf die Ausarbeitung des Ergebnisses, auf das visuelle oder funktionale Endprodukt, ohne von Anfang an alles festzulegen. Das macht bei Prototypen Sinn, weil der Weg zum Ziel explorativ ist. In AI-gestützter Entwicklung hingegen geht es nicht nur um das Ziel, sondern um den gesamten Weg dahin. Jede Entscheidung, jede Vorgabe wird klar definiert und überprüft. Es geht um strukturierte, nachvollziehbare Softwareentwicklung, bei der die AI ein mächtiges Werkzeug ist, nicht ein magischer Generator von Lösungen.

Am Ende bedeutet Entwickeln mit AI also keineswegs, dass man nur „vibe-codet“. Es ist eine durchdachte, präzise und kontrollierte Arbeit, die Planung, klare Vorgaben und sorgfältige Umsetzung erfordert – nur eben deutlich schneller und effizienter, ohne dass man auf Qualität oder Kontrolle verzichten muss.

Legacy-Software: Warum PHP hier super ist

Wenn es um Legacy-Software geht, denkt man oft zuerst an komplizierte Abhängigkeiten, schwer wartbaren Code und die Frage: Wie bekomme ich das Ganze wieder ans Laufen?
Doch in genau diesem Kontext spielt PHP seine Stärken aus.

Warum PHP bei Legacy-Systemen glänzt

Ein zentraler Vorteil ist, dass man den Code direkt vorliegen hat. Anders als bei kompilierten Sprachen muss nichts dekompiliert oder mühselig rekonstruiert werden. Stattdessen öffnet man einfach die Dateien und kann sofort mit der Arbeit beginnen.

Auch die Fehlersuche gestaltet sich unkompliziert. Fehlermeldungen lassen sich unmittelbar in den betroffenen Dateien nachvollziehen, ohne dass man komplizierte Werkzeuge bemühen oder Umwege gehen muss.

Kommt es einmal hart auf hart, sind Änderungen sogar direkt in den Dateien möglich. Man braucht keinen Deployment- oder Build-Prozess zu reparieren, um einen kleinen Fix einzubauen – was im Alltag oft enorm Zeit spart.

Darüber hinaus lässt sich ein altes Projekt einfach in ein Git-Repository überführen. Eine Kopie genügt, um anschließend Schritt für Schritt saubere Versionierung, Branching und moderne Workflows einzuführen.

Für die tägliche Arbeit stehen zudem starke Tools bereit. IDEs wie PhpStorm, VS Code oder Eclipse bieten eine breite Palette an Funktionen für Analyse, Refactoring und Debugging, sodass man auch bei großen Codebasen den Überblick behält.

Ein weiterer Pluspunkt: Selbst ältere PHP-Projekte setzen häufig auf bekannte Frameworks wie Symfony oder Laravel. Dadurch können Entwicklerinnen und Entwickler auf vertraute Strukturen zurückgreifen, statt sich durch völlig unbekannte Eigenkonstruktionen kämpfen zu müssen.

Nicht zu vergessen: Viele in der Branche haben ohnehin schon Erfahrung mit PHP. Diese Vertrautheit senkt die Einstiegshürden erheblich und beschleunigt die Einarbeitung.

Auch Updates der PHP-Umgebung sind meist kein Hexenwerk. Zwar braucht es manchmal kleinere Anpassungen, doch insgesamt bekommt man alte Anwendungen erstaunlich gut und zuverlässig wieder ans Laufen.

Schließlich spielt PHP auch bei der Infrastruktur seine Vorteile aus. Da es kaum komplexe Anforderungen mitbringt, lassen sich Test- und Entwicklungsumgebungen unkompliziert über Docker oder ähnliche Tools einrichten.

Fazit

Mit PHP kann man bei Legacy-Software-Projekten sofort loslegen: Fehler finden, Fixes einbauen, den Code in moderne Pipelines und Repositories überführen. Ohne dass man dem Quellcode mühsam hinterherlaufen muss, nur um einen winzigen Bug zu beheben.

Gerade in Zeiten, in denen viele Systeme noch lange weiterbetrieben werden müssen, zeigt sich: PHP ist für Legacy-Software oft genau die richtige Wahl gewesen.

AI: Next Generation Coding Monkey

Es fühlt sich an, als wäre Vibe-Coding schon ewig da – zumindest, wenn man in KI-Jahren rechnet. Vor ein paar Monaten war es noch “Magie”, heute ist es Alltag: LLMs, die nicht nur Code schreiben, sondern auch Gedichte, Songtexte oder Blogposts polieren.
Ich lasse mir manchmal einfach spontan ein paar Zeilen Songtext ausspucken, schmeiße sie in Suno, und zack – habe ich genau den Soundtrack, den ich in diesem Moment beim Arbeiten brauche. Verrückt, oder?

Und dann gibt es da noch Nano-Banana. Wer’s kennt, weiß: Die Zensur ist dort so streng, dass man schon mal “die erwachsene Zauberin” schreiben muss, nur damit aus einem Pixelbild ein realistisches Artwork wird. Klingt witzig, ist aber auch ein bisschen absurd.

Zurück zum Coding
Doch das alles ist nur die bunte Spielwiese. Richtig spannend wird es bei Vibe-Coding:
Programme einfach in normaler Sprache beschreiben, und die KI baut sie für dich. Keine umständlichen Prompts, kein Copy & Paste – Tools wie Gemini-CLI oder JetBrains Junie holen sich die KI direkt in die IDE. Klingt nach Zukunft, oder?

Ja. Aber.

Die Wahrheit ist: Die AI denkt nicht für dich.
Wenn du selbst keine Idee hast, wie du ein Problem lösen würdest, bekommst du am Ende nur Quatsch zurück. Der Traum, einfach zwei Sätze zu tippen und die KI spuckt die perfekte App aus, ist genau das – ein Traum.
Oft muss man der KI sogar haarklein sagen, welche Libraries oder APIs sie nutzen soll. Sonst landet man bei Code, der zwar hübsch aussieht, aber in der Realität nie laufen wird.

Was wirklich zählt
Nach ein paar Monaten Experimentieren habe ich gemerkt: Das Geheimnis liegt nicht im Prompt selbst, sondern in der Vorbereitung.
Ich habe mir angewöhnt, eine saubere requirements.md zu schreiben – und zwar selbst. Nicht von der KI. Darin halte ich fest:

- Welche Lösung ich mir vorstellen würde
- Welche Datenstrukturen ich brauche
- Welche Beispiele wichtig sind
- Welche Use Cases abgedeckt sein müssen
- Welche Acceptance Criteria gelten

Klingt nach klassischem Ticket-Schreiben? Genau. Eigentlich nichts Neues – nur dass es hier den Unterschied zwischen gutem und miesem KI-Code macht. Wenn man diese “Definition of Ready” sauber aufsetzt, liefert die KI plötzlich großartige Lösungen. Sogar Sicherheitsaspekte, die ich selbst nicht auf dem Schirm hatte, tauchen auf.

Fazit
Die KI ist wie ein genialer Coding Monkey: schnell, fleißig und unermüdlich. Aber sie ersetzt nicht dein Denken. Sie schreibt deinen Code – sie entwirft aber nicht deine Lösung.

Shopware 6: Deployment-Pipeline

Auch wenn Shopware 6.6 mittlerweile nicht mehr die aktuellste Version ist und ich derzeit nicht mehr überwiegend mit Shopware arbeite, habe ich meine GitLab-Pipeline für ein möglichst schlankes und robustes Shopware-6.6-Deployment so aufbereitet, dass ich sie hier veröffentlichen kann.
Die Pipeline lässt sich problemlos auch auf andere Shopware-6-Versionen anpassen (eine Variante für 6.4 lief bereits produktiv, bis sie per AI in GitHub Actions migriert wurde).

Für die lokale Entwicklung genügt ein sehr schlankes Projekt:

custom
apps
plugins
static-plugins
env_config
prod
stage
.env.local
auth.json
composer.json
composer.lock
docker-compose.yml

Die docker-compose.yml kann eine einfache Dockware-Variante sein, in der alle relevanten Ordner als Volumes gemountet werden, sodass man direkt darin entwickeln kann.

In env_config liegt alles, was für die jeweiligen Umgebungen spezifisch ist. Dateien aus diesem Verzeichnis werden übernommen und ergänzen oder überschreiben vorhandene Konfigurationen. Typischerweise findet man hier eine passende .env.local sowie verschiedene Konfigurationsdateien für den config-Ordner.

Die Einrichtung auf dem Server ist unkompliziert: Im gewünschten Verzeichnis wird folgendes Skript ausgeführt:

mkdir shopware
cd shopware
mkdir config
mkdir releases
mkdir shared
cd shared
mkdir media
mkdir thumbnail
mkdir bundles
mkdir files
mkdir log
mkdir sitemap
cd config
mkdir jwt
cd ../..
cd releases
mkdir _init
cd _init
mkdir public
cd public
echo "<html><body>INIT</body></html>" > index.php
cd ../../..
ln -sfn ./releases/_init/public current

Anschließend kann der VHost auf current/public/ zeigen – die INIT-Seite sollte dann bereits erreichbar sein.

Die eigentliche Pipeline besteht aus zwei Dateien: der .gitlab-ci und der rebuild.sh.
In der .gitlab-ci.yml werden sämtliche Dateien zusammengeführt, ohne dass Shopware-Code ausgeführt wird. Alles, was Shopware und eine Datenbank erfordert, wird in der rebuild.sh erledigt.

In der .gitlab-ci.yml sind folgende Variablen erforderlich:

* server
* server_folder
* ssh_user
* target_env
* SSH_PRIVATE_KEY

Falls zwischen Umgebungen unterschieden werden muss (z. B. unterschiedliche Server-Adressen für Stage und Prod), lassen sich hier Environments einsetzen. Die Bezeichnungen müssen exakt mit den Verzeichnisnamen in env_config übereinstimmen.

.gitlab-ci.yml

stages:
- deploy

.default_deploy:
image: kroniak/ssh-client:3.21
stage: deploy
script:
- echo "init start"
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
- echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
- echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
- chmod 600 ~/.ssh/id_rsa
- echo "init finished"
- apk add --no-cache zip
- zip -rq custom_$CI_PIPELINE_IID.zip custom
- cd env_config/$target_env/ && zip -rq ../../env_config_$CI_PIPELINE_IID.zip . -x "../*" && cd ../..
- ssh ${ssh_user}@${server} "cd ${server_folder} && composer create-project shopware/production ./releases/$CI_BUILD_TOKEN "v6.6.10.3" --no-interaction --ignore-platform-reqs"
- scp custom_$CI_PIPELINE_IID.zip ${ssh_user}@${server}:${server_folder}
- scp env_config_$CI_PIPELINE_IID.zip ${ssh_user}@${server}:${server_folder}
- scp composer.json ${ssh_user}@${server}:${server_folder}/releases/$CI_PIPELINE_IID/composer.json
- scp composer.lock ${ssh_user}@${server}:${server_folder}/releases/$CI_PIPELINE_IID/composer.lock
- scp auth.json ${ssh_user}@${server}:${server_folder}/releases/$CI_PIPELINE_IID/auth.json
- scp rebuild.sh ${ssh_user}@${server}:${server_folder}/releases/$CI_PIPELINE_IID/rebuild.sh
- ssh ${ssh_user}@${server} "cd ${server_folder} && unzip -oq custom_$CI_PIPELINE_IID.zip -d ./releases/$CI_PIPELINE_IID/"
- ssh ${ssh_user}@${server} "cd ${server_folder} && unzip -oq env_config_$CI_PIPELINE_IID.zip -d ./releases/$CI_PIPELINE_IID/"
- ssh ${ssh_user}@${server} "cd ${server_folder} && rm custom_$CI_PIPELINE_IID.zip"
- ssh ${ssh_user}@${server} "cd ${server_folder} && rm env_config_$CI_PIPELINE_IID.zip"
- ssh ${ssh_user}@${server} "cd ${server_folder} && cd ./releases/$CI_PIPELINE_IID/public && rm -rf media && ln -sfn ../../../shared/media media"
- ssh ${ssh_user}@${server} "cd ${server_folder} && cd ./releases/$CI_PIPELINE_IID/public && rm -rf thumbnail && ln -sfn ../../../shared/thumbnail thumbnail"
- ssh ${ssh_user}@${server} "cd ${server_folder} && cd ./releases/$CI_PIPELINE_IID/public && rm -rf sitemap && ln -sfn ../../../shared/sitemap sitemap"
- ssh ${ssh_user}@${server} "cd ${server_folder} && cd ./releases/$CI_PIPELINE_IID/public && rm -rf bundles && ln -sfn ../../../shared/bundles bundles"
- ssh ${ssh_user}@${server} "cd ${server_folder} && cd ./releases/$CI_PIPELINE_IID/var && rm -rf log && ln -sfn ../../../shared/log log"
- ssh ${ssh_user}@${server} "cd ${server_folder} && cd ./releases/$CI_PIPELINE_IID/ && rm -rf files && ln -sfn ../../shared/files files"
- ssh ${ssh_user}@${server} "cd ${server_folder} && cd ./releases/$CI_PIPELINE_IID/ && ./rebuild.sh"
- ssh ${ssh_user}@${server} "cd ${server_folder} && ln -sfn ./releases/$CI_PIPELINE_IID current"
- ssh ${ssh_user}@${server} "cd ${server_folder} && cd releases && ls -dt */ | tail -n +4 | xargs rm -rf && cd .."
tags:
- runner-docker

deploy_stage:
extends: .default_deploy
environment: stage
only:
- /^staging_(.+)$/

deploy_prod:
extends: .default_deploy
environment: prod
only:
- /^prod_(.+)$/

Das Skript rebuild.sh kann projektspezifisch angepasst werden, z. B. wenn zusätzliche Node.js-Versionen oder Build-Schritte erforderlich sind.

rebuild.sh

bin/console system:update:prepare
composer composer install
bin/console system:update:finish
bin/console cache:clear
bin/console database:migrate --all
bin/console cache:clear
npm install --prefix ./vendor/shopware/administration/Resources/app/administration
bin/build-administration.sh
bin/build-storefront.sh
bin/console sw:theme:compile
bin/console cache:clear

bin/console cache:warmup
bin/console http:cache:warm:up

--

Zum Schluss noch ein Beispiel für eine docker-compose.yml, die sich bei Bedarf leicht anpassen lässt:

version: "3"

services:
# shopware_full:
# build: ./infrastructure
# ports:
# - "80:80"
# - "443:443"
# - "2222:22"
# volumes:
# - ./infrastructure/my_vhost.conf:/etc/apache2/sites-enabled/000-default.conf:rw
# - ./shopware:/var/www/html
# networks:
# - web

shopware:
image: dockware/dev:6.6.10.3
ports:
- "80:80"
- "443:443"
- "2222:22"
volumes:
- "./custom/apps:/var/www/html/custom/apps"
- "./custom/plugins:/var/www/html/custom/plugins"
- "./custom/static-plugins:/var/www/html/custom/static-plugins"
- "./vendor:/var/www/html/vendor"
- "./composer.json:/var/www/html/composer.json"
- "./composer.lock:/var/www/html/composer.lock"
- "./env_config/dev/.env:/var/www/html/.env"
- "./env_config/dev/.env.local:/var/www/html/.env.local"
- "lang_mysql:/var/lib/mysql"
- "./docker/volumes/media:/var/www/html/public/media"
- "./docker/volumes/theme:/var/www/html/public/theme"
- "./docker/volumes/bundles:/var/www/html/public/bundles"
- "./config/packages/cache.yaml:/var/www/html/config/packages/cache.yaml"

networks:
- web
environment:
# default = 0, recommended to be OFF for frontend devs
- XDEBUG_ENABLED=0
- XDEBUG_REMOTE_HOST=172.17.0.1
# default = latest PHP, optional = specific version
- PHP_VERSION=8.2
- NODE_VERSION=20

#config host:mail, port:1025, user:demo, password:demo
mail:
image: mailhog/mailhog
networks:
- web
ports:
- 8025:8025

# use init or bin/console system:install --force to init database
shopware_mysql:
image: bitnami/mysql:8.4.5
environment:
MYSQL_ROOT_PASSWORD: root
MYSQL_DATABASE: shopware
MYSQL_USER: app
MYSQL_PASSWORD: app
networks:
- web
volumes:
- ./docker/dumps/:/docker-entrypoint-initdb.d
- mysql_data:/var/lib/mysql

# shopware_mysql:
# image: bitnami/mariadb:10.6.20
# environment:
# MARIADB_ROOT_PASSWORD: root
# MARIADB_DATABASE: shopware
# MARIADB_USER: app
# MARIADB_PASSWORD: app
# networks:
# - web
# volumes:
# - ./infrastructure/dumps/:/docker-entrypoint-startdb.d
# - mysql_data:/bitnami/mariadb

shopware_redis:
image: redis:7
networks:
- web

shopware_elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:8.13.4
networks:
- web
environment:
- discovery.type=single-node
- xpack.security.enabled=false
volumes:
- elasticsearch_data:/usr/share/elasticsearch/data

volumes:
lang_mysql:
mysql_data:
elasticsearch_data:

networks:
web:
external: false

Tipp: Firebird 2.5.x mit Intellij verwenden

Eine Firebird 2.5.x Datenbank mag nicht mehr die neuste Datenbank sein. Sie skaliert nicht zeitgemäß, SQL dafür Schreiben macht wirklich keinen Spaß und auch sonst sollte man alles tun um zu vermeiden damit arbeiten zu müssen.. aber sie funktioniert noch und es gibt auch noch Docker-Container dafür.

In alten Projekten findet man also manchmal noch so eine alte Firebird Version und man kann sie super und schnell im Docker-Container starten und hat eine kontrollierbar Entwicklungsumgebung. DBeaver kann man gut damit verwenden.. also DBeaver spricht gut mit der Firebird DB, aber auch das Programm scheint aus einer Zeit zu stammen also Delphi noch der heiße geile Scheiß war.

Ich kam auf die abstruse Idee einfach meine Intellij IDE damit Verbindungen zu wollen. Es geht gut, wenn man erstmal weiß was man so einstellen muss.

1. Mut die fast älteste Version des Treibers wählen, die dabei ist

2. Encoding einstellen... nicht erwarten das so etwas modernes wie UTF-8 funktioniert

3. Die Software, die die Firebird 2.5.x nutzt so schnell wie möglich ablösen oder auf eine aktuelle MySQL/MariaDB Version bringen.

Sollte damals schon jemand voll modern gewesen ein und richtige JOIN Strukturen im FROM verwendet haben (das funktioniert da wirklich schon.. irgendwie), sollte so eine Migration gar nicht so schwer sein. ChatGPT hilft sicher gerne das DDL zu migrieren.

Tipp: Linux Oracle-Treiber installieren

Falls man unter Ubuntu 24.04 LTS diese Fehlermeldung erhält

(libaio.so.1: cannot open shared object file: No such file or directory)

hilft das hier

sudo apt install libaio1t64
sudo ln -s /usr/lib/x86_64-linux-gnu/libaio.so.1t64 /usr/lib/x86_64-linux-gnu/libaio.so.

So ein Oracle-DB Client ist erstaunlich umständlich zu installieren.

AI: Kraut-Ipsum mit ChatGPT wiederbelebt

Lange Zeit war die erste Stelle für Platzhaltertexte immer Kraut-Ipsum. Doch dann war es weg. Nachdem nun GPT-5 rauskam brauchte ich ein paar Test-Ideen und irgendwie kam ich auf die Idee Kraut-Ipsum davon nochmal bauen zulassen.. ganz einfach und ganz simpler Prompt. Hab mich einmal bei der originalen Wort-Liste bedient aber man kann natürlich einfach sich da selber was zusammen basteln... so Firmen eigene Wort-Liste wäre auch möglich.

Demo:
https://krautipsum.annonyme.de/

Git:
https://gitlab.com/hpries/krautipsumresurrection

Agentur-Probleme: Verantwortung ist immer nach unten gerichtet

Agenturen haben gerade viele Probleme, und es müssen neue Wege gefunden werden, wie man mit der sich verändernden Wirtschaft, Gesellschaft und Weltsituation umgeht. Ein riesiges Problem ist, dass bisher niemand einen funktionierenden Ansatz gefunden hat – oder auch nur eine Idee, wie man überhaupt einen solchen Ansatz entwickeln könnte. Ich habe es selbst versucht und musste mir eingestehen: Ich hatte nicht nur keine gute Idee, sondern nicht einmal eine schlechte.

Fehlende Kunden, KI, schlechte Wirtschaftslage – das alles lässt sich grob zusammenfassen mit: „Es fehlt das Geld, um etwas zu tun.“
Um als Agentur weiter existieren zu können, braucht man Kunden, die nicht nur den Status quo bezahlen, sondern auch genug Geld mitbringen, um Freiräume zu schaffen – um neue Wege zu gehen, Risiken einzugehen, auch mal zu scheitern. Aber genau dieses Geld ist bei den Kunden heute nicht mehr vorhanden. Gleichzeitig ist ihre Kompetenz gestiegen – sie stellen plötzlich unangenehme, weil sehr gezielte und berechtigte Fragen.

Vor fünf Jahren hat man eben 2000 € für etwas bezahlt, ohne dass ganz klar war, warum – weil es lief und das Geld da war.

Heute ist der Kampf um Kunden voll entbrannt. Jetzt muss man sich kompetent, professionell und innovativ präsentieren. Auch Verträge müssen so formuliert werden, dass nicht bei einem Problem gleich das ganze Projekt oder gar die Firma scheitert.

Das Sales-Department ist gefragt – und soll liefern. Was viele vergessen: In Agenturen spielen die Entwickler eine zentrale Rolle bei der Kundenakquise. Warum? Weil der Kunde mit seinem eigenen IT-Menschen kommt – und der zerlegt jeden Sales-Mitarbeiter argumentativ in der Luft. Sales können verkaufen, aber haben oft keine tiefere Ahnung vom Produkt oder der Dienstleistung. Deshalb sprechen am Ende meist Entwickler mit Entwicklern – oder mit Leuten, die selbst mal programmiert haben.

So kommt man auf einen gemeinsamen Stand, mit dem beide Seiten leben könnten.
Aber: Der Entwickler entscheidet nichts. Dann kommt wieder Sales – und es wird kompliziert. Die wollen mehr Geld, bessere Positionen. Wenn Entwickler verhandeln, kommt selten ein Deal dabei raus, der den Kunden „über den Tisch zieht“. Aber wenn mit ehrlicher Arbeit kein Geld mehr verdient wird, entsteht Druck – und dann sucht man eben doch Wege, irgendwie Geld rauszuholen. Auch wenn es nicht ganz sauber ist.

Sales gibt die Richtung vor. Das C-Level will: mehr Geld bei weniger Aufwand. Entwickler? Die kündigen womöglich, wenn der Druck zu groß wird. Verzögerungen? Möglich. Wenn schon die letzten Projekte nur „okay“ liefen, weil der Kunde über Probleme hinweggesehen hat und man Features nachliefern durfte, will man nicht an einen Kunden geraten, der vor Gericht um sein Geld kämpfen würde.

Also wird umformuliert, Zeiten angepasst. Nicht das Ergebnis soll bezahlt werden, sondern die Arbeit. Entwickler werden aus der Kommunikation genommen – weil sie zu ehrlich waren, sich zu gut mit dem Kunden verstanden haben.
Stattdessen schickt man eine Welle aus Inkompetenz los, um dem Kunden zu „zeigen“, dass er keine Ahnung hat und es für ihn besser sei, mehr für weniger zu zahlen. Aussagen wie: „Ein Pflichtenheft ist nur zum Nachteil des Kunden, weil er dann nicht mehr flexibel genug ist.“ – als ob es die letzten Male der Kunde gewesen wäre, der die Probleme verursacht hat.

Kommen wir zurück zum Punkt: Kunden sind kompetenter und stellen gute Fragen.
Sie wissen, dass nicht sie sich um die Agentur bemühen müssen, sondern umgekehrt – und das machen sie auch deutlich.

Plötzlich ist der Entwickler wieder gefragt, weil er sich ehrlich mit dem Kunden auseinandergesetzt hat. Wenn man in so einer Situation landet: Nicht mitmachen!
Es gibt einen Grund, warum plötzlich wieder Leute zurückgeholt werden, die schon raus waren oder nie dabei sein wollten. Es ist bereits zu spät – jetzt geht es nur noch darum, zu erklären, was der Kunde sehen will und warum er Recht hat.

Sales sagt nein.
Der Entwickler antwortet: „So geht es nicht weiter – genau deshalb sind wir jetzt in dieser Situation.“
Wenn man so weitermacht, verliert man den Kunden.

Und dann passiert etwas, das ich so noch nie erlebt habe:
Der Sales-Mitarbeiter sagt, es sei ihm egal – er würde für nichts, was er getan, gesagt oder noch sagen wird, die Verantwortung übernehmen.
Alle im Meeting nehmen das hin. Kein Widerspruch. Weiter im Text.

Was soll nun geschehen? Soll der Entwickler noch mal versuchen, den Kunden mit Argumenten zurückzuholen?
Auf keinen Fall!
Der Entwickler würde an allem Schuld sein.
Der Kunde würde das Problem allein bei ihm sehen – schließlich hat er auf das vertraut, was der Entwickler ihm vermittelt hat. Und das wurde nicht geliefert. Unter dem Subtext: „Eigentlich müsste man dich feuern.“

Wenn man wirklich, wirklich unfassbares Glück hat, merkt der Abteilungsleiter irgendwann, dass man nur das getan hat, was Sales gefordert hat – und er war dabei, als alle Bedenken vom Tisch gewischt wurden. Man hatte sich bewusst gegen die Wünsche des Kunden entschieden.

Und dann erkennt man:
Der Abteilungsleiter hat einfach nicht mitgespielt beim Spiel der Verantwortungsschieberei.
Die Verantwortung wandert immer nach unten.
Der Klassiker „Das war der Azubi“ ist bittere Realität – blöd nur, wenn man keinen Azubi hat. Dann bist du schuld.

Aber zum Glück ist das kein Problem, mit dem man leben muss – also nicht das Weiterreichen von Verantwortung an sich, sondern solche Abteilungsleiter. Wozu braucht man die überhaupt? Sie stehen nur im Weg, wenn das C-Level, das längst keinen Bezug mehr zum Alltag hat, seinen Frust direkt auf die Entwickler abregnen will. Und Entwickler? Die beschweren sich nicht – und wenn doch, sind sie zum Glück in einer Gehaltsklasse, auf die man nicht hören „muss“.

Am Ende bleibt die alte Erkenntnis:
Du HAST nicht Schuld.
Du BEKOMMST die Schuld.

KI: Schon tot, bevor es richtig losging?

Ich beziehe mich hier hauptsächlich auf diesen Artikel bei Heise:
https://www.heise.de/meinung/KI-Agenten-Tisch-reservieren-ist-lahm-10494271.html

OpenAI hat seinen AI-Agenten vorgestellt, und für viele ist das der Beweis, dass KI schon jetzt in einer Sackgasse steckt. Es gebe keine sinnvolle Verwendung für KI, sie sei eine Lösung für ein Problem, das noch nicht gefunden wurde. Wenn man sich die Kommentare zu skeptischen Meinungen im Internet durchliest, ist die Haltung zu KI sehr eindeutig. Die Argumente sind klar: KI könne niemals etwas liefern, das für einen Menschen von echtem Nutzen sei.

Einige würden sagen, diese Leute seien einfach zu „deutsch“ und hätten nicht verstanden, wie KI (insbesondere LLMs) funktioniert. Sie hätten eine völlig falsche Vorstellung davon, was eine KI leisten kann. Aber ist es wirklich so einfach? Kurz gesagt: Ja! Doch wenn man etwas genauer hinsieht, merkt man, dass die Frage doch nicht ganz so simpel zu beantworten ist. Ich gehe mal auf ein paar Punkte ein:

Was bringt mir eine KI, die mir einen Tisch reservieren kann?
Zuerst wird sich darüber lustig gemacht, dass die KI ja „nur“ einen Tisch reservieren könne und nicht einmal richtig buche – obwohl das im Alltag zu 100 % deckungsgleich ist. Dann kommt die große Frage: Woher soll die KI wissen, was ich gerade will?

Die KI sucht irgendein Restaurant aus, reserviert zu einer beliebigen Zeit, zu der mein Kalender frei ist – und dann soll ich da hingehen, obwohl ich vielleicht gar keinen Hunger habe oder lieber Pizza statt asiatisch gegessen hätte. Genau so wäre es, wenn man der KI den Wocheneinkauf überlassen würde: Man hätte immer das Gleiche, vielleicht in völlig falschen Mengen – Woche für Woche. KIs liefern eben das, worauf sie trainiert wurden, und da jeder Mensch einzigartig ist, ist die Wahrscheinlichkeit, dass die KI etwas Passendes liefert, sehr gering. KI produziert also nur Dinge, die kaum jemand wirklich mögen kann?

KI fehlt einfach die Fantasie?
Wie jemand in den Kommentaren schrieb: KI fehlt einfach die Fantasie, um für Menschen interessante Dinge zu generieren. Egal ob Bilder, Videos, Texte oder Musik – die KI generiert nur das, worauf sie trainiert wurde, und was sie für den allgemeinen Geschmack hält.

Wenn ich die KI bitte, mir eine Geschichte zu schreiben, wird sie mir sicher nicht gefallen – denn ich lese ja am liebsten Fantasy-Romane. Eine Antwort darauf war: Die KI steckt deshalb in einer Sackgasse und könne erst dann wirklich hilfreich sein, wenn man ihr die eigenen Wünsche und Vorlieben mitteilen kann.

Und hier wird es seltsam…
Einen Weg finden, um der KI etwas mitzuteilen? Hat diese Person jemals mit einem LLM oder einer anderen generativen KI gearbeitet?

Wenn ich schreibe: „Schreib mir eine Geschichte“, mich wundere, dass mir das Ergebnis nicht gefällt, und mich dann über die KI beschwere – dann liegt das Problem wohl woanders. Viele Menschen, die KI für völlig sinnlos halten und befürchten, dass dadurch alles zum Einheitsbrei wird, betrachten KI wie ein Fernsehgerät – nur eben ohne Fernbedienung. Man müsse eben gucken, was gerade läuft. Sie erwarten, dass sie genau das bekommen, was sie sich wünschen – ohne aktiv zu kommunizieren, sondern nur passiv zu konsumieren.

Natürlich muss ich der KI sagen, was ich will. Wenn ich total unspezifisch bleibe, kommt auch nur etwas Unspezifisches heraus. Die KI kann keine Gedanken lesen.

Beschweren ist Volkssport?
Es wird sich beschwert. Sich zu beschweren ist für bestimmte Menschengruppen – oft aus dem gehobenen Alter – fast schon ein Hobby. Der Fernseher ist ein gutes Beispiel: Ältere Menschen sitzen davor, beklagen sich über das schlechte Fernsehprogramm (früher war natürlich alles besser) und sagen, sie wären lieber ins Bett gegangen (tun es aber nicht und schauen trotzdem weiter). Dabei gäbe es auf anderen Sendern durchaus Vielfalt – aber die emotionale Blockade, den gewohnten Bereich zu verlassen, verhindert das.

Eine KI kann ihre Stärken nur im Zusammenspiel entfalten. Wenn man aber selbst keine Initiative zeigt, wird auch keine brauchbare Reaktion kommen.

Kommunikationsschwäche als Kernproblem?
Viele Menschen sind nicht in der Lage, eine klare, zielgerichtete Kommunikation zu führen. Wenn jemand sagt: „Die Musik ist doof, ich mag so was nicht“, wäre die naheliegende Gegenfrage: „Was für Musik magst du denn?“ Doch viele Menschen würden daraufhin nur irritiert reagieren, lang überlegen und dann womöglich gereizt und laut entgegnen, was einen das überhaupt angehe. Man solle gefälligst selbst wissen, was man mag, und andere damit in Ruhe lassen. Auf so eine „dumme“ Frage habe man keine Lust.

Gefühlt ist diese Gruppe nicht klein. Dass diese Menschen eine KI weder verstehen noch richtig bedienen können, ist logisch. Wer seine Wünsche nicht formulieren kann, ist mit einer KI überfordert.

Heute werden KIs meist über Prompts gesteuert. Wer es nicht schafft, seine Erwartungen in einem Prompt zu formulieren, und auf eine Schnittstelle wartet, die genau das ermöglicht (was der Prompt ja bereits ist), der hat derzeit einfach keine Möglichkeit, mit einer KI sinnvoll zu interagieren.

Das eigentliche Problem ist also nicht die KI – sondern die Unfähigkeit vieler Menschen zur klaren Kommunikation. Die KI könnte fast alles liefern – wenn man ihr nur den richtigen Input gibt.

Fazit
Wenn OpenAI zeigt, dass ihr Agent einen Tisch reservieren kann, dann ist das für viele offenbar schwer als Beispiel zu erkennen. Sie nehmen es wortwörtlich – und denken nicht weiter. Dabei könnte man noch tausend andere Dinge mit der KI tun. Aber man muss eben selbst denken. Leider ist das auch nicht jedermanns Stärke.

Agentur-Probleme: Wenn das Kundenprojekt zur Geisel wird

Kunden sind manchmal unzufrieden. Das ist normal. Manchmal ist es berechtigt, und in manchen Fällen liegt es eher am Kunden selbst. Oft ist es aber einfach so, dass Agentur und Kunde nicht zueinander passen. Dann ist es völlig in Ordnung, getrennte Wege zu gehen.

Problematisch wird es nur, wenn zu viele Kunden gehen wollen – und man lieber einen ungeliebten Kunden behält als gar keinen. Ich habe vor vielen Jahren zum ersten Mal gehört, dass Kunden sich zwar von Agenturen trennen möchten, aber Angst haben, dabei ihre Website oder Domain zu verlieren. Die Agentur hat die Domain gekauft – nicht im Namen des Kunden, sondern sie lediglich zur Verfügung gestellt. Das Hosting läuft auf einem Agenturserver, oft nicht sauber von anderen Projekten und Kunden getrennt, sodass ein Zugriff für den Kunden unmöglich ist.

Ich bin ein großer Verfechter davon, dass der Kunde alles selbst besitzen soll. Ich berate und helfe gerne überall, aber am Ende sollte alles wirklich dem Kunden gehören. Der Kunde muss mir Zugriff auf seine Sachen geben – nicht ich ihm auf Dinge, die ihm eigentlich ohnehin gehören.

Eine Trennung zwischen Agentur und Kunde muss nicht negativ verlaufen. Vielleicht wurde die Firma des Kunden verkauft, oder der Agenturinhaber kann den Kunden aus gesundheitlichen Gründen nicht mehr betreuen. In jedem Fall ergibt es Sinn, das Kommen genauso einfach zu gestalten wie das Gehen.

Viele Agenturen sehen das leider anders. Sie nehmen die Entscheidung des Kunden, zu gehen, persönlich – selbst wenn es vorher bereits Streit gab und eigentlich keiner der beiden Seiten mehr Lust auf die Zusammenarbeit hat. Dann wird es schwierig: Der Kunde will gehen, möchte aber natürlich seine Website, seinen Shop oder sonstige Projekte mitnehmen. Weder eine Domain zu übertragen noch ein Git-Repository zu öffnen oder zu exportieren, ist wirklich schwer oder zeitaufwendig. Das sollte innerhalb von zwei Stunden erledigt sein.

Doch manche Agenturen verhalten sich dann so, dass man schon von einer Art Geiselnahme sprechen könnte (andere würden es als Nötigung bezeichnen). Die Domain kann nicht einfach übertragen, sondern nur zu einem hohen Preis verkauft werden. Der Quellcode wird als ZIP-Datei übergeben – was angeblich so aufwendig ist, dass es natürlich teuer wird. Datenbankkopien sind angeblich nur zu ganz bestimmten Zeiten möglich – und dass der Kunde einfach auf „Exportieren“ klickt, sei ihm nicht zumutbar.

Ein besonders extremes Beispiel habe ich kürzlich erlebt: Ein Kunde, zwei Agenturen. Bei der einen Agentur geht Know-how verloren, und der Entwickler der zweiten Agentur soll Zugriff auf Code und Server erhalten, um im Notfall etwas fixen zu können. Teile des Codes stammen ohnehin von ihm, und vor 1,5 Jahren hatte er bereits Zugriff auf das Projekt. Also nichts Neues, sondern eigentlich nachvollziehbar.

Doch die Angst der ersten Agentur war: „Wenn die den Code haben, sind sie ganz weg.“ Ja – das wird passieren. Und es hat auch seine Gründe. Zugänge sauber einzurichten und den Kunden beim Übergang zu unterstützen, wäre eigentlich die beste Lösung. Das kann man auch abrechnen – und niemand würde sich beschweren. Selbst wenn noch ein bis zwei Stunden bei der Agentur verbleiben, um intern alles zu koordinieren, wird das gerne bezahlt – solange alles sauber abgewickelt wird.

Aber plötzlich 5.000 Euro zu fordern und dem Kunden mitzuteilen, dass es ein Vertragsbruch sei, wenn der andere Entwickler einen Bugfix macht – und man gegen den Kunden vorgehen würde, falls dieser nicht zahlt –, das ist einfach nur extrem. Es ging um Plugins, die speziell für diesen einen Kunden entwickelt wurden, und die sich nicht sinnvoll für andere Kunden weiterverwenden lassen, ohne nochmal viel Zeit zu investieren. Der Agentur bringt dieser Code also gar nichts.

Ich verstehe nicht, warum Agenturen lieber auf etwas sitzen bleiben (spezialisierter Code, ungenutzte Domains etc.), anstatt sich fair und professionell zu verhalten. Einen Streit mit dem Kunden zu beginnen – der womöglich in schlechten Bewertungen endet – bringt niemandem etwas.

Eine Agentur sollte in der Lage sein, professionell zu agieren – ruhig, lösungsorientiert und kompromissbereit. Selbst wenn der Kunde sich danebenbenimmt (ich wurde auch schon wegen meines Stundensatzes beleidigt…), sollte man als Dienstleister einen kühlen Kopf bewahren.

AI übernimmt die Jobs von Entwicklern

Microsoft entlässt 9.000 Entwickler und ersetzt sie durch AI. Das ist mal eine Aussage – und zeigt, wie schwer es für Entwickler geworden ist. Die AI kommt und nimmt ihnen die Jobs weg. Klingt ein wenig zu einfach, um wahr zu sein ... ist es natürlich auch.

Erstens ist es bei amerikanischen Firmen immer wieder erstaunlich, wie viele Angestellte sie beschäftigen. „Hire and Fire“ führt dazu, dass man lieber mal zu viele Entwickler einstellt als zu wenige – ein Fehler, den man schnell korrigieren kann. Da werden mal eben 20 Entwickler für ein Projekt eingestellt, bis der Kunde doch abspringt – und schon werden die Entwickler einfach wieder entlassen. Der feuchte Traum eines jeden deutschen Agentur-Chefs. Dass man viele einstellt und dann in gewissen Wellen die Low Performer entlässt, ist auch nicht neu. Auch hier ist AI nicht das eigentliche Problem, sondern nur ein verstärkender oder beschleunigender Faktor.

Wenn man sich die Kommentare zu solchen News durchliest, kommt schnell der Einwand, dass die Firmen bald merken werden, dass eine AI keinen komplexen Code erzeugen kann – und dann die entlassenen Entwickler teuer zurückholen müssen. Gefühlt stammen solche Aussagen oft von Menschen, die nicht mit AI arbeiten, und deshalb eine etwas verzerrte Vorstellung davon haben, wie man mit AI-Agents arbeitet.

Jeder meiner Versuche, eine vollständige Anwendung mit Junie oder gemini-cli erstellen zu lassen, war nicht wirklich erfolgreich. Sich jedoch eine Boilerplate-Anwendung generieren zu lassen, in der man dann Schritt für Schritt seine Anwendung implementiert, lief dagegen echt gut. Ich brauchte ein winziges CMS für ein paar Seiten, ein paar Webhooks und einen AI-Agenten, bei dem sich Benutzer anmelden können. Grave war schon zu groß, also hat mir gemini-cli auf Basis meiner requirements.md genau das gebaut – und es funktionierte super. Auch der Code war ziemlich gut. Ich selbst hätte dafür sicher 3–4 Stunden gebraucht und die meiste Zeit nur primitiven Code geschrieben oder mir etwas aus alten Projekten kopiert. So war alles in 30 Minuten durch, und ich konnte direkt mit der eigentlichen Anwendung beginnen.

Brauche ich noch Designer, die mir nach meinen Beschreibungen Skizzen und Storyboards erstellen, wenn die AI das kann – und ich nach zwei Minuten einen angepassten Prompt eingebe und so in einer Stunde bis zu 30 Iterationen habe, wo ich mit einem Menschen vielleicht zwei oder drei geschafft hätte?

Im Zusammenhang mit den Microsoft-Kündigungen las man, dass sich Level-Designer ein AI-Tool gebaut haben, um das Leveldesign zu beschleunigen – und dann durch genau dieses Tool ersetzt wurden. Genauer gesagt ging es um Candy Crush und ähnliche Spiele. Mein Gefühl sagt mir, dass die Schöpfungshöhe solcher Level recht gering ist und festen Mustern folgt. Perfekt also, um sich so etwas von AI erzeugen zu lassen. Es scheint also auch vorher eher Fleißarbeit als Denkarbeit gewesen zu sein.

Am Ende werden Menschen nicht durch AI ersetzt, sondern durch Menschen, die AI möglichst effizient einsetzen. Menschen, deren Arbeit immer darin bestand, Dinge nach festen Vorgaben abzuarbeiten und strukturierten Output zu liefern, sind leichter zu ersetzen. Programmierer gehören oft dazu – denn selbst in der Zeit vor AI war die eigentliche Programmierung selten die Herausforderung. Meist wusste man, was man tun wollte, hatte den Code schon im Kopf und saß dann zwei Stunden da, um alles niederzuschreiben und zu testen. Das nimmt einem jetzt die AI ab. Auch wenn ein AI-Agent manchmal selbst länger braucht und 30 Minuten benötigt, um alles anzulegen und zu befüllen, spart man dennoch viel Zeit. Ich hatte auch schon Meetings, bei denen mir die AI nebenbei etwas gebaut hat – und ich konnte nach dem Meeting sofort testen und meine kleinen Verbesserungen oder Funktionen einbauen.

2004 in der Berufsschule haben wir gelernt, dass Entwickeln und Programmieren zwei unterschiedliche Dinge sind. Entwickeln ist die eigentliche Leistung, Programmieren ist der stupide, zeitraubende Teil der Aufgabe. Heute ist das deutlicher denn je.

Gleichzeitig zu diesen Entlassungen wird in Deutschland diskutiert, ob man die Arbeitszeiten verlängern sollte – vielleicht sogar einen Feiertag opfern sollte. Gerade für alle, die von AI betroffen sind, klingt das vollkommen realitätsfern. Die Menschen werden ja nicht entlassen, weil sie nicht in der Lage wären, mit AI-Tools mehr in weniger Zeit zu schaffen, sondern weil jetzt alle mehr schaffen – aber nicht mehr Arbeit da ist. Arbeit ist der limitierende Faktor, der es erlaubt, Leute freizustellen.

In Kommentaren regt man sich darüber auf, dass Firmen Millionengewinne einfahren und trotzdem so viele Angestellte entlassen. Aber es bringt auch nichts, Leute rumsitzen zu lassen, die keinen Mehrwert erbringen. Rumsitzen und nichts zu tun haben macht keinen Spaß und verursacht auch viel Stress. Die wenigsten Leute würden sich hinsetzen und einfach ein neues Produkt entwickeln. Wenn das so wäre, würde man sie liebend gern behalten – weil sie durch ihre Anwesenheit Mehrwert schaffen. Kaffee trinken und im Internet surfen zählt aber nicht dazu.

Die große Herausforderung für die Zukunft wird sein, dass Menschen lernen, wenig bis nichts mehr zu tun zu haben – weil weniger Menschen dieselbe Menge an Arbeit erledigen können, aber nicht mehr Arbeit entsteht. Auch die Gesellschaft muss einen Weg finden, den Menschen aufzuzeigen, wie sie einen Mehrwert schaffen können. Das Problem ist dann die Bezahlung, weil das bisherige Konzept nicht mehr passt. Das, was heute Geld einbringt, wird von AI übernommen – und der Mensch arbeitet noch, um sich selbst und die Gesellschaft zu verbessern.

AI: Vibe-Coding vs. Context-Engineering

Vibe-Coding war ein Begriff, der vor einiger Zeit einen regelrechten Hype auslöste und in aller Munde war. Wenn man heute noch mit Vibe-Coding kommt, schauen einen viele mitleidig an und fragen, ob man nicht Context-Engineering meint. Vibe-Coding ist eben schon sowas von letzte Woche … gefühlt ist es gerade mal drei Tage her, dass Context-Engineering als der neue heiße Shit gilt.

Als bei meinem Ex-Arbeitgeber Vibe-Coding der breiten Masse der Entwickler vorgestellt wurde (es ist tatsächlich schon ganze vier Wochen her – Ewigkeiten in AI-Zeit, heute wechseln AI-Dev-Konzepte so schnell wie früher Nvidia neue GeForce-Karten herausgebracht hat), gab es folgenden Tipp: Alle Anforderungen in eine Datei schreiben und im Prompt lediglich auf diese Datei verweisen. Die Dokumentation sollte in einem Unterverzeichnis liegen – man sollte sich nicht darauf verlassen, dass das LLM schon alles Nötige weiß. Also: Weniger in die Prompts und mehr Struktur direkt im Projekt.

Am Ende ist das nichts anderes als: „Erst denken, dann Code schreiben.“ Also nicht einfach drauflos coden, sondern zuerst Anforderungen und Konzepte überlegen.

Context-Engineering ist genau das. Den „Vibe“ rausnehmen, erst nachdenken, Informationen sammeln und strukturiert ordnen. Vibe-Coding eignet sich hervorragend, um Prototypen und Ideen schnell zu entwickeln. Diese lassen sich dann sauber dokumentieren und als Kontext in ein Projekt einbinden – ideal, wenn daraus später ein echtes Produkt entstehen soll.

Man kann also sagen: Vibe-Coding als kreative Vorstufe, Context-Engineering als methodischer Feinschliff.
Jedenfalls ist das meine Auffassung von dem, was gerade passiert. Aber vielleicht ist nächste Woche ja schon wieder alles anders.

N8N: Setup mit Traefik

N8N auf einem eigenen Server einrichten inkl. Traefik, damit man auch andere Dinge noch auf dem Server laufen lassen kann.

networks:
netintern:
external: false
web:
external: false

services:
traefik:
image: traefik:v3.4
container_name: traefik
restart: unless-stopped
logging:
driver: "json-file"
options:
max-size: "250m"
max-file: "1"
command:
- "--api.insecure=true"
- "--providers.docker=true"
- "--providers.docker.exposedbydefault=false"
- "--entrypoints.web.address=:80"
- "--entrypoints.websecure.address=:443"
- "--certificatesresolvers.letsencrypt.acme.email=myemail+n8n@gmail.com"
- "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
- "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"
- "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
ports:
- "80:80"
- "443:443"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- ./le:/letsencrypt
networks:
- web
- netintern

n8n:
image: docker.n8n.io/n8nio/n8n
container_name: n8n
logging:
driver: "json-file"
options:
max-size: "250m"
max-file: "1"
environment:
- N8N_HOST=n8n.mydomain.de
- N8N_PORT=443
- N8N_PROTOCOL=https
volumes:
- n8n_data:/home/node/.n8n
restart: unless-stopped
networks:
- netintern
labels:
- "traefik.enable=true"
- "traefik.http.routers.n8n.rule=Host(`n8n.mydomain.de`)"
- "traefik.http.routers.n8n.entrypoints=websecure"
- "traefik.http.routers.n8n.tls.certresolver=letsencrypt"
- "traefik.http.services.n8n.loadbalancer.server.port=443"
- "traefik.http.routers.n8n-http.rule=Host(`n8n.mydomain.de`)"
- "traefik.http.routers.n8n-http.entrypoints=web"
- "traefik.http.routers.n8n-http.middlewares=redirect-to-https"
- "traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https"

volumes:
n8n_data:
traefik_data:

Agentur-Probleme: Es läuft nicht mehr... AI!

Viele Agenturen haben momentan ein Problem: So wie es die letzten zwei bis drei Jahre lief, läuft es einfach nicht mehr. Kunden bleiben aus. Bestehende setzen weniger Geld um oder springen komplett ab. Was übrig bleibt, können wenige Mitarbeitende bewältigen – während der Rest darauf wartet, dass neue Kunden kommen. Doch das bindet das Sales-Team und erfordert hohe Investitionen, um überhaupt überschaubare Projekte zu gewinnen.

Aber wer oder was ist schuld an der Situation?

Wenn man den zeitlichen Verlauf betrachtet, fällt auf, dass mit dem Beginn der Probleme auch etwas anderes gewachsen ist: Künstliche Intelligenz. AI ermöglicht es Kunden, viele Dinge selbst zu erledigen. Einfach die AI fragen – und schon bekommt man eine brauchbare Antwort. Kunden sind dadurch mündiger geworden und stellen mehr in Frage. Das macht es schwerer, ihnen etwas zu verkaufen. Klar, die wirtschaftliche Lage spielt auch eine Rolle, aber AI scheint der Haupttreiber zu sein.

So einfach ist es dann aber doch nicht.

AI ist großartig, gerade im generativen Bereich. Aber: Kein Kunde ersetzt seine Agentur durch AI und generiert einfach selbst Code. Vielmehr wird AI in Produkte integriert und macht diese zugänglicher und einfacher in der Bedienung. Gleichzeitig wird es aber auch komplexer, diese Systeme zu erweitern – denn die AI muss diese Anpassungen auch „verstehen“. Ja, AI hat sicherlich Entwicklungen beschleunigt, aber viele Probleme gab es schon vorher – und sie wären auch ohne AI irgendwann sichtbar geworden.

Corona ist nun endgültig vorbei. Damals konnte man sich auf die Straße stellen, einmal laut rufen: „Ich bin Programmierer“ – und 20 Minuten später hatte man fünf neue Kunden. Webshops und Homepages waren plötzlich kein Hype mehr wie zu Dotcom-Zeiten, sondern überlebensnotwendig, um mit Kunden in Kontakt zu bleiben und weiterhin verkaufen zu können. Wer keinen Webshop hatte, war raus. Und wer einen hatte, wollte plötzlich wieder vorne mitspielen. Es brauchte Beratung. Sales sprach mit Kunden, als wären sie "dumm". Man konnte ihnen viel verkaufen, denn sie hatten weder Ahnung noch Erfahrung. Lieber zu viel investieren, als unterzugehen.

Diese Zeit ist vorbei. Jeder, der einen Webshop brauchte, hat längst einen. Der Rest hat überlebt – oder sich bestätigt gefühlt, dass es auch ohne geht. Diese kleinen, unerfahrenen Kunden in Massen? Verschwunden. Manche Sales-Abteilungen haben sich nicht angepasst. Heute steht dir ein potenzieller Kunde gegenüber, der Geld für ein Upgrade seines Shops hat – nicht, weil er bisher etwas falsch gemacht hat, sondern weil er vieles richtig gemacht hat. Wer den behandelt wie einen Anfänger, verliert ihn sofort. Warum sollte sich jemand von einem erklären lassen, wie das eigene – erfolgreiche – Geschäft funktioniert?

#1: Die Zeit, in der man Kunden wie Idioten behandeln konnte, ist vorbei!

Auch der Mangel an Entwicklern ist vorbei. Man muss nicht mehr in Osteuropa suchen oder in Asien einkaufen. Entwickler gibt es wieder überall: gute, mittelmäßige und schlechte – also genau wie es sein sollte.

Kein Kunde baut sich mit AI selbst ein Shopware-Plugin. Tools wie Cursor und Junie ermöglichen das theoretisch erst seit wenigen Monaten. Kunden sind auch nicht mehr dankbar, dass eine Agentur überhaupt Zeit für sie hat. Wenn eine Agentur nicht liefert – in Qualität oder Quantität – sucht man sich eine andere oder stellt eben direkt Entwickler ein. Gerade für Firmen mit IT-Abteilung, SAP-Beratern und ERP-Know-how ist es kein weiter Schritt, auch einen Shopware-Entwickler ins Team zu holen. Der kann dann auch direkt an der Middleware mitarbeiten – ohne großen Overhead.

Ich kenne zwei Fälle, in denen der Ansprechpartner beim Kunden selbst aus der IT kam – und entschied: „Das machen wir jetzt intern.“ Eine Vollzeitkraft ist produktiver als eine Agentur, weil kaum Overhead entsteht. Die Codequalität? Ausreichend.

Und dann höre ich von Agenturen:
„Der Kunde hat zwei Entwickler eingestellt, um unseren einen zu ersetzen… Die werden schon sehen, dass das nichts wird!“
Falsch! Der Kunde hat genug Arbeit für zwei Leute – und die Agentur konnte schlicht nicht genug liefern.

#2: Angestellte Entwickler sind eine echte Alternative zu Agenturen!

Entwickler haben in den letzten Jahren sehr gute Arbeit geleistet. Ich habe mal zu einem Arbeitgeber gesagt:
„Ich bin gut, wenn ich mich selbst überflüssig gemacht habe – wenn die Software so einfach ist, dass ihr mich nicht mehr braucht.“

Und genau das haben viele Entwickler geschafft: intuitive Oberflächen, einfache Bedienung, modular aufgebaut, wiederverwendbar. Kunden sind nicht so individuell, wie sie glauben. Zwei, drei Konfigurations-Flags – und ein Plugin funktioniert für mehrere. Viele Shops kann man heute zu 90 % aus bestehenden Plugins zusammenstellen – ohne eine einzige Codezeile.

Dieses "Zusammenklicken" lässt sich super in einfache Oberflächen gießen. Dazu automatisiertes Deployment – und zack, hat man einen Cloud-Service. SAP behauptet, es gäbe keine Standardschnittstellen – aber am Ende bauen sie doch bei jedem Kunden das Gleiche. 90 % gibt es schon, 10 % sind individuelle Anpassungen – theoretisch auslagerbar in eine JSON-Datei.

Webshops funktionieren seit 20 Jahren nach dem gleichen Prinzip: Listing, Produktseite, Warenkorb, Checkout, Account. Wer so lange entwickelt hat, hat alles schon mal gebaut. Der Punkt ist erreicht: Kunden finden fast alles, was sie brauchen, bereits fertig.

#3: Es gibt fast alles schon – es muss nicht mehr neu entwickelt werden!

Natürlich zahlt ein Kunde heute nicht denselben Preis, wenn jemand einfach einen Shop zusammenklickt, wie damals, als alles individuell programmiert werden musste. Für echtes Custom-Development zahlt man noch immer gut – aber es ist seltener nötig.

Ein weiteres Thema ist der Overhead. Kunden wollen für Impact zahlen – nicht für Projektmanagement. Viele Kunden wären zufrieden, wenn man den Projektmanager streicht. Spart Geld, spart Zeit.

Natürlich gibt es sehr gute Projektmanager – die wissen, was der Kunde will, die auch mal einen Shopware-Flow anpassen, damit der Entwickler sich auf Code konzentrieren kann. Aber genauso gibt es viele, die teure Projekte verkaufen und managen wollen – aber nicht mal den Admin-Bereich bedienen können. Kunden, die täglich mit dem System arbeiten, merken schnell, wenn sie es besser verstehen als die Agentur.

#4: Kenne dein Produkt – und sei ein echter Experte!

Heute haben wir Kunden, die Profis sind. Und wir haben Tools, die fast alles können. Jedes Ticket ist schnell erledigt. Weniger Aufwand, weniger Stunden – weniger Geld. Gleichzeitig wächst der Druck: Tickets sollen schneller fertig werden. Und wenn du gut bist und brauchst statt 8 nur 4 Stunden, super – nur bekommst du dann auch weniger bezahlt.

Zeit gegen Geld ist ein veraltetes Modell. Kunden bezahlen gerne für Impact – und oft auch dafür, es schnell zu bekommen. Warum machen wir Aufwandsschätzungen zum Problem des Kunden?

Der Kunde will ein Ergebnis – das bekommt einen Preis. Ob das nun schon fertig rumlag oder neu entwickelt wird, ist egal. Wenn der Entwickler freitags mittags geht, weil er fertig ist: gut so! Die Leistung ist erbracht, das Geld verdient.

#5: Weg vom Zeitmodell – hin zu Festpreisen für Ergebnisse. Impact zählt, nicht Aufwand.

AI beschleunigt die Entwicklung enorm – vor allem bei neuen Ideen, Prototypen und Design. Dass etwas schneller geht, ist ein Vorteil, den man verkaufen sollte – kein Nachteil!

Fazit: AI ist weder Schuld noch allein die Lösung. Die eigentlichen Probleme reichen tiefer und sind älter als brauchbare AI. Sie kann vieles verbessern – aber nur, wenn das Umfeld mitzieht. „Das haben wir schon immer so gemacht“ ist ein schwaches Argument, wenn es darum geht, warum plötzlich nichts mehr funktioniert.

Agentur-Probleme: Qualität kann nur aus Komplexität entstehen

Agenturen existieren in einer eigenen sehr speziellen Bubble, in der Gesetze gelten, die sich außerhalb dieser Bubble seit 20 Jahren oft schon überholt haben. Eines dieser Gesetze ist, dass Qualität nur aus Komplexität entstehen kann. Je komplexer eine Lösung ist, desto höher ist deren Qualität. Wenn es darum geht eine vorhandene alte Lösung durch eine schlankere und einfacher Lösung zu ersetzen, kommt neben dem "das haben wir schon immer so gemacht" auch eine reine Beurteilung an Anzahl der Zeilen, Anzahl der Dateien und ob Copy&Paste als Design-Pattern dort zum Einsatz kam. Also wenn die neue Lösung 40 Zeilen lang ist, in eine Datei passt und extends-Funktionalität nutzt ist die Qualität geringer als die alte Lösung aus über 200 Zeilen, 6 Dateien und wo alles per Copy&Paste erstellt wurde und mindestens 2 Dateien per Hand synchron gehalten werden beim verwendeten Docker-Image. Wenn man also noch eine Risikobewertung mit rein nimmt verhält sich Qualität also immer entgegen des Risikos. Das Onboarding eines neuen Developers dauert über eine Stunde und nicht 15min? Das nennt sich Qualität, weil jemand sehr viel mehr dran gearbeitet hat als andere neuen Lösung (die Zeilen und Dateien entstehen ja nicht ohne Arbeit). Viel Arbeit = Viel Qualität.
Das stammt auch aus der Art, wie Abgerechnet wird. Zeit gegen Geld. Somit gilt also: Viel Arbeit = Viel Geld = Viel Qualität.

Interessanter Weise gilt das selbe für die Auswahl bei von der AI generierten Lösungen. Je komplexer die präsentierte Lösung ist, desto besser und als qualitativ hochwertiger wird sie betrachtet, weil die AI darauf ja mehr Rechenleistung verbraten hat.

Shopware 6: HTML Ajax und JavaScript Plugins

Wenn man z.B. ein Product-Box per Ajax von einem Controller nach lädt, wird der "In den Warenkorb" Button nur als normale Form funktionieren und nicht den Off-Canvas Warenkorb nutzen per JavaScript. Weil bei dem initialisieren der Plugins der HTML-Code natürlich noch nicht da war. Das kann man aber einfach nachholen.

document.getElementById('productRecommendation').innerHTML = result.productRecommendation;
window.PluginManager.initializePlugins(document.getElementById('productRecommendation'));

Damit wird der HTML-Code nach Plugin-Markern durch sucht und die Plugins an den Elementen neu initialisiert.

Grav CMS Honeypot

Ein Honeypot in das Kontaktformular einbauen ist recht einfach. Man kann alles am Feld hinterlegen:

form:
name: contact-form
fields:
- name: honeypot
label: "Leave this field empty"
type: text
attributes:
style: "display: none; position: absolute; left: -9999px;"
validate:
required: false # Sicherstellen, dass das Feld nicht ausgefüllt werden muss
message: "Bot detected!" # Fehlermeldung, falls das Feld ausgefüllt wird
rule: empty # Das Feld muss leer bleiben
buttons:
- type: submit
value: Send

Man kann auch eine Rule in user/plugins/form/form.yaml[anlegen] und die rule anstelle von "empty" angeben. Wenn man mehrere Formulare auf der Seite hat, ist das sicher die bessere Methode.

rules:
honeypot:
message: "Bot detected!"
validate: empty

Ollama lokal mit Docker

Nachdem ich feststellen musste, dass ChatGPT nur per API nutzbar ist, wenn man dafür bezahlt und sowie es ja problematisch sein kann Daten wie Telefonnummern oder Adressen dahin zu schicken, habe ich mich nach Alternativen umgesehen. Google Gemini kann man ohne Probleme per API nutzen, auch wenn man nicht bezahlt, aber das Datenschutzproblem bleibt. Also wäre eine lokale Lösung sowie so viel besser.

So kam ich zu Ollama. Das kann man ohne Probleme per Docker starten. Ohne GPU-Beschleunigung war es aber doch recht langsam. Zum Glück installiert der Nvidia-Treiber alles mit, um auch unter Windows GPU-Beschleunigung in Docker-Containern nutzen zu können.

Selbst mit einer GTX 970 ist das llama3 Model recht gut nutzbar. Test mit einem separaten Linux-System und Telsa P4 folgen später, wenn die Karte da ist.

Docker-Container starten:

docker run -d -v ollama:/root/.ollama -p 11434:11434 --gpus=all --name ollama_2 ollama/ollama

Ollama CLI Eingabe starten:

docker exec -it ollama_2 ollama run llama3

Abfrage via API:

POST http://localhost:11434/api/generate
Content-Type: application/json

{
"model": "llama3",
"prompt": "write a short poem about a 1HE server.",
"stream": false
}

Rotations-Prinzip

Menschen kommen, scheitern und gehen. Der nächste wird besser sein. Es ist eine endlose Suche nach dem einen der diesen ewigen Kreislauf durchbricht. Wobei Suche der falsche Begriff ist. Es ist mehr ein warten. Ein passives Warten. Aber ganz sicher kommt irgendwann der eine oder die eine, die alles mitbringt was man haben will. Jemand der nicht auf die Hilfe der anderen angewiesen ist, die keine Zeit für sowas haben und somit das Scheitern für die meisten schon vorprogrammiert ist. Nein! Ein Mensch wird kommen und genau die Person sein, die man schon immer haben wollte.

Die anderen, die durch die Rotation gegangen sind, ziehen weiter. Zur nächsten Firma und durch den nächsten Rotationszyklus bis auch die Firma sie wieder ausspuckt. Diese Menschen sind das Rauschen, dass die gesuchten verdeckt, ihre Aufgabe ist es ausgesiebt zu werden oder bis sie sich ändern. Aber wenn sie sich ändern könnten, wären sie nicht da wo sie sind. Nicht gefangen in einen immer wieder kehrenden Zyklus von Kommen, Scheitern und Gehen gefangen.

Und somit.. mal gucken ob der nächste Projektmanager, die nächste Projektmanagerin ein weiter Zyklus in der Rotation ist oder diese Rotation durchbrechen kann.

Natürlich könnte man mehr Zeit in Auswahl, Förderung und Aufbau eigener Leute stecken.. aber das bezahlt einen eben niemand.

Shopwar 6: DatePicker außerhalb einer Form

In HTML gibt es die Möglichkeit Inputs auch außerhalb einer Form zu haben und diese mit einer Form zu verknüpfen. Dazu nutzt man das form-Attribute. Gerade im Checkout von Shopware 6 ist es echt praktisch. Beim DatePicker besteht aber das Problem, dass das Input, dass man selbst definiert durch ein neues Input-Feld ersetzt wird, wenn Flatpickr sich initialisiert. Diesem neuen Input muss man auch das form-Attribute geben.

Tut man es nicht, funktioniert z.B. das required-Flag am DatePicker nicht.

Hier eine Quick&Dirty Lösung für das Problem:

Shopware 6: Custom Storefront Endpoint in Apps

Da ich lange herum probieren und die Dokumentation interpretieren musste hier einmal schnell wie das Mapping zwischen Twig-Fule und URL aussieht.

URL

http:localhost/storefront/script/testscript?value=test

Path

Resources/scripts/storefront-testscript/index.twig

Beispiel

{% set value = hook.query['value'] %}

{% set response = services.response.json({'value': value}) %}
{% do response.cache.disable() %}
{% do hook.setResponse(response) %}

liefert einfach das was man übergibt als JSON zurück (ohne Cache).

Shopware 6: Immer Ärger mit den JWT-Dateien

Bei Deployments die ein per Composer erzeugtes Shopware 6 Projekt als Basis haben (was wohl alle neueren sind) muss man die JWT-Dateien immer noch zusätzlich erzeugen und sie müssen die richtigen Rechte haben.

Man kann auch Env-Variablen (JWT_PUBLIC_KEY und JWT_PRIVATE_KEY) verwenden, was bei mir aber irgendwie nicht korrekt funktionierte und beim Login in die Administration zu einer Exception führt.

Aber es gibt auch einen Weg ganz ohne JWT Keys und der verwendet das APP_SECRET aus der .env Datei.

Damit klappte auch ein Deployment auf platform.sh dann ohne Probleme.

Docker und AWS CLI: secretsmanager nutzen

Um z.B. in einer Gitlab Pipeline den AWS secretsmanager zu nutzen, um Passwörter oder Token abzufragen muss man erstmal den CLI Client installieren und konfigurieren. Das geht am Besten wenn man die Dateien direkt schreibt.

apt-get install -y python3 python3-pip awscli --no-install-recommends
mkdir ~/.aws
echo -e "[default]\naws_access_key_id = ${AWS_KEY}\naws_secret_access_key = ${AWS_SECRECT}" > ~/.aws/credentials
echo -e "[default]\nregion = eu-central-1\noutput = json" > ~/.aws/config
echo $(aws secretsmanager get-secret-value --secret-id my_secret_token --query SecretString --output text)

Shopware 6: Order Recalculation nach Änderung

Eine Bestellung zu bearbeiten in dem man z.B. ein LineItem löscht benötigt die Nutzung von Versionen. Was an sich nicht schwer ist, wenn man weiß
wie man es machen muss. (Beispiel ist Shopware 6.4)

$versionId = $this->orderRepository->createVersion($orderId, $this->getContext());
$this->orderLineItemRepository->delete([['id' => $id]], $this->getContext()->createWithVersionId($versionId));
$this->recalculationService->recalculateOrder($orderId, $this->getContext()->createWithVersionId($versionId));
$this->orderRepository->merge($versionId, $this->getContext());

Shopware 6 DB-Dump und sed

MySQL Dump bei Shopware haben manchmal das Problem, dass DEFINER und Datenbanknamen an Triggers mit exportiert werden, die nicht zur neuen Datenbank passen, wenn die Datenbank anders heißt und man einen anderen Benutzernamen hat.

Man kann dann mit einem Texteditor wie nano, vi oder Notepad++ die Datei durchsuchen und es per Hand fixen. Nur doof wenn die Datei 6GB groß ist und keiner der Editoren mehr so richtig performant mit der Datei arbeiten will.

Dafür gibt es dann in der Linux Kommandozeile sed:

mysqldump -u demouser -p demo_webshop > ./dump_for_65_update.sql
sed 's/`demo_webshop`.//g' dump_for_65_update.sql > dump_for_65_update_clean.sql
sed -i 's|/\*!50017 DEFINER=`demouser`@`localhost`\*/||g' dump_for_65_update_clean.sql
mysql --database=demo65_webshop --user=demouser65 -p < ./dump_for_65_update_clean.sql

Man kann da sicher noch allgemeine Ausdrücke für schreiben, aber das lag dieses mal außerhalb dem was der Kunde bezahlt hätte.

Shopware: Update von 6.4 auf 6.5

Shopware: Update von 6.4 auf 6.5

An sich geht es ganz einfach. In der Administration geht man auf Update, bestätigt alles, die Plugins werden deaktiviert (vielleicht auch das Language-Pack) und dann startet der Installer und .. läuft in einen Fehler und dann läuft garnichts mehr. Scheint jeden Falls öfters mal so zu passieren.

Ich hab mir ein Script gebastelt mit dem man sich eine Kopie des Shops auf die neue Version updaten kann und dann später auf diese Kopie switchen kann.

Man muss nicht alle Plugins deaktiveren, aber einfacher ist es. Also eine Kopie (Dateien und Datenbank) anlegen und da alles Plugins deaktiveren. Per SQL-Statement geht es recht schnell und einfach.

Der original Shop liegt in shop/ und der neue in shop65/. Die .env der Kopie (wegen DATABASE_URL) wird in shop_shared/ abgelegt und um LOCK_DSN="flock" und SHOPWARE_SKIP_WEBINSTALLER=1 ergänzen.

Dann das Script laufen lassen.. oder besser Zeile für Zeile per Hand ausführen.

rm -rf ~/public_html/shop65/{*,.*}
composer create-project shopware/production ~/public_html/shop65 "v6.5.0.0" --no-interaction

rsync -avh ~/public_html/shop/files/ ~/public_html/shop65/files/
rsync -avh ~/public_html/shop/public/bundles/ ~/public_html/shop65/public/bundles/
rsync -avh ~/public_html/shop/public/css/ ~/public_html/shop65/public/css/
rsync -avh ~/public_html/shop/public/fonts/ ~/public_html/shop65/public/fonts/
rsync -avh ~/public_html/shop/public/js/ ~/public_html/shop65/public/js/
rsync -avh ~/public_html/shop/public/media/ ~/public_html/shop65/public/media/
rsync -avh ~/public_html/shop/public/sitemap/ ~/public_html/shop65/public/sitemap/
rsync -avh ~/public_html/shop/public/theme/ ~/public_html/shop65/public/theme/
rsync -avh ~/public_html/shop/public/thumbnail/ ~/public_html/shop65/public/thumbnail/
rsync -avh ~/public_html/shop/public/.htaccess ~/public_html/shop65/public/.htaccess
rsync -avh ~/public_html/shop/var/log/ ~/public_html/shop65/var/log/
rsync -avh ~/public_html/shop/config/jwt/ ~/public_html/shop65/config/jwt
rsync -avh ~/public_html/shop/custom/ ~/public_html/shop65/custom/

rsync -avh ~/public_html/shop_shared/.env ~/public_html/shop65/.env

cd ~/public_html/shop65 && composer update
cd ~/public_html/shop65 && bin/console system:update:finish
cd ~/public_html/shop65/vendor/shopware/administration/Resources/app/administration && npm install && cd ~/public_html/shop65

Ziel ist es wieder in die Administration zu kommen und dort alle Plugins zu aktualisieren. Wenn das gelungen ist, dann alle nach und nach wieder aktivieren und wieder die Themes in den SalesChannels einrichten.

Wenn Fehler auftreten immer mal wieder bin/console aufrufen, weil dann die Exceptions meistens ganz gut dargestellt wird.

So kommt man auch sehr gut ohne den Installer zu seinem aktuellen Shopware und räumt auch direkt noch etwas auf.

Shopware 6 Filesysteme nutzen

Arbeiten mit Dateien ist in Shopware 6 an sich recht einfach, gerade seit die Media-Entity und deren Thumbnails ein Path-Feld haben, in dem der relative Pfad direkt angegeben werden kann. Wenn man den hat muss man nur noch den absoluten Pfad bauen. Wenn man z.B. in das public/ Verzeichnis will um dort etwas zu hinterlegen oder ein Media-File zu lesen kann man sich die Umgebungsvariable mit Symfony Project Root per Dependency Injection direkt in den Constructor seines Services geben und von da aus dahin navigieren. Von der aktuellen PHP-Datei aus ist es nicht so toll, da man nicht immer weiß wo das Plugin sich befindet. Z.B: kann es im custom-Folder oder irgendwo in vendor/ sich befinden.

<argument>%kernel.project_dir%</argument>

Und was ist wenn man die Dateien in einem Cluster-Betrieb über ein S3-Bucket an die Cluster-Nodes verteilt? Shopware 6.5 hat zum Glück nicht nur Flysystem dabei, sondern nutzt es auch richtig. Man kann sich direkt per Dependency Injection das privater oder das öffentliche Dateisystem geben lassen und dann ist es egal ob es auf einem FTP, in einem S3 Bucket oder im lokalen Dateisystem liegt.

namespace HPr\FSTest\Services;

use League\Flysystem\FilesystemOperator;
use Shopware\Core\Content\Media\MediaEntity;

class MediaTest {
public function __construct(private FilesystemOperator $filesystem){}

/**
* @throws FilesystemException
*/
public function md5Media(MediaEntity $media): string {
return md5($this->filesystem->read($media->getPath()));
}
}

Um nun das passende Dateisystem zu bekommen ist nicht viel nötig.

Public ist das öffentliche Verzeichnis, das man für Product-Bilder, CMS-Media oder auch andere Downloads nutzen kann, die jeder sehen darf. Dann gibt es auch das private Dateisystem, wo man alles wie Rechnungen und Dinge ablegt, die nicht jeder sahen darf und wo man den Zugriff am besten durch einen eigenen Controller kapselt. Die MediaEntity hat einen private-Flag, um anzugeben in welchem Dateisystem man die Datei findet.

Das Dateisystem selbst kann man in einer YAML-Datei in config/packages/ definieren. Wie man da z.B. seine Dateien in einem MinIO S3 Bucket ablegen kann, habe ich in einem Post vorher schon erklärt.

User	annonyme	Date	2025-10-12 19:27
Tags	ai, hannes pries, jira, mitarbeiter, prompts, senior developer, team, tickets

User	annonyme	Date	2025-10-08 14:57
Tags	ai, hannes pries, job, ki

User	annonyme	Date	2025-10-03 12:19
Tags	arbeit, hannes pries, job, psychologische sicherheit, team

User	annonyme	Date	2025-09-28 16:50
Tags	datenbank, docker, firebird, hannes pries, linux, php

Hannes Pries - Web/Shopware/JavaScript-Developer BlogWeil es immer eine simple Lösung gibt!

Hannes Pries - Web/Shopware/JavaScript-Developer Blog
Weil es immer eine simple Lösung gibt!