18. Juni 2025

KI in einer gut organisierten Softwarewerkstatt

Kunden fragen uns inzwischen regelmäßig, ob Software mit KI schneller und günstiger entsteht. Unsere ehrliche Antwort: Das kann sein, aber nur in einem Team, das bereits geordnet arbeitet. KI verstärkt den Prozess, in dem sie landet. In einer gut organisierten Werkstatt nimmt sie den Menschen Routine ab und lässt mehr Zeit für die schwierigen Teile. In einer chaotischen erzeugt sie mehr Code, den niemand richtig geprüft hat.

Deshalb geht es in diesem Beitrag weniger um Werkzeuge als darum, wo sie in unserem Prozess stehen. Er beschreibt, wie wir im Juni 2025 arbeiten – wohl wissend, dass sich die Werkzeuge alle paar Monate ändern.

Erst Ordnung, dann Werkzeuge

Bevor ein Assistent nützlich wird, müssen ein paar Dinge stehen. Keines davon ist neu, aber mit KI werden sie wichtiger, nicht unwichtiger:

  • Klare Aufgaben. In unseren Projekten ist jeder Pull Request mit einem Ticket verknüpft, das ein Ziel hat. Eine vage Aufgabe ergibt vagen Code, egal wer ihn schreibt.
  • Code-Review als Standard. Eine Änderung wird erst übernommen, wenn ein anderer Entwickler sie angesehen hat – ob sie von Hand geschrieben oder von einem Werkzeug vorgeschlagen wurde.
  • Automatische Prüfungen. Tests und Continuous Integration fangen die plausibel aussehenden Fehler ab, die Assistenten gern produzieren. In manchen Projekten veröffentlicht die Pipeline außerdem bei jedem Pull Request einen Bericht zur Testabdeckung.
  • Einheitlicher Code. Ein Assistent folgt den Mustern, die er in der Codebasis sieht. Ist die Codebasis einheitlich, sind es auch die Vorschläge.

Steht das, durchläuft alles, was ein Assistent erzeugt, genau dieselbe Pipeline wie jeder andere Code. Genau das macht den Einsatz sicher.

Was KI heute in unserer Pipeline tut

Eine Zusammenfassung jedes Pull Requests. Seit Dezember 2024 ist ein KI-Review-Bot, CodeRabbit, mit unserer GitHub-Organisation verbunden. Öffnet ein Entwickler einen Pull Request, veröffentlicht der Bot nach ein bis zwei Minuten eine kurze Zusammenfassung der Änderung, einen Durchgang Datei für Datei und, wo es hilft, ein Sequenzdiagramm des neuen Ablaufs. Er schreibt auf Polnisch, der Arbeitssprache der betroffenen Teams. In den ersten Wochen haben wir auch seine zeilenweisen Kommentare ausprobiert; heute nutzen wir vor allem die Zusammenfassungen. Der Bot genehmigt nichts: Wer das Review macht, beginnt mit einer klaren Übersicht über die Änderung, Freigabe und Merge bleiben bei einem Kollegen.

Assistenten im Editor. Die JetBrains-IDEs, für die unser Unternehmen Lizenzen hat, bringen inzwischen einen integrierten KI-Assistenten mit. Im Frühjahr 2025 wurde der Zugang dazu zu einer Einstellung auf Organisationsebene, und genau dorthin gehört diese Entscheidung: Ob und wie KI in einem Projekt eingesetzt wird, entscheiden das Unternehmen und der Vertrag, nicht jeder Entwickler für sich. Seit Dezember 2024 zahlt das Unternehmen außerdem für Cursor, einen rund um KI gebauten Editor; im Frühjahr 2025 arbeiteten mehrere unserer Entwickler und unser Softwarearchitekt darin mit Lizenzen, die das Unternehmen bezahlt. Die typischen Einsatzfälle sind überall gleich: Boilerplate und wiederkehrende Änderungen, Datenmappings, erste Entwürfe gut verstandener Komponenten und Tests sowie Erklärungen zu unbekanntem Code, bevor wir ihn anfassen.

Chat-Assistenten rund um den Code. Das Unternehmen zahlt seit Juni 2023 für ChatGPT, und seit Anfang 2025 zeichnet ein KI-Notizwerkzeug unsere Meetings auf und fasst sie zusammen. Wir nutzen sie für die Arbeit rund ums Programmieren: lange Spezifikationen durchgehen, offene Fragen sammeln, Dokumentation und Änderungsbeschreibungen entwerfen. Das Ergebnis ist ein Entwurf, den ein Mensch prüft, nie eine endgültige Antwort.

Weniger hilft KI dort, wo ein Problem wirklich neu ist: bei Architekturentscheidungen, subtiler Nebenläufigkeit und hardwarenahem Code für bestimmte Geräte, wo es kaum öffentliche Beispiele gibt und ein falscher Tipp teuer wird. In unseren Embedded- und IoT-Projekten behandeln wir Vorschläge besonders vorsichtig.

Unsere Regeln

  1. Der Entwickler verantwortet den Code. Was auch immer der Assistent vorgeschlagen hat: Wer die Änderung committet, ist dafür verantwortlich, muss sie verstehen und im Review erklären können.
  2. Code und Daten des Kunden nur mit seiner Zustimmung. Code gelangt nur dann in ein KI-Werkzeug, wenn Vertrag und Richtlinien des Kunden es erlauben und die Bedingungen des Werkzeugs passen. Personenbezogene Daten, Zugangsdaten und Geheimnisse kommen nie in einen Prompt.
  3. Der Vertrag geht vor. Manche Kunden begrüßen KI-Unterstützung, manche schränken sie ein, manche schließen sie aus. Wir halten uns an das, was im Vertrag steht.
  4. Menschen müssen wissen, wie Werkzeuge danebenliegen. Seit Februar 2025 verlangt der EU AI Act von Organisationen, die KI-Systeme einsetzen, Maßnahmen für ausreichende KI-Kompetenz ihrer Mitarbeitenden. Für ein Softwareteam ist das praktisches Wissen: erfundene Funktionen, veraltete Bibliotheken, selbstsichere, aber falsche Antworten – und was mit einem Werkzeug geteilt werden darf und was nicht.
  5. Ein Werkzeug bleibt, weil es hilft. Nicht, weil es gerade in Mode ist.

Wie man beurteilt, ob es wirklich hilft

Produktivitätsversprechen rund um KI sind leicht gemacht und schwer zu überprüfen, deshalb nennen wir keine einzelne Prozentzahl. Beobachten sollte man die Signale, die in jedem Projekt zählen: wie lange eine Aufgabe vom Start bis zum Merge dauert, wie viel Nacharbeit aus dem Review zurückkommt, wie viele Fehler nach dem Release auftauchen. Und die Entwickler selbst, denn sie merken schnell, wo ein Werkzeug Zeit spart und wo es nur Aufräumarbeit erzeugt.

Unsere Arbeitsannahme ist einfach: Der Nutzen ist bei routinemäßiger, klar definierter Arbeit am größten und bei schwierigen, neuen Problemen am kleinsten. Daran sehen wir, wo wir uns auf Assistenten verlassen und wo wir sie heraushalten.

Wie es weitergeht

Die Werkzeuge ändern sich schnell. Assistenten, die einst eine Codezeile ergänzt haben, führen inzwischen mehrere Schritte selbst aus: mehrere Dateien ändern, Tests starten, eine vollständige Änderung vorschlagen. Wir verfolgen das genau, und die Grundsätze bleiben dieselben: klare Aufgaben, Tests, Review und ein Mensch, der für das Ergebnis verantwortlich ist.

Darin steckt auch eine Lehre für unsere Kunden. Was KI in einem Softwareteam funktionieren lässt, lässt sie in jedem Geschäftsprozess funktionieren: erst den Prozess ordnen, dann das Werkzeug wählen. Genauso gehen wir vor, wenn wir eine KI-Idee prüfen, bevor wir sie bauen.

KI ist ein weiteres Werkzeug in einer gut organisierten Werkstatt: leistungsfähig, aber nur so gut wie der Prozess drumherum. Wenn Sie darüber sprechen möchten, wie KI Ihr Team oder Ihr Produkt unterstützen kann, sehen Sie sich unsere KI-Leistungen an oder sprechen Sie uns an.

Das könnte Sie auch interessieren:
Neues Büro in Lublin und die SALZ21 in Salzburg
Bevor Sie KI bauen: Machbarkeit, Daten, Ethik und Recht
Von Assistenten zu Agenten: So bauen wir heute Software

Angebot oder Beratung anfragen

Verantwortlich für die Verarbeitung Ihrer personenbezogenen Daten ist die EMBIQ sp. z o.o. (Lublin). Wir verarbeiten Ihre Angaben ausschließlich zur Beantwortung Ihrer Anfrage und speichern sie höchstens 24 Monate. Bei Fragen zu Ihren Daten erreichen Sie uns unter info@embiq.com.

Wir sehen uns Ihr Projektkonzept und seinen aktuellen Stand gemeinsam an.

Sie erhalten von uns einen ersten Vorschlag zum Projektumfang sowie eine Zeit- und Kostenschätzung.

Die Beratung ist durch eine Geheimhaltungsvereinbarung (NDA) geschützt.

EMBIQ sp. z o.o., Sitz: Lublin · Anschrift: al. Kraśnicka 27, 20-718 Lublin, Polen · Registergericht: Sąd Rejonowy Lublin-Wschód w Lublinie z siedzibą w Świdniku, VI Wydział Gospodarczy KRS · KRS 0000338852 · NIP 9462590420 · Stammkapital: 75.000,00 PLN