eproi pur – das ist „unsere“ Kategorie in der wir ganz speziell beleuchten was uns in/um/mit eproi bewegt. Dabei sowohl technisches aus unseren Projekten aber mitunter auch tagesaktuelle IT-Themen.
Eine Datenbank liegt auf einer verschlüsselten Festplatte. Das klingt sicher. Dann meldet sich jemand mit gültigen Zugangsdaten an und führt SELECT aus. Die Daten erscheinen lesbar. Genau an diesem Punkt endet der Schutz von Encryption at Rest.
(mehr …)
In Teil 1 dieser Reihe ging es um strukturelle Fehler: fehlende Fremdschlüssel, falsche oder fehlende Indizes, zu spät gesetzte Filter und Soft Deletes, die Daten nicht wirklich löschen.
Teil 2 hat gezeigt, warum mehrere zusammengehörige Schreibvorgänge in eine Transaktion gehören. Ohne BEGIN, COMMIT und ROLLBACK kann eine Anwendung Daten in einem Zustand hinterlassen, der nie hätte entstehen dürfen.
In Teil 3 ging es um Datenbanksicherheit: Root-Zugänge, Encryption at Rest, sensible Spalten und Backups. Dieser Teil führt den Gedanken konsequent weiter.
Denn selbst ein starkes Passwort und ein geschlossener Port lösen ein grundlegendes Problem nicht: Wenn die Anwendung mit einem Benutzer verbunden ist, der alles darf, wird aus jeder Schwachstelle in der Anwendung potenziell ein vollständiger Datenbankzugriff.
(mehr …)
In Teil 1 dieser Reihe ging es um strukturelle Fehler: fehlende Fremdschlüssel, falsche Indizes, Abfragen die unter Last zusammenbrechen. In Teil 2 um Transaktionen und warum ein fehlendes BEGIN die Datenbank in Zustände bringt aus denen es keinen sauberen Ausweg gibt.
Teil 3 ist unangenehmer. Nicht weil das Thema komplexer ist, sondern weil die Fehler die hier beschrieben werden selten aus bösem Willen entstehen. Manchmal ist es Zeitdruck. Manchmal Bequemlichkeit. Oft schlicht, dass in diese Richtung noch gar nicht gedacht wurde. ‚Die Datenbank läuft, der Zugriff ist geregelt, das reicht‘ — und damit endet die Sicherheitsbetrachtung, bevor sie die entscheidenden Punkte erreicht hat.
(mehr …)
In Teil 1 dieser Reihe ging es um strukturelle Fehler: fehlende Fremdschlüssel, falsche Indizes, Soft Deletes die keine sind. Am Ende stand ein Versprechen: Transaktionen. Ein Thema das in der Theorie einfach klingt und in der Praxis erschreckend oft falsch eingesetzt wird — oder gar nicht.
(mehr …)
„Wir brauchen keinen Entwickler mehr, dafür haben wir jetzt KI.“ Dieser Satz fällt gerade in vielen Unternehmen. Manche sagen ihn laut in Meetings. Andere denken ihn still beim nächsten Budgetgespräch. Und ein paar haben bereits entsprechend gehandelt: Entwickler entlassen, Stellen nicht neu besetzt, Projekte an Tools übergeben die Prompts in Code verwandeln.
Das ist ein Fehler. Nicht weil KI nutzlos wäre. Sondern weil der Unterschied zwischen „Code erzeugen“ und „programmieren“ größer ist als er auf den ersten Blick aussieht.
Eine KI beantwortet die Frage die ihr gestellt wird. Schreibt man „Erstell mir eine PHP-Funktion die Nutzereingaben validiert“, bekommt man eine PHP-Funktion die Nutzereingaben validiert. Das ist beeindruckend. Das ist auch nützlich. Aber es ist nicht dasselbe wie Programmieren. Unklar bleibt bei diesem Prompt auch, ob es die richtigen, zielführenden Validierungen sind. Und ob im Rahmen des Projekts vielleicht noch weitere Validierungen notwendig sein würden; oder zumindest hilfreich.
Das liegt vor allem an einem Punkt: Die KI kennt nur den Kontext den man ihr explizit gibt — und der ist fast immer unvollständig. Nicht weil man es nicht besser wüsste, sondern weil beim ersten Prompt niemand daran denkt alles zu nennen: Serverumgebung, bestehende Architektur, Abhängigkeiten, Einsatzzweck, Sicherheitsanforderungen. Die KI baut sich diesen Kontext nicht selbst zusammen. Sie baut die Funktion für das was im Prompt steht und ignoriert alles was fehlt. Dabei greift sie auf clevere Algorithmen und Wahrscheinlichkeiten zurück. Daher passt das Ergebnis dann meist in abstrakten, generellen Anforderungem, aber nicht immer für die konkrete Situation.
Programmieren bedeutet: Architekturentscheidungen treffen. Wissen welcher Ansatz in drei Jahren noch wartbar ist. Verstehen wie ein Server unter Last reagiert. Einschätzen welche Datenstruktur für diesen konkreten Anwendungsfall passt und welche nicht. Sicherheitsimplikationen durchdenken bevor jemand den Code anfasst. Und sicherlich auch die Edge Cases mit im Blick haben, die der Wahrscheinlichkeit nach nicht so relevant sind, aber wenn sie auftreten, furchtbar wirken können.
All das steckt nicht im Prompt. All das ist das Handwerk hinter dem Code.
Eine Funktion die aus einem gegebenen Prompt entsteht, ist nicht zwingend eine vollständige integrative Lösung. Der entscheidende Test ist nicht „liefert sie das erwartete Ergebnis bei normaler Nutzung“ sondern: Was passiert wenn jemand sie falsch nutzt? Was passiert bei einer leeren Eingabe, einem unerwarteten Datentyp, einem Angreifer der gezielt nach Schwachstellen sucht? Und wie wirkt die Funktion im Zusammenspiel mit der gesamten Anwendung?
Diese Fragen beantworten zu können setzt voraus zu verstehen was die Funktion im Inneren macht. Wer das nicht weiß, weiß auch nicht wo sie bricht. Und KI-generierter Code bricht — nicht öfter als von Menschen geschriebener Code, aber genauso. Der Unterschied ist: Bei menschlichem Code weiß der Entwickler warum. Bei KI-Code weiß niemand es mehr.
Das ist kein Argument gegen KI als Werkzeug. Es ist ein Argument gegen KI ohne Review.
Ein CSS-Snippet per KI generieren: unkritisch. Eine Hilfsfunktion zum Formatieren eines Datums: unkritisch. Einen Login-Flow, eine Zahlungsschnittstelle, eine Rechteverwaltung per KI bauen und dann so deployen: fahrlässig.
Der Unterschied liegt nicht in der Komplexität einzelner Codeblöcke. Er liegt darin wie viele Annahmen in eine Architektur eingeflossen sind, wie viele davon sicherheitsrelevant sind, und wie viele davon ein Nicht-Programmierer weder stellen noch beantworten kann. KI kennt diese Annahmen nicht. Sie beantwortet die Frage die ihr gestellt wird nicht die Fragen die man „vergessen“ hat zu stellen.
Große Softwareprojekte entstehen nicht an einem Tag. Sie wachsen über Wochen und Monate, mit Entscheidungen die aufeinander aufbauen, mit Architekturen die sich entwickeln, mit Kontext der sich anhäuft. Und manchmal auch mit Kehrtwenden, wenn sich herausstellt, dass der Ansatz nicht trägt oder sich die Rahmenbedingungen zwischenzeitlich geändert haben.
KI hat davon nichts. Jede neue Session startet bei null. Wer täglich mit KI an einer komplexen Codebase arbeitet verbringt einen erheblichen Teil der Zeit damit die KI erst wieder in den Stand zu versetzen der nötig ist um sinnvollen Anschlusscode zu erzeugen: Hier ist die bestehende Struktur. Hier ist die bisherige Logik. Hier sind die Constraints die wir uns letzte Woche überlegt haben.
Das ist kein theoretisches Problem; es ist ein täglicher Overhead der den versprochenen Geschwindigkeitsvorteil in vielen Projekten schlicht aufzehrt. KI beschleunigt isolierte Aufgaben. Komplexe, gewachsene Systeme sind das Gegenteil davon. Dazu kommt: KI arbeitet nicht deterministisch. Und nur weil ich ihr heute wieder alles rein gebe, was wir gestern erarbeitet haben, muss im Anschluss nicht dasselbe rauskommen, was gestern rausgekommen ist.
Viele Unternehmen entlassen gerade Entwickler oft genug auch erfahrene Senior Developers. Die Begründung: KI übernimmt das. Was dabei übersehen wird: Genau diese Entwickler wären die einzigen die KI-generierten Code seriös reviewen könnten.
Wer einen Junior fragt ob der Code sicher ist, bekommt „ja“; weil er es nicht beurteilen kann. Wer eine KI fragt ob ihr eigener Code sicher ist, bekommt ebenfalls „ja“. Was fehlt ist der erfahrene Blick der weiß was er suchen muss, der Edge Cases kennt, der Sicherheitslücken erkennt bevor sie ausgenutzt werden.
Die Quittung für diese Entscheidungen kommt. Nicht heute. Aber in zwei, drei Jahren wenn Systeme die heute mit KI gebaut werden unter Last versagen, Daten verloren gehen oder Sicherheitslücken auftauchen die niemand mehr im Team schließen kann.
Funfact übrigens: Auch das Entlassen aller Junior-Developer ist fahrlässig. Wer soll denn in einigen Jahren, wenn die „alten Hasen“ weg sind, die Architektur und den Code weiterverfolgen, wenn niemand mehr gelernt hat, wie „Senior Dev“ eigentlich geht!?
KI ist ein leistungsfähiges Werkzeug für klar umgrenzte, überschaubare Aufgaben. Boilerplate-Code. Erste Entwürfe. Recherche. Erklärungen. Das alles ist genuiner Mehrwert.
Was KI nicht ist: ein Ersatz für Architekturdenken, Sicherheitskompetenz, Projekterfahrung und Reviewkompetenz. Wer das verwechselt baut schnell und baut auf Sand.
Der sinnvolle Einsatz von KI in der Softwareentwicklung setzt genau das Wissen voraus das angeblich überflüssig geworden ist: zu verstehen was hinter dem Code steckt.
KI-Unterstützung entfaltet ihren Mehrwert wenn sie von Entwicklern eingesetzt wird die den Output verstehen, prüfen und verantworten können. Wie das konkret aussieht und wie ich KI in bestehende PHP- und Laravel-Systeme integriere findest du auf unserer Seite zur KI-Integration.
Die Datenbank ist das Fundament jeder Anwendung. Das Frontend lässt sich neu bauen, Business-Logik refactoren, ein Framework austauschen — aber eine schlecht strukturierte oder langsame Datenbankschicht zieht die gesamte Anwendung nach unten. Und das meist schleichend: Nicht mit einem Knall, sondern mit Abfragen die nach und nach langsamer werden, mit Daten die irgendwann nicht mehr stimmen, mit einem System das unter Last in die Knie geht.
Trotzdem bekommt die Datenbank in vielen Projekten die wenigste Aufmerksamkeit. Sie läuft, also ist sie gut. Bis sie es nicht mehr ist.
In der Praxis sehe ich immer wieder dieselben Muster: Egal ob Neuprojekt oder gewachsenes System. Hier sind die fünf die mir am häufigsten begegnen.
(mehr …)Die Datenbank ist das Fundament jeder Anwendung. Das Frontend lässt sich neu bauen, Business-Logik refactoren, ein Framework austauschen — aber eine schlecht strukturierte oder langsame Datenbankschicht zieht die gesamte Anwendung nach unten. Und das meist schleichend: Nicht mit einem Knall, sondern mit Abfragen die nach und nach langsamer werden, mit Daten die irgendwann nicht mehr stimmen, mit einem System das unter Last in die Knie geht.
Trotzdem bekommt die Datenbank in vielen Projekten die wenigste Aufmerksamkeit. Sie läuft, also ist sie gut. Bis sie es nicht mehr ist.
In der Praxis sehe ich immer wieder dieselben Muster: Egal ob Neuprojekt oder gewachsenes System. Hier sind die fünf die mir am häufigsten begegnen.
(mehr …)
Bei der Analyse einer älteren WordPress-Installation fiel mir kürzlich etwas auf, das auf den ersten Blick harmlos wirkt: Dateien mit der Endung .php — die aber kein einziges Byte PHP enthalten. Stattdessen: XML-Strukturen, SVG-Markup, statische Inhalte. Alles prima, nur eben nicht PHP.
Klingt nach Kleinigkeit. Ist es nicht.
(mehr …)Bei der Analyse einer älteren WordPress-Installation fiel mir kürzlich etwas auf, das auf den ersten Blick harmlos wirkt: Dateien mit der Endung .php — die aber kein einziges Byte PHP enthalten. Stattdessen: XML-Strukturen, SVG-Markup, statische Inhalte. Alles prima, nur eben nicht PHP.
Klingt nach Kleinigkeit. Ist es nicht.
(mehr …)
Manchmal merkt man beim Arbeiten an einem neuen Projekt was einem an einem älteren fehlt. Genau das ist passiert: Bei neueren Laravel-Projekten haben wir direkt mit Version 13 gestartet und dabei Features entdeckt, die wir rückwirkend auch in unserem eigenen Produkt haben wollten.
Allen voran: native Suche in verschlüsselten Datenbankspalten. Ein Feature das für datenschutzsensible Anwendungen konkret relevant ist — und das in Laravel 13 sauber im Standard mitkommt, ohne eigene Konstrukte drumherum.
Dazu kam eine pragmatische Entscheidung: Lieber jetzt migrieren, bevor weitere Features dazukommen. Je mehr ein System wächst, desto mehr gibt es beim nächsten Mal zu testen und anzupassen. Wer das kennt, kennt auch den Moment wo man sich denkt: hätte ich das früher gemacht.
Das Projekt hatte über die Zeit einige eigene Klassenkonstrukte und Besonderheiten im Front- und Backend angesammelt. Dinge, für die Laravel zwar die Basis gelegt hatte, die wir aber selbständig weiterentwickelt hatten. Entsprechend stand zu Beginn gefühlt eine sehr lange Checkliste im Raum.
Am Ende zeigte sich: Es ging schneller als erwartet. Der Grund dafür hat weniger mit der Laravel-Version zu tun als mit dem Zustand des Projekts davor.
(mehr …)Manchmal merkt man beim Arbeiten an einem neuen Projekt was einem an einem älteren fehlt. Genau das ist passiert: Bei neueren Laravel-Projekten haben wir direkt mit Version 13 gestartet und dabei Features entdeckt, die wir rückwirkend auch in unserem eigenen Produkt haben wollten.
Allen voran: native Suche in verschlüsselten Datenbankspalten. Ein Feature das für datenschutzsensible Anwendungen konkret relevant ist — und das in Laravel 13 sauber im Standard mitkommt, ohne eigene Konstrukte drumherum.
Dazu kam eine pragmatische Entscheidung: Lieber jetzt migrieren, bevor weitere Features dazukommen. Je mehr ein System wächst, desto mehr gibt es beim nächsten Mal zu testen und anzupassen. Wer das kennt, kennt auch den Moment wo man sich denkt: hätte ich das früher gemacht.
Das Projekt hatte über die Zeit einige eigene Klassenkonstrukte und Besonderheiten im Front- und Backend angesammelt. Dinge, für die Laravel zwar die Basis gelegt hatte, die wir aber selbständig weiterentwickelt hatten. Entsprechend stand zu Beginn gefühlt eine sehr lange Checkliste im Raum.
Am Ende zeigte sich: Es ging schneller als erwartet. Der Grund dafür hat weniger mit der Laravel-Version zu tun als mit dem Zustand des Projekts davor.
(mehr …)
Es fing mit einer simplen Aufgabe an: Eine AJAX-Abfrage sollte idempotent werden. Konkret bedeutete das — egal wie oft der Request gefeuert wird, das Ergebnis bleibt stabil und vorhersehbar. Kein Flackern, keine Race Conditions, keine doppelten Einträge die sich gegenseitig überholen.
Die klassische Lösung: ORDER BY id. Fertig. Nächstes Problem.
Nur dass es diesmal kein nächstes Problem gab. Zumindest nicht sofort.
(mehr …)Nach unserer Event‑Ressourcenplattform Ende letzten Jahres folgt nun das nächste Produkt aus dem eproi‑Ökosystem: PageConvertPage.
Mit diesem Tool lassen sich Webseiteninhalte direkt in den gewünschten Pagebuilder übersetzen – schnell, zuverlässig und mit weitaus geringerer manueller Nacharbeit als bisher.
