AI Coding im Unternehmen: Produktivität, Qualität und Governance

„78 Prozent schneller programmieren mit KI” liest sich gut in einer Pressemitteilung. Die unbequemere Zahl steht in derselben Studienlandschaft ein Stück weiter hinten: In einer Befragung von 1.528 Entwickler:innen und IT-Entscheider:innen berichten 85 Prozent, dass sich der Engpass durch KI-Coding-Tools von der Code-Erstellung zur Prüfung verschoben hat – und 92 Prozent nennen irgendeine Form von Governance-Problem mit KI-generiertem Code. AI Coding beschleunigt einen Teil der Arbeit zuverlässig. Es verschiebt gleichzeitig Aufwand und Risiko an eine andere Stelle im Prozess, die viele Teams noch nicht organisiert haben.

Dieser Artikel ist Teil unseres Themen-Clusters KI-Softwareentwicklung. Er beantwortet die zentralen Fragen zu AI Coding im Unternehmen: Was ist gemeint, welche Aufgaben eignen sich, welche Datenrisiken bestehen, wie prüft man Code und Architektur verlässlich, und welche Regeln braucht ein Team.

Problem und Zielgruppe

Der typische Ausgangspunkt in KMU sieht so aus: Ein Entwickler installiert sich einen KI-Code-Assistenten, weil er in einem Blogpost davon gelesen hat. Nach zwei Wochen nutzt die halbe Entwicklung das Tool – unterschiedlich, unkoordiniert, ohne dass irgendjemand entschieden hätte, welche Daten dabei das Unternehmen verlassen oder wer die Vorschläge eigentlich prüft. Das Muster ist dasselbe wie bei anderer Schatten-IT: Es entsteht Nutzen, aber niemand kann sagen, wie viel davon tatsächlich im Code landet und was das für Wartbarkeit und Sicherheit bedeutet.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die entweder selbst entwickeln (interne Tools, Web-Apps, Kundenportale) oder Entwicklung extern beauftragen und wissen wollen, was AI Coding für Tempo, Qualität und Verantwortlichkeit bedeutet – unabhängig davon, ob die Umsetzung intern oder bei einem Dienstleister passiert.

Begriffe kurz geklärt

• AI Coding ist der Oberbegriff für den Einsatz generativer KI-Modelle im Entwicklungsprozess: Vorschläge während des Tippens, eigenständige Änderungen über mehrere Dateien hinweg, generierte Tests, Erklärungen zu Fehlermeldungen oder bestehendem Code.
• Code-Assistent meint konkret das Werkzeug – von der einfachen Autovervollständigung bis zum agentischen System, das selbstständig Dateien ändert, Befehle ausführt und Tests startet.
• Agentisches Coding bezeichnet die Stufe, auf der die KI nicht nur einzelne Zeilen vorschlägt, sondern über mehrere Schritte hinweg – lesen, ändern, testen, iterieren – relativ eigenständig arbeitet, bevor ein Mensch das Ergebnis sieht. Genau hier wächst der Prüfaufwand am schnellsten, weil zwischen Prompt und Ergebnis mehr passiert, als eine Person auf einen Blick nachvollziehen kann.
• Vibe Coding ist der informelle Begriff für die Praxis, KI-Vorschläge weitgehend ungeprüft zu übernehmen, solange der Code „funktioniert aussieht”. Für Prototypen und Wegwerf-Skripte ist das vertretbar. Für Produktivsysteme ist es der direkte Weg zu den Risiken, die weiter unten beschrieben werden.

Was ist AI Coding?

AI Coding bezeichnet den Einsatz von KI-Modellen als Werkzeug im Softwareentwicklungsprozess: Sie schlagen Code vor, ändern bestehende Dateien, schreiben Tests oder erklären Fehler – auf Zuruf in natürlicher Sprache statt durch manuelle Eingabe jeder Zeile. Die verantwortliche Entwicklerin oder der Entwickler bleibt entscheidend: definiert die Aufgabe, prüft jeden Vorschlag und entscheidet, was ins Produktivsystem geht. AI Coding ersetzt keine Softwareentwicklung, sondern beschleunigt einzelne Schritte darin – bei gleichzeitig höherem Prüfaufwand.

Was das in der Praxis heißt, hängt stark vom Reifegrad des Tools ab. Auf der einen Seite steht die Autovervollständigung, die die nächste Zeile vorschlägt – ein Effizienzgewinn ohne große Tragweite, vergleichbar mit einer besseren Autokorrektur. Auf der anderen Seite steht ein Agent, der eigenständig eine Datei-Struktur anlegt, mehrere Module ändert, Tests schreibt und ausführt, und am Ende einen fertigen Pull Request präsentiert. Beides heißt „AI Coding”, aber das Risiko- und Prüfprofil ist grundlegend verschieden. Wer im Unternehmen über Regeln für AI Coding spricht, sollte diese Unterscheidung immer mitdenken – „wir nutzen KI beim Programmieren” ist als Aussage fast bedeutungslos, ohne zu sagen, auf welcher Stufe.

Belastbar belegt ist der Effekt auf reine Bearbeitungsgeschwindigkeit: In einem kontrollierten Experiment von GitHub mit 95 professionellen Entwickler:innen, zufällig in zwei Gruppen aufgeteilt, löste die Gruppe mit Code-Assistent eine definierte Aufgabe (einen HTTP-Server in JavaScript implementieren) im Schnitt in 1 Stunde 11 Minuten – die Vergleichsgruppe ohne Assistent brauchte 2 Stunden 41 Minuten, ein statistisch signifikanter Unterschied von 55 Prozent. Die Erfolgsquote lag mit Assistent bei 78 Prozent gegenüber 70 Prozent ohne. Wichtig für die Einordnung: Das Experiment misst eine klar abgegrenzte, gut testbare Aufgabe unter Laborbedingungen. Es sagt nichts darüber aus, wie sich der Effekt in einer gewachsenen Codebasis mit unklaren Anforderungen und Altlasten verhält – und genau dort liegt in der Praxis der Unterschied zwischen Demo und Alltag.

Welche Aufgaben eignen sich für AI Coding?

Ich baue selbst Software mit KI-Unterstützung – von internen Tools bis zu einem eigenen Produkt, das speziell für AI-Coding-Workflows Kontext und Nachvollziehbarkeit organisiert. Meine Erfahrung deckt sich mit dem, was aus den Studien als Muster erkennbar wird: Die Eignung hängt weniger von der Größe der Aufgabe ab als von zwei Eigenschaften – wie gut lässt sich das Ergebnis automatisiert oder schnell manuell prüfen, und wie teuer ist ein unentdeckter Fehler.

Gut geeignet:

• Boilerplate und Gerüst-Code. Wiederkehrende Strukturen – ein neuer API-Endpunkt nach bestehendem Muster, ein Formular mit Validierung, ein Datenbank-Schema-Migrationsskript. Hohe Trefferquote, klare Prüfbarkeit gegen ein bekanntes Muster.
• Tests zu bestehender Logik. Wenn die Funktion schon da ist und ihr Verhalten bekannt ist, ist das Schreiben von Testfällen eine der zuverlässigsten Anwendungen – die KI muss nichts erfinden, nur systematisch Fälle durchspielen.
• Refactoring nach bekanntem Schema. Eine Umbenennung über die gesamte Codebasis, die Umstellung auf ein neues API-Muster, das konsequent überall gleich angewendet wird.
• Fehlersuche in überschaubaren Ausschnitten. Eine Fehlermeldung erklären, eine Stack-Trace einordnen, einen Bug in einer einzelnen Funktion eingrenzen.
• Dokumentation und Erklärung. Bestehenden Code zusammenfassen oder kommentieren – hier ist der Ausgangspunkt bereits vorhanden, die KI muss nur wiedergeben und ordnen, nicht neu entscheiden.

Schlecht geeignet oder nur mit engem Prüfrahmen:

• Architekturentscheidungen mit hoher Tragweite. Welche Datenbank, welches Berechtigungsmodell, welche Schnittstellenstruktur – hier fehlt der KI der Gesamtkontext über Geschäftsanforderungen, die selten vollständig im Prompt stehen.
• Sicherheitskritische Logik. Authentifizierung, Zahlungsabwicklung, Zugriffssteuerung. Ein Fehler ist hier nicht „ein Bug mehr”, sondern ein Sicherheitsvorfall.
• Aufgaben ohne gute Testabdeckung. Ohne automatisierte Tests fehlt die schnelle, objektive Rückmeldung, ob eine Änderung tatsächlich funktioniert – dann bleibt nur die manuelle Prüfung, die bei komplexer Logik leicht etwas übersieht.
• Große, unklare Aufgaben ohne Zerlegung. „Baue mir das komplette Feature” produziert häufig einen Vorschlag, der auf den ersten Blick überzeugt und in der Tiefe an mehreren Stellen falsch abbiegt – schwerer zu prüfen als fünf kleine, klar abgegrenzte Schritte.

Die Grundregel, die ich in eigenen Projekten anwende: Je kleiner und geprüfter der Schritt, desto verlässlicher der Nutzen von AI Coding. Große, ungeprüfte Sprünge sehen im Moment beeindruckend aus und sind im Nachhinein der teuerste Teil der Arbeit.

Welche Datenrisiken bestehen bei AI Coding?

Zwei Risikoarten sind in der Praxis relevant, und beide werden regelmäßig unterschätzt, weil sie nicht im Code selbst sichtbar sind, sondern im Prozess drumherum.

1. Datenabfluss über Prompts und Kontext. Moderne Code-Assistenten sammeln oft automatisch Kontext – offene Dateien, Projektstruktur, teils ganze Repositories –, um bessere Vorschläge zu machen. Wenn dieser Kontext an einen externen Dienst geht, wandern potenziell Zugangsdaten, interne Geschäftslogik oder Kundendaten aus Testdatenbanken mit. Das BSI empfiehlt für den Umgang mit generativer KI allgemein, so wenig sensible Daten wie möglich mit einer KI-Anwendung zu teilen und vorab genau zu prüfen, welche Informationen man einer Anwendung mitgibt – ein Grundsatz, der für Code-Assistenten mit Repository-Zugriff besonders gilt, weil die Menge an mitgesendetem Kontext für Einzelne oft nicht überschaubar ist.

2. Halluzinierte oder manipulierte Paketnamen. KI-Modelle schlagen gelegentlich Softwarepakete vor, die nicht existieren oder die inhaltlich nicht zur Aufgabe passen – ein bekanntes Muster generativer Modelle, die plausible, aber falsche Inhalte erzeugen können (im BSI-Sprachgebrauch: „Halluzination”). Angreifende können das ausnutzen, indem sie Pakete mit exakt diesen häufig vorgeschlagenen, aber nicht existierenden Namen gezielt in öffentlichen Paket-Registries anlegen – wer den Vorschlag ungeprüft installiert, holt sich Schadcode ins Projekt. Das Gegenmittel ist unspektakulär, aber wirksam: jedes neue Paket vor der Installation einmal bewusst prüfen (Existenz, Verbreitung, Herkunft), statt automatisierte Vorschläge blind zu übernehmen.

Dazu kommt ein drittes, subtileres Risiko, das die GitLab-Befragung deutlich macht: Verlust der Nachvollziehbarkeit. 43 Prozent der befragten Entwickler:innen und IT-Entscheider:innen gaben an, KI-generierten Code nicht zuverlässig von menschlich geschriebenem Code in der eigenen Codebasis unterscheiden zu können. Das ist kein direktes Sicherheitsrisiko, aber es untergräbt jede spätere Fehlersuche, jedes Audit und jede Entscheidung darüber, welche Codeteile besonders sorgfältig geprüft werden sollten.

Wie prüft man KI-generierten Code und Architektur?

Hier liegt der eigentliche Kern der Governance-Frage – und der Punkt, an dem viele Teams nachrüsten müssen, nachdem sie AI Coding bereits eingeführt haben. 85 Prozent der von GitLab befragten Organisationen berichten, dass sich der Engpass durch KI-Tools von der Code-Erstellung zur Prüfung und Validierung verschoben hat. Schneller Code entsteht nicht automatisch schneller geprüfter Code.

In meiner eigenen Arbeit hat sich ein fester Ablauf bewährt, den ich für jede Änderung durchziehe, die über eine triviale Kleinigkeit hinausgeht – vom internen Tool bis zum Kundenprojekt. Als eigenes Modell für diesen Artikel:

Schritt	Was passiert	Wer/was prüft	Evidenz
1. Prompt & Kontext	Aufgabe klar abgegrenzt formulieren, relevanten Kontext gezielt bereitstellen (nicht das ganze Repository)	Entwickler:in definiert Scope vorab	Prompt-Text und einbezogene Dateien dokumentiert
2. Änderung generieren	KI schlägt Code-Änderung vor, ggf. über mehrere Dateien	–	Diff als nachvollziehbarer Änderungssatz
3. Automatisierte Prüfung	Linter, Typprüfung, bestehende und neue Tests laufen gegen die Änderung	CI-Pipeline	Testergebnis (grün/rot), Coverage-Delta
4. Menschliches Review	Diff UND architektonischer Zusammenhang werden bewertet, nicht nur Zeile für Zeile	Zweite Person, nicht der Prompt-Autor	Review-Kommentare, Freigabe oder Ablehnung
5. Abnahme-Entscheidung	Merge, Nacharbeit oder Verwerfen	Verantwortliche Entwicklerin/Owner	Merge-Protokoll mit Begründung
6. Evidenzspur	Wer hat wann was mit welchem Modell/Prompt erzeugt und wer hat es freigegeben	Dauerhaft im Versionskontrollsystem	Commit-Historie, Review-Log, ggf. Herkunftskennzeichnung

Eigener Workflow Philogic Labs, aus der Praxis mit KI-gestützter Entwicklung eigener Tools und Kundenprojekte.

Zwei Punkte aus diesem Ablauf sind in der Praxis besonders oft die Lücke:

Schritt 4 wird übersprungen oder verwässert. Wenn KI-Code „auf den ersten Blick sauber” aussieht, sinkt die Sorgfalt beim Review – ein bekanntes Muster, weil generierter Code oft stilistisch konsistent und gut kommentiert wirkt, auch wenn er inhaltlich falsch abbiegt. Die Reviewerin oder der Reviewer braucht deshalb bewusst den Blick auf den architektonischen Zusammenhang, nicht nur auf Syntax und Formatierung: Passt die Änderung zum bestehenden Muster? Öffnet sie eine neue Angriffsfläche? Verändert sie stillschweigend eine Schnittstelle, die andere Teile des Systems nutzen?

Schritt 6 fehlt fast immer. Genau hier liegt die Erklärung für die 43-Prozent-Zahl von oben: Ohne bewusste Kennzeichnung, welche Änderung wie entstanden ist, verschwimmt nach einigen Monaten die Unterscheidung. Das wird spätestens dann teuer, wenn nach einem Produktionsfehler geklärt werden muss, welche Änderung ihn verursacht hat und wie sorgfältig sie ursprünglich geprüft wurde. Genau dieses Nachvollziehbarkeitsproblem war für mich der Auslöser, ein eigenes Werkzeug für Kontext- und Evidenzmanagement bei AI-Coding-Workflows zu entwickeln – nicht als Ersatz für Review, sondern als Gedächtnis dafür, was geprüft wurde und was nicht.

Für Architektur-Entscheidungen speziell gilt eine zusätzliche Regel: Ein KI-Vorschlag für eine neue Komponente oder Schnittstelle sollte nie isoliert bewertet werden, sondern immer im Vergleich zu mindestens einer Alternative – weil generative Modelle tendenziell den erstbesten plausiblen Weg vorschlagen, nicht notwendigerweise den, der zur bestehenden Systemlandschaft passt.

Welche Regeln braucht ein Team?

Aus den Governance-Zahlen der GitLab-Befragung lässt sich ein klarer Handlungsauftrag ableiten: 80 Prozent der befragten Organisationen haben KI-Coding-Tools eingeführt, bevor sie Regeln zu deren Kontrolle hatten – die Lücke zwischen Tempo und Steuerung ist damit eher die Regel als die Ausnahme. Ein Team braucht dafür keine umfangreiche Richtlinie, aber mindestens vier klare Antworten:

1. Welche Tools und Modelle sind erlaubt? Eine geprüfte Liste statt „jeder installiert sich, was er will” – inklusive Klärung, wo Anbieter Daten zum Training weiterverwenden könnten und wo nicht.
2. Welche Daten dürfen niemals in Prompts oder automatisch gesammelten Kontext gelangen? Produktivdaten mit Personenbezug, Zugangsdaten, unveröffentlichte Geschäftsgeheimnisse – am besten technisch durchgesetzt (z. B. über getrennte Entwicklungsumgebungen mit synthetischen Testdaten), nicht nur per Anweisung.
3. Welche Aufgabenklassen brauchen ein Zwei-Personen-Review? Sicherheitskritische Logik, Zahlungslogik, Datenbank-Migrationen mit Datenverlustrisiko – hier reicht die übliche Ein-Personen-Freigabe nicht.
4. Wie wird Herkunft und Prüfung dokumentiert? Mindestens: Commit-Historie, die erkennen lässt, was KI-unterstützt entstand, plus Review-Freigabe mit Namen und Zeitpunkt.

Diese Regeln sind kein Selbstzweck, sondern die Voraussetzung dafür, dass im Ernstfall – ein Produktionsvorfall, ein Sicherheitsaudit, ein Kundenaudit bei einem Auftragsprojekt – innerhalb kurzer Zeit geklärt werden kann, was passiert ist. Laut GitLab-Report sind zwar 87 Prozent der Organisationen zuversichtlich, dass sie das innerhalb von 24 Stunden könnten – aber unter den Organisationen, die tatsächlich einen Vorfall hatten, konnten 34 Prozent das im Nachhinein nicht zuverlässig feststellen. Diese Lücke zwischen Selbsteinschätzung und Realität ist der eigentliche Grund, warum Regeln vor der breiten Einführung stehen sollten, nicht danach.

Für Teams, die noch keine Grundkompetenz zu KI-Grenzen und -Risiken im Haus haben, sind strukturierte Schulungen oft der schnellste Weg, um diese vier Fragen mit dem ganzen Team statt im Alleingang der IT zu klären – gerade weil Regeln nur wirken, wenn sie verstanden und nicht nur verordnet werden.

Umsetzung: wie man AI Coding einführt, ohne die Kontrolle zu verlieren

Die praktikable Reihenfolge unterscheidet sich vom verbreiteten Muster „Tool installieren, loslegen”:

Erstens: Pilotbereich abgrenzen. Nicht die gesamte Codebasis auf einmal, sondern ein Projekt oder Modul mit guter Testabdeckung und überschaubarem Risiko, an dem sich Nutzen und Reibung realistisch beobachten lassen.

Zweitens: Die vier Regeln aus dem vorigen Abschnitt vor dem breiten Rollout festlegen – nicht als Idealzustand, sondern als Mindeststandard, den alle kennen, bevor sie loslegen.

Drittens: Den Prüf-Workflow aus dem Modell oben in die bestehende CI/Review-Praxis einbauen, statt eine Parallelwelt für „KI-Code” zu schaffen. Der beste Schutz ist kein Sonderprozess, sondern ein bestehender, disziplinierter Review-Prozess, der auf KI-generierten Code genauso konsequent angewendet wird wie auf jeden anderen.

Viertens: Nach vier bis acht Wochen ehrlich Bilanz ziehen. Ist die tatsächliche Durchlaufzeit (nicht nur die gefühlte Tippgeschwindigkeit) gesunken? Wie oft mussten Reviews KI-Vorschläge grundlegend zurückweisen? Gab es Zwischenfälle mit Datenabfluss oder fragwürdigen Paketvorschlägen? Erst danach lohnt sich die Entscheidung, den Einsatz auf weitere Teams oder Projektbereiche auszuweiten.

Wenn intern die Kapazität oder Erfahrung fehlt, um Scope, Architektur oder bestehenden Code vor der Einführung von AI Coding einzuordnen, ist das eine der Situationen, in denen sich ein kurzer externer Blick auszahlt – etwa im Rahmen einer KI-Beratung, die konkret auf Architektur- und Prozessfragen bei Softwareentwicklung eingeht, statt allgemeine KI-Strategie zu behandeln.

Risiken & Grenzen

Ehrlich zu Ende gedacht gehören zu AI Coding auch die Fälle, in denen es die falsche Antwort ist oder zumindest zusätzliche Vorsicht braucht:

• Fehlende Testabdeckung macht jede Beschleunigung gefährlich. Ohne automatisierte Prüfung verlässt du dich allein auf manuelles Review – bei höherem Änderungsvolumen durch KI steigt damit auch die Wahrscheinlichkeit, dass etwas durchrutscht.
• Plausibilität ist keine Korrektheit. KI-generierter Code liest sich oft sauberer und selbstbewusster, als er tatsächlich ist – ein psychologischer Effekt, der Reviewer:innen dazu verleiten kann, weniger kritisch zu prüfen als bei offensichtlich unfertigem Code.
• Verantwortung lässt sich nicht outsourcen. Wenn ein KI-generierter Fehler in Produktion Schaden anrichtet, hilft „das hat die KI vorgeschlagen” rechtlich und geschäftlich nicht weiter – verantwortlich bleibt, wer die Änderung freigegeben hat.
• Rechtlicher Rahmen ist in Bewegung (Stand Juli 2026, keine Rechtsberatung). Die europäische KI-Verordnung verpflichtet Anbieter und Betreiber von KI-Systemen bereits seit Februar 2025 zur KI-Kompetenz ihrer Mitarbeitenden (Artikel 4) – für Teams, die produktiv mit KI-Code-Assistenten arbeiten, gehört dazu auch ein belastbares Verständnis der Grenzen dieser Systeme. Details zu Anwendungsbereich und Fristen stehen bei der Europäischen Kommission; bei konkreten Compliance-Fragen gehört das Thema zu Rechtsberatung oder Datenschutzbeauftragten.
• Nicht jede Aufgabe wird durch mehr KI-Einsatz besser. Manche Probleme in der Softwareentwicklung sind Architektur- oder Prozessprobleme, die ein Code-Assistent nicht löst, sondern nur schneller reproduziert – etwa wenn die zugrundeliegende Systemlandschaft selbst unübersichtlich ist.

Und eine Grenze dieses Artikels selbst: Die zitierten Studien – ein kontrolliertes Experiment mit 95 Entwickler:innen bei einer einzelnen, klar abgegrenzten Aufgabe, eine Befragung von 1.528 Fachleuten zu Governance-Wahrnehmung – zeigen Tendenzen, keine Garantie für dein Projekt. Wie viel Zeitersparnis und wie viel zusätzlicher Prüfaufwand bei dir konkret entstehen, hängt von Codebasis, Testabdeckung und Teamerfahrung ab und lässt sich nur an einem eigenen, begrenzten Piloten wirklich beobachten.

Checkliste: AI Coding im Unternehmen einführen

1. Wir wissen, auf welcher Stufe unser Team AI Coding einsetzt – einfache Vervollständigung oder eigenständig agierender Assistent – und haben das nicht einfach als „KI beim Programmieren” pauschalisiert.
2. Wir haben festgelegt, welche Aufgabenklassen sich eignen (Boilerplate, Tests, Refactoring nach Schema) und welche nicht (sicherheitskritische Logik, Aufgaben ohne Testabdeckung).
3. Es gibt eine geprüfte Liste erlaubter Tools und Modelle statt freier Wahl im Team.
4. Es ist klar geregelt, welche Daten niemals in Prompts oder automatisch gesammelten Kontext gelangen dürfen – idealerweise technisch durchgesetzt, nicht nur angewiesen.
5. Neue, von der KI vorgeschlagene Pakete werden vor der Installation bewusst geprüft, nicht automatisch übernommen.
6. Jede nicht-triviale KI-unterstützte Änderung durchläuft automatisierte Tests UND ein menschliches Review, das auch den architektonischen Zusammenhang bewertet.
7. Sicherheitskritische oder folgenreiche Änderungen haben ein Zwei-Personen-Review, kein Standard-Review.
8. Herkunft und Freigabe jeder Änderung sind nachvollziehbar dokumentiert – wir könnten im Ernstfall innerhalb von 24 Stunden klären, ob KI-Code an einem Vorfall beteiligt war.
9. Wir haben einen abgegrenzten Pilotbereich gewählt, statt AI Coding unternehmensweit auf einmal einzuführen.
10. Die Mitarbeitenden, die mit KI-Code-Assistenten arbeiten, kennen deren Grenzen – im Zweifel über gezielte Schulung, nicht nur durch Ausprobieren.
11. Nach einigen Wochen ziehen wir ehrlich Bilanz zu Durchlaufzeit, Review-Aufwand und Zwischenfällen, bevor wir den Einsatz ausweiten.
12. Uns ist bewusst, dass Verantwortung für freigegebenen Code nicht an das Werkzeug delegierbar ist – unabhängig davon, wie der Code entstanden ist.

Die Auswahl und Bewertung geeigneter Projekte für den Einstieg – etwa ein erstes internes Tool oder ein MVP mit KI-gestützter Entwicklung – vertiefen die weiteren Artikel im Cluster KI-Softwareentwicklung.