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

Warum wir auch im Zeitalter von AI immer noch Frameworks brauchen

In den letzten Wochen habe ich mir aus Neugier per Vibe-Coding eine kleine Chat-Anwendung gebaut. Nichts Großes, nichts Kompliziertes – ein simples PHP-Backend, komplett ohne Framework. Kein Symfony, kein Slim, einfach pures PHP.

Und ganz ehrlich: Es läuft erstaunlich gut.

Für diese kleine Anwendung wäre Symfony völlig überdimensioniert gewesen. Zu schwer, zu viel Ballast. Slim hingegen hätte durchaus gepasst, aber am Ende habe ich mich bewusst dagegen entschieden. Es ging auch ohne Framework problemlos. Genau an diesem Punkt stellt sich fast automatisch eine Frage, die aktuell viele umtreibt: Brauchen wir überhaupt noch Frameworks, wenn AI uns beim Programmieren so stark unterstützt?

Die kurze Antwort lautet: Ja. Die längere Antwort ist etwas differenzierter.

Dank AI ist es heute extrem einfach geworden, kleine Anwendungen schnell zusammenzubauen. Boilerplate-Code, Routing, einfache Logik oder sogar kleinere Sicherheitsmechanismen lassen sich in kürzester Zeit generieren. Für kleine Tools, Prototypen oder Experimente funktioniert das hervorragend. Dadurch entsteht schnell der Eindruck, dass Frameworks vielleicht gar nicht mehr notwendig sind.

Dieser Eindruck hält allerdings meist nur so lange, bis eine Anwendung wächst oder länger gepflegt werden soll.

Frameworks bringen vor allem einen entscheidenden Vorteil mit: Sie bestehen aus Code, der von sehr vielen Menschen genutzt, gelesen und getestet wird. Fehler fallen dadurch schneller auf und werden behoben. Auch wenn AI guten Code generieren kann, erreicht individuell erzeugter Code diesen Reifegrad nicht automatisch. Getesteter, vielfach eingesetzter Code bleibt langfristig stabiler.

Ein weiterer wichtiger Punkt ist Sicherheit. In etablierten Frameworks sind viele Sicherheitsmechanismen bereits sauber integriert. Dinge wie CSRF-Schutz, Input-Validierung, sichere Standardkonfigurationen oder Authentifizierungsmechanismen sind dort kein nachträglicher Gedanke, sondern fester Bestandteil. Ohne Framework muss man jedes Mal selbst überprüfen, ob wirklich alles korrekt umgesetzt wurde und ob man nicht irgendwo eine Lücke übersehen hat. Genau diese Wiederholungsarbeit nehmen einem Frameworks ab.

Auch beim Thema Unterstützung zeigen sich klare Vorteile. Wenn die AI einmal nicht weiterkommt oder eine Lösung nicht sauber funktioniert, ist man mit einem bekannten Framework deutlich besser aufgestellt. Dokumentationen, Blogposts, Stack Overflow, GitHub-Issues – für gängige Frameworks findet man fast immer Hilfe. Bei individuell zusammengeschustertem Code sieht das oft anders aus.

Interessanterweise lassen sich Anwendungen mit einem bekannten Framework oft sogar schneller anpassen – selbst ganz ohne AI. Die klaren Strukturen, Konventionen und Best Practices sorgen dafür, dass Änderungen nachvollziehbar und sauber umgesetzt werden können, ohne jedes Mal neu denken zu müssen.

Bei CMS-artigen Anwendungen gehe ich inzwischen allerdings einen etwas anderen Weg. Hier neige ich dazu, mir mithilfe von AI ein sehr schlankes und schnelles Mini-CMS zu bauen, das exakt auf den jeweiligen Anwendungsfall zugeschnitten ist. Ziel ist dabei immer, dass es so einfach zu bedienen ist, dass ich Inhalte notfalls komplett ohne Programmieraufwand per Hand pflegen kann.

Auf klassische Backends verzichte ich dabei fast immer. Entweder ist das System so simpel, dass ein normaler Editor völlig ausreicht, oder ich nutze direkt einen AI-Agenten, um Inhalte einzupflegen. Ein komplexes Admin-Interface ist in vielen Fällen schlicht nicht mehr notwendig.

Am Ende bleibt ein recht klares Fazit. Ja, wir brauchen auch weiterhin Frameworks. Allerdings dürfen und sollten sie schlanker, technischer und fokussierter werden. Viele klassische WYSIWYG-Editoren lassen sich heute problemlos durch AI-Agenten ersetzen, die Inhalte schneller und konsistenter erstellen. Und Template-Sprachen wie Twig sind nach wie vor hervorragend geeignet, um Content strukturiert zu erstellen und zu pflegen – egal ob per Hand oder mit Unterstützung durch AI. Sie sind klarer, wartbarer und oft angenehmer als reines PHP oder Plain HTML, ohne dass man dafür etwas völlig Neues erfinden muss.

AI verändert massiv, wie wir entwickeln. Sie nimmt uns Arbeit ab und beschleunigt Prozesse. Aber sie ersetzt nicht alles, was sich über Jahre bewährt hat. Frameworks gehören weiterhin dazu – nur eben in einer moderneren, schlankeren Form.

Wenn du willst, passe ich den Stil noch weiter an, mache den Text provokanter, kürzer für Social Media oder technischer für eine Entwicklerplattform.

Veraltete, Microsoft-zentrierte Mindsets in Projekten – ein Problem, das wir endlich benennen sollten

In vielen Projekten begegnet man ihnen noch immer: Word-Dokumenten und Excel-Sheets als zentrales Projektmanagement-Instrument. Oft mit dem Argument verteidigt, dass diese Dateien ja inzwischen in OneDrive liegen, geteilt werden können und damit „modern“ seien. Doch machen geteilte Word-Dokumente ein Projekt wirklich zeitgemäß? Kurz gesagt: nein.

Geteilt heißt nicht strukturiert

Nur weil Word-Dokumente und Excel-Sheets in der Cloud liegen, sind sie noch lange kein modernes Projektmanagement-System. Eine Sammlung von Dateien bleibt eine Sammlung von Dateien – schwer durchsuchbar, schlecht strukturiert und kaum skalierbar. Wer jemals versucht hat, in dutzenden Word-Dokumenten die relevante Information zu finden, weiß, wie ineffizient das ist.

Unübersichtliche Verzeichnisstrukturen verschärfen das Problem zusätzlich. Was in Dateiordnern schnell im Chaos endet, ist in Confluence klar strukturiert: Seitenhierarchien, automatisch aktualisierte Inhaltsverzeichnisse und konsistente Navigation sorgen dafür, dass Wissen auffindbar bleibt – ohne dass bei jeder strukturellen Änderung mehrere Dokumente manuell angepasst werden müssen.

Wissen vernetzen statt Dateien verlinken

Auch das Verlinken zwischen Word-Dokumenten und Excel-Sheets ist in der Praxis umständlich und fehleranfällig. Links brechen, Pfade ändern sich, Versionen driften auseinander. Moderne Wissens- und Projekttools setzen hier an einem anderen Punkt an: Inhalte sind direkt miteinander verknüpft, kontextualisiert und immer aktuell.

Confluence ist kein „besseres Word“, sondern ein Wissenssystem. Jira ist kein „buntes Excel“, sondern ein Projekt- und Prozesswerkzeug mit eingebauter Logik.

Excel ersetzt kein Jira-Board

Ein paar Hintergrundfarben und Filter in Excel machen noch kein Sprint-Board. Jira bringt Scrum- und Kanban-Logik von Haus aus mit: Backlogs, Sprints, Workflows, Abhängigkeiten, Reports. Wer Einträge manuell von einem Excel-Sheet ins nächste kopiert, um Sprints nachzubilden, arbeitet gegen das Tool – und gegen das Projekt.

Das kostet nicht nur Zeit, sondern verhindert Transparenz, Nachvollziehbarkeit und saubere Prozesse.

Eine Frage der Haltung – nicht der Tools

Wer sich heute aktiv weigert, etablierte Tools wie Confluence und Jira zu nutzen, und stattdessen auf lose Sammlungen von Word-Dokumenten und Excel-Sheets setzt, sollte sich ehrlich fragen, ob dieses Mindset noch zur eigenen Rolle passt. Projektarbeit bedeutet Zusammenarbeit, Transparenz und kontinuierliche Verbesserung – nicht das Festhalten an Arbeitsweisen aus den frühen 2000ern.

Gleiches gilt für Teammitglieder, die sich im Projekt konsequent gegen die vereinbarten Tools sperren. Tool-Disziplin ist keine Schikane, sondern eine Voraussetzung für effiziente Zusammenarbeit.

Fazit

Moderne Projekte brauchen moderne Werkzeuge – und vor allem moderne Denkweisen. Microsoft Word und Excel haben ihren Platz, aber nicht als Ersatz für professionelle Projekt- und Wissensmanagement-Systeme. Wer Projekte erfolgreich führen will, sollte nicht nur Prozesse modernisieren, sondern auch alte, bequem gewordene Mindsets hinterfragen.

Storage-Benchmark Script

Ich habe die Aufgabe zu bewerten, ob bestimmte virtuelle Server genau so viel Leistung bringen, wie ein Test-Server, der auf einem Ryzen Mini-PC basiert. Der Anbieter der Software ist sich noch unsicher, ob wir mit einer virtualisierten Umgebung hinkommen, da er bis jetzt immer nicht mit "echten" Server gearbeitet hat.

Dafür habe erstmal eine kleines Script gebaut, um die Storage Performance schnell messen zu können ohne irgendwelche Software installieren zu müssen. Das Script funktioniert unter Debian und Ubuntu (was ja auch ein Debian ist...).

#!/usr/bin/env bash

set -e

# === Konfiguration ===
TEST_DIR="${1:-./disk_test}"
TEST_FILE="$TEST_DIR/testfile.bin"
FILE_SIZE_MB=1024
BLOCK_SIZE_SEQ=1M
BLOCK_SIZE_4K=4K
COUNT_4K=262144 # 4K * 262144 = 1GB
JSON_FILE="disk_benchmark_$(date +%Y%m%d_%H%M%S).json"

mkdir -p "$TEST_DIR"

clear_cache() {
sync
if [ "$EUID" -eq 0 ]; then
echo 3 > /proc/sys/vm/drop_caches
fi
}

measure_time() {
START=$(date +%s.%N)
eval "$1"
END=$(date +%s.%N)
awk "BEGIN {print $END - $START}"
}

echo "Starte Benchmark im Verzeichnis: $TEST_DIR"
echo

# =============================
# Sequential Write
# =============================
echo "Teste Sequential Write..."
clear_cache
TIME_SEQ_WRITE=$(measure_time \
"dd if=/dev/zero of=$TEST_FILE bs=$BLOCK_SIZE_SEQ count=$FILE_SIZE_MB conv=fdatasync status=none")

SEQ_WRITE_MBPS=$(awk "BEGIN {printf "%.2f", $FILE_SIZE_MB / $TIME_SEQ_WRITE}")

# =============================
# Sequential Read
# =============================
echo "Teste Sequential Read..."
clear_cache
TIME_SEQ_READ=$(measure_time \
"dd if=$TEST_FILE of=/dev/null bs=$BLOCK_SIZE_SEQ status=none")

SEQ_READ_MBPS=$(awk "BEGIN {printf "%.2f", $FILE_SIZE_MB / $TIME_SEQ_READ}")

# =============================
# 4K Random Write
# =============================
echo "Teste 4K Random Write..."
clear_cache
TIME_4K_WRITE=$(measure_time \
"dd if=/dev/urandom of=$TEST_FILE bs=$BLOCK_SIZE_4K count=$COUNT_4K conv=fdatasync status=none")

TOTAL_MB_4K=$(awk "BEGIN {print ($COUNT_4K * 4) / 1024}")
WRITE_4K_MBPS=$(awk "BEGIN {printf "%.2f", $TOTAL_MB_4K / $TIME_4K_WRITE}")
WRITE_4K_IOPS=$(awk "BEGIN {printf "%.0f", $COUNT_4K / $TIME_4K_WRITE}")

# =============================
# 4K Random Read
# =============================
echo "Teste 4K Random Read..."
clear_cache
TIME_4K_READ=$(measure_time \
"dd if=$TEST_FILE of=/dev/null bs=$BLOCK_SIZE_4K status=none")

READ_4K_MBPS=$(awk "BEGIN {printf "%.2f", $TOTAL_MB_4K / $TIME_4K_READ}")
READ_4K_IOPS=$(awk "BEGIN {printf "%.0f", $COUNT_4K / $TIME_4K_READ}")

rm -f "$TEST_FILE"

TIMESTAMP=$(date -Iseconds)
HOSTNAME=$(hostname)
KERNEL=$(uname -r)

echo
echo "===== Ergebnisse ====="
echo "Seq Write: $SEQ_WRITE_MBPS MB/s"
echo "Seq Read: $SEQ_READ_MBPS MB/s"
echo "4K Write: $WRITE_4K_MBPS MB/s ($WRITE_4K_IOPS IOPS)"
echo "4K Read: $READ_4K_MBPS MB/s ($READ_4K_IOPS IOPS)"

cat <<EOF > "$JSON_FILE"
{
"timestamp": "$TIMESTAMP",
"hostname": "$HOSTNAME",
"kernel": "$KERNEL",
"test_directory": "$TEST_DIR",
"results": {
"sequential_write_mb_s": $SEQ_WRITE_MBPS,
"sequential_read_mb_s": $SEQ_READ_MBPS,
"random_4k_write_mb_s": $WRITE_4K_MBPS,
"random_4k_write_iops": $WRITE_4K_IOPS,
"random_4k_read_mb_s": $READ_4K_MBPS,
"random_4k_read_iops": $READ_4K_IOPS
}
}
EOF

echo
echo "Ergebnisse gespeichert in: $JSON_FILE"

Es orientiert sich etwas an CrystalDiskBench, aber ist dafür gedacht schnell per SSH und Nano auf dem Server angelegt und dann ausgeführt zu werden.

chmod +x disk_benchmark.sh
./disk_benchmark.sh

Wenn ein AI-Agent zu lange läuft, ist das Problem meist nicht der Agent

Manuel Fuß hat auf LinkedIn kürzlich eine einfache, aber sehr treffende Regel beschrieben: AI-Agenten sollten nie länger als 30 Minuten ohne Stopp und Review laufen. Seine Begründung ist klar: Nach etwa 30 Minuten verliert der Agent den Kontext, die Ergebnisse werden zunehmend unbrauchbar und der Agent beginnt, Dinge zu tun, die nicht mehr sauber zum ursprünglichen Ziel passen.

Dem kann ich mich nur anschließen.

Was passiert, wenn ein Agent zu lange läuft?

Wenn ein AI-Agent über längere Zeit „durchläuft“, ist das in der Praxis fast immer ein Warnsignal. Meist bedeutet das, dass der Agent immer wieder versucht, ein Projekt neu aufzusetzen, dabei scheitert, alles löscht und erneut von vorne beginnt. Häufig trifft er dabei Entscheidungen, die nie explizit gefordert waren, oder produziert immer mehr Code, ohne dem eigentlichen Ziel wirklich näherzukommen.

Ich habe das selbst schon erlebt, zum Beispiel mit gemini-cli. Es war zwar spannend, fast zwei Stunden zuzusehen, wie der Agent immer wieder neue Anläufe unternahm und dabei scheiterte, produktiv war das Ganze aber nicht. Zum Vergleich: JetBrains Junie hat dasselbe Setup später in wenigen Minuten sauber aufgesetzt. Der Unterschied lag nicht in der „Intelligenz“ des Modells, sondern in der Klarheit, Struktur und Begrenzung der Aufgabe.

Lange Laufzeit ist ein Zeichen für schlechtes Feature-Design

Auch bei der Entwicklung von Features ist eine lange Laufzeit des Agents ein deutliches Indiz dafür, dass etwas grundsätzlich nicht stimmt. Kein einzelnes Feature benötigt so viele Code-Änderungen oder neue Tests, dass eine Agent-Laufzeit von mehr als 30 Minuten gerechtfertigt wäre. Da ein AI-Agent sehr schnell Code schreibt, ist eine große Menge erzeugten Codes in kurzer Zeit eher ein schlechtes als ein gutes Zeichen.

Besonders problematisch wird es, wenn der Agent beginnt, neue Libraries einzubinden oder verschiedene technische Ansätze auszuprobieren. Das kostet Zeit, erhöht die Komplexität und sollte in der Regel entweder bereits vorab erledigt sein oder zumindest extrem klar definiert werden. Wenn solche Entscheidungen während der Ausführung offen bleiben, ist ein Scheitern fast vorprogrammiert – nicht weil der Agent schlecht ist, sondern weil die Aufgabe zu unklar gestellt wurde.

Das eigentliche Problem sind zu große, unklare Aufgaben

Der wichtigste Punkt liegt jedoch noch tiefer. Ein Feature, das ein AI-Agent realistisch 30 Minuten oder länger zur Umsetzung benötigt, kann man selbst in der Regel gar nicht vollständig durchdacht haben. Solch große Aufgaben lassen sich kaum präzise genug beschreiben, ohne dass der Agent gezwungen ist, Lücken zu füllen, Annahmen zu treffen und eigene Lösungswege zu erfinden. Genau an diesem Punkt beginnt er, sich zu verselbstständigen.

Das widerspricht eigentlich allem, was wir aus guter Softwareentwicklung kennen. Auch wir Menschen arbeiten in kleinen Iterationen, bauen Funktionen Schritt für Schritt, reviewen regelmäßig unseren Code und passen unsere Pläne an, sobald neue Ideen oder Erkenntnisse entstehen. Genau so sollte man auch mit AI-Agenten arbeiten. Man lässt sie kleine, klar abgegrenzte Schritte umsetzen, überprüft das Ergebnis und verfeinert anschließend sowohl den Code als auch die eigenen Anforderungen.

30 Minuten bedeuten: zurück ins Refinement

Läuft ein Agent 30 Minuten, ohne ein brauchbares Ergebnis zu liefern, dann hat entweder der Agent Fehler gemacht – oder, was deutlich häufiger der Fall ist, die Aufgabe wurde von uns selbst falsch, zu groß oder zu ungenau formuliert. Das ist im Grunde nichts Neues. Früher war es genauso: Wenn ein Entwickler nach einer halben Stunde Herumprobieren bei einem angeblichen „1-Stunden-Ticket“ noch kein Ergebnis hatte, war das Ticket schlicht nicht gut genug und musste zurück ins Refinement.

Ein AI-Agent ist letztlich nichts anderes als ein Entwickler, nur sehr viel schneller. Und genau deshalb gelten für ihn dieselben Regeln wie für menschliche Entwickler. Ist eine Aufgabe zu groß, zu unklar oder widersprüchlich formuliert, kann auch der beste Agent kein gutes Ergebnis liefern.

Fazit

Wenn ein AI-Agent zu lange läuft, sollte man den Lauf stoppen, die Anforderungen kritisch hinterfragen und die Aufgabe neu zuschneiden. In den allermeisten Fällen liegt das Problem nicht zuerst beim Agenten, sondern bei der Art und Weise, wie wir die Aufgabe gestellt haben.

Wer das akzeptiert und bereit ist, wieder zurück ins Refinement zu gehen, bekommt am Ende deutlich bessere Ergebnisse – sowohl von AI-Agenten als auch von menschlichen Entwicklern.

Prompt Engineering ist tot – willkommen im Zeitalter des Denkens

„Prompt Engineering is dead.“
Ein Satz, der provoziert. Und genau das soll er auch.

Kaum war der Begriff Prompt Engineering geboren, wurde er auch schon beerdigt – nur um durch neue Buzzwords ersetzt zu werden:
Context Engineering, Flow Engineering, morgen vielleicht Intent Engineering.
Alles neue Etiketten für etwas, das im Kern nichts Neues ist.

Das große Missverständnis

Die Annahme dahinter:
Man brauche spezielle Menschen, spezielle Rollen, spezielle Fähigkeiten, um mit KI zu arbeiten.
Doch das stimmt nicht.

KI braucht keine „Prompt Engineers“.
Sie braucht Menschen, die klar denken und sauber kommunizieren können.

Prompts sind keine Programmiersprache.
Sie sind keine geheime Kunst.
Und sie sind ganz sicher nichts, was man jahrelang studieren muss.

Wer früher in der Lage war, ein brauchbares Ticket zu schreiben – mit klaren Anforderungen, Use Cases, User Stories und Akzeptanzkriterien – kann heute genauso gut mit einer KI kommunizieren.

Kommunikation schlägt Technik

Was wirklich gebraucht wird, sind keine Entwickler oder Techniker im klassischen Sinn, sondern Menschen, die:

- Gedanken strukturieren können
- Ziele klar formulieren
- Kontext sauber vermitteln
- Feedback geben und iterieren

Kurz gesagt: [n]Menschen, die bewusst und gelenkt kommunizieren können.

Das ist keine neue Fähigkeit.
Das ist eine menschliche Kernkompetenz.

Neue Begriffe machen es nicht besser

Sich ständig neue Begriffe auszudenken, um Wichtigkeit zu simulieren, hilft niemandem.
Im Gegenteil: Es verschleiert, dass sich im Kern nichts verändert hat.

Wenn wir lange genug neue Namen erfinden, merken wir vielleicht irgendwann,
dass dahinter gar kein neues „Fachgebiet“ steckt – sondern einfach Kommunikation.

Und genau deshalb wirkt dieser Trend langsam schon fast lächerlich.

Keine neue Qualifikation – nur ein anderes Mindset

Man braucht keine zusätzliche Ausbildung,
keinen neuen Titel,
keine Zertifizierung.

Man braucht nur das richtige Mindset.

Und das ist nichts, was man „lernen“ kann wie eine Programmiersprache.
Man hat es – oder man entwickelt es durch Denken, Reflektieren und Anwenden.

Das ist auch der eigentliche Vorteil von KI:
Sie demokratisiert Fähigkeiten, statt neue Hürden aufzubauen.

Das Ende der Titel

Vielleicht erleben wir gerade das schleichende Ende vieler Berufsbezeichnungen, die ohnehin immer bedeutungsloser wurden.

Nicht weil Menschen weniger wert sind –
sondern weil das, was zählt, nicht mehr auf dem Titel steht, sondern in der Fähigkeit, klar zu denken und sinnvoll zu handeln.

Und das ist eine ziemlich gute Entwicklung.

Deutsche Standards in der IT: Neuer Name, alte Technik, viel Aufwand

Wer in Deutschland IT-Systeme entwickelt und dabei rechtlich auf der sicheren Seite sein möchte, muss eine Vielzahl an Standards einhalten. An diesen wird seit Jahren, teils seit Jahrzehnten, intensiv gearbeitet. Die Einführung neuer Regelwerke ist häufig langfristig geplant, zieht sich über mehrere Jahre und bindet erhebliche Ressourcen. Dabei ist eines auffällig: Die Anwendungsfälle, die diese Standards abdecken sollen, sind in der Regel nicht neu. Für fast alle existieren bereits seit Langem etablierte und praxiserprobte Lösungen – meist auf internationaler Ebene.

Trotzdem scheinen internationale Standards in Deutschland oder der EU oft nicht auszureichen. Statt auf Bewährtes aufzubauen, werden eigene nationale oder europäische Varianten geschaffen. Der Anspruch dahinter ist meist, es „besser“ und „sicherer“ zu machen als der Rest der Welt. In der Praxis bedeutet das jedoch, dass bestehende Konzepte neu verpackt werden. Etwas komplett neu zu entwickeln kostet Zeit und Geld – Ressourcen, die bei deutschen Standards häufig weniger in technische Innovation als in politische Abstimmungen, Gremienarbeit und Meetings fließen.

Die eigentliche Entwicklung soll dann möglichst schnell und günstig erfolgen. Gleichzeitig sind IT-Fachkräfte selten daran interessiert, funktionierende Konzepte neu zu erfinden. Das Ergebnis sind komplexe Konstrukte mit neuen Namen, umfangreichen Spezifikationen und schwer verständlicher Dokumentation. Allein die Namensfindung scheint oft schon ein eigenes Projekt zu sein.

Geht man tiefer in die technischen Details, stößt man jedoch immer wieder auf alte Bekannte. XRechnung basiert letztlich auf XML-Standards wie UN/CEFACT oder UBL von OASIS. KIM, der „sichere“ Kommunikationsdienst zwischen Ärzt:innen und Laboren, nutzt im Kern S/MIME. Qualifiziert signierte elektronische Rechnungen waren bereits vor Jahren nichts anderes als signierte PDFs auf Basis etablierter Kryptostandards. Neu ist daran meist nur das Drumherum.

Problematisch ist, dass diese Zusammenhänge selten offen benannt werden. Hinweise auf die zugrunde liegenden Standards sind oft gut versteckt und werden nie klar kommuniziert. Statt direkt auf öffentliche Spezifikationen zu verweisen oder die Unterschiede sauber zu erklären – etwa bei Pflichtfeldern oder Prozessen – wird alles in eigenen Dokumenten neu beschrieben. Das erschwert die Implementierung unnötig und kostet Entwickler:innen viel Zeit und Nerven.

Am Ende bleibt der Eindruck, dass enorm viel Arbeit und Geld investiert wird, nur um nicht zuzugeben, dass internationale Standards oft genauso gut sind – und in vielen Fällen seit Jahren voraus. Leidtragende sind vor allem diejenigen, die diese Vorgaben umsetzen müssen.

Sei kein Arschloch (auch nicht als Chef)

Wer glaubt, dass in einem Team immer jemand „das Arschloch sein muss“, hat Teamarbeit nicht verstanden. Respektvolle, freundliche Kommunikation ist keine nette Zugabe, sondern eine der wichtigsten Fähigkeiten von Führungskräften. Je länger man arbeitet und je weiter man im Job aufsteigt, desto entscheidender werden Soft Skills. Druck erzeugt keine besseren Ergebnisse – Stress ist der Feind von Qualität.

Gute Führung beginnt bei einem selbst. Wenn etwas schiefläuft, sollte man zuerst die eigenen Fehler suchen: unklare Erwartungen, schlechte oder unvollständige Kommunikation. Niemand kann Gedanken lesen. Wer verstanden werden will, muss seine Gedanken klar in Worte fassen und sicherstellen, dass sie auch ankommen. Eigene Unsicherheit oder Wut am Team auszulassen, rächt sich schneller, als man denkt. Fehler einzugestehen und sich zu entschuldigen ist immer der bessere Weg, als in eine Eskalationsspirale zu geraten.

Ein Chef unterstützt sein Team, statt nur zu diktieren oder Fehler zu bestrafen. Er stellt sich vor seine Leute, schützt sie und schiebt nicht proaktiv Schuld weiter, um selbst gut dazustehen. Wenn Aufgaben wiederholt falsch laufen oder nicht fertig werden, ist das meist ein strukturelles Problem – kein persönliches. Genau daran kann man gemeinsam arbeiten, zum Beispiel mit klaren Prozessen, Definition of Ready und Definition of Done. Am Ende gilt: Jeder gibt sein Bestes. Das sollte man anerkennen und gemeinsam nach Lösungen suchen, wenn mal etwas schiefgeht.

Warum Linux in Unternehmen oft nicht am Betriebssystem scheitert

Die Diskussion rund um Windows 11 und vermeintlich „zu alte“ Hardware greift häufig zu kurz. Technisch ist längst klar: Viele Linux-Distributionen laufen stabil, sicher und performant auf Hardware, die von Windows offiziell nicht mehr unterstützt wird. Trotzdem bedeutet das nicht automatisch, dass Unternehmen problemlos auf Linux umsteigen können.

Das eigentliche Problem ist selten eine grundsätzliche Ablehnung von Linux in IT-Abteilungen. Im Gegenteil: Linux ist dort allgegenwärtig – auf Servern, in der Cloud und in der Infrastruktur. Die Hürde liegt fast immer woanders: bei gewachsener, oft selbstgebauter Legacy-Software.

In vielen Unternehmen existieren Anwendungen, die gerade noch unter Windows 10 funktionieren, aber stark an die Windows-Plattform gebunden sind. Native Win32-Programme, hart kodierte Pfade, Abhängigkeiten von Netzlaufwerken, speziellen Druckertreibern oder einer lokal installierten Office-Version sind keine Ausnahme. Für solche Software ist Linux – selbst mit Wine – entweder keine realistische Option oder nur mit unverhältnismäßig hohem Aufwand.

Hinzu kommt Drittanbieter-Software, für die es außerhalb von Windows keinen Support gibt. Selbst wenn eine Anwendung technisch lauffähig wäre, fehlt oft die rechtliche oder vertragliche Absicherung. In produktiven Umgebungen ist das ein entscheidender Faktor.

Unternehmen, die frühzeitig auf browserbasierte Anwendungen gesetzt haben, sind hier klar im Vorteil. Wenn der Arbeitsalltag vollständig im Web stattfindet und ein aktueller Chrome oder Firefox genügt, wird das Betriebssystem weitgehend irrelevant. In diesen Fällen ist Linux auf dem Desktop tatsächlich eine sehr realistische Alternative.

Der oft zitierte Vendor-Lock-in ist daher weniger ein Problem einzelner Hersteller als das Ergebnis jahrelanger Architekturentscheidungen. Wer sich heute schwer tut, ist meist nicht von außen gezwungen worden – sondern hat sich das Problem selbst gebaut.

KI: Kleine Modelle, große Qualität, hohes Risiko?

Ich habe mir Z-Image Turbo 6B einmal etwas angesehen und meine typischen Testbilder durchgejagt (bzw. eher darauf gewartet). Die Tests sind jetzt nicht groß ausgefeilt oder erzeugen irgendwelche wirklich messbaren Resultate außer Sekunden pro Bild. Ich hatte abends einfach etwas Zeit, Z-Image war noch sehr neu und ich habe SwarmUI gestartet, geupdatet und dann die größte GGUF heruntergeladen, weil selbst die größte Variante noch in den Speicher meiner alten GTX 1070 mit 8 GB VRAM passt. Ein Bild dauerte dann so um die 4–5 Minuten. Ich hatte keine Lust, noch auf dem Linux-Rechner mit der RTX 5060 Ti 16 GB zu testen, die dann bestimmt bei gut unter einer Minute gelegen hätte.

Die Qualität ist wirklich gut. Es steht in Qualität und Prompt-Verständnis Flux1, Hunyuan oder Qwen-Image in nichts nach und übertrifft diese teilweise sogar in meinen Versuchen. Es soll nicht zensiert sein, wobei ich da nicht wirklich etwas getestet habe—nur so viel, dass es mehr zulässt als Nano Banana in seinen ersten Ausführungen (was teilweise einfach lächerlich war, wenn man anstelle von „Zauberin“ „erwachsene Zauberin“ schreiben musste, weil der Prompt sonst als zu risikoreich eingestuft wurde). Beeindruckend ist auch die Geschwindigkeit und die geringe Größe des Modells. Zuletzt brauchten Bilder mit der GTX 1070 und modernen Modellen gerne mal bis zu 45 Minuten pro Bild. Mit Z-Image kann man nun sehr kostengünstig und lokal Bilder erstellen, ohne Geld für irgendwelche Cloud-Dienste ausgeben zu müssen oder auf zensierte Services von Meta.ai, OpenAI oder anderen bekannten Anbietern setzen zu müssen. Das bedeutet aber natürlich auch, dass diese Bilder ohne Wasserzeichen oder andere Markierungen erstellt werden können.

Sora-Videos waren zuerst wirklich gut zu erkennen, weil eben direkt im Video stand, dass sie damit erstellt wurden. So sah man schnell, welche Art und welche Styles so ein Video ausmachen, und man konnte Sora-Videos recht schnell auch ohne Markierung als solche erkennen. Natürlich nur für kurze Zeit, weil auch Sora immer besser wird und die Leute mit den Standard-Templates und Prompts irgendwann durch sind und selbst anfangen, damit zu experimentieren. Wenn es nach der EU geht, soll ab August 2026 jedes Werk, das mit Hilfe von KI erzeugt wurde, als solches gekennzeichnet sein, wenn es nicht sowieso schon als nicht real erkennbar ist. Ein Anime-Video wird also nicht gekennzeichnet werden müssen (was bestimmten Studios, die durch bestimmte Stile bekannt wurden, sicher auch nicht gefallen dürfte, um Fanarts eindeutig zu erkennen). Wenn alles über die großen Anbieter läuft, ist es nicht schwer, Markierungen in Bildern, Videos oder auch Musik unterzubringen. Privat kann man sich auch einen Workflow bauen, der so etwas einbringt. Aber die Personen, die bewusst etwas generieren, um Schaden oder Unsicherheit zu erzeugen, werden sich nicht daran halten. Sie hätten entweder die Marker wieder entfernt oder sich einen Service gesucht, der bewusst so etwas nicht einbaut (also China, Osteuropa, Asien… alles nicht EU). Jetzt geht es super auch zuhause, ohne viel Geld in Hardware investieren zu müssen.

Oft wird auch schon gesagt, dass wir nun in eine Zeit geraten, in der man Bildern und Videos generell nicht mehr glauben kann. Das sind wohl Leute, die die letzten 30 Jahre Photoshop verschlafen haben, denn man konnte schon lange keinem Bild mehr glauben und auch Videos waren schon vor AI nicht mehr allzu schwer zu manipulieren. Jetzt geht alles super einfach und super schnell. Im Internet konnte man also schon fast von Anfang an keinem Text oder Bild vertrauen, das man dort sah. Man musste die Quelle kennen, sonst musste man immer einen Restzweifel behalten.

Aber bringt es jetzt etwas, EU-Gesetze auf den Weg zu bringen, die an sich genau das machen wollen, womit man schon bei digital bearbeiteten Fotos gescheitert ist? Wie oft sollte es Marker für mit Photoshop bearbeitete Bilder geben, um Fakes oder zu sehr „aufgehübschte“ Bilder von Schauspielern und Models kenntlich zu machen? Oft – und nie haben sich mehr als eine Handvoll von Medienunternehmen (teilweise) daran gehalten. Diese Unternehmen konnten sagen, sie tun etwas für die Transparenz und den Schutz von Kindern und Menschen allgemein… meistens genau so lange, bis doch bei einem Foto etwas nachgeholfen wurde und sie dann „aus Versehen“ vergaßen, das Bild korrekt zu markieren.

Ich halte diese Gesetze nicht nur für nicht durchsetzbar, sondern auch für recht gefährlich, weil damit den Menschen suggeriert wird, es werde etwas gegen KI-Fakes getan und sie wären nun sicher davor und könnten diese immer erkennen. Aber da sich maximal die Unternehmen in der EU daran halten, ist das Fehlen eines Markers kein Indiz für die Echtheit. Man kann vielleicht einige Bilder und Videos eindeutig als KI-generiert erkennen, aber beim großen Rest kann man es immer noch nicht sicher sagen. Die markierten Bilder sind die, die auch vorher schon in den Bildunterschriften als solche geführt worden sind. Bilder, die eine Gefahr darstellen, werden weiterhin keine Marker erhalten und es ändert sich einfach nichts. Lieber sollte man sich die Energie sparen, um Modelle zu zensieren oder den Output mit Markern zu versehen, und akzeptieren, dass wir schon sehr bald in einer Zeit leben werden, in der es so gut wie unmöglich sein wird, die Echtheit eines Bildes oder Videos zu bestimmen, ohne dessen Kontext und Quelle zu kennen. Es ist auch nicht die Qualität allein, die noch steigt, sondern die Menge an hochqualitativem Output. Menschen müssen lernen, das, was sie lesen, sehen oder hören, selbst zu bewerten und nach gesundem Menschenverstand einer eigenen Risikobewertung zu unterziehen.

Es gibt auch Vorteile. Geleakte Nacktfotos kann man nicht mehr als wirklich echt identifizieren, weil es ja KI sein könnte. Es geht also in beide Richtungen. Man muss skeptisch sein und auch bleiben. Man muss hinterfragen und bewerten. Kein EU-Gesetz kann einem das abnehmen.

Debugging und Fixing mit KI – warum der schwierigste Teil oft bei uns bleibt

Code mit einem KI-Agenten zu schreiben, geht heute unglaublich schnell. Viele Ergebnisse sind auf Anhieb fehlerfrei, und selbst komplexere Funktionen stehen manchmal in Minuten. Trotzdem gibt es einen Bereich, in dem KI für mich noch deutlich schwächelt: Debugging.

Oft schaue ich auf einen Fehler und sehe sofort, was falsch gelaufen ist – manchmal verrät mir die Fehlermeldung schon alles. In solchen Fällen ist es schneller, den Fix selbst einzubauen, anstatt die KI mehrere Versuche machen zu lassen. Gerade bei Layout- oder Template-Anpassungen ist das ähnlich: Ein kleiner Style-Tweak ist meist manuell schneller erledigt, als der KI umständlich zu erklären, was sie tun soll.

Für die Fehlersuche nutze ich deshalb lieber einen klassischen KI-Chat, statt meinen Code-Agenten weiter herumprobieren zu lassen. Zu oft habe ich erlebt, wie eine KI zwischen zwei Fehlerzuständen pendelt, ohne wirklich weiterzukommen.

Mittlerweile folge ich einer einfachen Regel:

- Wenn ich genau weiß, was falsch ist: Fixe ich es selbst – solange es nur eine kleine Stelle ist.
- Wenn ich die Lösung klar beschreiben kann: Dann darf die KI ran.
- Wenn ich den Fehler erst verstehen muss: Schaue ich erst selbst tiefer rein, bevor ich entscheide.

Ich lasse mir auch lieber ein komplettes Feature von der KI bauen und teste es anschließend Schritt für Schritt, anstatt jeden kleinen Codeschnipsel einzeln durchzugehen. Am zuverlässigsten funktioniert das Ganze, wenn ich vorher sehr klar weiß, was ich will und wie es funktionieren soll. Die KI ist vielleicht nicht die beste Ideengeberin für neue Features – aber sie schreibt Code nun mal viel schneller, als ich es könnte.

Am Ende bleibt für mich: KI ist der Next-Generation Coding Monkey – extrem fleißig, extrem schnell, aber manchmal braucht es doch den Menschen, um Fehler wirklich zu verstehen und zu beheben.

KI: Der Verlust jeglicher Individualität

Es scheint im Internet grob zwei Arten von KI-Experten zu geben: Diejenigen, die KI nutzen, und diejenigen, die vor KI und ihren Folgen warnen. Letzteres wirkt auch sehr typisch deutsch, denn es wird sich selten umfassend mit dem Thema beschäftigt. Stattdessen konzentriert man sich fast ausschließlich auf die Gefahren und negativen Auswirkungen, die KI hat oder haben könnte. Es wird untersucht, wie sich diese negativen Auswirkungen auf die Gesellschaft auswirken werden, ohne vorher zu überprüfen, ob die angenommene Ursache überhaupt existiert.

Ein Beispiel ist die Behauptung, KI würde jegliche Individualität zerstören, weil sie angeblich immer nur die häufigste Antwort liefert und alle anderen Antworten verwirft. Die Annahme wäre etwa: Man fragt die KI, wie man eine Homepage baut, und erhält grundsätzlich die Antwort, man solle WordPress verwenden, weil die meisten Seiten darauf basieren. Oder das PHP-Framework wäre immer Symfony.

Jeder, der wirklich mit KI gearbeitet hat und nicht nur ein paar oberflächliche Fragen stellt, um sich in der eigenen Ansicht über die angeblichen Gefahren zu bestätigen, weiß, dass eine KI extrem differenzierte Vorschläge liefern kann. Sie findet sehr passende Lösungen, wenn man ihr den nötigen Kontext liefert. Oft liefert sie sogar Lösungen, von denen man selbst noch nie gehört hat.

Das eigentliche Problem ist, dass viele Menschen Schwierigkeiten damit haben, klar zu formulieren, was sie brauchen oder möchten. Selbst Suchmaschinen überfordern viele schon deutlich – und eine KI sinnvoll zu nutzen erfordert noch mehr Fähigkeit, den eigenen Wunsch oder die eigene Frage präzise auszudrücken. Auch ein Mensch kann nur allgemeine Antworten geben, wenn die Frage allgemein formuliert ist. „Womit baue ich mir eine Homepage?“ ist eben keine besonders hilfreiche Frage, wenn man eine auf den konkreten Anwendungsfall zugeschnittene Antwort erhalten möchte. Dennoch wird die Antwort der KI dann schnell als unzulänglich bewertet, weil sie beispielsweise kein Shopsystem nennt – obwohl gar nicht danach gefragt wurde.

Solche Situationen gab es früher schon im menschlichen Austausch: Manche bezeichneten einen sofort als unfähig oder meinten, man würde seinen Beruf nicht beherrschen, nur weil man nicht die Antwort geliefert hat, die nie gestellt, aber trotzdem erwartet wurde.

Wer also nur allgemeine Antworten von einer KI erhält, sollte zuerst seine eigenen Fragen und Prompts überprüfen. Eine KI kann keine Gedanken lesen.

Google liefert inzwischen sehr viel schneller nur noch allgemeine Ergebnisse – selbst bei komplexeren Suchbegriffen – während eine KI den bereitgestellten Kontext nutzen kann, um genau dieses Problem zu umgehen.

Eine alte Weißheit

Pika-Dollar vs. Digitales Gold: Eine FinTech-Analyse, warum Ihr Glurak Holo die bessere (oder schlechtere) Währung ist als Bitcoin

geschrieben von Gemini 2.5-fast mit deep-reasearch

Willkommen, liebe Nerds und Investoren mit Hang zur Nostalgie, zu einer Analyse, die wir in den Tiefen der Finanztheorie und den feuchten Kartons der Kindheit verankert haben. Die Frage ist so absurd wie millionenschwer: Kann der bedruckte Karton, der einst auf Schulhöfen seinen Wert bewies, heute tatsächlich mit dem rechenintensiven, dezentralen Code von Bitcoin konkurrieren? Können Pokémon-Karten als alternative Währung – der sogenannte „Pika-Dollar“ – gelten und sind sie dem „Digitalen Gold“ überlegen?

Diese Abhandlung wird zeigen, dass beide Märkte – der physische Sammlermarkt und die Kryptosphäre – primär von zwei Dingen angetrieben werden: dem Glauben an künftige Knappheit und der „Greater Fool Theory“. Um diesen absurden Vergleich jedoch ernsthaft zu führen, müssen wir beide spekulativen Assets an den drei klassischen Säulen der monetären Ökonomie messen :

Wertspeicher (Store of Value, SoV): Behält der Vermögenswert seinen Wert stabil oder erhöht er ihn sogar über lange Zeiträume?

Tauschmittel (Medium of Exchange): Kann man damit Waren und Dienstleistungen erwerben, ohne dass die Transaktionskosten astronomisch sind?

Recheneinheit (Unit of Account): Kann man Preise und Schulden darin bemessen (z. B. 1 Glurak für 5 Pizzas)?

Die folgende Tabelle bietet eine erste nüchterne, wenn auch zynische, Zusammenfassung der Stärken und massiven Schwächen beider Spekulationsobjekte:

Monetäre Eignungsprüfung: Pokémon vs. Bitcoin

Monetäre Metrik	Pokémon Karte (PSA 10)	Bitcoin (BTC)	Analyse
Fungibilität (Austauschbarkeit)	Niedrig (Jede Karte ist einzigartig/seriell)	Hoch (Jeder BTC ist wie der andere)	Sie können eine Münze nicht durch einen Picasso ersetzen.
Teilbarkeit (Divisibility)	Extrem Niedrig (Kein Schneiden erlaubt!)	Hoch (Bis zu 8 Dezimalstellen: Satoshis)	Pokémon: All-in. Bitcoin: Kleingeld für den Kaffee.
Wertspeicher (Store of Value)	Hoch (Generationelle Nostalgie, Rarity)	Hoch/Mittel (Volatil, aber deflationäres Design)	Sammlerwert vs. Code-basiertes Versprechen.
Tauschmittel (Medium of Exchange)	Sehr Niedrig (Zu hoher Aufwand/Kosten)	Mittel (Wird akzeptiert, aber oft langsam)	Versuchen Sie, an der Tankstelle mit Glurak zu bezahlen.
Recheneinheit (Unit of Account)	Nein (Wert in USD/EUR festgelegt)	Ja (Wert direkt in BTC/Satoshis)	Eine Währung muss sich selbst zählen können.

Akt I: Der Karton-Standard – Pokémon im monetären Leistungstest

Der Wertspeicher der Träume: Seltenheit und Höchstpreise
Der Pika-Dollar hat unbestreitbar bewiesen, dass er als exzellenter Wertspeicher fungieren kann, zumindest für jene, die in der Lage sind, die extremsten Sammlerstücke zu erwerben und zu halten. Das Paradebeispiel für diese extreme, durch Sammlerwahn getriebene Wertspeicherung ist die legendäre Pikachu Illustrator Karte von 1998. Im Jahr 2022 erwarb der Influencer Logan Paul das einzige bekannte Exemplar mit der Bestnote PSA 10 zu einer astronomischen Bewertung von 5,275 Millionen USD. Er zahlte dafür 4 Millionen USD in bar und tauschte eine PSA 9-Version derselben Karte ein – ein Tauschgeschäft, das die Tiefe und Exklusivität dieses Marktes beweist.

Auch andere „Blue Chips“ des Kartonuniversums wie der 1st Edition Shadowless Charizard Holo von 1999 in PSA 10 beweisen mit Verkaufspreisen von bis zu 420.000 USD, dass der Wert über Jahrzehnte massiv steigen kann. Wie Gold und Bitcoin besitzt der Pika-Dollar eine schwere reproduzierbare Knappheit. Allerdings hängt der Wert des Kartons nicht nur von der ursprünglichen Auflage (Druck) ab, sondern kritisch von der Qualität des physischen Zustands. Genau hier beginnt die hochgradig zentrale Abhängigkeit.

Die Diktatur der Grade: PSA als Zentralbank des Kartons
Während Bitcoin sein Vertrauen durch dezentrale, mathematische Konsensmechanismen (Proof-of-Work) schafft , basiert der Pika-Dollar auf dem Vertrauen in eine zentrale, menschliche Autorität: die Grading-Häuser wie PSA und BGS.

Die Jagd nach dem PSA 10 (Gem Mint) ist der Motor dieses Marktes. Analysten bestätigen, dass ein kleiner, scheinbar unwesentlicher Unterschied im Zustand – beispielsweise eine Frontzentrierung zwischen 55/45 und 60/40 – den Wert einer Karte von Tausenden auf Hunderttausende Dollar katapultieren kann. Der Wert eines Assets hängt hier exponentiell von einem einzigen, subjektiven (wenn auch standardisierten) Urteil einer zentralen Instanz ab.

Dieser Mechanismus, bei dem PSA die Echtheit (Authentifizierung) und den Zustand (Qualitätsstufe) zertifiziert und die Karte in einem versiegelten Case kapselt, fungiert im Grunde als eine hochgradig zentralisierte, physische Blockchain. Sie stellt den Konsens über den Wert her, jedoch nicht durch Code, sondern durch menschliche Experten und proprietäre Prozesse. Im Jahr 2020 führte die enorme Nachfrage und der daraus resultierende Bearbeitungsstau bei PSA dazu, dass die Firma neue Einreichungen zeitweise stoppen musste. Dies verdeutlicht einen zentralen Single Point of Failure: Die dezentrale Natur des Sammelns endet, sobald die Wertmaximierung beginnt und auf die Legitimation durch einen Mittelsmann angewiesen ist. Bitcoin verspricht die Abschaffung des Mittelsmanns; Pokémon-Karten brauchen ihn zur Wertmaximierung.

Fungibilität und Teilbarkeit: Das Glurak-Problem
Der zentrale monetäre Makel des Pika-Dollars ist seine fundamentale Nicht-Fungibilität. Per Definition ist eine gegradete Karte PSA 10 ein einzigartiges Gut (Non-Fungible). Selbst zwei identische 1st Edition Shadowless Charizard PSA 10 Karten könnten aufgrund minimaler, nicht erfasster Sub-Grades oder ihrer jeweiligen Auktionshistorie unterschiedliche Preise erzielen. Diese Einzigartigkeit widerspricht dem fundamentalen Prinzip des Geldes, bei dem ein $10-Schein exakt dem Wert von zwei $5-Scheinen entsprechen muss, unabhängig von der Seriennummer.

Noch schlimmer ist das Problem der fehlenden Teilbarkeit (Divisibility). Moderne Finanzinstrumente wie Kryptowährungen sind hochgradig teilbar (BTC bis zu acht Dezimalstellen, genannt Satoshis). Eine Pokémon-Karte hingegen ist ein monolithisches Gut. Man kann nicht mit einem Viertel eines Glurak bezahlen, ohne den Wert der gesamten Karte auf null zu reduzieren. Die Währung ist unflexibel und verlangt einen All-in-Handel. Alleine die Logistik spricht Bände: Wenn ein modernes Pokémon-Booster-Pack etwa $4 kostet, bräuchten Sie 1.318.750 Booster-Packs, um theoretisch den Wert des $5,275 Millionen Pikachu Illustrator zu erreichen. Das ist ein massives Skalierungs- und Teilbarkeitsproblem.

Akt II: Das Digitale Dungeon – Bitcoin in der Wirtschaftsprüfung

Dezentralität als Glaubenssatz: Das Vertrauen in Code
Bitcoin trat an, um die Mängel traditioneller, staatlich kontrollierter Fiat-Währungen zu beheben, deren Wert auf dem Vertrauen in eine Zentralbank beruht. Bitcoin bietet einen staatlich unabhängigen Wertspeicher, dessen Knappheit und Ausgabe durch ein dezentrales, transparentes Code-Protokoll garantiert werden.

Allerdings leidet Bitcoin unter einem gravierenden Mangel, der seine Eignung als tägliches Tauschmittel empfindlich beeinträchtigt: extreme Volatilität. Die dramatischen Preisschwankungen, oft als Reaktion auf makroökonomische Ereignisse oder reine Spekulation, sind legendär. Nach dem Zusammenbruch einer großen Kryptowährungsbörse fiel der Wert von Bitcoin beispielsweise an einem einzigen Tag um 22%. Solche Schwankungen sind bei stark regulierten traditionellen Währungen undenkbar. Eine derart volatile Währung wird ohne staatlichen Zwang (der die Zahlung von Steuern in dieser Währung verlangt) kaum als Tauschmittel akzeptiert.

Der Umwelt-Footprint: Schürfen vs. Zocken (PoW vs. Pack-Odds)
Der Konsensmechanismus von Bitcoin, Proof-of-Work (PoW), erfordert erhebliche Rechenleistung, um Transaktionen zu validieren und die Blockchain zu sichern. Diese energieintensive Methode ist notorisch ineffizient; Bitcoin verbraucht schätzungsweise 127 Terawattstunden pro Jahr, was den Energiebedarf ganzer Länder wie Norwegen oder Argentinien übersteigt. Darüber hinaus sind PoW-Netzwerke systembedingt langsam (im Durchschnitt 10 Minuten pro Block), was sie für alltägliche Transaktionen, verglichen mit modernen Proof-of-Stake (PoS)-Systemen (z. B. Ethereum nach dem Merge, 12 Sekunden), unpraktisch macht.

Diese Energie- und Ressourcenverschwendung bei Bitcoin findet eine zynische Entsprechung im Sammelmarkt. Bitcoin-Mining ist ein brutaler, hochtechnisierter Wettbewerb um einen zufälligen Block-Reward, der auf der Erbringung von "Arbeit" (Rechenleistung) basiert. Sammler betreiben einen ähnlichen, wenn auch analogen, "Mining"-Prozess. Der Kauf von Pokémon-Booster-Packs ist eine statistische Lotterie. Um die seltensten Assets zu "schürfen", müssen Sammler große Mengen an statistisch wertlosen Karten ansammeln. Die Wahrscheinlichkeit, eine seltene "Hyper Rare" Karte zu ziehen, liegt bei etwa 1 zu 137 Packs.

Das Ergebnis ist in beiden Fällen dasselbe: Ein hoher Ressourceneinsatz (Energie/Geld für PoW oder Packungen/Zeit für das Sammeln und Graden) führt zur Generierung eines extrem seltenen, hoch bewerteten Assets. Beide Assets basieren auf einem impliziten Proof-of-Waste-Mechanismus, der lediglich die künstliche Knappheit zementiert.

Die Logistik des Vermögens: Feuer, Schimmel und die verlorene Seed Phrase

Die Lagerung und Sicherung dieser alternativen Vermögenswerte offenbart einen fundamentalen Gegensatz in der Risikostruktur. Der Anleger muss wählen, ob er gegen die Gesetze der Thermodynamik oder gegen sein eigenes schlechtes Gedächtnis kämpfen will.

Physische Bedrohungen: Der Feind ist die Luftfeuchtigkeit
Im Gegensatz zu digitalem Code oder unzerstörbaren Goldbarren sind Pokémon-Karten anfällig für physische Zerstörung. Die Durabilität ist ein ernstes Problem. Umwelteinflüsse stellen eine erhebliche Bedrohung dar. Hohe Luftfeuchtigkeit kann zu Verformung (Warping) und Schimmel führen, während UV-Strahlen die Farben verblassen lassen. Der Sammler muss de facto zum Amateur-Archivar werden und spezielle Lagerlösungen nutzen, wie Silica-Gel-Päckchen in Binders.

Katastrophenrisiken potenzieren diese Gefahr. Berichte zeigen, dass bei einem Hausbrand die Karten, die nicht verbrannten, durch Rauch- und Wasserschäden – oft "nasty water" – vollständig zerstört wurden. Der Wert des Pika-Dollars hängt davon ab, ob man ihn trocken, kühl und UV-geschützt lagern kann.

Digitale Katastrophen: Ein Tippfehler trennt Sie von 8.000 BTC
Bitcoin-Investitionen erfordern absolute, fehlerfreie digitale Selbstverwaltung (Self-Custody). Das größte Risiko bei Kryptowährungen ist nicht die Volatilität, sondern das kognitive Versagen des Nutzers.

Im Web3-Bereich gibt es keine Bank oder Behörde, die ein verlorenes Passwort zurücksetzen könnte. Der Verlust der Seed Phrase (Passwort) bedeutet, dass die Kryptowährung unwiederbringlich "GONE for Good" ist. Der Fall von James Howells, der eine Festplatte mit 8.000 BTC in den Müll warf und damit Hunderte von Millionen verlor, ist ein permanentes Mahnmal. Digitale Assets erfordern Schutz vor Hacking-Angriffen und vor allem vor dem eigenen Vergessen. Der Anleger muss wählen, ob er lieber gegen Schimmel oder gegen sein eigenes schlechtes Gedächtnis kämpft – beide Szenarien erfordern einen enormen logistischen Aufwand und spezialisierte Sicherheitsmaßnahmen.

Die FinTech-Fusion: Wenn Glurak zum Token wird

Die inhärenten monetären Mängel der physischen Pokémon-Karte – mangelnde Fungibilität, fehlende Teilbarkeit und geringe Liquidität – haben zur Entstehung einer neuen FinTech-Infrastruktur geführt, die versucht, diese Probleme zu beheben.

Tokenisierung als Heilmittel für monetäre Mängel
Die Tokenisierung ist ein klares Eingeständnis, dass die physische Karte selbst als Tauschmittel unzureichend ist. Plattformen wie Collector Crypt überbrücken diese Kluft, indem sie physische, durch PSA oder BGS gegradete Karten in sicheren, klimakontrollierten Tresoren lagern (Vaulting, z. B. bei PWCC) und das Eigentumsrecht als handelbares NFT auf einer Blockchain (z. B. Solana) verbriefen.

Diese digitale Transformation schafft Eigenschaften, die der physische Karton niemals bieten konnte:

Liquidität: Der 24/7 globale Handel der Tokens ist ohne physischen Versand möglich, wodurch Transaktionsrisiken eliminiert werden.

Fungibilität und Teilbarkeit: Fraktionalisierung ermöglicht es, Tausende von ERC-20 Tokens zu erstellen, die einen einzigen, hochpreisigen Glurak repräsentieren. Dies macht den Wert teilbar und liquide, und Preis-Orakel können einen zuverlässigen Echtzeitwert der Karte bereitstellen.

Burn-to-Redeem: Der digitale Besitzer kann das NFT "verbrennen" (Burn-Transaktion) und die physische Karte gegen eine Gebühr (typischerweise 2%) aus dem Tresor anfordern, was die physische Unterlegung garantiert.

Karten als Kreditsicherheit: Der Sprung ins DeFi
Der höchste finanzielle Nutzen, den Pokémon-Karten in der modernen Ökonomie erreichen können, liegt nicht in ihrer Verwendung als Währung, sondern als Sicherheit (Collateral).

Hochwertige, gegradete Karten werden zunehmend als Pfand für Kredite genutzt. Sowohl traditionelle Kreditgeber (z. B. Qollateral) als auch dezentrale Finanzplattformen (DeFi) arbeiten daran, Sammlerstücke als Pfand zu akzeptieren, um dem Eigentümer Liquidität zu verschaffen, ohne dass dieser das Asset verkaufen muss.

Diese Entwicklung klassifiziert die Karte als Real World Asset (RWA). Die Karte ist die illiquide, aber wertstabile Reserve, während der aufgenommene Kredit (der in Fiat oder Stablecoins ausbezahlt wird) die funktionale Tauschwährung darstellt. Dies bestätigt endgültig: Der Glurak ist der Tresor, aber der Bitcoin (oder Stablecoin) ist das Bargeld.

Fazit und Hitzige Empfehlungen: Wer gewinnt den Spekulations-Battle?

Die Analyse kommt zu einem klaren Urteil: Pokémon-Karten sind im strengen Sinne keine Währung. Sie sind extrem wertvolle, nicht-fungible Barter-Assets, deren Liquidität, Teilbarkeit und allgemeine Akzeptanz erst durch die komplexe Infrastruktur des 21. Jahrhunderts (Grading, Vaulting, Tokenization) künstlich geschaffen werden müssen, um monetäre Eigenschaften zu imitieren. Der Pika-Dollar besteht den Test als exzellenter Wertspeicher (SoV), versagt aber massiv als Tauschmittel und Recheneinheit.

Bitcoin hingegen besteht theoretisch alle Währungstests: Es ist fungibel, hochgradig teilbar und in seiner Ausgabe limitiert. Es leidet jedoch unter extremen praktischen Mängeln wie der prohibitiven Volatilität, langsamen Transaktionsgeschwindigkeiten und der enormen Logistik der Selbstverwahrung (Self-Custody). Bitcoin ist somit ein überlegener digitaler Wertspeicher und ein Reserve-Asset, aber kein ideales tägliches Zahlungsmittel.

Beide Märkte sind ein Spiegelbild des spekulativen Glaubens. Ihr Wert hängt nicht von einem intrinsischen Nutzen ab, sondern vom kollektiven Hype und der fortwährenden Nachfrage zukünftiger Generationen.

Abschließender Rat an den IT-Blog-Leser:

Wenn Sie den Nervenkitzel der Jagd und die materielle Sicherheit (gegen Schimmel) bevorzugen, HODLn Sie den Glurak. Wenn Sie die Bequemlichkeit der digitalen Welt und die Freiheit der Dezentralität schätzen, HODLn Sie Bitcoin. Im Zweifel sollten Sie den Glurak als Pfand hinterlegen, um Kredite in Stablecoins aufzunehmen, und diese Stablecoins dann verwenden, um Waren zu kaufen. Aber bezahlen Sie Ihre Miete am besten mit Satoshis – es sei denn, Ihr Vermieter ist ein Sammler, der gerade einen PSA 10 Trophy Pikachu (No. 1 Trainer) gegen ein Jahr Vorauszahlung eintauschen möchte.

Wenn Verantwortung schwerfällt – Gedanken zu Personalentscheidungen

Vor Kurzem hatte ein Kollege eine Erfahrung, die wohl viele von uns irgendwann einmal machen: Eine Mitarbeiterin aus seinem Team musste entlassen werden.
Es war keine leichte Entscheidung, aber am Ende unumgänglich. Die Zusammenarbeit war über einen längeren Zeitraum schwierig geworden – sowohl fachlich als auch menschlich. Gespräche wurden geführt, Unterstützung angeboten, Alternativen gesucht. Doch irgendwann war klar: Es gibt keine gemeinsame Basis mehr für eine konstruktive Zusammenarbeit.

Der Kollege, der in diesen Prozess eingebunden war, hat mich im Nachhinein überrascht. Er war ehrlich betroffen, konnte kaum schlafen.
Viele, die schon länger Personalverantwortung tragen, waren erstaunt, wie sehr ihn diese Entscheidung mitnahm – und doch konnten sich wohl alle ein Stück weit darin wiederfinden.

Denn auch ich erinnere mich gut an die erste Situation, in der ich um meine Einschätzung gebeten wurde:
Gibt es noch eine Zukunft mit diesem Mitarbeiter – oder ist der Punkt erreicht, an dem man sich trennen sollte?
Das war kein leichter Moment. Aber ich wusste, dass ich vorher alles versucht hatte, um die Situation zu verbessern. Ich hatte Feedback gegeben, Gespräche gesucht, Unterstützung angeboten. Doch wenn das alles ohne Wirkung bleibt, dann kommt irgendwann der Moment, an dem man loslassen muss.

Diese Momente sind nie schön. Aber sie gehören zur Führungsverantwortung.
Wichtig ist, dass man sich bewusst macht: Wir sind nicht für das Leben oder die Entscheidungen anderer verantwortlich.
Unsere Aufgabe ist es, faire Chancen zu geben, klar zu kommunizieren und Entwicklung zu ermöglichen. Doch wenn jemand nicht bereit ist, diese Chancen anzunehmen, dann trägt er oder sie auch die Verantwortung für die Konsequenzen.

Am Ende bleibt das Fazit:
Führung heißt, menschlich zu bleiben – aber auch, professionell zu handeln.
Man kann helfen, fördern, begleiten – aber nicht für andere entscheiden, welchen Weg sie gehen.

Warum du auch im Zeitalter von ORMs weiter SQL lernen solltest

In modernen Softwareprojekten greifen viele Entwicklerinnen und Entwickler heute kaum noch direkt auf Datenbanken zu. Stattdessen nutzen wir Abstraktionslayer wie Doctrine, Hibernate, Eloquent oder SQLAlchemy. Diese Tools sind bequem, sie übersetzen unsere Objektmodelle automatisch in Datenbankabfragen und nehmen uns vieles ab. Auf den ersten Blick scheint es fast so, als müsste man sich mit SQL gar nicht mehr beschäftigen. Doch das ist ein gefährlicher Irrtum.

Denn auch wenn wir das SQL nicht mehr selbst schreiben, läuft es unter der Oberfläche trotzdem ab. Jede ORM-Abfrage wird letztlich zu einer SQL-Query, die in der Datenbank ausgeführt wird. Und genau dort entscheidet sich, ob unsere Anwendung schnell und effizient arbeitet oder ob sie durch unbedachte Abfragen ins Stocken gerät. Wer SQL versteht, kann erkennen, was tatsächlich passiert, und eingreifen, wenn es nötig ist.

ORMs abstrahieren vieles, aber sie ersetzen kein Verständnis für das, was im Hintergrund läuft. Sobald eine Anwendung langsamer wird, Reports unvollständig sind oder plötzlich hunderte kleine Datenbankabfragen entstehen, hilft kein ORM mehr weiter. Dann zählt, wer in der Lage ist, das generierte SQL zu lesen, zu analysieren und zu optimieren. Dieses Wissen spart Zeit, Nerven und oft auch Serverressourcen.

Auch der Umgang mit Datenbanktools setzt SQL-Kenntnisse voraus. Programme wie JetBrains DataGrip, phpMyAdmin, DBeaver oder die Command-Line-Tools von PostgreSQL und MySQL sind mächtige Werkzeuge. Doch sie entfalten ihr volles Potenzial erst dann, wenn man weiß, was man mit ihnen tut. Wer SQL versteht, kann Abfragen nachvollziehen, Query-Pläne interpretieren, Daten effizient analysieren oder eigene Reports erstellen, ohne auf externe Hilfe angewiesen zu sein.

In der Praxis kommt immer der Moment, in dem man selbst eingreifen muss. Vielleicht verlangt ein Kunde einen speziellen Bericht, der sich mit ORM-Mitteln nur umständlich umsetzen lässt. Vielleicht taucht ein Performanceproblem auf, das sich nicht durch Code-Refactoring lösen lässt. In solchen Situationen ist SQL die Sprache, die dich rettet. Sie ermöglicht es, direkt an der Quelle zu arbeiten und genau das Ergebnis zu erzielen, das du brauchst – schnell, präzise und kontrolliert.

SQL zu beherrschen ist kein überflüssiges Relikt aus vergangenen Zeiten, sondern eine der wichtigsten Fähigkeiten im Umgang mit Daten. Sie bildet die Grundlage für jedes performante System, egal ob du mit PostgreSQL, MySQL, SQLite oder einem anderen System arbeitest. Wer SQL versteht, versteht Daten – und wer Daten versteht, kann bessere Software bauen.

Deshalb lohnt es sich, das eigene SQL-Wissen bewusst zu pflegen und immer wieder zu vertiefen. Mit jeder neuen Query wächst das Verständnis für Strukturen, Zusammenhänge und Optimierungsmöglichkeiten. ORMs sind eine großartige Hilfe im Alltag, aber sie nehmen uns das Denken nicht ab. Am Ende bleibt SQL die Sprache, in der sich entscheidet, wie gut eine Anwendung wirklich mit ihren Daten umgeht.

Warum 1 Gbit/s im Heimnetz auch 2025 noch völlig ausreicht

Seit über einem Jahrzehnt ist 1 Gigabit-Ethernet (1 Gbit/s) der Standard im Heimnetzwerk. Und obwohl Technikbegeisterte heute von 2.5 Gbit/s, 10 Gbit/s oder gar Glasfaser-Backbones sprechen, zeigt sich in der Praxis: Für den typischen Haushalt – selbst mit Homeoffice, NAS und Smart-Home-Geräten – reicht 1 Gbit/s immer noch völlig aus.

1 Gbit/s: ein Standard, der sich bewährt hat

Seit etwa 2005 ist Gigabit-Ethernet in Mainboards, Routern und Switches fest integriert. Mit rund 110 MB/s realer Übertragungsrate bietet es seit Jahren mehr Bandbreite, als die meisten Geräte tatsächlich nutzen können.
Ob große Dateiübertragungen, HD- oder 4K-Streaming, Online-Gaming oder Homeoffice – 1 Gbit/s liefert zuverlässig genug Reserven, um mehrere parallele Aktivitäten gleichzeitig zu bedienen.

Internetzugang bleibt der Engpass

Der eigentliche Flaschenhals liegt längst nicht mehr im lokalen Netzwerk, sondern beim Internetzugang selbst.
Auch 2025 sind 1 Gbit/s Downstream und 50–100 Mbit/s Upstream im Privatbereich schon ein oberes Limit dessen, was bezahlbar angeboten wird.
Ein schnelleres Heimnetz bringt hier keinen Vorteil – denn selbst wenn das lokale Netz 10 Gbit/s hergibt, ist die Verbindung ins Internet trotzdem auf 1 Gbit/s oder weniger begrenzt.

Moderne Software denkt ohnehin „online“

Ein weiterer Punkt: Viele moderne Programme kommunizieren heute über das Internet, selbst wenn zwei Geräte im gleichen LAN stehen.
Beispiele sind Cloud-Dienste wie OneDrive, Google Drive, Microsoft Teams oder sogar manche Smart-Home-Systeme.
Die Daten laufen meist nicht direkt von Gerät zu Gerät im lokalen Netz, sondern über externe Server – was bedeutet, dass die lokale Netzwerkgeschwindigkeit gar nicht mehr ausschlaggebend ist.

2.5 Gbit/s und mehr: interessant, aber selten nötig

Natürlich gibt es Einsatzszenarien, in denen sich schnellere LAN-Verbindungen lohnen – etwa für Content-Creator, die regelmäßig große Videodateien auf ein NAS kopieren, oder für kleine Server-Setups mit mehreren gleichzeitigen Clients.
Für den normalen Haushalt jedoch, in dem Streaming, Cloud-Synchronisation, Online-Gaming und Homeoffice dominieren, bleibt der Unterschied zwischen 1 Gbit/s und 2.5 Gbit/s praktisch unsichtbar.

Fazit

Trotz technischer Fortschritte hat sich 1 Gbit/s als solide Basisgeschwindigkeit im Heimnetz etabliert.
Die meisten Anwendungen profitieren kaum von mehr Bandbreite, weil sie entweder durchs Internet limitiert sind oder ihre Kommunikation ohnehin extern abwickeln.
Wer also keine speziellen Hochlast-Szenarien hat, kann beruhigt sagen:
Ein gutes 1 Gbit/s-Netzwerk ist auch 2025 noch mehr als schnell genug.

Andererseits zeigt diese Situation auch, wie begrenzt der Ausbau der deutschen Netze bisher vorangeschritten ist.
Mehr als 1 Gbit/s für Privatkunden wäre gerade für Homeoffice, Remote-Arbeiten und größere Cloud-Anwendungen teilweise sehr angenehm – doch die Realität ist, dass solche Anschlüsse oft noch teuer oder gar nicht verfügbar sind.
Insofern ist die Tatsache, dass wir mit 1 Gbit/s auskommen müssen, weniger ein technisches Problem, als ein Hinweis darauf, dass noch viel Potenzial für den Netzausbau besteht.

Warum direkter Kontakt oft besser ist als TeamViewer

Klar, TeamViewer ist praktisch.
Ein Klick, kurz die ID und das Passwort eingetippt, und schon kann man sich auf den PC des Mitarbeiters schalten, das Problem beheben – und fertig. Schnell, effizient, kein Overhead. Der Mitarbeiter lehnt sich zurück, schaut (vielleicht) zu und bekommt am Ende den Anruf: „So, läuft wieder!“

Aber mal ehrlich: so richtig gut ist das nicht.

Der stille Mitarbeiter

Das Problem an dieser Methode: Es passiert keine echte Kommunikation.
Der Mitarbeiter sitzt passiv vor dem Bildschirm, versteht oft gar nicht, was genau gemacht wurde – und vor allem warum. Es gibt keinen Kontext, kein Gespräch, keine Rückfragen.
Das ist schade, denn gerade im Austausch entstehen oft die wirklich wertvollen Informationen.

Mehr als nur Fehlerbehebung

In der IT geht’s nicht nur darum, Probleme zu lösen. Das „I“ in IT steht schließlich für Information.
Unsere Aufgabe ist es also nicht nur, Systeme am Laufen zu halten, sondern auch Informationen zu sammeln, zu verstehen und einzuordnen.
Wenn jemand zum Beispiel sagt: „Ich kann meine PDF nicht drucken“, dann ist es hilfreich zu wissen, warum er das überhaupt tun will. Geht’s um einen wichtigen Vertrag? Eine Serienproduktion? Eine interne Freigabe?

Diese Infos helfen uns, Zusammenhänge zu erkennen – und langfristig Prozesse zu verbessern.
Viele IT-Abteilungen haben dadurch einen besseren Überblick über Abläufe und Workflows als die Fachbereiche selbst. Nicht, weil wir schlauer sind, sondern weil wir durch viele Berührungspunkte sehen, wie alles zusammenhängt.

Warum direkter Kontakt zählt

Wenn man stattdessen einen kurzen Teams-Call macht, den Bildschirm teilen lässt und dem Mitarbeiter erklärt, was zu tun ist, passiert plötzlich etwas:
Man redet.
Man stellt Fragen.
Man versteht, wie der Mitarbeiter arbeitet und wo vielleicht noch andere Stolperfallen liegen.

Oder man geht – wenn’s möglich ist – einfach mal vorbei.
Sich das Problem vor Ort zeigen zu lassen, bringt oft nicht nur die Lösung, sondern auch Kontext.
Und genau dieser Kontext ist Gold wert.

TeamViewer? Ja, aber richtig!

Versteh mich nicht falsch: TeamViewer ist nicht grundsätzlich schlecht. Es ist ein tolles Tool – wenn man es richtig nutzt.
Wenn du dich per TeamViewer aufschaltest, dann halte den Call mit dem Mitarbeiter offen. Sprich mit ihm. Erklär, was du machst. Lass ihn mitdenken.
So bleibt der Informationsfluss bestehen – und aus einer anonymen Fernwartung wird wieder ein echtes Miteinander.

Fazit

Direkter Kontakt ist durch nichts zu ersetzen.
Er sorgt für mehr Verständnis, bessere Kommunikation – und am Ende auch für bessere IT.
Denn: Nur wer Informationen sammelt, kann wirklich etwas verbessern.
Und genau darum geht’s doch, oder?

Tool: List-Tranform

Ich habe in den letzten Tagen für Black Friday viele Listen von Werten hin und her gewandelt: Produktnummern aus einer Excel-Datei in SQL, per SQL abgefragte IDs in ein JSON-Array und so weiter. ChatGPT ist dabei eine große Hilfe, aber auch nicht gerade schnell. Am Ende stellte sich heraus, dass es teilweise schneller ging, sich eine kleine Web-App für diese Zwecke schreiben zu lassen, als die Liste von ChatGPT selbst transformieren zu lassen. Die Web-App hat keine 30 Sekunden in der Erzeugung gedauert und sicher auch nicht mehr als eine Minute für den Prompt.

https://list.annonyme.de

KI hilft also – aber sie muss nicht immer alle Aufgaben selbst übernehmen.

Programm-Updates: setup.exe vs. composer update

Warum ich keine Lust mehr auf umständliche Softwarepflege habe

Kennt ihr das Gefühl, wenn man schon beim Gedanken an ein Software-Update innerlich stöhnt? Ich auf jeden Fall. Und jedes Mal, wenn ich wieder irgendwo eine „setup.exe“ starten muss, frage ich mich ernsthaft, warum wir im Jahr 2025 immer noch so arbeiten.

Früher war das ja normal – jede Software hatte ihr eigenes Setup, ihre eigenen Client-Versionen, ihre Eigenheiten. Heute sind viele Anwendungen glücklicherweise im Web angekommen. Und ganz ehrlich: überall dort, wo Performance nicht der entscheidende Faktor ist, ist das auch richtig so.

Bei Videobearbeitung oder großen Grafikprojekten hinken Webanwendungen zwar noch ein bisschen hinterher, aber selbst da holen sie auf. Für alles Kaufmännische – also ERP, CRM, Warenwirtschaft, Finanzbuchhaltung & Co. – ist eine Weblösung heute eigentlich die einzig logische Wahl.

Warum Web einfach besser ist

Ein paar offensichtliche Vorteile zuerst:

- Keine lokalen Server mehr, keine verrückten Abhängigkeiten von Windows-Versionen, Benutzerkonten oder Hardware.
- Lizenzverwaltung zentral und übersichtlich.
- Und man kann seine Software endlich als SaaS oder Clouddienst anbieten, statt sich mit Installationsroutinen herumzuärgern.

Aber der wahre Gamechanger ist die Update-Einfachheit.

Updates ohne Drama

Bei klassischen Client-Server-Anwendungen ist jedes Update ein kleines Projekt.
Man muss jeden Arbeitsplatz anfassen, überall prüfen, dass die Clients geschlossen sind (Spoiler: sind sie nie), Passwörter neu eingeben, Leute in ihrer Arbeit unterbrechen – und am Ende ist man sich trotzdem nicht sicher, ob wirklich alles sauber läuft.

Ich hab das zuletzt wieder bei einem Kunden mit CGM Turbomed erlebt.
Allein die setup.exe auf dem Server braucht rund 40 Minuten, und das ist nur der Anfang.
Dann kommt der erste Client – nochmal 15 Minuten, plus ein paar Minuten für den Funktionstest.
Die restlichen sechs Arbeitsplätze lassen sich zwar parallel machen, aber jeder Mitarbeiter ist trotzdem rund fünf Minuten raus.
Und das alles, nur um dieselbe Software in Version 8.7 statt 8.6 zu haben.
Ganz ehrlich: Das ist reine Lebenszeitverschwendung.

Und wehe, etwas geht schief – dann darf man nochmal von vorne anfangen.

Die Webvariante: kurz, schmerzlos, fertig

Ein Update bei einer modernen Webanwendung sieht dagegen so aus:

1. Wartungsmodus ankündigen
2. Wartungsmodus aktivieren
3. composer update
4. Kurz testen
5. Wartungsmodus wieder raus
6. Bescheid sagen

Die User drücken einmal F5 – und zack, alle sind wieder produktiv.
Keine Installationsorgien, keine Benutzerunterbrechungen, keine Passwörterdramen.
Was früher einen halben Tag gedauert hat, ist plötzlich in 30 Minuten erledigt.

Fazit

Jede kaufmännische Software, die heute noch einen nativen Client braucht – egal ob mit Server oder direktem Datenbankzugriff – ist für mich ein No-Go.
Ich will meine Zeit nicht mit Setup-Assistenten, MSI-Paketen oder Update-Skripten verbringen.

Die Zeit, die man bei der Pflege moderner Websysteme spart, ist enorm.
Und wenn das Ganze dann auch noch in der Cloud läuft – also ohne eigenen Server, ohne Update-Stress – spart man so viel Zeit und Geld, dass man sich oft einen halben Mitarbeiter spart.
Einen, der sich dann um echte Verbesserungen kümmern kann, statt Fortschrittsbalken anzustarren.

Wenn ich die Wahl habe zwischen einer setup.exe und einem simplen composer update, dann ist die Entscheidung klar.
Ich nehme das Update, das mich nicht nervt.

Winget: Nett ist die kleine Schwester von Bemüht

Es ist ein wirklich nettes kleines Tool, um sich schnell Dinge zu installieren. Man kann auch viele Dinge auf einmal per Logon-Script installieren.

Es ist wie apt-get nur eben für Windows und es verhält sich auch richtig Windows-mäßig. Also ohne UI kommt man doch nicht aus und bloß weil ich es über CLI ausführe heißt ja nicht, dass ich nicht doch noch rum klicken muss.

winget ist gefühlt noch weit von apt-get oder snap entfernt.

TeamViewer für Remote-Arbeit

Warum AI-Commit-Messages mehr sind als nur ein Text

Ich geb’s zu: Ich schreibe meine Commit-Messages schon länger nicht mehr selbst.
Nicht, weil ich keine Lust habe – naja, vielleicht ein bisschen – sondern weil’s einfach besser funktioniert, wenn ich die KI das übernehmen lasse.

Ich nutze GitKraken, und da ist es wirklich nur ein Klick: Änderung committen, KI-Message generieren, fertig. Kein Grübeln mehr über die passende Formulierung, kein „Fix minor bug“ oder „Update stuff“. Stattdessen bekomme ich in Sekunden eine ausführliche, gut lesbare Beschreibung, die ich so wahrscheinlich nie geschrieben hätte.

Klar, es ist bequemer. Und schneller. Aber darum geht’s mir gar nicht in erster Linie.
Der eigentliche Mehrwert liegt woanders.

Wenn ich ein Code Review mache, schaue ich mir zuerst immer nur den Code an – ganz ohne Kontext. Ich versuche zu verstehen, was der Code fachlich und technisch macht, und überprüfe dann, ob das mit den Anforderungen übereinstimmt. Wenn alles zusammenpasst, weiß ich: Die Intention hinter der Änderung stimmt.

Und genau das mache ich mittlerweile auch mit der AI-Commit-Message.
Nachdem die KI den Text generiert hat, lese ich ihn mir durch und frage mich:
„Trifft das wirklich das, was ich gemacht habe?“

Wenn die Beschreibung von der AI nicht ganz zu meinem Code passt, ist das für mich ein Signal: Ich schaue mir die Änderung nochmal an. Oft finde ich dann kleine Dinge, die ich sonst vielleicht übersehen hätte – zum Beispiel ein vergessenes Debug-Statement oder eine ungewollte Anpassung, die eigentlich gar nicht in den Commit gehört.

Im Grunde ist die AI für mich damit zu einer Art zweiten Paar Augen geworden.
Sie fasst meine Änderungen zusammen – fachlich und technisch – und hilft mir, nochmal kritisch draufzuschauen. Und genau das bringt einen echten Mehrwert:
Nicht nur, weil ich Zeit spare, sondern weil meine Commits dadurch sauberer, konsistenter und nachvollziehbarer werden.

Kleine Hilfe, großer Effekt.
AI-Commit-Messages sind für mich längst nicht mehr nur ein bequemer Textgenerator – sie sind ein echtes Qualitätstool in meinem Entwicklungsprozess.

Wenn sich das Internet getriggert fühlt

Letzte Woche passierte etwas, das eigentlich völlig banal war – und trotzdem das halbe Internet in Aufruhr versetzte.
Ein 24-Jähriger verließ um 7:00 Uhr morgens seine Wohnung, kam abends kurz vor 19:00 Uhr zurück, startete einen TikTok Live-Stream und sagte:
„Puh, war ein langer Tag.“

Mehr nicht.
Doch das reichte, um einen Shitstorm loszutreten.
Vor allem ältere Generationen fühlten sich getriggert: Wie könne jemand nach über elf Stunden außer Haus nicht den Wunsch äußern, noch ein paar Überstunden dranzuhängen?

Jede Nachrichtenseite, Talkshow und selbst ernannte Expertin fühlte sich berufen, etwas dazu zu sagen.
Der Tenor war klar: Wie faul die Jugend doch ist! Und natürlich steht die ganze Gen Z gleich mit am Pranger.

Das perfekte Timing der Politik

Passend dazu lief gerade die politische Diskussion darüber, wie man die deutsche Wirtschaft „ankurbeln“ könnte – natürlich durch längeres und intensiveres Arbeiten.
Ob Samstagsarbeit, weniger Feiertage oder längere Wochen – plötzlich klang alles nach „Zurück in die 70er“.

Und sofort war für viele klar: Da muss doch ein Zusammenhang bestehen!
Die Jungen sind faul, also geht die Wirtschaft den Bach runter.
Die Lösung? Mehr Arbeit! Denn: „Zeit ist Geld – und mehr Zeit ist mehr Geld.“

Ich habe schon einmal geschrieben, dass genau diese Annahme grundfalsch ist.
Zeit allein bedeutet weder Qualität noch Produktivität.
Dieses Denken stammt aus den 60er- und 70er-Jahren – aus einer Zeit, in der die Welt, die Arbeit und die Wirtschaft völlig anders funktionierten.
Heute haben sich die Grundvoraussetzungen komplett verändert.

Mehr Arbeitszeit heißt nicht mehr Arbeit

Die Idee, dass man mehr Geld verdient, wenn alle einfach mehr arbeiten, funktioniert nur, wenn überhaupt genug Arbeit vorhanden ist.
Damals, in den 60ern und 70ern, gab es Arbeit im Überfluss. Man konnte schuften, so viel man wollte – die Arbeit ging nicht aus.
Heute ist das Gegenteil der Fall: Das Problem ist nicht Faulheit, sondern das Fehlen sinnvoller Arbeit.

Unsere Wirtschaft ist so effizient geworden, dass sie in kürzester Zeit produziert, was früher Tage dauerte.
Doch die Menschen brauchen nicht mehr als früher – im Gegenteil.
Weihnachten steht vor der Tür, und viele wissen gar nicht, was sie sich wünschen sollen, weil sie im Grunde schon alles haben.
Geräte halten länger, Fernseher werden günstiger, aber kaum besser.
Nach dem IT-Boom der späten 90er und frühen 2000er hat sich das Tempo ohnehin verlangsamt.

Also bringt es wenig, Menschen einfach acht Stunden mehr pro Woche arbeiten zu lassen, wenn sie ihren Job ohnehin in 40 Stunden entspannt schaffen.
Das verlängert nur den Tag, senkt aber die Effizienz – und kostet am Ende mehr Geld, als es einbringt.

Wenn ein Automobilhersteller 3000 Mitarbeitende entlässt, liegt das nicht daran, dass sie alle faul waren.
Und der Hersteller steht danach auch nicht verzweifelt da und fragt sich, wer jetzt die Arbeit erledigen soll – denn die Arbeit ist gar nicht mehr da.
Das ist keine Schuld der Arbeiter, sondern schlicht ein wirtschaftlicher Umstand.

Mehr Arbeitszeit schafft keine Arbeit.
Teilzeitstellen existieren heute nicht, weil Menschen weniger leisten wollen, sondern weil weniger Arbeit anfällt.
Und ausländische Unternehmen werden nicht plötzlich in Deutschland produzieren, nur weil wir hier 16 Stunden länger in der Woche schuften.
Die Produktionskosten bleiben zu hoch – also gehen sie dorthin, wo es günstiger ist.

Wer genug Arbeit und faire Bezahlung bietet, findet auch Menschen, die sie erledigen.
Die angebliche „faule Gen Z“ ist also nicht das Problem – sie ist nur ein praktischer Sündenbock, um von den echten, komplexen Ursachen abzulenken.

Eine Randbemerkung

In den Kommentarspalten liest man oft:
„Früher haben wir auch von 6 bis 18 Uhr gearbeitet! Die Jugend ist einfach faul!“

Das ist dieselbe Generation, die einem erzählt, Homeoffice sei ja ganz praktisch, „weil da merkt ja keiner, wenn man zwischendurch mal einen kleinen Schluck nimmt“.
Oder: „Auf der Arbeit hatte ich meinen Spind, da stand immer was drin – da ging man halt ab und zu vorbei.“
Nach Feierabend dann noch zwei Bier am Arbeitsplatz.

Das ist kein Witz – das wurde mir genau so erzählt.
Und so sah für viele das Arbeitsleben eben aus:
Harte Arbeit, viel Alkohol, und das war gesellschaftlich völlig normal.
Wer auf Montage war, ging abends in die nächste Kneipe, um sich „ordentlich einen zu gönnen“.
Weil: „Man war ja fleißig, man hat’s sich verdient.“

Und genau diese Leute werfen der jungen Generation heute vor, sie habe ein falsches Verhältnis zur Arbeit.
Dabei war es bei ihnen ganz selbstverständlich, die Belastung mit Alkohol zu betäuben – und viele landeten genau deshalb in der Abhängigkeit.

Es ist die Generation, für die Alkoholismus fast schon zum guten Ton gehörte, „weil die ja immer so gut drauf waren“.
Wie gesagt: reale Gespräche, nicht ausgedacht.

Fazit

Die Empörung über den TikTok-Post zeigt nicht, dass die Jugend faul ist – sondern wie sehr viele Menschen immer noch an überholten Vorstellungen von Arbeit festhalten.
Arbeiten heißt heute nicht mehr, 12 Stunden im Betrieb zu stehen, sondern effizient, kreativ und gesund zu bleiben.
Wer das als Schwäche versteht, hat das eigentliche Problem vielleicht gar nicht bei der Jugend – sondern im eigenen Weltbild.

SwarmUI: Notizen

Da ich meine Blog oft auch als Notizzettel für mich selber nutze, hier einmal meine Notizen zur KI Bilder-Generierung mit SwarmUI.

Basis-Einstellungen

qwen-image
steps: 25
cfg scale: 4

flux1-dev
steps: 20
cfg scale: 1

hunyuan image 2.1
steps: 20
cfg scale: 4

highdream i1 dev
steps: 20
cfg scale: 1

sd3.5 large
steps: 20
cfg scale: 7

Firebird: SQL-Logging unter Linux

Wenn man mit Firebird-Datenbanken arbeitet, kommt irgendwann der Punkt, an dem man genau wissen möchte, welche SQL-Statements tatsächlich auf der Datenbank ausgeführt werden. Vielleicht, um Performance-Probleme zu untersuchen, vielleicht um unerwartetes Verhalten einer Anwendung zu verstehen oder einfach, um ein besseres Gefühl für den Datenbankzugriff zu bekommen.

Firebird bringt dafür seit der Version 2.5 ein sehr mächtiges Werkzeug mit: das Trace- und Audit-Subsystem. Damit lassen sich Abfragen, Transaktionen, Verbindungsinformationen und vieles mehr protokollieren – ohne dass man tief ins System eingreifen oder die Anwendung verändern muss.

In diesem Beitrag zeige ich dir Schritt für Schritt, wie du mit Firebird 2.5.9 unter Linux (egal ob direkt auf dem Host oder in einem Docker-Container) ein SQL-Logging aktivierst und die Ergebnisse live einsehen kannst.

Trace-Konfigurationsdatei erstellen

Der Trace-Mechanismus in Firebird braucht zunächst eine Konfigurationsdatei, die beschreibt, was geloggt werden soll. Diese Datei kann an einem beliebigen Ort liegen – wir nehmen in diesem Beispiel /opt/fb_trace_all.conf.

Öffne die Datei mit einem Editor deiner Wahl, zum Beispiel nano oder vi:

nano /opt/fb_trace_all.conf

Füge dann den folgenden Inhalt ein:

<database>
enabled true
log_connections true
log_statement_prepare true
log_statement_start true
log_statement_finish true
print_plan true
print_perf true
time_threshold 0
max_sql_length 65000
max_arg_length 240
max_arg_count 100
</database>

Was bedeutet das?

* enabled true – Schaltet das Logging für die Datenbank ein.
* log_connections true – Verbindungs- und Trennungsereignisse werden protokolliert.
* log_statement_prepare true – Auch das „Vorbereiten“ eines SQL-Statements (also bevor es ausgeführt wird) wird festgehalten.
* log_statement_start true / log_statement_finish true – Beginn und Ende jeder Abfrage werden geloggt.
* print_plan true – Der Ausführungsplan (Execution Plan) für jede Abfrage wird mit ausgegeben – sehr nützlich, wenn es um Performance geht.
* print_perf true – Zeitmessungen und andere Performance-Daten werden angezeigt.
* time_threshold 0 – Es gibt keine Mindestzeit; jede Abfrage wird geloggt, egal wie kurz sie läuft.
* max_sql_length / max_arg_length / max_arg_count – Diese Werte legen fest, wie groß die protokollierten SQL-Statements und ihre Parameter werden dürfen.

Mit dieser Konfiguration erhältst du ein sehr detailliertes Protokoll, das alle SQL-Statements sichtbar macht, die gegen deine Firebird-Datenbank laufen.

Trace Watcher starten

Nun muss Firebird angewiesen werden, diesen Trace-Job zu starten. Das geschieht über das Tool fbtracemgr, das mit der Firebird-Installation mitgeliefert wird.

Beispiel:

./fbtracemgr -se localhost:service_mgr -user SYSDBA -pass masterkey -start -name allsql -conf /opt/fb_trace_all.conf >> /tmp/lognamen.log

Erklärung der Parameter:

-se localhost:service_mgr – Verbindung zum Service Manager auf localhost.
-user SYSDBA -pass masterkey – Authentifizierung mit dem Standard-Administrator-Account.
-start – Startet einen neuen Trace-Job.
-name allsql – Vergibt einen Namen für diesen Job, z. B. „allsql“.
-conf /opt/fb_trace_all.conf – Verweist auf die Konfigurationsdatei von oben.
>> /tmp/lognamen.log – Leitet die Ausgabe in eine Log-Datei um.

Der Prozess läuft so lange, bis er manuell beendet wird (z. B. mit Ctrl+C).

Logdatei live mitverfolgen

Um nicht immer wieder die Log-Datei neu öffnen zu müssen, empfiehlt sich ein „Live-Tail“. In einem zweiten Terminal kannst du dir die Einträge direkt beim Eintreffen anschauen:

tail -f /tmp/lognamen.log

Jetzt siehst du sofort, wenn deine Anwendung eine Abfrage an Firebird schickt – inklusive der SQLs, der Ausführungspläne und der Performance-Daten.

Praktische Tipps
Docker-Setup: Wenn Firebird in einem Container läuft, musst du nur darauf achten, dass sowohl das fbtracemgr-Binary als auch die Konfigurationsdatei im Container verfügbar sind. Ein Volume-Mount für /opt/fb_trace_all.conf und /tmp/lognamen.log ist sinnvoll.

Ressourcen im Blick behalten: Da jede Abfrage geloggt wird, kann die Logdatei schnell sehr groß werden. Für längere Analysen solltest du mit Filtern arbeiten oder ein Tool wie grep verwenden.

Filterung: Du kannst in der Konfigurationsdatei auch bestimmte Datenbanken oder bestimmte Events ausschließen, um die Menge der Informationen überschaubarer zu halten.

Sicherheit: Achte darauf, dass sensible Daten (Passwörter, personenbezogene Daten) in Logs landen können. Im Produktivbetrieb sollte man also genau abwägen, welche Daten man wirklich braucht.

Fazit

Mit dem Firebird-Trace-Subsystem hat man ein mächtiges Werkzeug an der Hand, das es erlaubt, SQL-Abfragen transparent zu überwachen und zu analysieren. Gerade bei der Fehlersuche oder bei Performance-Optimierungen ist das oft der schnellste Weg, um zu verstehen, was im Hintergrund tatsächlich passiert.

Die hier gezeigte Konfiguration ist ein „Alles mitnehmen“-Ansatz, mit dem man sofort loslegen kann. Danach kann man Schritt für Schritt Feintuning betreiben, um genau die Informationen zu loggen, die man wirklich braucht.

Digitale Unabhängigkeit der EU – zwischen Anspruch und Realität

Immer öfter liest man Schlagzeilen, dass Europa unabhängiger von den USA werden soll – vor allem wenn es um Cloud, Künstliche Intelligenz oder Hardware geht. Spätestens seit Trump ist das Thema präsent: seine Sprunghaftigkeit hat vielen in Europa gezeigt, wie riskant Abhängigkeiten sein können. Gleichzeitig erinnert das Ganze an Corona: Damals hat man gesehen, wie schlecht Schulen digital aufgestellt waren – viel Aktionismus, wenig greifbare Ergebnisse. Heute wirkt es ähnlich: Man startet Projekte, verteilt Fördergelder, aber am Ende bleibt oft das Gefühl, dass man versucht, das Problem einfach auszusitzen.

Politik und die ewige Symbolik

Die EU fördert viele Programme, schreibt Strategiepapiere und stellt Forschungsgelder bereit. Auf dem Papier klingt das beeindruckend. Aber oft fehlt der nächste Schritt: ein Produkt, das man wirklich nutzen kann. Anstatt pragmatisch Lösungen einzukaufen oder bestehende Anbieter zu stärken, wird lieber geforscht und diskutiert. Am Ende heißt es dann: „Wir haben viel gelernt.“ Das erinnert an die Raumfahrtprojekte der ESA – während Europa jahrelang lernt, übernimmt SpaceX die Aufträge der Industrie.

Cloud und Hyperscaler – Kopieren statt Neues wagen

Bei der Cloud will die EU eigene Hyperscaler aufbauen – also quasi europäische Versionen von AWS, Azure oder Google Cloud. Der Haken: Man will eigentlich nur beweisen, dass man das Gleiche bauen kann. Doch während man an der Kopie arbeitet, sind die US-Anbieter schon wieder einen Schritt weiter. Für viele Kunden in Europa ist das Angebot ohnehin überdimensioniert. Sie wollen meist gar kein komplexes Kubernetes-Cluster, sondern einfach einen stabilen Server, der zuverlässig läuft. Statt also auf die tatsächlichen Bedürfnisse einzugehen, versucht die EU, ein Modell nachzubauen, das hier oft gar nicht gebraucht wird.

Hardware – die europäische CPU

Ein besonders ambitioniertes Beispiel ist der Plan, eine europäische CPU für Rechenzentren zu entwickeln. Klingt spannend, aber auch hier geht die EU den Forschungsweg. Anstatt bestehende Designs zu kaufen oder mit Firmen zusammenzuarbeiten, die schon Erfahrung haben, startet man ein neues Großprojekt. Ergebnis: viel Papier, lange Laufzeiten und am Ende ein Chip, der bei Markteinführung schon veraltet ist. Offiziell heißt es dann: „Wir haben wichtige Erkenntnisse gewonnen“ – aber nutzen will die CPU keiner.

KI – Mistral als Hoffnungsträger

Im Bereich KI sieht es immerhin etwas besser aus. Mit Mistral AI aus Frankreich gibt es ein Startup, das schon einiges erreicht hat und Milliardeninvestitionen anzieht. Ein echter Hoffnungsträger für Europa. Aber auch hier fehlt es an Infrastruktur – die Rechenzentren, um wirklich auf Augenhöhe mit den USA zu arbeiten, gibt es schlicht nicht. Und während in den USA KI-Produkte direkt am Markt getestet werden, diskutiert man in Europa erst einmal lange über Risiken wie Fake News oder Copyright-Fragen. Wichtig, klar – aber zu oft wird dadurch der Fortschritt ausgebremst.

Warum es so schwer ist

Das Muster zieht sich durch alle Bereiche: Europa will unabhängiger werden, scheitert aber an langsamen Prozessen, fehlendem Kapital und politischem Zögern. Chips kommen weiterhin aus den USA, Cloud-Infrastruktur dominiert Amazon & Co., und bei KI hat man zwar Ideen, aber wenig Durchschlagskraft. Eine komplette Unabhängigkeit ist schlicht nicht machbar. Dafür hängen Lieferketten, Talente und Technologien zu stark weltweit zusammen.

Fazit – weniger kopieren, mehr eigene Wege gehen

Europa wird die USA oder China in absehbarer Zeit nicht ablösen können. Aber das ist vielleicht auch gar nicht nötig. Statt von „vollständiger Unabhängigkeit“ zu träumen, sollte die EU auf strategische Autonomie setzen: in den Bereichen, die wirklich kritisch sind, eigene Lösungen aufbauen, die im Ernstfall einspringen können. Das heißt: schneller entscheiden, mehr Geld in die Hand nehmen, Produkte statt endlose Forschungsprojekte fördern – und vor allem nicht nur kopieren, was andere schon machen.

Wenn die EU den Mut hat, eigene Wege zu gehen, kann sie tatsächlich etwas bewegen. Wenn nicht, bleibt sie beim Status quo: man lernt viel, aber kommt im globalen Wettbewerb nicht voran.

Und am Ende natürlich die Hoffnung aller, dass man die Situation aussitzen kann. Hat in der Corona-Pandemie ja auch geklappt.

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?“

User	annonyme	Date	2026-02-26 17:35
Tags	api, cms, framework, hannes pries, php, slim, symfony, twig

User	annonyme	Date	2026-02-17 15:23
Tags	atl, confluence, excel, hannes pries, jira, mindset, projekt management, word

User	annonyme	Date	2026-02-12 17:47
Tags	benchmark, esxi, hannes pries, linux, server, ssd, storage, vm

User	annonyme	Date	2026-01-31 19:45
Tags	ai, context, flows, hannes pries, ki, mindset, prompt engineering, zukunft

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!