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

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.

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

Blog: Latest Entries (15):