[{"data":1,"prerenderedAt":96},["ShallowReactive",2],{"content:blog:ki-first-was-das-im-alltag-heisst":3,"content:blog":33},{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":12,"toc":16,"body":32},"ki-first-was-das-im-alltag-heisst","KI im Unternehmen: was KI-First im Alltag eines Entwicklers heißt","Drei Ebenen, eine Infrastruktur und eine Grenze, die wir nicht überschreiben","2026-09-03","KI-First im Alltag: drei Ebenen, Gateway, Wissensbasis","KI-First konkret: Pflichtschritte im Entwicklungsprozess, eine Agenten-Farm, ein Gateway mit Kostengrenze – und wo KI in Unternehmen nicht beschleunigt.","„AI-powered“ steht auf jeder zweiten Website. Wir beschreiben, was ein Entwickler bei uns an einem normalen Vormittag anders macht: erster Entwurf und erstes Review vom Modell, Agenten, die Aufgaben bis zum Pull Request ausführen, ein Gateway mit harter Kostengrenze – und ehrlich, wo das alles nicht hilft.",4,[13,14,15],"KI-First","Arbeitsweise","KI-Agenten",[17,20,23,26,29],{"id":18,"text":19},"begriff","KI im Unternehmen: ein Wort, das jeder auf der Website hat",{"id":21,"text":22},"ebene-1","Ebene 1: das Werkzeug des Entwicklers",{"id":24,"text":25},"ebene-2","Ebene 2: Agenten, die Aufgaben ausführen",{"id":27,"text":28},"ebene-3","Ebene 3: KI im Unternehmen des Kunden",{"id":30,"text":31},"grenze","Wo die Beschleunigung aufhört","\u003Cp>KI im Unternehmen ist selten eine Frage des Modells und fast immer eine Frage der Organisation. Wir schreiben KI-First auf unsere Seiten und schulden deshalb eine Antwort darauf, was ein Entwickler bei uns an einem Dienstagvormittag anders macht. Sie besteht aus drei Ebenen, einer Infrastruktur und einer Grenze.\u003C\u002Fp>\n\n\u003Ch2 id=\"begriff\">KI im Unternehmen: ein Wort, das jeder auf der Website hat\u003C\u002Fh2>\n\u003Cp>KI-First heißt bei uns nicht „wir nutzen KI“, sondern: Der erste Griff bei jeder Aufgabe geht zu einem Werkzeug, das ein Sprachmodell im Kern hat, und der Prozess ist so gebaut, dass dieser Griff der Normalfall ist – mit Regeln, Limits und Prüfschritten. Das ist ein Unterschied in der Organisation, nicht in der Technologie.\u003C\u002Fp>\n\u003Cp>Die Modelle, die wir nutzen, kann jeder mieten. Die 169 angebundenen Systeme, die 179 katalogisierten Aktionen und die 63 dokumentierten Prozeduren drumherum haben wir seit 2023 für uns selbst gebaut, weil wir unser eigenes Unternehmen damit steuern. Diese Unterscheidung ist der ganze Inhalt des Begriffs: nicht Zugang zu einem Modell, sondern ein Prozess, in dem das Modell einen festen Platz und harte Grenzen hat.\u003C\u002Fp>\n\n\u003Ch2 id=\"ebene-1\">Ebene 1: das Werkzeug des Entwicklers\u003C\u002Fh2>\n\u003Cp>Das ist die Ebene, die die meisten meinen. Bei uns ist sie kein Angebot, sondern ein Pflichtschritt:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Erster Entwurf.\u003C\u002Fstrong> Code, Migrationen, Tests, Konfiguration: Der erste Entwurf kommt vom Modell, mit dem Kontext aus unserer Wissensbasis. Der Entwickler liest, korrigiert, entscheidet.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Erstes Review.\u003C\u002Fstrong> Bevor ein Mensch eine Änderung sieht, hat ein Modell sie gelesen: gegen unsere Regeln, gegen die Dokumentation, gegen bekannte Fehlerklassen. Das menschliche Review beginnt bei den Punkten, die übrig bleiben.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Fremde Dokumente.\u003C\u002Fstrong> Ausschreibungsunterlagen, API-Dokumentationen, Altcode ohne Kommentare: Das Modell fasst zusammen und beantwortet Fragen, der Entwickler prüft die Stellen, auf die es ankommt.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Texte und Übersetzungen.\u003C\u002Fstrong> Oberflächen, Dokumentation, Nachrichten an Kunden – Entwurf vom Modell, Freigabe vom Menschen. Ein Beispiel mit Zahlen: 8 677 UI-Strings einer Anwendung in etwa einer Stunde ins Türkische gebracht; den Ablauf beschreiben wir in einem eigenen Beitrag.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Das Wort „Pflicht“ ist wichtig. Ein Werkzeug, das jeder nutzen darf, nutzt die Hälfte der Mannschaft. Ein Werkzeug, das im Prozess steht, nutzen alle – und erst dann lassen sich seine Ergebnisse messen.\u003C\u002Fp>\n\n\u003Ch2 id=\"ebene-2\">Ebene 2: Agenten, die Aufgaben ausführen\u003C\u002Fh2>\n\u003Cp>Auf der zweiten Ebene wird es interessant. Wir betreiben eine Farm von \u003Ca href=\"\u002Flexikon\u002Fwas-ist-ein-ki-agent\">KI-Agenten\u003C\u002Fa>: Mehrere Agenten bearbeiten gleichzeitig Aufgaben aus unserem Aufgabensystem, jeder in einem eigenen Terminal, sichtbar auf einem Bildschirm, protokolliert und überprüfbar. Eine Aufgabe kann so eigenständig bis zum Ergebnis laufen – am Ende steht ein Pull Request, den ein Mensch prüft und freigibt.\u003C\u002Fp>\n\u003Cp>Im Alltag heißt das: Ein Entwickler formuliert morgens drei Aufgaben präzise genug, dass ein Agent sie ausführen kann, und arbeitet parallel an der vierten, die diese Präzision noch nicht hat. Die Kunst liegt in der Formulierung, nicht im Warten. Wer schlecht spezifiziert, bekommt drei Pull Requests, die er ablehnt – derselbe Mechanismus wie bei einem neuen Kollegen, nur dass die Rückmeldung in Minuten kommt statt in Tagen.\u003C\u002Fp>\n\u003Cp>Darunter liegt eine Infrastruktur, ohne die diese Ebene nicht verantwortbar wäre. Jeder Aufruf eines Sprachmodells – aus einem Skript, einem Agenten, einem Chat – läuft durch eine eigene Schleuse mit harter Kostengrenze; eine Umgehung ist auf Build-Ebene gesperrt. Wer eine Aufgabe schickt, nennt die Art der Aufgabe, nicht das Modell. So wissen wir jeden Tag, was der Betrieb kostet, und kein Agent kann ein Budget verbrennen. Dazu kommt ein Katalog: Ein Agent greift nur auf Aktionen zu, die dort eingetragen und abgenommen sind.\u003C\u002Fp>\n\n\u003Ch2 id=\"ebene-3\">Ebene 3: KI im Unternehmen des Kunden\u003C\u002Fh2>\n\u003Cp>Die dritte Ebene ist das, was wir liefern: einen KI-Empfang, der eingehende Nachrichten aus allen Kanälen in einen Posteingang holt und Antwortentwürfe im Namen des zuständigen Mitarbeiters vorbereitet; einen Souffleur, der während eines Kundengesprächs Hinweise einblendet; Auswertungen, die Kennzahlen beobachten und melden, wenn eine Zahl aus dem Rahmen fällt. Das ist kein Entwicklungswerkzeug mehr, sondern arbeitendes Personal – mit einem Menschen, der freigibt.\u003C\u002Fp>\n\u003Cp>Die Grundlage dafür ist eine Wissensbasis mit Freigabe-Warteschlange: Regeln, Prozesse und Stammdaten liegen in einer Datenbank mit semantischer Suche, neues Material strukturiert das Modell und legt es in die Warteschlange. In die Wissensbasis kommt nichts ohne Freigabe durch einen Menschen. Das ist der Unterschied zwischen einer Suche über einen Dokumentenhaufen und einer Suche über geprüftes Wissen. Wie ein solches Vorhaben abläuft, steht unter \u003Ca href=\"\u002Fleistungen\u002Fki-implementierung\">KI-Implementierung für den Mittelstand\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Ch2 id=\"grenze\">Wo die Beschleunigung aufhört\u003C\u002Fh2>\n\u003Cp>Die Zahlen aus unseren Projekten – 8 677 Strings in etwa einer Stunde, 19 686 Bestellungen ohne eine einzige Dublette in ein CRM übernommen – stammen alle aus derselben Kategorie: viel, gleichförmig, gut prüfbar. Anbindungen, Datenübernahmen, Lokalisierung, Dokumentenanalyse, erstes Review, gleichartiger Code. Dort ist ein Entwickler mit dieser Ausstattung um ein Vielfaches schneller als ohne.\u003C\u002Fp>\n\u003Cp>Bei Architekturentscheidungen, in Gesprächen mit dem Fachbereich und bei Aufgaben, die noch niemand so gelöst hat, bestimmt der Entwickler das Tempo, nicht das Werkzeug. Ein Modell liefert dort Optionen und Gegenargumente, keine Entscheidung. Wir versprechen deshalb nicht „fünfmal schneller bei allem“: Dieses Versprechen würde am ersten Projekt scheitern, und mit ihm das Vertrauen. Was wir zusagen, ist deutlich schneller, wo die Arbeit Volumen hat – und Ehrlichkeit dort, wo sie Kopf braucht.\u003C\u002Fp>\n\u003Cp>In welche der beiden Kategorien ein Vorhaben fällt, klärt meist ein kurzes Gespräch – oder eine \u003Ca href=\"\u002Fleistungen\u002Fki-beratung\">KI-Beratung für den Mittelstand\u003C\u002Fa>, wenn die Antwort einen Arbeitstag braucht.\u003C\u002Fp>",[34,42,70],{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":35,"toc":36},[13,14,15],[37,38,39,40,41],{"id":18,"text":19},{"id":21,"text":22},{"id":24,"text":25},{"id":27,"text":28},{"id":30,"text":31},{"slug":43,"title":44,"subtitle":45,"date":46,"metaTitle":47,"metaDescription":48,"excerpt":49,"readingMinutes":11,"tags":50,"toc":54},"8677-ui-strings-in-einer-stunde","8 677 UI-Strings in einer Stunde: KI-Automatisierung mit Prüfschritten","Was das Modell übernommen hat, was der Mensch – und wo die Fehler saßen","2026-08-20","8 677 UI-Strings in einer Stunde übersetzt: der Ablauf","Eine Anwendung bekommt eine fünfte Sprache: parallele Blöcke, ein Glossar, harte Prüf-Gates und ein zweites Review – Automatisierung mit KI und ihre Grenzen.","Ein Kunde brauchte sein Panel auf Türkisch. 8 677 Übersetzungsschlüssel, parallele Blöcke, ein Glossar, drei automatische Prüfungen und ein unabhängiges Review: Der Kern der Arbeit dauerte etwa eine Stunde, der ehrliche Aufwand einen Arbeitstag.",[51,52,53],"Lokalisierung","LLM","Praxisbericht",[55,58,61,64,67],{"id":56,"text":57},"ausgangslage","Ausgangslage: vier Sprachen, ein neuer Kollege",{"id":59,"text":60},"aufteilung","KI-Automatisierung heißt Arbeitsteilung, nicht Ersatz",{"id":62,"text":63},"pipeline","Die Pipeline: Blöcke, Glossar, harte Gates",{"id":65,"text":66},"fehler","Wo es hakte",{"id":68,"text":69},"lessons","Was KI-Automatisierung nicht abkürzt",{"slug":71,"title":72,"subtitle":73,"date":74,"metaTitle":75,"metaDescription":76,"excerpt":77,"readingMinutes":11,"tags":78,"toc":81},"abnahmekriterien-statt-zusagen","Abnahmekriterien statt Zusagen: wie aus „bauen Sie uns etwas“ ein prüfbarer Satz wird","Welche drei Fragen wir stellen, was davon ins Angebot kommt – und wo wir uns selbst geschadet haben","2026-08-14","Prüfbare Kriterien statt Zusagen: so entsteht ein Angebot","Wie aus einem vagen Wunsch ein Abnahmekriterium wird, das vor dem Start im Angebot steht: drei Fragen, drei Beispiele aus Projekten und unsere eigenen Fehler.","„Bauen Sie uns ein System für die Bestellungen“ ist ein Wunsch, kein Auftrag. Wir beschreiben, mit welchen drei Fragen daraus ein Satz wird, den beide Seiten am Ende gegen die Wirklichkeit halten können, was davon vor dem Start im Angebot steht – und welche unserer eigenen Formulierungen uns später Diskussionen eingebracht haben.",[14,79,80],"Werkvertrag","Projektpraxis",[82,85,88,91,94],{"id":83,"text":84},"wunsch","Warum „bauen Sie uns ein System“ kein Auftrag ist",{"id":86,"text":87},"fragen","Abnahmekriterien entstehen aus drei Fragen",{"id":89,"text":90},"angebot","Abnahmekriterien gehören ins Angebot, nicht ins Protokoll",{"id":92,"text":93},"beispiele","Drei Sätze aus echten Projekten",{"id":65,"text":95},"Wo wir uns selbst geschadet haben",1789232596306]