Vor zwei Jahren hätte ich ein Angebot wie “interne Business-Software plus Automatisierung plus KI-Integration” für die meisten Kund:innen ehrlich nicht seriös umsetzen können – zumindest nicht als Einzelperson, nicht in vertretbarer Zeit. Heute gehört genau das zum Kern dessen, was ich anbiete. Der Grund ist nicht, dass ich plötzlich doppelt so schnell tippe, sondern dass sich verschoben hat, wo die Zeit in einem Projekt eigentlich draufgeht.

Wo die Zeit früher wirklich hinging

Der langsamste Teil eines Projekts war selten das Tippen von Code. Es war das Nachschlagen von API-Signaturen, das Schreiben von Boilerplate für die zehnte CRUD-Ressource, das Durchsuchen von Stack Overflow nach einem Edge Case, den schon mal jemand hatte. Genau diese Routine lässt sich heute an ein LLM delegieren – zuverlässig genug, dass es sich lohnt, und schnell genug, dass ganze Kategorien von Arbeit, die früher einen Tag gekostet haben, heute in einer Stunde stehen.

Das ist der eigentliche Hebel: nicht “KI schreibt die App”, sondern “KI übernimmt die Routine, ich behalte die Kontrolle über das, was zählt”.

Was sich dadurch im Angebot ändert

Wenn Routine-Arbeit schneller geht, verschiebt sich die Kalkulation für Projekte, die früher schlicht zu aufwendig für ein Einzelstudio waren:

  • Interne Tools, die sich früher nur für Unternehmen mit eigenem Dev-Team gelohnt haben, werden für kleinere Betriebe wirtschaftlich machbar.
  • Rapid Prototyping wird ernst gemeint möglich – ein klickbarer Prototyp in Tagen statt Wochen, bevor überhaupt Budget für die “richtige” Version fließt.
  • KI-Integrationen (Chatbots, Personalisierung, smarte Automatisierung) lassen sich in bestehende Produkte einbauen, ohne dass dafür ein eigenes ML-Team nötig wäre.

Das ist der Kern meiner Positionierung: nicht Nischen-Webagentur, sondern jemand, der ein deutlich breiteres Spektrum abdecken kann als noch vor Kurzem.

Wo ich bewusst nicht delegiere

Genauso wichtig ist die andere Seite. Architekturentscheidungen, Sicherheitsfragen und die langfristige Wartbarkeit einer Codebasis prüfe ich weiterhin selbst – bewusst. Ein LLM kennt weder dein Geschäftsmodell noch die Konsequenzen einer falschen Datenmodellierung in zwei Jahren. Es liefert Vorschläge, keine Verantwortung.

In der Praxis heißt das: Ich lasse mir bei einer neuen Laravel-Ressource gerne die Boilerplate für Migration, Model und Factory generieren – aber die Entscheidung, ob eine Beziehung hasMany oder doch besser über eine Pivot-Tabelle abgebildet wird, treffe ich anhand des tatsächlichen Anwendungsfalls, nicht anhand dessen, was am plausibelsten aussieht.

Ein konkretes Beispiel

Bei einem aktuellen internen Tool ging es darum, wiederkehrende Exporte (PDF und Excel) für unterschiedliche Empfängergruppen zu bauen. Früher wäre das ein guter Tag Arbeit gewesen: Paket-Recherche, Boilerplate für jedes Format, Fehlerbehandlung für Edge Cases. Mit KI-gestützter Entwicklung stand ein erster funktionierender Entwurf nach einer Stunde – die verbleibende Zeit floss in das, was tatsächlich Sorgfalt braucht: korrekte Zahlenformate, Rechteprüfung, saubere Fehlermeldungen für die Endnutzer:innen.

Fazit

KI-Tools haben nicht die Softwareentwicklung ersetzt, sondern die Grenze verschoben, was für ein Einzelstudio wirtschaftlich sinnvoll umsetzbar ist. Für mich bedeutet das: mehr Angebot, kürzere Wege von der Idee zum nutzbaren Ergebnis – bei gleichbleibendem Anspruch an Architektur und Sicherheit. Genau diese Kombination versuche ich in jedem Projekt zu liefern.