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

Blog: Blog-entries by search-pattern/Tags:

Andere Abteilungen sind nicht dumm

Ich habe über dieses Thema schon einmal geschrieben, damals vor allem im Kontext von Agenturkunden. Doch ein aktueller Anlass bringt mich dazu, es noch einmal aufzugreifen – diesmal mit Blick auf die Zusammenarbeit innerhalb derselben Firma. Genauer gesagt: auf das Verhältnis zwischen IT oder Entwicklung und allen anderen Abteilungen.

Was mich immer wieder stört, ist diese Haltung, die man leider nicht selten erlebt: Entwickler oder ganze IT-Teams verhalten sich, als wären sie die einzigen wirklich intelligenten Menschen im Unternehmen. Alles, was nicht direkt aus ihrer Welt stammt, wird schnell als unzureichend oder inkompetent abgestempelt. Anforderungen seien nicht detailliert genug, auf Rückfragen kämen keine sofortigen Antworten, sondern erst nach interner Abstimmung. Prozesse seien unklar, Entscheidungen nicht nachvollziehbar, und überhaupt – warum kennt sich die Leitung eigentlich nicht technisch bis ins letzte Detail aus?

Diese Kritikpunkte tauchen immer wieder auf. Doch die Art und Weise, wie sie vorgetragen werden, ist oft das eigentliche Problem. Dahinter steckt nicht selten eine übersteigerte Arroganz, die andere Mitarbeiter direkt oder indirekt abwertet. Es wird sich offen gewundert, wie ein Unternehmen mit solchen Leuten überhaupt funktionieren kann. Und nicht selten wird die Diskussion sogar persönlich.

Wer so denkt und handelt, hat meiner Meinung nach nicht nur ein zwischenmenschliches Problem, sondern auch ein grundlegendes Missverständnis davon, wie Arbeitswelt funktioniert. Ein IT-Leiter muss kein Top-Entwickler sein. Seine Aufgabe ist es, Verantwortung zu übernehmen, wirtschaftlich zu planen und Entscheidungen zu treffen. Dafür gibt es Entwickler im Team – genau wie es in anderen Abteilungen Experten gibt, die ganz andere Fähigkeiten mitbringen.

Denn genau das wird oft vergessen: Die Kompetenzen in anderen Bereichen sind nicht geringer, sie sind einfach anders gelagert. Marketing, Vertrieb, HR oder Controlling folgen eigenen Logiken, sprechen eigene Sprachen und lösen Probleme auf ihre Weise. Und ganz ehrlich: Jeder Entwickler, der behauptet, sämtliche Abläufe in der IT vollständig zu durchdringen, hat wahrscheinlich selbst schon die Hälfte vergessen oder nie im Detail verstanden.

Am Ende sitzen überall Fachkräfte. Menschen, die in ihrem Bereich deutlich mehr wissen als man selbst. Und wenn angeblich alle anderen so unfähig sind – wie kommt es dann, dass das Unternehmen erfolgreich genug ist, um sich teure Entwickler leisten zu können? Diese Frage sollte man sich ruhig öfter stellen.

Hinzu kommt, dass Entscheidungen im Unternehmen selten rein technisch getroffen werden. Es geht um Budgets, Risiken, Zeitpläne und strategische Überlegungen. Die „beste“ technische Lösung ist nicht immer die sinnvollste. Das zu verstehen, braucht Erfahrung – und oft auch den Blick über den eigenen Tellerrand hinaus.

Interessanterweise ändert sich die Perspektive häufig, je weiter man in seiner Karriere kommt. Mit wachsender Verantwortung wächst auch das Verständnis für die Komplexität von Entscheidungen und für die Fähigkeiten anderer. Dinge, die vorher unverständlich oder „dumm“ wirkten, ergeben plötzlich Sinn.

Als Entwickler ist man letztlich auch nur ein Teil des Ganzen. Man arbeitet mit den Informationen, die man bekommt, und bewegt sich innerhalb eines Systems, das von vielen anderen geprägt wird. Wer wirklich besser werden will, sollte anfangen, mit anderen Abteilungen zusammenzuarbeiten, ihre Denkweisen zu verstehen und ihre Sprache zu lernen.

Denn genau darin liegt der Schlüssel: Wenn jemand versucht, „IT zu sprechen“, klingt das für Entwickler oft unbeholfen. Aber das Gleiche gilt umgekehrt. Wer sich die Mühe macht, die Sprache anderer Disziplinen zu lernen, merkt schnell, wie viel Wissen und Intelligenz dort steckt.

Oder, um es mit einem Zitat aus der Serie Modern Family zu sagen: „Do you even know how smart I am in Spanish?“

Gedanken zu Kündigungen in Zeiten von KI

Über die letzten Jahre war ich mehrfach an Kündigungen beteiligt, und auch wenn jeder einzelne Fall unterschiedlich war, haben sich gewisse Muster immer wieder gezeigt. Es ging selten um fehlende Programmierfähigkeiten. Viel häufiger waren es mangelnde Erfahrung für die jeweilige Position, ein nicht passendes Mindset oder – gerade in schnelllebigen Agenturumfeldern – eine fehlende Stressresistenz. Was dabei jedoch nie gefehlt hat, waren Gespräche. Es wurde Feedback gegeben, Erwartungen wurden klar formuliert und Probleme offen angesprochen. Gleichzeitig war aber auch oft spürbar, dass gewisse Dinge nicht kurzfristig veränderbar sind. Mindset, Zuverlässigkeit oder Kommunikationsfähigkeit lassen sich nicht einfach „nachschulen“.

Trotzdem gab es immer eine gewisse Sicherheit im Hintergrund. Die meisten dieser Personen hatten zuvor gearbeitet und konnten grundsätzlich auf einem bestimmten Niveau bestehen. Wenn jemand beispielsweise als Senior eingestellt wurde, sich aber eher als Junior entpuppte, war eine Trennung zwar unangenehm, aber kein Drama. Der Markt war aufnahmefähig, insbesondere für Entwickler. Selbst Junior-Positionen waren oft verfügbar, und die Gewissheit, dass jemand wieder unterkommen würde, hat solche Entscheidungen erleichtert.

Vor Kurzem gab es wieder einen solchen Fall. Die Situation war relativ eindeutig. Es gab eine konsequente Weigerung, grundlegende Tools wie Confluence oder Jira zu nutzen. Commits ins Git-Repository erfolgten nur nach mehrfacher Aufforderung, oft mit der Begründung, dass der Code ja noch nicht fertig sei – obwohl genau darin der Sinn moderner Versionskontrolle liegt. Aufgaben dauerten um ein Vielfaches länger als erwartet, und gleichzeitig bestand eine klare Ablehnung gegenüber dem Einsatz von AI-Agents in der Entwicklung. Dazu kamen fehlende Soft Skills, teils grenzwertiges Verhalten gegenüber anderen Führungskräften und eine insgesamt mangelnde Zuverlässigkeit. Einsicht war nicht vorhanden.

Die Besonderheit in diesem Fall lag darin, dass die Person formal auf Abteilungsleiterebene agierte – weniger aus Qualifikation heraus, sondern weil zu einem bestimmten Zeitpunkt schlicht niemand anderes verfügbar war. Doch ein Titel ersetzt keine Erfahrung. Ein Junior-Entwickler wird nicht plötzlich zum CTO, nur weil es organisatorisch gerade passt.

Was mich jedoch wirklich überrascht hat, war die Reaktion auf die Kündigung. Die Aussage, man würde als Entwickler ohnehin sofort wieder einen Job finden, kam mit einer Selbstverständlichkeit, die ich so nicht mehr für realistisch halte. Noch irritierender war die Ergänzung, man könne ja sonst einfach ins Projektmanagement wechseln. Diese Haltung unterschätzt gleich zwei Dinge fundamental. Zum einen sind gute Projektmanager extrem selten, und ihre Arbeit ist alles andere als ein Ausweichplan. Zum anderen basiert erfolgreiches Projektmanagement genau auf den Fähigkeiten, die hier zuvor gefehlt haben: Kommunikation, Struktur, Verlässlichkeit und der souveräne Umgang mit Tools wie Jira.

Ich habe in meiner Laufbahn nur eine Handvoll wirklich herausragender Projektmanager erlebt, obwohl ich mit vielen gearbeitet habe. Diese Rolle erfordert ein tiefes Verständnis für Menschen, Prozesse und Prioritäten. Sie ist kein Auffangbecken für gescheiterte Entwicklerkarrieren.

Auch die Annahme, dass Entwickler grundsätzlich immer gefragt sind, beginnt zu bröckeln. Wer moderne Entwicklungstools ablehnt und stattdessen darauf beharrt, dass sich alles auch mit Word, Excel und einem geteilten Laufwerk lösen lässt, sendet klare Signale. Spätestens in Bewerbungsgesprächen, an denen erfahrene Entwickler beteiligt sind, fallen solche Haltungen schnell auf. Ebenso entwickelt man ein Gespür dafür, wie realistisch die Erwartungen eines Kandidaten sind. Wenn jemand davon ausgeht, dass jedes Ticket vollständig ausgearbeitet ist, umfassende Dokumentation vorliegt und gleichzeitig eine hundertprozentige Testabdeckung existiert, dann zeigt das weniger Professionalität als vielmehr eine fehlende Nähe zur Realität moderner Softwareentwicklung.

Interessanterweise ist Programmieren selbst nach wie vor selten das eigentliche Problem. Wenn jedoch eine vergleichsweise günstige Tool-Subscription die Produktivität eines Entwicklers um ein Vielfaches steigern könnte und dieser Mehrwert nicht genutzt wird, dann ist das ein deutliches Warnsignal. Genau hier setzt auch der Einfluss von KI an. Die aktuellen Entwicklungen verschieben die Anforderungen immer stärker in die Bereiche, in denen viele Entwickler traditionell Schwächen haben. Kommunikation wird wichtiger, Dokumentation unverzichtbar, und die Geschwindigkeit sowie Qualität in der Umsetzung steigen durch den Einsatz von KI-gestützten Werkzeugen erheblich. Gleichzeitig gewinnen das Verständnis für das jeweilige Unternehmen und seine Produkte sowie die Fähigkeit, sinnvolle Tests zu schreiben, weiter an Bedeutung.

Diese Entwicklung macht manche Profile schlicht untragbar für moderne Teams. Und auch wenn es hart klingt, hoffe ich in diesem konkreten Fall, dass nicht sofort wieder eine vergleichbare Position gefunden wird. Nicht aus Missgunst, sondern weil Entwicklung Zeit braucht. Wer noch nicht so weit ist, sollte die Chance bekommen, in einem passenden Umfeld zu wachsen. Unternehmen, die bewusst Junior-Entwickler einstellen und fördern, spielen dabei eine entscheidende Rolle. Nur so entsteht langfristig die Erfahrung, die später notwendig ist, um höhere Positionen nicht nur zu erreichen, sondern auch erfolgreich auszufüllen.

Tokenmaxxing: Kosten über Resultate

In den letzten Tagen bin ich auf einen interessanten Begriff gestoßen: Tokenmaxxing. Gelesen habe ich darüber in einem Artikel auf Golem, und die Grundidee hat mich sofort nachdenklich gemacht. Vereinfacht gesagt geht es dabei darum, möglichst viele Tokens bei der eigenen Arbeit mit KI-Tools zu generieren. Hohe Tokenzahlen bedeuten schließlich hohe Kosten – und in manchen Kreisen scheint genau das zunehmend mit Produktivität oder intensiver Nutzung von KI im Job gleichgesetzt zu werden.

Solche extremen Werte entstehen vor allem dann, wenn große Loops laufen gelassen werden oder riesige Kontexte wie komplette Codebasen in Prompts geschoben werden. Auch der parallele Einsatz vieler Agenten treibt den Tokenverbrauch schnell nach oben. Dabei dürfte es zwangsläufig zu Redundanzen kommen, weil mehrere Prozesse ähnliche Aufgaben bearbeiten oder sich gegenseitig überholen. Rein technisch ist das nachvollziehbar. Fragwürdig wird es jedoch, wenn daraus Leistungskennzahlen abgeleitet werden.

Denn ob jemand monatlich 150.000 Dollar an Tokenkosten verursacht, sagt zunächst einmal sehr wenig über seine tatsächliche Produktivität oder sein Können aus. Diese Denkweise erinnert stark an ein altes Paradigma aus der Softwareentwicklung: die Bewertung von Entwicklerleistung anhand geschriebener Codezeilen. Schon vor Jahrzehnten wurde erkannt, dass viele Zeilen Code keineswegs automatisch für Qualität stehen – häufig sogar für das Gegenteil. Guter Code ist optimiert, übersichtlich und wartbar. Und oft ist er gerade deshalb so gut, weil er so kurz wie möglich ist.

Im Grunde geht es um eine Haltung zur Problemlösung. Wer sich Zeit nimmt, nachzudenken und eine durchdachte Lösung zu entwickeln, erreicht sein Ziel meist mit weniger Aufwand – und eben auch mit weniger Tokens. Wer hingegen versucht, jedes Problem mit möglichst viel generiertem Output zu erschlagen, verliert schnell den Überblick. Hohe Tokenzahlen zeigen dann vor allem eines: dass KI intensiv genutzt wird. Sie zeigen jedoch nicht, ob sie sinnvoll eingesetzt wird. Im Gegenteil, bei sehr großen Mengen könnte man sogar vermuten, dass die Kontrolle über den Entwicklungsprozess teilweise verloren gegangen ist.

Hinzu kommt eine Nachhaltigkeitsperspektive, die man nicht ignorieren sollte. Unnötig Geld und Energie zu verbrennen, kann kaum ein sinnvolles Ziel sein – weder für Einzelpersonen noch für Unternehmen, die langfristig denken wollen. Gleichzeitig ist schwer einzuschätzen, wie verbreitet dieses Tokenmaxxing tatsächlich ist. Vielleicht handelt es sich nur um einzelne Extremfälle oder sogar um eine Form von Trolling. Ohne die konkreten Anwendungsfälle zu kennen, lässt sich auch nicht beurteilen, ob der hohe Verbrauch in bestimmten Szenarien gerechtfertigt oder sogar wirtschaftlich sinnvoll ist.

Für den normalen Entwickler sollte das Ziel jedenfalls ein anderes sein. Es geht darum, mit möglichst geringem Aufwand maximale Ergebnisse zu erzielen. Effizienz bedeutet nicht, möglichst viele Ressourcen zu verbrauchen, sondern sie klug einzusetzen. Firmen, die glauben, allein aus Tokenzahlen etwas Positives über Leistung oder Fortschritt ablesen zu können, wirken dabei fast ein wenig wie Relikte aus einer anderen Zeit. Modernität zeigt sich nicht darin, neue Kennzahlen einzuführen, sondern darin, die richtigen Fragen zu stellen.

OpenCode mit Ollama.. einfach!

Ich geh einfach mal davon aus, dass Ollama in der einen oder anderen Variante schon läuft. Dabei ist es egal ob es nativ auf einem Rechner läuft oder in einem Docker-Container.
Als Model nutzen wir Qwen3:8b. Wir starten das Model in Ollama via

ollama run qwen3:8b

darin ändern wir num_ctx und speichern es unter neuen Namen ab. Das ist EXTREM wichtig, weil sonst die Agentic Tools (z.B. schreiben von Dateien) nicht funktionieren werden.. ich habe es probiert.

/set parameter num_ctx 16384
/save qwen3:8b-16k
/bye

Nun installieren wir OpenCode (Linux):

curl -fsSL https://opencode.ai/install | bash

Und legen die Config (~/.config/opencode/config.json) an:

{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"options": {
"baseURL": "http://your_ollama_server:11434/v1"
},
"models": {
"qwen3:8b-16k": {
"tools": true
}
}
}
}
}

Nun kann man OpenCode mit opencode starten und das Model per /models auswählen und loslegen.

gemma:latest funktioniert auch, wenn man die num_ctx Anpassung vornimmt.

KI kann unsere Standards nicht einhalten

Manchmal macht es tatsächlich Spaß, mit anderen Menschen über KI in der Softwareentwicklung zu diskutieren. Besonders dann, wenn man auf Positionen trifft, die unterschiedlicher kaum sein könnten. Auf der einen Seite stehen diejenigen, die mit KI experimentieren, ihre Möglichkeiten austesten und versuchen, sie sinnvoll in den Entwicklungsalltag zu integrieren. Auf der anderen Seite gibt es immer noch viele, die jede Nutzung von KI kategorisch ablehnen. Für sie ist das Thema im Grunde bereits entschieden: KI taugt nichts, produziert keinen brauchbaren Code und spart am Ende ohnehin keine Zeit.

Interessanterweise gehen viele dieser Meinungen mit einer gewissen Verweigerungshaltung einher. Häufig hört man, dass es sich gar nicht lohne, KI überhaupt auszuprobieren. Allein das Testen sei bereits Zeitverschwendung, schließlich gebe es genügend Argumente, die angeblich belegen würden, dass KI ohnehin nichts taugt. Besonders oft fällt in diesem Zusammenhang das Argument, dass der durch KI erzeugte Code ja überprüft werden müsse. Dieser zusätzliche Review-Aufwand würde den möglichen Zeitgewinn direkt wieder zunichtemachen.

Dabei wird implizit eine bemerkenswerte Annahme getroffen: dass menschliche Entwickler offenbar keinen Code produzieren, der überprüft werden muss. Als wären Code Reviews nur deshalb erfunden worden, weil es jetzt KI gibt. In dieser Logik wäre der Code von Menschen grundsätzlich korrekt, während nur KI fehlerhaften Code erzeugt. Die Realität in der Softwareentwicklung sieht allerdings deutlich anders aus. Code Reviews existieren nicht, weil irgendjemand in der Vergangenheit KI vorhergesehen hat, sondern weil jede Quelle von Code potenziell fehleranfällig ist. Ganz egal, ob dieser Code von einer Maschine oder einem Menschen stammt.

Meine eigenen Erfahrungen zeigen ziemlich klar, dass Menschen sehr viele Fehler machen. Das ist völlig normal und gehört zum Entwicklungsprozess dazu. Jeder Entwickler hat schon schlechten Code geschrieben, oft ohne es in dem Moment zu merken. Im Vergleich dazu schneidet eine KI erstaunlich häufig ziemlich gut ab. Der entscheidende Unterschied liegt dabei weniger in der Fehlerfreiheit als in der Geschwindigkeit. Wenn ein Mensch einen Fehler macht, kann es Stunden dauern, bis er entdeckt und korrigiert wird. Mit KI laufen diese Iterationen oft innerhalb weniger Minuten ab. Fehler entstehen auf beiden Seiten, aber die Geschwindigkeit, mit der man sie finden und beheben kann, verändert sich drastisch.

Ein weiteres häufiges Argument lautet, dass der Review von KI-Code besonders aufwendig sei, weil bestehende Konzepte und Teamstandards nicht eingehalten würden. Die KI kenne diese Regeln schließlich nicht. Interessanterweise wird dabei selten erwähnt, dass neue Entwickler diese Standards ebenfalls nicht automatisch kennen. Niemand beginnt einen neuen Job und weiß intuitiv, welche internen Regeln in einem Team gelten. Auch Menschen müssen diese erst lernen, meistens anhand von Dokumentationen oder durch Gespräche mit Kollegen.

Genau dieselben Informationen könnte man einer KI ebenfalls geben. Tatsächlich liest eine KI ein solches Dokument sogar deutlich schneller als ein Mensch. Sollte es allerdings gar keine dokumentierten Standards geben, liegt das Problem vermutlich an einer ganz anderen Stelle. In vielen Teams existieren diese Regeln nämlich nur in den Köpfen einzelner Entwickler. Sobald jemand Neues hinzukommt, beginnt das mühsame Entschlüsseln dieser impliziten Erwartungen. Dass eine KI daran scheitert, zeigt dann weniger eine Schwäche der KI als eine Schwäche der vorhandenen Prozesse.

Oft wird auch argumentiert, dass eine KI gar nicht wissen könne, welche zusätzlichen Informationen in Meetings oder Calls besprochen wurden. Aber dieses Problem betrifft jeden, der an einem Meeting nicht teilgenommen hat. Wenn Informationen nicht festgehalten werden, kann niemand darauf zugreifen. Wer daraus ableitet, dass nur KI dadurch ein schlechter Entwickler wäre, müsste konsequenterweise auch jedem Kollegen, der einmal einen Termin verpasst hat, dieselbe Unfähigkeit unterstellen. In der Praxis wäre es ohnehin sinnvoller, solche Meetings zu dokumentieren oder direkt automatisch zusammenfassen zu lassen.

Ein besonders unterhaltsamer Teil dieser Diskussionen dreht sich um Coding-Standards und Code Style. Ich habe im Laufe meiner Karriere an genügend Code-Style-Meetings teilgenommen, um eine gewisse Skepsis gegenüber deren tatsächlichem Nutzen entwickelt zu haben. Häufig werden solche Meetings von jemandem initiiert, dessen persönliches ästhetisches Empfinden durch den Code anderer Entwickler beleidigt wurde. Diese Person erklärt dann zunächst ausführlich, wie wichtig ein einheitlicher Coding Style für jedes Team sei.

Darauf folgt meist eine Liste dramatischer Szenarien darüber, was alles passieren könnte, wenn man sich nicht darum kümmert. Der Code wäre angeblich schon nach wenigen Monaten völlig unlesbar. Danach werden Beispiele präsentiert, wie man Dinge „richtig“ macht. Ich habe tatsächlich einmal erlebt, dass ernsthaft gefordert wurde, die Einrückung im Code von vier auf drei Spaces zu ändern, weil dies angeblich deutlich besser lesbar sei. Nicht zwei, nicht vier – exakt drei.

Unternehmen lieben solche Initiativen, weil sie den Eindruck vermitteln, dass damit automatisch die Codequalität steigt und Fehler drastisch reduziert werden. Am Ende schreibt jemand ein Dokument mit den neuen Regeln. Dieses Dokument wird anschließend kaum noch gelesen, während es von seinem ursprünglichen Autor gelegentlich weiter gepflegt wird. In Code Reviews fallen Verstöße selten auf, weil auch der Reviewer das Dokument nie wirklich studiert hat. Manchmal gibt es dann irgendwann einen automatischen Reformat, und der Code landet wieder beim Standardstil der verwendeten IDE.

Ich habe in solchen Situationen oft gefragt, warum man bei PHP nicht einfach sagt, dass man sich an PSR-12 halten soll. Eine kurze Nachricht im Chat würde ausreichen, und jeder wüsste sofort, woran er ist. Die Reaktionen zeigen dann meist recht schnell, dass es selten wirklich um Verbesserungen ging. Häufig stehen persönliche Vorlieben oder ein gewisses Bedürfnis nach Einfluss im Mittelpunkt.

Genau hier liegt übrigens eine der Stärken von KI. Man gibt ihr einen etablierten öffentlichen Coding-Standard und lässt zusätzlich eine Pipeline laufen, die diesen Stil automatisch überprüft und erzwingt. Die KI kann sich problemlos daran halten oder bestehenden Code entsprechend anpassen. Sobald die Regeln klar formuliert sind, funktioniert das erstaunlich zuverlässig.

Grundsätzlich gilt: Wenn Prozesse sauber dokumentiert sind, kann eine KI hervorragend damit arbeiten. Wenn stattdessen viele Dinge nur im Kopf einzelner Entwickler existieren, dann deckt eine KI lediglich bereits vorhandene strukturelle Probleme auf. In gewisser Weise verhält sich die Einführung von KI sehr ähnlich wie das Onboarding eines neuen Junior Developers. Wenn ein Team daran scheitert, einer KI die notwendigen Informationen bereitzustellen, hätte es vermutlich auch große Schwierigkeiten gehabt, einen neuen Entwickler sinnvoll einzuarbeiten.

Natürlich kostet die Nutzung von KI Zeit. Man muss Prompts formulieren, Ergebnisse prüfen und manchmal nachjustieren. Aber genau diese Aufwände entstehen auch bei menschlicher Zusammenarbeit. Oft sogar in größerem Umfang. Gleichzeitig bringt KI einen enormen Geschwindigkeitsvorteil mit sich. Code entsteht in Sekunden oder Minuten statt in Stunden. Dieser Code ist nicht immer perfekt, aber perfekt war Code früher auch nicht.

Am Ende wirken viele der vorgebrachten Argumente weniger wie fundierte Kritik und mehr wie Ausreden. Dahinter steckt oft die Hoffnung, dass sich das Thema irgendwie von selbst erledigt, wenn man lange genug abwartet. Stattdessen wäre es wahrscheinlich sinnvoller, sich aktiv damit auseinanderzusetzen und die Entwicklung mitzugestalten. Denn wenn es berechtigte Bedenken gibt, dann lassen sie sich nur lösen, wenn man beginnt, mit der Technologie zu arbeiten – nicht, wenn man sie ignoriert.

Das kann ICH alles besser! – Wenn Selbstüberschätzung zum Unternehmensrisiko wird

Es gibt Kollegen, die misstrauen grundsätzlich allem, was sie nicht selbst gemacht haben. Dabei spielt es keine Rolle, ob eine Lösung von anderen Teammitgliedern stammt oder extern eingekauft wurde. Was nicht aus der eigenen Feder kommt, wird kritisch beäugt, vorschnell abgewertet oder direkt als mangelhaft abgestempelt. Besonders häufig zeigt sich dieses Verhalten im technischen Umfeld, wenn es um Software oder Hardware geht. Programme werden als fehlerhaft und unoptimiert bezeichnet, ohne dass sie jemals ernsthaft getestet oder analysiert wurden. Geräte gelten als unzuverlässig oder schlecht verarbeitet, weil einmal etwas nicht reibungslos lief. Aus einer einzelnen Beobachtung wird ein grundsätzliches Problem konstruiert.

Statt sich strukturiert mit möglichen Ursachen auseinanderzusetzen oder nüchtern nach Alternativen zu suchen, beginnt dann das große Herumbasteln. Es wird geschraubt, getauscht, umkonfiguriert und optimiert, um vermeintliche Unzulänglichkeiten zu beheben, die in dieser Form oft gar nicht existieren. Ein besonders anschauliches Beispiel war ein Mini-PC, der beim Kopieren sehr großer Dateien nicht den erhofften Datendurchsatz erreichte. Dabei wurde mehrfach erklärt, dass solche Szenarien im normalen Office-Alltag praktisch nicht vorkommen und sich bislang kein einziger Nutzer über die Performance beschwert hatte. Dennoch wurde aus diesem Einzelfall kurzerhand geschlossen, dass die gesamte Baureihe fehlerhaft sei und alle Geräte bald ausfallen würden.

Was folgte, war eine regelrechte Optimierungsodyssee. Die Wärmeleitpaste wurde ersetzt, weil es vermeintlich bessere Varianten gäbe. Mehrere zusätzliche SSDs wurden angeschafft und getestet, obwohl die eingebaute OEM-SSD für typische Büroaufgaben vollkommen ausreichend dimensioniert war. Die WLAN-Karte wurde ausgebaut, da sie als potenzielle Stabilitätsursache vermutet wurde. Das Kühlkonzept wurde als grundsätzlich schlecht durchdacht bezeichnet, Teile davon wurden mit Werkzeug entfernt und später provisorisch wieder eingebaut. Selbst nach weiteren Anpassungen und erneutem Austausch der Wärmeleitpaste blieb das Ziel, bessere Benchmarkergebnisse zu erzielen, insbesondere in synthetischen Tests wie Cinebench, die für einen Office-PC keinerlei Relevanz im Alltag haben. Am Ende zeigte das Gerät tatsächlich Probleme, doch nach so vielen Eingriffen war kaum noch nachvollziehbar, wodurch sie verursacht wurden. Ein Austausch gegen eine bewährte Alternative wie eine HP Z2 G1a wurde kategorisch abgelehnt, da der ursprüngliche Einzelfall inzwischen als Beweis für die generelle Untauglichkeit von Mini-PCs interpretiert wurde.

Ein ähnliches Muster zeigte sich bei einer Legacy-Software. Die Datenbank sei falsch aufgebaut, die Anbindung schlecht umgesetzt, alles voller Fehler. Den Entwicklern wurde unterstellt, sie hätten keine Ahnung und seien nicht in der Lage, bestehende Probleme zu beheben. Die gesamte Konfiguration wurde als unprofessionell dargestellt. Also wurde eine eigene Konfiguration entwickelt, vieles neu aufgesetzt und umgebaut. Doch nach umfangreichen Tests zeigte sich, dass die vorgenommenen Änderungen keinerlei messbare Verbesserung brachten. Die ursprüngliche Lösung funktionierte genauso gut oder schlecht wie zuvor.

Grundsätzlich ist es positiv, wenn Probleme angegangen und Lösungen gesucht werden. Doch nicht jedes kleine Symptom rechtfertigt es, ein gesamtes Produkt oder eine komplette Lösung als grundsätzlich fehlerhaft zu brandmarken. Wenn außer einer einzelnen Person niemand Probleme wahrnimmt, spricht vieles dafür, dass es sich nicht um ein systemisches, sondern um ein situatives Thema handelt. Ein sehr hochbezahlter Entwickler sollte seine Zeit nicht damit verbringen, verschiedene Wärmeleitpasten durchzutesten, um für einen Office-Rechner marginal bessere Benchmarks zu erzielen. Investierte Arbeitszeit muss in einem sinnvollen Verhältnis zum Nutzen stehen. Ressourcen sollten dort eingesetzt werden, wo sie echten Mehrwert schaffen, und nicht zur Absicherung theoretischer Grenzfälle, die im realen Betrieb nie auftreten.

Die Folgen eines solchen Verhaltens sind gravierend. Schuld wird reflexartig bei anderen gesucht, externe Partner werden unnötig unter Druck gesetzt, um Notfälle zu verhindern, die mit hoher Wahrscheinlichkeit nie eintreten werden. Es wird Geld verbrannt, ohne dass ein messbarer Impact entsteht. Gleichzeitig wird die Arbeit anderer abgewertet, obwohl sie nach bestem Wissen und Gewissen und auf Basis sauberer Tests durchgeführt wurde. Wenn ständig behauptet wird, alles ließe sich besser machen, ohne dass sich diese Behauptung jemals belegen lässt, verliert Kritik an Glaubwürdigkeit. Am Ende weiß niemand mehr, ob Einwände berechtigt sind oder lediglich Ausdruck persönlicher Selbstüberschätzung.

Besonders problematisch wird dieses Verhalten in Führungspositionen. Wer grundsätzlich niemandem im Team vertraut, wird jede Arbeit hinterfragen und kleinreden. Statt Verantwortung zu delegieren, wird alles an sich gezogen, häufig mit dem Ergebnis, dass schlechtere Lösungen entstehen, als es mit etablierten Produkten oder externem Know-how der Fall gewesen wäre. Hinzu kommen unnötige Ausgaben, weil bewährte Lösungen aus Prinzip abgelehnt werden, obwohl sie anderswo seit Jahren stabil funktionieren. Führung bedeutet jedoch, Vertrauen zu schenken, Kompetenzen zu bündeln und die Stärken anderer anzuerkennen, nicht alles selbst besser wissen zu wollen.

Am Ende bleibt eine einfache Erkenntnis: Man kann nicht alles besser. Kollegen und externe Partner arbeiten in der Regel nach bestem Wissen und Gewissen. Ohne konkreten Anlass ihre Arbeit grundsätzlich infrage zu stellen, ist nicht nur unfair, sondern auch ineffizient. Wer behauptet, alles besser zu können, muss dies auch nachweislich belegen. Wenn jedoch trotz großer Worte keine besseren Ergebnisse entstehen, sollte man eher an der eigenen Selbstwahrnehmung arbeiten als an der Hardware. Und wer dauerhaft Misstrauen sät, unnötige Kosten verursacht und etablierte Lösungen aus Prinzip ablehnt, sollte keine Führungsverantwortung tragen, denn eine solche Haltung führt selten zu besseren Ergebnissen – aber fast immer zu einem zerrütteten Team.

Sind lokale große Server tot?

Ich sitze gerade in einer Umgebung, die sinnbildlich für ein ganz bestimmtes IT-Zeitalter steht. In einem kleinen Labor werkeln drei ziemlich große ESXi-Hosts von VMware, flankiert von mindestens ebenso vielen NAS-Systemen von QNAP. In diesen Racks steckt unglaublich viel Geld. Viel Blech, viel RAM, viele SAS-SSDs, redundante Netzteile, dedizierte RAID-Controller – alles, was man sich vor ein paar Jahren unter „Enterprise“ vorgestellt hat.

Und ja, damals war das beeindruckend. Viele Windows-VMs, sauber getrennt, alles hochverfügbar, alles virtualisiert. Das war State of the Art.

Nur kam dann die Ryzen- und Epyc-Zeit.

Hier steht inzwischen als Testsystem ein unscheinbarer Mini-PC, eine Leihgabe eines Software-Anbieters. Ein kleiner Kasten mit Ryzen-CPU, 96 GB DDR5-RAM und schnellen NVMe-SSDs. Nichts davon klingt nach Rechenzentrum. Aber egal, wie viele CPUs, wie viel RAM oder wie viele SAS-SSDs ich einer VM auf den großen Hosts zuweise – an die gefühlte und messbare Performance dieses kleinen Ryzen-Systems kommt keine davon heran. Nicht, weil die VM schlecht konfiguriert wäre, sondern weil der Unterbau limitiert. Alte CPUs von 2017 oder 2019, Storage-Anbindungen, die nie wirklich auf NVMe-Niveau waren, gewachsene Strukturen, die auf maximale Konsolidierung statt auf maximale Performance ausgelegt sind.

Cloud war übrigens auch mal ein Thema. Noch bevor ich dazu gestoßen bin, wurden die Pläne wieder beerdigt. Zu teuer, zu komplex, zu viele offene Fragen. Also blieb alles on-prem – aber eben in einem Denkmuster, das stark in den 2010ern verwurzelt ist.

Dicke ESXi-Server mit einem Zoo aus Windows-VMs waren lange total in. Jede Anwendung bekam ihren eigenen Windows Server. Eine MongoDB hier, eine Firebird-Datenbank dort, noch ein Applikationsserver daneben. Alles sauber getrennt, alles ordentlich lizenziert, alles virtuell – aber auch alles schwerfällig. Heute frage ich mich ernsthaft, warum eine MongoDB oder eine Firebird-Datenbank zwingend auf einem eigenen Windows-Server laufen muss, wenn sie sich technisch problemlos in getrennten Docker-Containern auf einem schlanken Linux-Host betreiben ließe. Containerisierung ist kein Hype mehr, sondern Alltag. Docker-Setups sind reproduzierbar, leichtgewichtig und in vielen Fällen performanter als klassische VM-Monolithen.

Stattdessen werden weiter große Server gekauft. Schwer, teuer, beeindruckend auf dem Datenblatt – aber mit erstaunlich langsamen CPUs. Die „neueste“ CPU-Generation hier stammt von 2019, der Rest von 2017. In rechenintensiven OCR-Anwendungen würde vermutlich schon ein mittelmäßiger AMD EPYC 4005 die teuren Xeons deutlich abhängen. Und wenn man dann noch an eine kleine GPU wie die NVIDIA A2 mit 16 GB VRAM denkt, wird klar, wie viel Potenzial hier brachliegt – nicht aus Mangel an Budget, sondern aus Mangel an Paradigmenwechsel.

Refurbished-Hardware spart auf dem Papier Geld, und ich bin grundsätzlich ein Freund davon. Aber man landet schnell an einem Punkt, an dem günstige, moderne Systeme die objektiv bessere Wahl gewesen wären. Gerade bei den heutigen Speicherpreisen relativiert sich vieles. Server-Hardware ist teuer, keine Frage. Doch wenn man Systeme mit fest verbautem, aber schnellem Speicher betrachtet, wird es plötzlich interessant. Und ein Server ohne NVMe-SSDs fühlt sich inzwischen schlicht nicht mehr zeitgemäß an.

Für mich sind die Zeiten der riesigen, alles-konsolidierenden Server weitgehend vorbei. Ich würde lieber mehrere kompakte Workstation-Systeme wie den HP Z2 G1a ins Rack stellen, jeweils mit 128 GB schnellem RAM und NVMe-Storage, dazu sauber angebundener Blockspeicher von den NAS-Systemen. Anwendungen granular verteilen, Dienste klar trennen, auf schlanke Lösungen wie Docker setzen, wo immer es geht. Ein Fileserver muss nicht zwangsläufig eine Windows-VM sein, wenn das NAS selbst diese Aufgabe solide übernehmen kann. Warum also noch Maschinen mit 3 TB RAM und vier CPUs betreiben, die im Kern nur Windows-VMs vorhalten und bei denen ausgerechnet an der schnellen Massenspeicheranbindung gespart wurde?

Vielleicht sind große lokale Server nicht tot. Aber ihr bisheriger Einsatzzweck gehört zunehmend hinterfragt. Die Frage ist nicht mehr, wie viel wir auf einen Host packen können, sondern wie wir mit möglichst wenig Overhead möglichst viel reale Leistung bekommen. Weniger Ballast, mehr Fokus. Weniger Nostalgie für alte Architekturprinzipien, mehr Mut zu schlanken, modernen Setups.

Manchmal ist der kleine, unscheinbare Mini-PC im Rack die deutlich ehrlichere Antwort als das nächste tonnenschwere „Enterprise“-Monster.

PDFs sind keine Digitalisierung

Wir leben in einer Zeit, in der „alles digital“ sein soll. Papier gilt als Relikt vergangener Tage, und in vielen Unternehmen ist das erklärte Ziel, möglichst keine physischen Dokumente mehr zu produzieren. Gleichzeitig zeigt der Alltag, dass Papier noch erstaunlich oft zum Einsatz kommt. Doch selbst dort, wo Ordner verschwinden und Scanner surren, bedeutet das noch lange nicht, dass echte Digitalisierung stattfindet.

Denn wer seine Zettelwirtschaft einfach einscannt und als PDF ablegt, hat im Kern nur das Medium gewechselt. Der Prozess dahinter bleibt derselbe. Eine digitale Mitarbeiterakte ist eben nicht einfach ein Netzlaufwerk mit hunderten von eingescannten Dokumenten. Ein Produktkatalog, der als PDF verschickt oder auf die Website gestellt wird, ist kein digitaler Vertriebskanal, sondern lediglich ein gedrucktes Dokument in neuem Gewand. Das Ergebnis wirkt moderner, doch die Strukturen bleiben analog gedacht.

Wer durch kleine und mittelständische Unternehmen in Deutschland geht, gewinnt oft den Eindruck, dass die gesamte Organisation auf vier Grundpfeilern ruht: Windows, Word, Excel und Outlook. Diese Werkzeuge sind allgegenwärtig und zweifellos nützlich. Doch sie ersetzen keine durchdachten Systeme. Spezialisierte Lösungen wie PIM-, CRM- oder Warenwirtschaftssysteme sind deutlich seltener im Einsatz, als man es in einer angeblich digitalisierten Wirtschaft erwarten würde. Je größer und internationaler ein Unternehmen ist, desto eher findet man solche spezialisierten Softwarelösungen. Gerade kleinere Firmen hingegen begnügen sich häufig damit, Papier in Dateien zu verwandeln, ohne ihre Prozesse grundlegend zu hinterfragen oder anzupassen.

Besonders irritierend ist in diesem Zusammenhang, wie hartnäckig sich alte Denkweisen halten. Dass der Begriff „Fax“ im Jahr 2026 immer noch selbstverständlich fällt, wirkt fast surreal. Warum sollte man eine PDF-Datei faxen, wenn sie sich per E-Mail in Sekunden verschicken lässt? Solche Fragen zeigen, dass es oft nicht an der Technik fehlt, sondern am Verständnis für digitale Möglichkeiten und an der Bereitschaft, Gewohnheiten zu verändern.

Ein zentrales Problem ist dabei das mangelnde Bewusstsein für den Wert strukturierter Daten. Ein gescanntes Dokument ist im Grunde nur ein Bild. Es lässt sich nicht sinnvoll auswerten, automatisiert verarbeiten oder zuverlässig analysieren. Echte Digitalisierung bedeutet, Informationen so zu erfassen, dass sie durchsuchbar, verknüpfbar und auswertbar sind. Reports, Analysen und Auswertungen sollten nicht davon abhängen, dass ein Mitarbeiter stundenlang Daten manuell zusammensucht und in Excel-Tabellen kopiert. Moderne Systeme erledigen solche Aufgaben automatisiert und schaffen damit Freiräume für wertschöpfende Tätigkeiten.

Wer als Entwickler in ein solches Umfeld kommt, stellt schnell fest, dass die Rolle weit über das reine Programmieren hinausgeht. Man wird zum Berater, manchmal sogar zum Übersetzer zwischen alter und neuer Welt. Es geht nicht nur darum, Software einzuführen, sondern Mindsets zu verändern und Versäumnisse der letzten fünfzehn Jahre aufzuholen. Das ist oft ein kultureller Prozess, kein technischer.

Und nein, ein Unternehmen ist nicht automatisch modern, nur weil seine Excel-Datei in der Cloud liegt oder über OneDrive synchronisiert wird. Die Speicherung ändert nichts an der grundlegenden Logik, nach der gearbeitet wird. Digitalisierung bedeutet nicht, analoge Prozesse zu konservieren und ihnen einen digitalen Anstrich zu geben. Sie bedeutet, Prozesse neu zu denken, Daten strukturiert nutzbar zu machen und Technologie als strategisches Werkzeug zu verstehen. PDFs sind dabei höchstens ein Zwischenschritt – aber ganz sicher nicht das Ziel.

KI ohne messbaren Impact – oder nur falsch eingeführt?

In den letzten Monaten war immer wieder zu lesen, dass Unternehmen trotz verfügbarer KI-Werkzeuge keine echte Steigerung ihrer Produktivität messen konnten. Führungskräfte berichten davon, dass man viel ausprobiert habe, Lizenzen eingekauft wurden und dennoch am Ende keine klaren Zahlen vorlägen, die einen Durchbruch belegen. Auffällig ist jedoch, dass selten darüber gesprochen wird, wie genau KI eingeführt wurde, welche Bereiche betroffen waren und welche Erwartungen man eigentlich an den Einsatz geknüpft hat.

KI ist kein Werkzeug wie Outlook, das man einfach jedem Mitarbeitenden zur Verfügung stellt, in der Hoffnung, es werde sich schon von selbst sinnvoll integrieren. Wer Unternehmen beobachtet, die gleichzeitig KI- und Cloud-Initiativen starten, erkennt schnell ein wiederkehrendes Muster. Technologie wird bereitgestellt, doch Prozesse, Verantwortlichkeiten und Denkweisen bleiben unverändert. Die Enttäuschung folgt dann meist planbar.

Nicht jeder Arbeitsbereich profitiert in gleichem Maße von KI. Wer täglich viele E-Mails schreibt, braucht oft keine komplexen Prompts, wenn das Formulieren des Prompts am Ende genauso lange dauert wie die Nachricht selbst. Zudem wiederholen sich Formulierungen häufig, sodass der Mehrwert begrenzt ist. Ganz anders sieht es in der Softwareentwicklung aus. Dort entstehen Prototypen nicht mehr erst nach zwei Tagen intensiver Arbeit, sondern entwickeln sich bereits während der Konzeptionsphase. Neue Features lassen sich schneller implementieren, wodurch deutlich mehr Zeit für Tests, Qualitätssicherung und echte Verbesserung bleibt. Der Effekt ist hier nicht nur eine Beschleunigung, sondern auch eine qualitative Verschiebung der Arbeit.

Entscheidend ist jedoch nicht allein das Werkzeug, sondern das Verständnis für seinen Einsatz. KI sinnvoll zu nutzen bedeutet nicht, fünf Standard-Prompts zu kennen und diese minimal anzupassen. Jede Aufgabe ist anders, jede Fragestellung hat ihren eigenen Kontext. Wer glaubt, zwei Entwickler könnten sich intensiv einarbeiten und anschließend zwanzig weiteren Kolleginnen und Kollegen in einer kurzen Schulung ein paar Prompts an die Hand geben, damit das gesamte Team „KI-enabled“ ist, unterschätzt die Tiefe des Themas. KI ist weniger eine Frage der Bedienung als eine Frage des Mindsets.

Gerade im klassischen Büroalltag zeigt sich diese Problematik besonders deutlich. KI verhält sich hier ähnlich wie Cloud-Technologie. Man kann nicht einfach OneDrive bereitstellen, einen Link mit der Überschrift „So funktioniert OneDrive“ verschicken und erwarten, dass plötzlich alle Prozesse cloudbasiert, effizient und strukturiert ablaufen. Technologie entfaltet ihren Nutzen nur dann, wenn Menschen verstehen, wie sie bestehende Arbeitsweisen anpassen müssen, um von den Vorteilen zu profitieren. Es geht darum, Arbeitsprozesse neu zu denken, statt alte Muster digital zu kopieren.

Warum bleibt der messbare Impact also häufig aus? Oft werden lediglich Werkzeuge bereitgestellt, ohne begleitende Strukturveränderung. Man verlässt sich darauf, dass Mitarbeitende schon selbst herausfinden werden, wie man KI sinnvoll einsetzt, ohne ihnen dafür Zeit oder Raum zum Experimentieren zu geben. Führungskräfte, die selbst wenig Berührungspunkte mit der Technologie haben, können zudem schwer beurteilen, ob sie richtig oder oberflächlich genutzt wird. Hinzu kommt, dass Produktivität in vielen Bereichen schon vor der Einführung von KI schwer messbar war. Backoffice-Abteilungen oder interne Softwareentwicklung generieren keinen unmittelbar sichtbaren Umsatz. Wer hier erwartet, einen Monat nach Einführung direkt messbare Gewinnsteigerungen zu sehen, setzt falsche Maßstäbe.

Eine ernsthafte Einführung von KI bedeutet deshalb, jeden Arbeitsplatz und jeden Prozess einzeln zu betrachten. Es geht darum zu analysieren, wo echte Hebel liegen, wie Verbesserungen bewertet werden können und welche Kennzahlen überhaupt sinnvoll sind. In vielen Bereichen führt KI bereits heute zu enormen Produktivitätssteigerungen oder zumindest zu einer Verschiebung von Tätigkeiten, sodass die Qualität der Ergebnisse deutlich steigt. Nicht jede Verbesserung zeigt sich sofort in Umsatzkennzahlen, manche äußert sich in geringerer Fehlerquote, höherer Innovationsgeschwindigkeit oder zufriedeneren Mitarbeitenden.

Wer behauptet, KI bringe keinen messbaren Impact, sollte sich daher zunächst selbstkritische Fragen stellen. Liegt es vielleicht am Aufgabenbereich, in dem der Nutzen naturgemäß geringer ist? Wurden Mitarbeitende wirklich geschult, eingebunden und befähigt, oder hat man ihnen lediglich ein neues Tool vor die Nase gesetzt? Und misst man womöglich falsch, weil man davon ausgeht, dass sich Verbesserung ausschließlich in kurzfristigen finanziellen Kennzahlen zeigen muss?

Einfach zu sagen, KI bringe nichts und man müsse sich deshalb nicht weiter damit beschäftigen, ist eine bequeme Haltung. Langfristig jedoch werden jene Unternehmen vorne liegen, die nicht nur Werkzeuge einführen, sondern Denkweisen verändern. Wer heute aus Frust oder Ungeduld aussteigt, könnte morgen feststellen, dass andere im selben Marktumfeld sehr wohl gelernt haben, das Potenzial zu heben. Dann war es nicht die Technologie, die keinen Impact hatte, sondern die eigene Ignoranz gegenüber dem notwendigen Wandel.

„Wenn du doch länger brauchst, sag bitte dann Bescheid …

Diesen Satz habe ich in Projekten schon oft gehört. Und jedes Mal schwingt darin dasselbe mit: Unsicherheit. Unsicherheit darüber, wie lange etwas wirklich dauert, was es am Ende kosten wird und wer eigentlich das Risiko trägt.

Ich mochte Projektarbeit zu Festpreisen schon immer lieber als Time & Material. Und seit ich wieder in der internen Softwareentwicklung arbeite und regelmäßig mit Agenturen und externen Anbietern zu tun habe, fühle ich mich darin nur noch mehr bestätigt.

Ich brauche keine hochkomplexen Kalkulationen, um das Risiko eines Projekts zu bewerten. Ein Festpreis zwingt automatisch dazu, sich früh Gedanken zu machen: Was ist wirklich Teil des Projekts, was nicht, und wo liegen die Unsicherheiten? Gerade auf Kundenseite ist das ein enormer Vorteil. Freigaben zu bekommen ist viel einfacher, wenn nicht ständig die Frage im Raum steht, was passiert, wenn das Projekt fast fertig ist, aber doch noch mehr Geld benötigt wird – und ob es sich dann überhaupt noch lohnt, weiterzumachen.

Auch in der Rolle des Anbieters ziehe ich Festpreise klar vor. Ich weiß von Anfang an, was ich verdienen werde und wie lange ein Projekt maximal dauern darf. Dadurch lasse ich mich nicht auf Endlosprojekte ein, bei denen zwar kontinuierlich Geld fließt, aber kein Ende in Sicht ist. Nachverhandlungen entfallen ebenfalls, weil der finanzielle Rahmen klar ist und sich daran nichts mehr ändert.

Diese Klarheit hat einen wichtigen Nebeneffekt: Ich muss selbst sauber planen. Eigene Unzulänglichkeiten lassen sich nicht einfach auf den Kunden abwälzen, indem man sagt, dass alles eben länger dauert und deshalb mehr kostet. Gleichzeitig nimmt ein Festpreis dem Kunden sehr viel Unsicherheit. Selbst wenn etwas nicht ideal läuft, steigen die Kosten nicht plötzlich. Diese Sicherheit ist Kunden auch Geld wert. Viele zahlen lieber etwas mehr, als später intern erneut Prozesse durchlaufen zu müssen, um zusätzliches Budget freizugeben.

Natürlich hat Time & Material seine Berechtigung. In der Praxis verleitet dieses Modell jedoch schnell zu problematischem Verhalten. Häufig wird nicht ausreichend geplant oder spezifiziert, weil Vorleistungen nicht bezahlt werden und man möglichst schnell abrechenbare Stunden generieren möchte. Neue Anforderungen werden gerne noch in laufende Projekte aufgenommen, weil sie vielleicht noch ins geplante Budget passen könnten. In der Realität tun sie das nie. Beim Festpreis ist hingegen klar, dass zusätzliche Anforderungen extra kosten – und vor allem auch, wie viel genau.

Time & Material ermöglicht außerdem Preis-Dumping, weil kein Risiko eingepreist werden muss. Beim Festpreis werden sowohl der Initialaufwand als auch ein Puffer berücksichtigt. Bei Time & Material wird dagegen oft gehofft, diesen Initialaufwand über die Laufzeit des Projekts zu kompensieren. Wenn alles länger dauert, ist das erst einmal egal, denn der Kunde zahlt weiter – zumindest so lange, bis er sich weigert oder das Ganze juristisch eskaliert.

Ein weiterer Punkt, der mir beim Festpreis wichtig ist, betrifft die eigene Freiheit in der Zeitplanung. Dem Kunden ist es egal, wie lange ich tatsächlich brauche oder wann ich arbeite. Ich liefere ein Feature, keine Arbeitszeit. Natürlich kann auch ein Festpreisprojekt grob zeitlich eingeordnet werden, und das ist oft sinnvoll, damit der Kunde weiß, wann er womit rechnen kann. Der entscheidende Unterschied ist jedoch, dass der Druck nur auf der Auslieferung liegt und nicht darauf, möglichst wenig Zeit zu bezahlen.

Sollte etwas deutlich schneller gehen als gedacht, kann man immer noch einen Rabatt gewähren. Das freut den Kunden und stärkt die Beziehung. Die Kontrolle bleibt dabei trotzdem beim Anbieter, und der Kunde kann keinen Druck aufbauen in der Hoffnung, durch Verzögerungen weniger zahlen zu müssen.

Mein persönliches Fazit – gerade auch mit Blick auf neue Arbeitsweisen und KI – ist daher recht klar: Es geht um den Wert eines Features, nicht um die Zeit, die seine Umsetzung gebraucht hat. Wenn jemand eine sehr gute Idee hat und dadurch extrem schnell liefert, ist das oft mehr wert als eine Lösung, die länger braucht. Eigentlich sollte dann auch genau diese Leistung besser bezahlt werden.

Lass dir Schnelligkeit und Qualität bezahlen, nicht die Tatsache, dass du besonders lange an einem Feature arbeitest. Gib dem Kunden die Kontrolle über das Projekt zurück. Denn je geringer das Risiko ist, desto entspannter – und am Ende auch besser – arbeiten alle Beteiligten.

Vibe-Coding ist keine Demokratisierung

In meiner LinkedIn-Bubble lese ich aktuell ständig von Menschen, die sich durch „Vibe-Coding“ in kürzester Zeit großartige Produkte gebaut haben – ganz ohne Programmierer.

Sie seien nun endlich selbst in der Lage, ihre Vorstellungen und Pläne in ein fertiges Produkt zu verwandeln. Kein Ticket schreiben. Kein Entwickler-Briefing. Kein Warten.

Das klingt nach Demokratisierung.
Ist es aber nicht.

Die Rolle des Programmierers war nie die, die man ihr gerade zuschreibt

Was mich an dieser Erzählung stört: Sie schiebt die Rolle des klassischen Programmierers in eine Höhe, die sie seit Jahren faktisch nicht mehr innehat.

Anfang der 2000er war Programmieren tatsächlich noch stark mit technischer Exzellenz verbunden. Man schrieb viel Code selbst, dachte intensiv über Strukturen und Speicher nach und arbeitete teilweise sogar noch direkt mit Pointern. Wer mit C oder gar Assembler gearbeitet hat, weiß, wie viel konzeptionelle und technische Denkleistung darin steckte. Damals bestand ein großer Teil der Arbeit darin, sich überhaupt zu überlegen, wie eine Idee technisch umsetzbar ist und wie sie sauber im Code abgebildet werden kann.

Ab etwa 2010 hat sich das grundlegend verändert. Frameworks und Libraries haben einen Großteil der Arbeit übernommen. Mit Maven, Composer oder npm zieht man sich heute nahezu alles ins Projekt, was man benötigt. Authentifizierung, UI-Komponenten, Datenbankzugriff oder komplette Backend-Strukturen lassen sich mit wenigen Befehlen integrieren. Die wirklich harte technische Komplexität ist in den meisten Anwendungsbereichen verschwunden oder zumindest stark abstrahiert worden.

Code schreiben ist heute keine Kunst mehr

Das meine ich nicht abwertend, sondern nüchtern. In den allermeisten modernen Softwareprojekten ist das eigentliche Schreiben von Code nicht mehr der kreative Kern der Arbeit. Es ist häufig Fleißarbeit.

Man hat den Plan im Kopf, kennt die Architektur und weiß genau, wie das System aufgebaut sein soll. Der schwierigste Teil – das Denken, Strukturieren und Entscheiden – ist bereits passiert. Danach folgt oft nur noch die relativ langwierige Überführung dieser Gedanken in Code. Natürlich geht das mit moderner Autovervollständigung deutlich schneller als früher. Trotzdem bleibt ein Gefühl: Man würde eigentlich gerne so schnell schreiben, wie man denken kann.

Genau hier setzt KI an. Sie tippt schneller. Aber sie ersetzt nicht das Denken.

Entwickler waren schon immer mehr als Code-Schreiber

Wer nie selbst programmiert hat, denkt oft, der Entwickler sei in erster Linie derjenige, der Code schreibt. In Wirklichkeit war das schon lange nicht mehr die entscheidende Rolle.

In vielen Teams sieht man das klassische Gefälle zwischen Senior und Junior. Der Senior entwickelt Konzepte, entscheidet über Architektur, priorisiert und entwirft Lösungen. Der Junior schreibt einen Großteil des Codes. Nicht, weil er die bessere Idee hatte, sondern weil das reine Runterschreiben von Code nicht die wertvollste Kompetenz im gesamten Prozess ist.

Wenn man es so betrachtet, ersetzt KI im Grunde genau diesen mechanischen Teil. Sie ist ein schnelleres Werkzeug, das die Umsetzung beschleunigt. Mehr nicht.

Demokratisierung? Nein.

Demokratisierung würde bedeuten, dass sich die Machtverhältnisse verschieben. Dass plötzlich Menschen Produkte entwickeln können, die es vorher nicht konnten.

Aber das stimmt so nicht.

Die Person, die ein Produkt wirklich durchdenken und entwickeln kann, konnte das auch schon vorher. Programmieren zu lernen ist heute kein exklusives Privileg mehr. Die Tools sind seit Jahren zugänglich, die Komplexität in vielen Bereichen stark reduziert und die Einstiegshürden vergleichsweise niedrig. Wer in der Lage ist, ein Produkt sauber zu konzipieren, wäre auch ohne KI in der Lage gewesen, es selbst zu programmieren. Es hätte nur mehr Zeit gekostet.

KI spart Zeit. Sie verschiebt keine Kompetenz.

Der eigentliche Engpass war nie das Programmieren

Meine Mutter wird kein Produkt per Vibe-Coding entwickeln. Nicht, weil am Ende kein Code generiert würde. Sondern weil sie bereits an der grundlegenden Entwicklung und am Konzept scheitern würde.

Der eigentliche Engpass liegt nicht im Schreiben von Code, sondern in der Fähigkeit, Probleme sauber zu analysieren, Anforderungen zu strukturieren, Prioritäten zu setzen, Features sinnvoll zu designen und ein echtes Verständnis für Nutzer und deren Bedürfnisse zu entwickeln. Genau dort entsteht der Wert. Genau dort entscheidet sich, ob ein Produkt funktioniert oder nicht.

Diese Kompetenzen waren schon immer entscheidend – lange bevor KI existierte.

Wer sollte hier eigentlich stolz sein?

Deshalb mein Punkt: Wer jetzt stolz ist, per Vibe-Coding ein Produkt gebaut zu haben, sollte Programmierer nicht größer machen, als sie sind, und sich selbst nicht kleiner, als man eigentlich ist.

Die Kompetenz lag nie primär im Tippen von Code. Sie liegt im Denken, im Strukturieren und im echten Produktverständnis.

KI macht den Prozess schneller. Aber sie demokratisiert ihn nicht.

Die Macht verschiebt sich nicht.
Nur das Werkzeug wird schneller.

Und vielleicht ist genau das die eigentliche Wahrheit hinter dem ganzen Hype.

Schnelles Kopieren einer Firebird-2.5-Datenbank unter Linux

Wer mit großen Firebird-2.5-Datenbanken arbeitet, kennt das Problem:
Ein klassisches Backup mit gbak kann extrem lange dauern. In meinem Fall benötigte ein gbak-Backup einer ca. 90-GB-Datenbank auf einem Surface-PC über 12 Stunden.

Mit nbackup lässt sich das gleiche Ziel jedoch in rund 20 Minuten erreichen.

Der verwendete Befehl

cd /usr/local/firebird/bin && \
./nbackup -user SYSDBA -password masterkey -L /firebird/data/testdb.fdb && \
cp /firebird/data/testdb.fdb /firebird/data/testdb_bkp_$(date +%Y%m%d).fdb && \
./nbackup -user SYSDBA -password masterkey -N /firebird/data/testdb.fdb && \
./nbackup -user SYSDBA -password masterkey -F /firebird/data/testdb_bkp_$(date +%Y%m%d).fdb

Was passiert hier genau?

nbackup -L (Lock)
Die Datenbank wird kurzzeitig in einen konsistenten Zustand versetzt.
Schreibzugriffe werden blockiert, laufende Leser dürfen weiterarbeiten.

cp
Die Datenbankdatei wird direkt auf Dateisystem-Ebene kopiert.
Das ist extrem schnell, da keine logische Analyse der Daten erfolgt.

nbackup -N (Normal)
Die Datenbank wird wieder freigegeben und arbeitet ganz normal weiter.

nbackup -F (Fixup)
Die Kopie wird „repariert“, sodass sie als eigenständige, saubere Datenbank genutzt werden kann.

Warum ist das schneller als gbak?

gbak arbeitet logisch:

- jede Tabelle,
- jeder Index,
- jeder Datensatz
wird gelesen, interpretiert und neu geschrieben.

Das ist sicher und portabel, aber bei großen Datenmengen sehr langsam.

nbackup dagegen arbeitet physisch:

- es wird praktisch eine konsistente Momentaufnahme der Datenbankdatei erstellt,
- ohne Daten zu interpretieren oder neu aufzubauen.

Das Ergebnis:
➡️ Minuten statt Stunden bei sehr großen Datenbanken.

Fazit

Für schnelle Sicherungen oder Klone großer Firebird-2.5-Datenbanken ist nbackup die deutlich bessere Wahl.
gbak bleibt sinnvoll für Migrationen oder Versionswechsel – aber für den Alltag spart nbackup enorm viel Zeit und Nerven.

nbackup gibt es natürlich auch unter Windows!

Was wird in zwei Jahren sein?

Was wird in zwei Jahren sein? Diese Frage beschäftigt mich in letzter Zeit immer häufiger. Es sind keine ausgearbeiteten Prognosen, sondern eher lose Überlegungen darüber, wie sich alles entwickeln könnte, wenn die aktuelle Dynamik anhält. Und falls es am Ende doch ganz anders kommt, dann lag ich eben daneben. Sollte sich jedoch herausstellen, dass ich mit meinen Einschätzungen richtig liege, werde ich vermutlich nicht widerstehen können, das mit einem gewissen Stolz zu erwähnen.

Wenn ich mir anschaue, mit welcher Geschwindigkeit ich in den letzten Tagen neue kleine Tools und Features in bestehende Legacy-Systeme eingebaut habe, wird mir deutlich, dass sich etwas Grundlegendes verändert hat. Aufgaben, die früher Planung, Abstimmung und viele Stunden konzentrierter Entwicklungsarbeit erfordert hätten, lassen sich heute oft in einem Bruchteil der Zeit umsetzen. Dieses Gefühl von Beschleunigung ist nicht mehr nur ein leises Hintergrundrauschen, sondern wird zunehmend zum dominanten Taktgeber im Arbeitsalltag.

Das Disruptive daran ist, dass diese Veränderung längst nicht mehr nur innerhalb der Softwareentwicklung zu spüren ist. Ich hatte zuletzt mehrere Anfragen dazu, wie sich etwa Plugins für Shop-Systeme mithilfe von KI entwickeln lassen. Gleichzeitig wächst das Unverständnis darüber, warum man noch mehrere Personentage bei einer Agentur einkaufen sollte, wenn sich vergleichbare Ergebnisse scheinbar in wenigen Stunden erzielen lassen. Diese Perspektive ist nachvollziehbar und wirft gleichzeitig spannende Fragen auf: Wie wird die Zusammenarbeit mit Agenturen künftig aussehen, wenn der eigentliche Code nicht mehr zwingend von ihnen stammt, sondern von einer KI generiert wird, die theoretisch von jedem bedient werden kann? Genau an diesem Punkt entscheidet sich, wie Agenturen in Zukunft ihren Wert definieren und ihr Geld verdienen werden.

Wird KI Jobs verändern? Daran besteht für mich kein Zweifel. Ich habe das Gefühl, mich gerade mitten im Epizentrum dieser Entwicklung zu befinden, weil die Softwareentwicklung vermutlich eines der ersten Berufsfelder ist, das die volle Härte, aber auch das enorme Potenzial dieser Technologie zu spüren bekommt. Einige Menschen werden ihren Job verlieren, wenn sie sich nicht anpassen, und selbst diejenigen, die sich weiterentwickeln, werden möglicherweise feststellen, dass künftig einfach weniger Entwickler benötigt werden.

Doch die Veränderungen gehen noch tiefer. Je besser KI wird, desto mehr verliert Software als Produkt an sich an Bedeutung. Ich ertappe mich immer häufiger dabei, dass ich nicht mehr gezielt nach Websites oder Tools suche, um kleine Aufgaben zu erledigen. Stattdessen lasse ich mir einfach eine kleine Web-App erstellen, die genau auf meinen Bedarf zugeschnitten ist. Wenn sich diese Entwicklung fortsetzt, könnte es sich irgendwann kaum noch lohnen, Standardsoftware zu kaufen, wenn man sie sich direkt individuell generieren lassen kann. Viele Anwendungen sind in ihrer Struktur einfacher, als sie auf den ersten Blick wirken, und genau hier spielt KI ihre Stärke aus.

Was also macht ein Entwickler in zwei Jahren? Ich vermute, dass sich die Rolle deutlich verschiebt. Entwickler werden stärker definieren, was Software leisten soll und wie Systeme miteinander interagieren müssen. Sie werden Code eher prüfen als selbst schreiben, Kontext zu bestehenden Legacy-Systemen dokumentieren und alte Strukturen so aufbereiten, dass KI effektiv damit arbeiten kann. Gleichzeitig werden sie Unternehmen dabei unterstützen, KI sinnvoll einzusetzen, Automatisierungen zu entwickeln und neue Arbeitsweisen zu etablieren. Das wichtigste Werkzeug eines Entwicklers wird dabei die KI selbst sein.

Für mich persönlich bedeutet das, dass ich aktuell vor allem in einem überschaubaren Zeithorizont plane. Die nächsten zwei Jahre erscheinen mir greifbar genug, um Entscheidungen über neue und bestehende Systeme sowie deren Weiterentwicklung und Pflege zu treffen. Ich gehe davon aus, dass KI in diesem Zeitraum ein Niveau erreicht, auf dem sich ein Großteil der benötigten Standardsoftware direkt generieren lässt. Sollte mir ein Legacy-System dann nicht mehr passen, könnte es realistischer werden, es einfach neu zu bauen, statt es mühsam weiterzuentwickeln.

Ich stelle mir Meetings vor, in denen Fachabteilungen und Entwickler gemeinsam Anforderungen formulieren, während im Hintergrund bereits neue Versionen der Software entstehen. Eine Art „Vibe-Coding“ im größeren Maßstab, bei dem Systeme kontinuierlich angepasst und neu zusammengesetzt werden. Mein persönlicher Vorteil liegt dabei weniger im eigentlichen Programmieren, sondern darin, dass ich die Firma, ihre Prozesse und ihre Sprache kenne. Diese Fähigkeit, Anforderungen klar und eindeutig zu formulieren, könnte wichtiger werden als jede einzelne Programmiersprache.

Am Ende bleibt dennoch eine große Unsicherheit. Es wird sich zeigen, ob diese Entwicklungen tatsächlich in der Geschwindigkeit eintreten, die heute möglich erscheint, und welche Auswirkungen sie auf Gesellschaft und Wirtschaft haben werden. Mein Eindruck ist, dass Deutschland auf viele dieser Veränderungen noch nicht ausreichend vorbereitet ist. Umso spannender wird es sein zu beobachten, wie sich Technologie, Arbeitswelt und Erwartungen in den kommenden Jahren gegenseitig beeinflussen und neu ausrichten.

Was verstehe ich unter einem Commitment?

Der Begriff Commitment wird im Arbeitsalltag häufig verwendet, bleibt dabei aber oft unscharf. Für mich bedeutet ein Commitment deutlich mehr als ein loses „Ich kümmere mich darum“. Es ist eine bewusste Zusage und die Grundlage für professionelle Zusammenarbeit sowie für Vertrauen innerhalb eines Teams.

Ein Commitment beginnt damit, dass man klar kommuniziert, bis wann man sich um ein Thema gekümmert hat. Anschließend tut man alles dafür, diesen Zeitpunkt auch einzuhalten. Dabei geht es nicht darum, dass immer alles perfekt läuft. Entscheidend ist vielmehr, Verantwortung für die eigene Zusage zu übernehmen.

Es ist grundsätzlich kein Problem, wenn ein Commitment nicht eingehalten werden kann. Wichtig ist jedoch, dass die Gründe dafür nachvollziehbar sind und dass sie rechtzeitig und vollständig kommuniziert werden. Überraschungen kurz vor Ablauf oder gar erst auf Nachfrage untergraben Vertrauen und erschweren Zusammenarbeit unnötig.

Zu einem Commitment gehört für mich immer auch eine saubere und transparente Kommunikation. Dazu zählt, offen darzulegen, was konkret bereits umgesetzt wurde und welche Schritte unternommen wurden. Ebenso wichtig ist es, ehrlich zu benennen, welche Probleme aufgetreten sind und ob – und von wem – versucht wurde, Unterstützung zu bekommen. Gerade bei Schwierigkeiten ist es ein Zeichen von Professionalität, sich aktiv Hilfe zu suchen, statt Probleme still auszusitzen.

Wenn es Hindernisse gab, die sich nicht überwinden ließen, müssen auch diese klar benannt werden. Dabei geht es nicht um Rechtfertigung, sondern darum zu erklären, was genau nicht funktioniert hat und welche Auswirkungen das auf das Ergebnis oder den Zeitplan hat. Ebenso gehört zu guter Kommunikation die klare Aussage, ob ein Thema abgeschlossen ist oder wann realistisch mit einem Abschluss zu rechnen ist.

Ein weiterer wichtiger Aspekt ist die Reflexion. Treten Probleme auf, sollte man prüfen, ob sich daraus Verbesserungen für die eigenen Workflows oder für die bestehende Infrastruktur ableiten lassen. Ebenso relevant ist die Frage, ob man plant, diese Verbesserungen auch tatsächlich umzusetzen. Ein Commitment endet nicht zwangsläufig mit dem Ergebnis, sondern oft erst mit den daraus gezogenen Lehren.

Kommunikation ist dabei mindestens genauso wichtig wie die Umsetzung selbst. Eine gute Lösung, über die niemand Bescheid weiß oder deren Status unklar ist, bringt in der Praxis oft wenig. Umsetzung ohne Kommunikation führt fast zwangsläufig zu Missverständnissen, Doppelarbeit oder falschen Erwartungen.

Dabei darf man niemals davon ausgehen, dass die andere Seite ja hätte nachfragen müssen. Diese Annahme erzeugt unnötige Arbeit und verschiebt Verantwortung in die falsche Richtung. Die Pflicht zur Statuskommunikation liegt immer bei der Person, die das Commitment abgegeben hat – also beim aktiven Part.

Commitments sind deshalb kein formales Beiwerk, sondern eine absolute Voraussetzung für professionelle Arbeit. Ohne verlässliche Zusagen und transparente Kommunikation funktionieren weder Planung noch Zusammenarbeit, insbesondere nicht in Teams mit mehreren Abhängigkeiten.

Gleichzeitig ist es wichtig, Commitments nicht als Maßstab für den persönlichen Wert zu missverstehen. Wenn jemand es nicht schafft, Commitments zuverlässig einzuhalten, heißt das nicht automatisch, dass diese Person ein schlechter Entwickler oder eine schlechte Fachkraft ist. Es kann jedoch ein Hinweis darauf sein, dass Rollen mit hoher Verantwortung – etwa auf Senior-Level, in der Teamleitung oder in Führungspositionen – vielleicht nicht oder noch nicht der richtige nächste Schritt sind.

Commitment bedeutet am Ende klare Zusagen zu machen, aktiv zu kommunizieren, Verantwortung für Probleme und Verzögerungen zu übernehmen und aus Fehlern zu lernen. Wer das ernst nimmt, verbessert nicht nur die eigene Arbeit, sondern auch die Zusammenarbeit im gesamten Team.

Zwei Arten von Entwicklern

In meiner Zeit als Entwickler und generell in Softwareprojekten habe ich immer wieder zwei sehr unterschiedliche Typen von Softwareentwicklern kennengelernt. Der Unterschied liegt weniger im Können oder im Wissen, sondern vor allem in der Herangehensweise bei der Lösungsfindung. Beide Gruppen können zu sehr guten Ergebnissen kommen, aber sie arbeiten auf völlig unterschiedliche Weise.

Ich selbst gehörte immer zu den Entwicklern, die sich zunächst lange Gedanken machen. Bevor die ersten Zeilen Code entstehen, steht bei mir meist eine Phase der Analyse und Konzeption. Ich überlege mir mögliche Architekturen, entwerfe Strukturen und versuche, das Problem möglichst umfassend zu verstehen. Erst wenn sich ein klares Bild ergibt, beginne ich mit der eigentlichen Implementierung. Das hat den Vorteil, dass viele Entscheidungen bereits getroffen sind, bevor sie im Code sichtbar werden.

Diese Vorgehensweise hat allerdings eine kleine Schwäche, zumindest aus Sicht vieler Kunden. Sie sehen gerne möglichst früh etwas Greifbares. Wenn über längere Zeit nichts Sichtbares entsteht, werden sie schnell unruhig. Sobald die eigentliche Entwicklung beginnt, geht es zwar oft sehr schnell voran und die Begeisterung ist groß, aber die Phase davor muss man häufig mit kleinen sichtbaren Fortschritten überbrücken, damit Vertrauen und Geduld erhalten bleiben.

Andere Entwickler haben dieses Problem kaum. Sie steigen direkt mit dem Code ein und lassen das Konzept während der Arbeit entstehen. Ideen werden unmittelbar ausprobiert, Ansätze getestet und bei Bedarf auch wieder verworfen. Für sie ist es selbstverständlich, Code neu zu schreiben oder ganze Teile zu ersetzen, wenn sich während der Entwicklung bessere Lösungen ergeben. Dabei entsteht oft ein Flow, in dem man Schritt für Schritt weiterkommt und sich die Lösung organisch entwickelt.

Auch dieses Vorgehen hat jedoch seine eigene Dynamik in der Zusammenarbeit mit Kunden. Zwar gibt es sehr früh etwas zu sehen, doch danach kann es Phasen geben, in denen sich aus Kundensicht scheinbar wenig bewegt. Vieles passiert im Hintergrund: Refactoring, neue Ansätze, verworfene Ideen und erneute Versuche. Für Außenstehende wirkt es dann manchmal so, als würde der Fortschritt langsamer werden, obwohl intern intensiv gearbeitet wird.

Wenn man sich heutige Diskussionen über Begriffe wie Vibe Coding und Context Engineering anschaut, erkennt man erstaunlich viele Parallelen zu diesen beiden klassischen Arbeitsweisen. Beim Context Engineering wird zunächst der Kontext aufgebaut, strukturiert und vorbereitet, bevor er an eine KI übergeben wird. Das erinnert stark an die Entwickler, die zuerst ein Konzept ausarbeiten und erst später mit der eigentlichen Umsetzung beginnen.

Beim Vibe Coding hingegen entsteht der Kontext während der Arbeit mit der KI. Man probiert Dinge aus, passt Prompts an, verwirft Ergebnisse und tastet sich iterativ an eine Lösung heran. Genau wie beim Entwickler, der direkt mit dem Coden beginnt und das Konzept währenddessen wachsen lässt.

Was nun besser oder schlechter ist, lässt sich kaum eindeutig beantworten. Viel hängt von persönlichen Vorlieben ab, aber auch davon, welche Informationen zu Beginn vorhanden sind und welche Erwartungen der Kunde hat. Manche Projekte profitieren von einer klaren Konzeptphase, andere von einem experimentelleren Ansatz.

Interessant ist vor allem, dass die aktuellen KI-Diskussionen im Kern keine völlig neuen Arbeitsweisen hervorbringen. Sie greifen vielmehr bekannte Konzepte der Softwareentwicklung auf und machen sie sichtbarer. Die Werkzeuge ändern sich, doch die grundlegenden Denkweisen bleiben erstaunlich konstant. KI verstärkt diese Unterschiede lediglich und räumt gleichzeitig viele Nebengeräusche aus dem Weg, die sie früher überlagert haben.

KI hat mich abgehängt. So richtig doll.

Ich habe das Gefühl, dass ich den Anschluss verliere. Und das ausgerechnet bei KI – einem Thema, mit dem ich mich eigentlich gut auskenne.

Vor zwei Jahren war die Welt noch überschaubar. ChatGPT, Stable Diffusion und eine Handvoll weiterer Tools – das war machbar. Man konnte sich reinarbeiten, Dinge ausprobieren, ein Gefühl dafür entwickeln. Heute? Heute gibt es eine schier unendliche Anzahl an mächtigen KI-Tools, Modellen, Frameworks, Agenten und Plattformen.

Ich habe eine Liste mit KI-Modellen und Anwendungen, die ich mir „mal anschauen“ will. Und das sind wohlgemerkt nur die bekanntesten. Wenn ich mir jedes neue Tool, jeden Agenten oder jedes Modell wirklich ansehen wollte, wäre ich damit den ganzen Tag beschäftigt. Und selbst das Anschauen ist ja nur die halbe Miete – richtig anwenden, verstehen, integrieren, produktiv nutzen… das kostet nochmal deutlich mehr Zeit.

Ein gutes Beispiel ist n8n. Ich habe es schon mal benutzt, weiß also, was möglich ist – und genau deshalb hätte ich gern viel mehr Zeit, mich da wirklich reinzufuchsen. Oder Suno: die Idee, das durch ein Open-Source-Modell zu ersetzen, klingt großartig. HeartMula liegt bei mir seit Wochen auf der „Will ich mir ansehen“-Liste. Seit Wochen.

Bei KI-Agenten für die Entwicklung habe ich irgendwann einfach aufgegeben. Ich nutze inzwischen JetBrains Junie – pragmatisch. Das Tool baut mir aus einer kurzen Beschreibung in zwei Minuten eine XML für einen Report, für die ich sonst 30 Minuten zusammenkopieren müsste. Okay, fairerweise: Das Haupt-Query bastle ich immer noch selbst. Aber das tue ich auch ohne KI. Und genau das ist der Punkt.

Dass ich mir flux.2-klein überhaupt angesehen habe, war gefühlt schon eine Leistung. Es hat sich gelohnt – auch wenn ich ehrlich gesagt nicht mehr sicher sagen kann, ob das besser ist als z-image-turbo. Ich glaube, wir sind an einem Punkt angekommen, an dem diese Unterschiede kaum noch wirklich greifbar sind.

Viele behaupten, die Entwicklung von KI hätte sich verlangsamt. Ich merke davon nichts. Ganz im Gegenteil: Ich komme nicht hinterher. Es kommen immer noch schneller neue Dinge heraus, als ich sie mir anschauen kann. Und selbst wenn ich es schaffe, mir etwas anzusehen, fehlt oft die Zeit, es wirklich sauber in den Alltag zu integrieren.

Eigentlich müsste ich mir bei der Arbeit einen ganzen Tag pro Woche freihalten – nur für KI. Nicht zum Spielen, sondern um sinnvoll Dinge zu evaluieren, zu testen und anzuwenden. Denn man könnte so viele Prozesse in der Firma massiv verbessern oder beschleunigen. Man kommt nur einfach nicht dazu.

2D-Images zu 3D-Meshes und dann drucken? Habe ich eine Zeit lang gemacht. Vielleicht im Sommer wieder. Die Sprünge, die es zuletzt bei BambuLab MakerWorld gab, waren schon enorm. Ich will gar nicht wissen, wie gut das inzwischen ist. Eigentlich könnte ich alles noch mal neu und besser machen.

Manchmal frage ich mich, ob „KI-Berater“ inzwischen ein anerkannter Job ist. Denn das zu werden wäre sicher spannend. Oder man holt sich einfach jemanden, der genau das übernimmt: sich mit all dem neuen Zeug auseinanderzusetzen, während man selbst die Alltagsaufgaben erledigt – oft noch ganz ohne KI.

Ich war nie ein großer Freund davon, aber inzwischen kopiere ich E-Mails mit Fragen zu OneDrive oder Datenschutz direkt in ChatGPT, überfliege die Antwort einmal kurz und schicke sie unverändert weiter. Ich bin im Grunde nur noch die Qualitätskontrolle für KI-Resultate. Und irgendwie… finde ich das auch echt gut.

Ich habe sogar eine Python-Webanwendung geschrieben – beziehungsweise von Junie schreiben lassen. Ich kann Python gut lesen, habe aber selbst nur sehr selten damit gearbeitet. Trotzdem: super Ergebnis.

All das zeigt mir wieder, wie schnell sich gerade alles verändert. Und wie schwer es selbst für mich ist, Schritt zu halten – obwohl ich mich mit solchen Themen wirklich gut auskenne und KI auch gut anwenden kann. Ich frage mich, wann diese Erkenntnis in der Breite der Gesellschaft ankommt. Wann die meisten merken, dass sie in einer Welt leben, die zunehmend von KI-Agenten dominiert wird. Dass sie die Kontrolle eigentlich schon längst verloren haben – und im Grunde nur noch akzeptieren können, wie es ist.

Und während ich das schreibe, wird mir klar: All diese Gedanken waren eben noch eine lose Liste aus kurzen Sätzen in Notepad++. Und jetzt sind sie – dank ChatGPT – ein richtiger Text.

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.

Blog-entries by search-pattern/Tags:

User	annonyme	Date	2026-05-30 20:08
Tags	hannes pries, kompetenz, kunden, mitarbeiter, sprache

User	annonyme	Date	2026-05-21 19:38
Tags	chef, cto, entwickler, hannes pries, job, ki

User	annonyme	Date	2026-05-15 18:19
Tags	hannes pries, ki, nachhaltigkeit, token

User	annonyme	Date	2026-05-14 12:55
Tags	hannes pries, ollama, opencode, qwen3, setup

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!