KI-Telefonassistenten gibt's ab 10 €/Monat. Der wahre Wert liegt aber in der Anbindung an CRM, Kalender und Ticketsystem – so gelingt die In...
Worum es geht: Seit mehreren Monaten setzen wir bei Aburok Softwareentwicklung Claude Code und andere KI-Tools in echten Kundenprojekten ein – nicht zum Ausprobieren, sondern produktiv, jeden Tag. Dieser Artikel ist mein ehrlicher Erfahrungsbericht. Was hat sich verändert? Wo helfen die Tools wirklich? Wo enttäuschen sie? Und was bedeutet das für unsere Kunden im Mittelstand?
Wie dieser Artikel entstanden ist
Vor einigen Wochen habe ich auf LinkedIn eine Frage gestellt, die in unserer Branche selten so direkt ausgesprochen wird: „Wird Softwareentwicklung durch KI günstiger – und kommt die Ersparnis tatsächlich beim Kunden an?"
Meine kurze Antwort dort war: Ja, sie wird günstiger. Aber bei vielen Anbietern bleibt die Ersparnis komplett beim Dienstleister. Stundensatz unverändert, Aufwand sinkt heimlich, Marge wächst – der Kunde merkt nichts. Das finde ich nicht fair.
Der Post hat erstaunlich viele Reaktionen ausgelöst – manche zustimmend, manche skeptisch („Wie viel Ersparnis konkret?"), manche herausfordernd („Bist du sicher, dass du nicht naiv bist?"). Genug Fragen, um aus dem Mini-Post einen ausführlichen, persönlichen Erfahrungsbericht zu machen.
Dieser Artikel ist die lange Version. Mit echten Projekt-Beispielen, konkreten Zahlen, ehrlichen Schwächen und einer klaren Position dazu, was das für mittelständische Unternehmen bedeutet.
Die Skepsis war groß
Als der KI-Hype Anfang 2024 richtig losging, habe ich erst einmal abgewartet. Das war keine Verweigerung. Ich entwickle seit über fünfzehn Jahren Software, und ich kenne diese Wellen: Mal heißt es, Low-Code wird die Branche umkrempeln. Mal sollen Visual Programming, Domain Specific Languages oder No-Code-Plattformen die Entwickler überflüssig machen. Am Ende läuft fast immer dasselbe: Das neue Werkzeug hat eine echte Nische – und gleichzeitig hat es nicht annähernd geliefert, was die Marketing-Versprechen behauptet haben.
Als die ersten KI-Coding-Assistenten kamen, war meine erste Reaktion: nett, aber wird sich zeigen. ChatGPT konnte beeindruckende Snippets generieren – aber in echten Projekten, mit echtem Kontext, echten Legacy-Codebases, echten Anforderungen? Da war ich vorsichtig.
Also habe ich gewartet. Habe Tools verglichen. Habe gelesen, was Kolleginnen und Kollegen berichten. Und irgendwann, als die Tools spürbar reifer wurden und sich bei mir mehrere Hinweise gehäuft hatten, habe ich angefangen, sie systematisch in meinen Arbeitsalltag zu integrieren. Erst Claude Code, dann GitHub Copilot, dann verschiedene andere – alles parallel laufend, kontinuierlich beobachtet, immer mit der Frage: Macht das hier wirklich einen Unterschied? Oder ist das nur ein anderes Tippen?
Heute, mehrere Monate später, kann ich sagen: Es ist nicht „nur ein anderes Tippen". Es hat sich tatsächlich etwas verändert. Aber nicht so, wie ich erwartet habe – und schon gar nicht so, wie es in den meisten LinkedIn-Posts klingt.
Der Moment, in dem es klick gemacht hat
Es gibt diesen einen Moment, den ich noch genau weiß. Ich saß an einem Sonntagabend an einem Kundenprojekt – eine mittelständische Firma in Nordhessen, die ihre veraltete PHP-Anwendung modernisieren wollte. Klassischer Mittelstands-Auftrag: Bestandssoftware aus dem Jahr 2014, gewachsen, schwer durchschaubar, aber geschäftskritisch.
Mein Auftrag: ein bestehendes Modul für die Kalkulation von Provisionsabrechnungen analysieren, dokumentieren und vorsichtig refactoren. Normalerweise hätte ich dafür einen halben Tag investiert – viel Lesen, viel Skizzieren, viel „warte, was macht diese Methode eigentlich genau?". Genau die Art Arbeit, die jeder Entwickler kennt und niemand wirklich liebt.
An jenem Abend habe ich versuchsweise Claude Code daran gelassen. Ich habe das Modul reingegeben und gesagt: Erkläre mir, was das macht, in deutscher Geschäftssprache, für jemanden, der den Code nicht kennt, aber das fachliche Geschäft versteht.
Was dann kam, war eine drei-seitige Erklärung, die fachlich präzise, sprachlich klar und für meinen Kunden lesbar war. Inklusive der drei verzwickten Edge Cases, bei denen ich selbst zweimal hinschauen musste. Inklusive des Hinweises auf eine Stelle, die offenbar Bug-Verdacht hatte – und der war tatsächlich da, später vom Kunden bestätigt.
Ich saß ein paar Sekunden davor und habe gedacht: Okay. Das ist nicht „nett". Das ist ein anderes Arbeiten.
Wie sich der Arbeitstag verändert hat
Wenn ich heute beschreiben sollte, wie sich mein Tag verändert hat, würde ich es so sagen: Ich verbringe weniger Zeit mit Tippen und mehr Zeit mit Denken.
Das klingt fast banal, ist aber tatsächlich der Kern. Software-Entwicklung war immer eine Mischung aus zwei sehr unterschiedlichen Tätigkeiten. Die eine ist das mechanische Schreiben von Code: Boilerplate, Tests, Migrationen, Standard-Setup, repetitive Strukturen. Die andere ist das Nachdenken über Architektur, Entscheidungen, Konsequenzen, Domäne, Kundenwünsche, langfristige Wartbarkeit.
In der klassischen Welt hat das mechanische Schreiben einen größeren Anteil ausgemacht, als die meisten Menschen außerhalb der Branche denken. Wenn ich eine neue Funktion bauen wollte, brauchte ich erst einmal eine halbe Stunde, um das Gerüst hinzustellen – Eingabe-Validierung, Datenbank-Anbindung, Error-Handling, Tests. Erst dann konnte ich mich der eigentlichen Logik widmen.
Heute mache ich diese halbe Stunde Setup-Arbeit oft in zehn Minuten. Ich beschreibe, was ich brauche, schaue mir den Vorschlag an, korrigiere drei Stellen, übernehme. Die gewonnene Zeit nutze ich nicht, um schneller fertig zu sein – sondern um länger über die wirklich wichtigen Fragen nachzudenken: Passt die Architektur zum langfristigen Plan des Kunden? Gibt es einen einfacheren Weg, das Problem zu lösen? Wo könnte das in zwei Jahren weh tun?
Das ist eine bessere Arbeitsweise. Nicht weil ich plötzlich klüger geworden bin, sondern weil mir mehr Aufmerksamkeit für die Fragen bleibt, bei denen Erfahrung wirklich zählt.
Vier konkrete Beispiele aus den letzten Wochen
Damit das nicht zu abstrakt bleibt – hier vier reale Aufgaben aus aktuellen Projekten und wie KI mir dabei geholfen oder eben nicht geholfen hat. Alle Beispiele sind anonymisiert, die Zahlen aber echt.
Beispiel 1 – Eine Schnittstelle zur Buchhaltung
Ein Kunde aus dem Großhandel brauchte eine Schnittstelle zwischen seinem Shopware-Shop und DATEV. Klingt simpel, ist es nicht. Steuerschlüssel, Reverse Charge, Rabatte, Gutscheine, Stornierungen – jede Konstellation braucht eine eigene Buchungs-Logik.
Klassisch hätte das Projekt etwa vier bis sechs Wochen Entwicklungszeit gedauert. Mit Claude Code habe ich die Standard-Buchungs-Logik in unter einer Woche gehabt – sauber strukturiert, getestet, mit ausführlichen Code-Kommentaren. Die restliche Zeit ging in die wirklich knifflige Arbeit: das Verhandeln mit dem Steuerberater des Kunden über die korrekte Behandlung von Rückerstattungen mit Gutschein-Verrechnung. Da hilft mir keine KI. Da hilft nur, sich hinzusetzen, zuzuhören, Fragen zu stellen.
Endergebnis: Projekt nach dreieinhalb Wochen produktiv. Knapp 40 Prozent Zeitersparnis. Und der Kunde hat den Vorteil weitergereicht bekommen – wir haben das Projekt zu einem Preis berechnet, der dem realen Aufwand entsprach, nicht dem historischen.
Beispiel 2 – Dokumentation einer Legacy-Software
Mittelständler, sieben Jahre alte Java-Anwendung, knapp 80.000 Zeilen Code. Der ursprüngliche Entwickler ist seit zwei Jahren nicht mehr im Unternehmen. Die Doku passt auf eine A4-Seite und ist meistens falsch.
Mein Auftrag: eine vollständige technische Dokumentation erstellen, damit zukünftige Entwickler die Anwendung warten können. Klassisch wäre das ein Drei-Wochen-Projekt gewesen – Code lesen, verstehen, schreiben, korrigieren, mit dem Kunden abstimmen, nochmal überarbeiten.
Mit Claude Code: Ich habe Modul für Modul durch das Tool gejagt und für jedes Modul eine erste Roh-Dokumentation generiert. Dann habe ich diese Rohfassung gelesen, geprüft, korrigiert, mit dem Kunden abgestimmt, ergänzt. Statt drei Wochen brauchte ich eineinhalb.
Wichtig dabei: Die KI hat nicht „die Dokumentation gemacht". Sie hat mir den ersten Wurf gegeben, den ich verifizieren und veredeln musste. Ohne meine Prüfung wären in der Doku Sachen gelandet, die nicht stimmten. Dieses ehrliche Lektorat braucht weiterhin Zeit – etwa ein Drittel der Gesamtarbeit. Aber zwei Drittel mechanische Schreibarbeit fallen weg.
Beispiel 3 – Eine neue Web-App aus dem Nichts
Ein lokales Bauunternehmen wollte ein einfaches Tool zur Verwaltung von Materialbestellungen – keine fertige Standardlösung passte, also Eigenentwicklung. Anforderung: Login für etwa fünfzehn Mitarbeiter, Bestellungs-Workflow, Anbindung an einen bestehenden Lieferanten-API, mobile Bedienbarkeit.
Klassisch: vielleicht acht Wochen Vollzeit-Entwicklung. Realistisch: vier Wochen plus zwei Wochen Test/Anpassung.
Mit KI-Unterstützung von Anfang an: Drei Wochen bis zur ersten lauffähigen Version. Wieder kein Zaubertrick – sondern weil sich die mechanische Arbeit halbiert. Architektur entwerfen, Anforderungen verstehen, Kundenfeedback einarbeiten, Edge Cases bewerten: das alles macht weiterhin der Mensch.
Beispiel 4 – Eine knifflige Debugging-Session
Hier ist das ehrliche Beispiel, das die andere Seite zeigt. Ein Kunde meldete einen sporadischen Fehler in seiner Webapp – etwa alle zwei Tage, immer um die gleiche Uhrzeit, immer mit den gleichen Symptomen. Klassisches Mysterium: kein klares Reproduktions-Szenario, keine offensichtliche Ursache.
Ich habe alles ausprobiert. Claude Code mehrfach gefragt, Logs analysieren lassen, Hypothesen generieren lassen. Die Tools haben sieben verschiedene mögliche Ursachen vorgeschlagen – alle plausibel, alle technisch sauber argumentiert. Alle falsch.
Am Ende war es ein Cron-Job auf dem Server, der nichts mit der Anwendung zu tun hatte, sondern eine Datenbank-Verbindung aufmachte und nicht sauber schloss. Habe ich rausgefunden, indem ich an einem Sonntagvormittag mit Kaffee davor saß und mir alle laufenden Prozesse angesehen habe. Klassisch. Ohne KI.
Lektion: Bei komplexen Debugging-Aufgaben mit unklarer Reproduzierbarkeit sind die heutigen KI-Tools nicht besonders hilfreich. Sie können Hypothesen generieren, aber nicht entscheiden, welche davon stimmt. Diese Arbeit liegt weiterhin beim erfahrenen Entwickler.
Was mich überrascht hat (positiv)
Drei Dinge haben mich in den letzten Monaten ehrlich überrascht – Sachen, mit denen ich nicht gerechnet hatte.
Die Tools sind besser im Erklären als im Schreiben. Wenn ich Code-Vorschläge prüfe, finde ich oft Stellen, die ich nicht so gemacht hätte – und die teilweise schlechter sind als meine eigene Version. Aber wenn ich die KI bitte, mir bestehenden Code zu erklären, ist sie häufig erstaunlich präzise. Das hat meine Erwartung umgedreht. Ich nutze die Tools deshalb mehr zum Verstehen und Diskutieren als zum reinen Generieren.
Sie sind ein guter Sparringspartner für Architektur-Entscheidungen. Wenn ich vor einer Entscheidung stehe – soll diese Funktion in den Service oder in den Controller, brauche ich hier ein Repository-Pattern, ist eine eventgetriebene Lösung besser als ein direkter Aufruf – kann ich mit der KI die Trade-offs durchspielen. Sie hat keine Meinung, sondern listet sauber auf, was die Optionen sind. Das hilft mir, meine eigene Entscheidung schärfer zu fassen.
Sie helfen beim Schreiben für Kunden. Ich entwickle Software für mittelständische Unternehmen, nicht für andere Entwickler. Das bedeutet: Ich muss regelmäßig technische Konzepte in eine Sprache übersetzen, die Geschäftsführer und Fachabteilungs-Leiter verstehen. Da bin ich mit der Zeit besser geworden, aber es kostet mich immer noch Aufmerksamkeit. Mit KI-Unterstützung schaffe ich diese Übersetzungsarbeit deutlich schneller – bei besserer Verständlichkeit für den Empfänger.
Was mich enttäuscht hat
Zwei Dinge, die in der KI-Marketing-Sprache anders klingen als in der Realität.
„Self-driving development" gibt es nicht. Auf Twitter und LinkedIn liest man Geschichten von Entwicklern, die ein ganzes Projekt nur mit KI-Befehlen gebaut haben und nie selbst Code geschrieben haben. Diese Geschichten lasse ich mal in der Hoffnung stehen, dass sie in Spielzeug-Beispielen funktionieren. In echten Mittelstands-Projekten mit Schnittstellen, Legacy-Anbindungen, regulatorischen Anforderungen und nicht-trivialer Domänenlogik geht das nicht. Wer das versucht, baut technische Schulden in Lichtgeschwindigkeit. Der Code sieht erstmal sauber aus, aber in drei Monaten kollabiert das Ganze unter dem Gewicht von Annahmen, die niemand mehr nachvollziehen kann.
KI-Vorschläge sind oft zu „smart". Die Tools haben eine Tendenz, elegante, abstrakte Lösungen zu bauen – viele Layers, viele Generics, viele Patterns. Das ist beeindruckend zu lesen und furchtbar zu warten. Im Mittelstand schreibe ich gerne den einfachen, vorhersehbaren Code, den auch ein anderer Entwickler in fünf Jahren noch sofort versteht. Die KI muss man da regelmäßig zurückpfeifen: Nein, hier nicht das Strategy-Pattern, hier reicht ein If-Else. Wer den KI-Output nicht aktiv vereinfacht, baut langfristig schlechtere Software.
Was das für unsere Kunden bedeutet
Damit komme ich zu dem Punkt, der mir besonders wichtig ist: Was bedeutet diese Veränderung für die mittelständischen Unternehmen, mit denen wir arbeiten? Aus meiner Sicht das hier:
Erstens: Software-Projekte werden tatsächlich günstiger. Wenn man die KI-Realität ehrlich in die Kalkulation einrechnet, sind Projekte heute zwischen 30 und 50 Prozent günstiger als noch vor zwei Jahren. Bei einem typischen Projekt mit historisch etwa 50.000 Euro Aufwand sind das schnell 15.000 bis 25.000 Euro Ersparnis. Vorausgesetzt, der Anbieter gibt sie weiter.
Zweitens: Die Qualität sinkt nicht – eher im Gegenteil. Weil mehr Aufmerksamkeit für die wichtigen Entscheidungen bleibt, sind die Architekturen, die heute entstehen, tendenziell durchdachter. Vorausgesetzt – und das ist ein großes Vorausgesetzt – der Anbieter prüft und vereinfacht den KI-Output aktiv.
Drittens: Kleinere Projekte werden plötzlich wirtschaftlich. Vorher musste eine Investition in eine eigene Software-Lösung mindestens fünfstellig sein, damit sie sich rechnete. Heute können viele Mittelständler bereits mit drei- bis vierstelligen Budgets sinnvolle Webapps bauen lassen – für genau einen Prozess, der sie nervt. Das öffnet eine ganze Klasse von Projekten, die früher nie passiert wären.
Viertens: Die Auswahl des Dienstleisters wird wichtiger. Wer den KI-Vorteil komplett für sich behält und weiter Stundenpreise von vor drei Jahren in Rechnung stellt, ist kein guter Partner. Wer dagegen offen kommuniziert, wie er KI einsetzt und wie das in die Kalkulation einfließt, ist wahrscheinlich der bessere Partner – auch wenn der Stundensatz vergleichbar oder sogar höher ist.
Wir bei Aburok haben uns dafür entschieden, die KI-Realität offen anzusprechen. Wir nutzen Claude Code und andere Tools jeden Tag. Wir rechnen den realistischen Aufwand mit KI ein, nicht den historischen ohne. Und wir geben den Effizienzvorteil weiter – nicht weil wir naiv sind, sondern weil wir langfristig denken. Dass mehr Tempo allein noch keine bessere Software macht, ist die andere Seite der Medaille – dazu der Beitrag KI macht Entwickler schneller – nicht besser.
Was kommt als nächstes
Wenn ich nach vorne schaue, sehe ich drei Entwicklungen, die in den nächsten zwölf bis vierundzwanzig Monaten wichtig werden.
Die Tools werden besser im Verstehen größerer Codebases. Heute funktioniert KI-Unterstützung am besten in begrenzten Kontexten – eine Datei, ein Modul, ein klar abgegrenztes Feature. Sobald es übergreifend wird, wird der Mensch wieder zur Schlüsselrolle. Das wird sich teilweise auflösen, aber nicht ganz. Architekturen, die in fünf Jahren noch funktionieren sollen, brauchen weiterhin menschliche Verantwortung.
KI-Unterstützung wird im Mittelstand zur Selbstverständlichkeit. So wie heute niemand mehr fragt, ob ein Anbieter Versionskontrolle nutzt, wird in zwei bis drei Jahren niemand mehr fragen, ob KI im Einsatz ist. Was zur differenzierenden Frage wird: Wie geht der Anbieter mit der dadurch entstehenden Verantwortung und der Ersparnis um?
Eigene KI-Workflows werden ein Wettbewerbsvorteil. Bei Aburok experimentieren wir gerade mit eigenen, projektspezifischen KI-Workflows: Code-Review-Pipelines, automatische Dokumentations-Aktualisierung bei Commits, Standard-Refactoring-Routinen. Das ist noch in der Anfangsphase, aber es wird die nächste Differenzierungsebene. Wer das gut hinbekommt, kann Mittelstandsprojekte mit der Qualität größerer Häuser zu deutlich faireren Preisen anbieten.
Wenn Sie das selbst überlegen
Falls Sie als Geschäftsführerin oder IT-Verantwortlicher eines mittelständischen Unternehmens überlegen, in eigene Software zu investieren – sei es eine Webapp, eine Schnittstelle oder die Modernisierung einer Bestandslösung – sind das die zwei Fragen, die ich aus dieser Erfahrung an Ihre Anbieter stellen würde:
Erstens: „Wie hat sich Ihre Kalkulation in den letzten zwei Jahren durch KI verändert?" Ein ehrlicher Anbieter kann das mit konkreten Beispielen beantworten. Vage Floskeln sind ein Warnsignal.
Zweitens: „Können Sie für mein Projekt eine Aufwandsabschätzung machen, in der Sie den KI-Einsatz explizit einrechnen?" Wer das ablehnt oder nicht versteht, lebt entweder noch in 2022 oder hat etwas zu verbergen.
Bei uns ist beides selbstverständlich. Wir reden gerne offen darüber, wie wir arbeiten – auch wenn es manchmal unbequem ist.
Fazit nach mehreren Monaten
Was sich für mich nach mehreren Monaten Claude Code im Alltag wirklich verändert hat, ist nicht in erster Linie die Geschwindigkeit. Es ist die Aufmerksamkeit. Ich kann mich heute auf die Fragen konzentrieren, bei denen Erfahrung und Urteilsvermögen den Unterschied machen – und das sind die Fragen, für die Kunden mich eigentlich engagiert haben. Die mechanische Arbeit, die früher den Großteil meines Tages ausgefüllt hat, ist deutlich kleiner geworden.
Das ist eine bessere Arbeit. Nicht eine andere. Und sie macht Software-Entwicklung für mittelständische Unternehmen zugänglicher, ehrlicher und langfristig nachhaltiger – vorausgesetzt, die Effizienzgewinne werden geteilt.
Wenn Sie Lust auf ein Gespräch haben – wie sich diese KI-Realität konkret für Ihre Anforderungen rechnen würde, was wir an einem Beispiel-Projekt bauen würden, welche Kosten realistisch sind: einfach melden. Erstgespräch ist kostenlos und unverbindlich.
