Interne Tools mit KI erstellen ohne Entwickler: was geht, welches Modell, welche GPU

Interne Tools mit KI bauen, wenn in der Firma niemand programmiert

Auch ein Unternehmen ohne Entwickler kann seine kleinen internen Tools selbst mit KI erstellen. Eine Büro-, Betriebs- oder Produktionsleitung beschreibt das Tool in einfachen Worten, ein KI-App-Builder schreibt den Code, und die Person prüft das Ergebnis in einer Vorschau und korrigiert es mit Worten. Mit dem quelloffenen App-Builder Dyad und einem Sprachmodell auf einer firmeneigenen Workstation bleiben Beschreibungen, Code und Testdaten im Haus. Eine Workstation mit einer NVIDIA RTX PRO 4500 Blackwell (32 GB) ist die kleinste Konfiguration, die wir für eine Person empfehlen; Tools, die mit dem ERP-System sprechen, sich mit Firmenkonten anmelden oder im Internet erreichbar sind, brauchen weiterhin einen Entwickler.

Zuerst drei Begriffe. Ein App-Builder ist ein Programm, in dem Sie eine Anwendung im Chat beschreiben und das den Code für Sie schreibt und startet; diese Arbeitsweise heißt oft Vibe Coding. Ein Modell ist die KI, die den Code schreibt: eine große Datei, die auf einer Grafikkarte (GPU) mit genügend Speicher läuft. Lokal bedeutet, dass das Modell auf Ihrer eigenen Hardware läuft und nicht in der Cloud eines Anbieters.

Dieser Leitfaden richtet sich an die Person, die die Tools bauen würde, und an die Geschäftsführung, die darüber entscheidet. Die App-Builder selbst vergleicht unser Vergleich selbst gehosteter Lovable-Alternativen.

Was ohne Programmier­kenntnisse geht und was einen Entwickler braucht

Dyads FAQ hält fest, dass es „only supports JavaScript-based apps at this time“, also nur JavaScript-Anwendungen unterstützt; praktisch sind das Webanwendungen, die im Browser laufen. Das deckt einen großen Teil der Büroarbeit ab; die Tabelle ordnet typische Wünsche ein.

Dyad-FAQ, gelesen am 30. Oktober 2026; die Einordnung ist unsere Empfehlung.

Eine Excel-Liste in eine Web-App umzuwandeln ist der häufigste erste Wunsch. Beschreiben Sie die Spalten und was die Maske tun soll, hängen Sie einige Zeilen erfundener Beispieldaten an und bitten Sie um ein Formular, das Einträge anlegt, und eine Tabelle, die sie filtert. Nehmen Sie erfundene Namen statt der echten Kundenliste, bis feststeht, wo die Daten liegen werden. Je mehr Logik Sie als Regel formulieren können („5 Prozent Rabatt ab 100 Stück“), desto besser, weil Sie das Ergebnis an Fällen prüfen können, die Sie kennen.

Entscheidend ist, worauf ein Tool zugreift. Ein Tool, das eine Datei liest und anzeigt, ist leicht zu prüfen. Eines, in das mehrere Personen gleichzeitig schreiben, braucht eine Datenbank, Benutzerrechte und Datensicherung, und sobald es personenbezogene Daten enthält oder andere Systeme anbindet, sollte jemand mit IT-Verantwortung es prüfen. Lässt sich die Aufgabe in einer Tabelle lösen, ist unser Leitfaden zu Excel-Makros und VBA mit lokaler KI der kürzere Weg; IT-Teams, die eine Plattform mit Rollen und Freigaben suchen, vergleichen Power-Apps-Alternativen mit lokaler KI.

Beschreiben, prüfen, korrigieren und Versionen behalten

Dyads Schnellstart beschreibt den Ablauf. Sie tippen in den Chat, was Sie wollen, die KI erzeugt den Code, Sie bestätigen ihn, und die App wird laut Anleitung gespeichert und auf Ihrem Rechner ausgeführt („saved and run on your computer“), in einer Vorschau neben dem Chat. Die Vorschau läuft auf Node.js, dem Programm, das JavaScript außerhalb des Browsers ausführt, und die erste Vorschau einer App installiert deren npm-Pakete, fertige Code-Bausteine, deshalb braucht die Workstation für diese Downloads einen Internetzugang. Tritt ein Fehler auf, bietet Dyad unter Umständen eine Schaltfläche „Fix with AI“ an; sonst beschreiben Sie das Symptom in Worten, etwa „Nach dem Login sehe ich nichts“, dem Beispiel aus Dyads Anleitung zur Fehlersuche.

Jede Änderung bleibt erhalten: Dyads Anleitung zur Versionierung hält fest, dass „Every version in Dyad is essentially a git commit“, und das Wiederherstellen einer früheren Version legt einen neuen Commit an, statt Arbeit zu löschen. Drei Gewohnheiten helfen:

1. Mit einer Maske und einer Aufgabe beginnen, dann Funktionen Anfrage für Anfrage ergänzen.
2. Nach jeder Änderung die wichtigsten Abläufe in der Vorschau testen, wie Dyads Anleitung zur Fehlersuche empfiehlt.
3. Tools klein halten: Dyads Anleitung für große Apps rät, eine zu groß gewordene App in kleinere aufzuteilen.

Was mit einem lokalen Modell im Haus bleibt

Während Sie ein Tool bauen, enthalten die Eingaben Ihre Feldnamen, Beispieldatensätze und Preisregeln und manchmal echte Kunden- oder Mitarbeiterdaten, die jemand zum Testen eingefügt hat. Mit einem Cloud-Modell geht all das an den Modellanbieter. Dyads Datenschutzerklärung, zuletzt aktualisiert am 22. Juni 2026, sagt es deutlich: Mit eigenen API-Schlüsseln gehen Eingaben und Code direkt an die Modellanbieter („your prompts and code are sent directly to the model providers“), mit lokalen Modellen gilt „everything stays on your device“, und in beiden Fällen „your data never passes through Dyad's servers“. Telemetrie wird nur mit Ihrer Einwilligung erhoben und enthält laut derselben Erklärung keine Chatnachrichten, Eingaben oder Code („does not include your chat messages, prompts, or code“). Dieselbe Erklärung hält fest, dass mit Dyad Pro „your prompts and code are proxied through Dyad servers before reaching the model providers“; eine Einrichtung, bei der alles im Haus bleibt, nutzt Dyad deshalb ohne Pro und Ollama mit abgeschalteten Cloud-Modellen und abgeschalteter Websuche (OLLAMA_NO_CLOUD=1, wie Ollamas FAQ beschreibt).

Einige Wege führen dennoch aus dem Haus, und wer baut, sollte sie kennen:

• Datenbanken. Dyads dokumentierte Anbindungen für Daten und Login sind Supabase und Neon. Die Server-Funktionen von Supabase laufen auf den Servern von Supabase, und Dyads Dokumentation beschreibt Neon als „a serverless, fully-managed Postgres platform“. Ein daran angebundenes Tool speichert seine Daten bei diesem Anbieter.
• Veröffentlichen. Dyads Anleitung zum Veröffentlichen behandelt GitHub und Vercel, die den Code und die laufende App auf ihren Plattformen halten.
• Downloads. npm-Pakete und Modelldateien kommen aus dem Internet, deshalb braucht die Workstation diesen Zugang auch dann, wenn das Modell lokal läuft.

Ein lokales Modell nimmt den Modellanbieter aus dem Spiel; den übrigen Datenschutz erledigt es nicht. Unser Leitfaden zu lokaler KI und DSGVO erklärt, was der eigene Betrieb löst und was Pflicht des Unternehmens bleibt, und Ihr Datenschutz­beauftragter bestätigt, wie personenbezogene Daten in so gebauten Tools verwendet werden dürfen.

Sie können die Workstation allein bestellen, die Einrichtung von Dyad, Ollama und dem Modell allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Welches Modell für einen App-Builder reicht

Die Größe des Modells entscheidet, ob ein App-Builder überhaupt funktioniert. Dyads FAQ schreibt, wenn der Builder scheitert, nutze man wahrscheinlich „a local model which is too small and not smart enough to follow Dyad's instructions“. Sein Blogbeitrag vom 4. Februar 2026 ergänzt, dass „Smaller models (under 7B parameters) often struggle to follow structured output formats“, empfiehlt für die besten lokalen Ergebnisse Qwen 2.5 Coder 14B oder 32B und hält fest, dass die besten Cloud-Modelle „are still stronger at complex coding tasks than most models you can run locally“.

Die Modelle haben sich seit diesem Beitrag weiterentwickelt, und wir beginnen bei der 27B-Klasse (27 Milliarden Parameter):

• Qwen3.8-27B, im August 2026 von Qwen unter Apache 2.0 veröffentlicht, mit einem Kontext von 262.144 Token. Ollama führt es als qwen3.8:27b, als Download von 18 GB in 4 Bit (Q4_K_M) und als 8-Bit-Version mit 30 GB (q8_0). In Qwens eigener Tabelle erreicht es 90,3 Punkte in LiveCodeBench v6 gegenüber 88,8 für Anthropics Cloud-Modell „Opus4.6 Max“ und 73,0 gegenüber 78,2 in Terminal Bench 2.1; das sind Angaben des Herstellers.
• Qwen3.6-35B-A3B, im April 2026 unter Apache 2.0 veröffentlicht, ein Mixture-of-Experts-Modell, das pro Token (ein Wort oder Wortteil) etwa 3 seiner 35 Milliarden Parameter nutzt und deshalb schneller schreibt. Ollamas 4-Bit-Version ist ein Download von 24 GB. Qwens Tabelle gibt ihm 1.397 Punkte in QwenWebBench, Qwens Test für das Bauen von Webseiten, gegenüber 1.197 für Gemma4-31B.

Beide brauchen einen langen Kontext, also die Textmenge, die das Modell auf einmal liest: die Anweisungen des Builders, Ihre Anfrage und den Code der App. Ollamas Dokumentation sagt, Coding-Tools „should be set to at least 64000 tokens“, während Ollama auf einer Karte mit 24 bis 48 GiB Speicher standardmäßig 32K einstellt. Ob ein lokales Modell in Ihrem Fall Cloud-Dienste ersetzen kann, behandelt unser Artikel Reicht ein lokales Modell fürs Vibe Coding?

Wie viele Personen eine Workstation versorgt

Die Hardwarefrage ist eine Frage des Speichers: Das Modell und sein Cache für die laufenden Sitzungen müssen in den Speicher der Grafikkarte passen. Wir rechnen mit unserer Regel für Nutzer je Karte: 90 Prozent des Speichers, den der Treiber meldet, abzüglich 3 GiB pro Karte, müssen das Modell und einen Cache für jede gleichzeitig arbeitende Sitzung aufnehmen. Eine Sitzung mit 64.000 Token braucht bei Qwen3.8-27B mit Ollamas standardmäßigem 16-Bit-Cache 4,14 GiB, nach unserer Rechnung aus der Konfiguration des Modells wie in unserem Leitfaden zu den Qwen-Hardware­anforderungen.

Nutzbarer Speicher nach unserer Regel für Nutzer je Karte: 25,7, 40,0 und 83,0 GiB pro Karte; Download-Größen von Ollama (18 und 30 GB) laut ollama.com am 30. Oktober 2026, in GiB umgerechnet; 4,14 GiB Cache pro Sitzung mit 64K. WS: Workstation Edition (eine Max-Q hat denselben Speicher), SE: Server Edition. Unsere Schätzungen, keine Messungen.

Die Einstiegsstufe in Zahlen: 18 GB sind 16,8 GiB, und 25,7 − 16,8 lässt 8,9 GiB, Platz für zwei Sitzungen. Eine Workstation mit einer RTX PRO 4000 Blackwell (24 GB) hat nach derselben Regel 18,5 GiB; nach dem Modell bleiben 1,7 GiB, zu wenig für eine Sitzung mit 64K. Sie passt zu anderen KI-Aufgaben, nicht zu diesem Modell im App-Builder. Auf der RTX PRO 5000 48 GB lässt die 8-Bit-Version (27,9 GiB) 12,1 GiB für zwei Sitzungen, die 4-Bit-Version Platz für fünf. Eine RTX PRO 6000 Blackwell Workstation Edition mit 96 GB hält die 8-Bit-Version mit dreizehn. In der Serverstufe betreibt eine Karte das Builder-Modell und die zweite ein Chat-Modell für die ganze Firma, wie unser Leitfaden Eigene KI für Firmen mit 10 bis 100 Mitarbeitern beschreibt. Unser Leitfaden zur Vibe-Coding-Workstation nach RTX-PRO-Stufe vergleicht diese Ausstattungen mit 128K Kontext für längere Projekte.

Eine Sitzung ist eine Person, deren Anfrage gerade beantwortet wird, nicht jede Person, die das Tool nutzen darf.

Die andere Hälfte ist die Geschwindigkeit. StorageReview hat Qwen3.8-27B im Format NVFP4 mit vLLM 0.27.1 in einem Test vom 14. Oktober 2026 gemessen: Bei einer einzelnen Anfrage lag jede Karte, auf der das Modell lief, zwischen 17 und 22 Token pro Sekunde, von der RTX PRO 4500 Server Edition und einer L40S bis zu einer RTX PRO 6000 Workstation Edition. Bei diesem Tempo dauert eine Antwort von 1.000 Token nach unserer Rechnung etwa 45 bis 60 Sekunden. Auf Ihrem System hängt die Geschwindigkeit von der Speicherbandbreite der Karte, dem Format des Modells und der Serving-Software ab.

Nach unserer Schätzung (Karte, ein Prozessor mit 350 W und 15 Prozent für den Rest) nimmt eine Workstation mit einer RTX PRO 4500 unter Volllast etwa 0,6 kW auf, mit einer RTX PRO 5000 etwa 0,75 kW und mit einer RTX PRO 6000 Workstation Edition etwa 1,1 kW, jeweils an einem normalen 230-V-Bürostromkreis. Der Server mit zwei Karten nimmt etwa 1,8 kW auf und gehört in einen Serverraum.

Wo das fertige Tool läuft und wer es betreut

In Dyads Vorschau läuft das Tool nur auf dem Rechner der Person, die es baut. Dyad beschreibt das Ergebnis als „normal code in a folder you keep“, also normalen Code in einem eigenen Ordner, der auch auf einer anderen Maschine in Ihrem Netzwerk laufen kann. Damit Kolleginnen und Kollegen es nutzen, stellen Sie es auf eine Maschine im Firmennetz: Die Workstation mit RTX PRO 6000 Workstation Edition aus der größeren Stufe oder der KI-Server der Firma kann die fertigen Tools neben dem Modell betreiben. Halten Sie sie vom Internet fern; ein Tool, das von außen erreichbar sein muss, geht zuerst an einen Entwickler und durch eine Sicherheitsprüfung.

Vereinbaren Sie drei Punkte, bevor das erste Tool in Betrieb geht:

• Wem es gehört. Wer das Tool gebaut hat, verantwortet seinen Inhalt und entscheidet über Änderungen; der IT-Dienstleister betreibt Maschine, Datensicherung und Zugänge, wie in unserem Leitfaden KI-Server ohne IT-Abteilung.
• Welche Daten es halten darf. Eine kurze Regel in der KI-Nutzungsrichtlinie der Firma legt fest, welche Tools personenbezogene Daten speichern dürfen und wer sie prüft.
• Eine Prüfung. Dyad hat eine Sicherheitsprüfung, die mit KI nach Schwachstellen sucht. Die Dokumentation nennt die Funktion experimentell, schreibt, sie „may not catch all relevant security issues“, und empfiehlt, sie zusammen mit anderen Sicherheitsprodukten zu nutzen; unsere Prüfungen vor dem Livegang einer mit KI gebauten App nennen, was sonst zu prüfen ist.

Ob für eine Person oder für mehrere in Ihrem Netzwerk: Senden Sie uns die Tools, die Sie planen, und wir schlagen die Konfiguration vor.

Lizenzen von Dyad, Ollama und LM Studio für den Firmeneinsatz

GitHub-Repositorys und Release-Seiten von Dyad und Ollama sowie die App-Bedingungen von LM Studio, gelesen am 30. Oktober 2026.

bolt.diy, ein weiterer quelloffener App-Builder, ist im Wartungsmodus und läuft auf der WebContainers API von StackBlitz, die für den produktiven Einsatz in einem gewinnorientierten Unternehmen eine kommerzielle Lizenz braucht; unser Vergleich selbst gehosteter Lovable-Alternativen behandelt ihn. Für interne Tools eines Unternehmens ist Dyad die einfachere Wahl.

LM Studio, die Alternative zu Ollama, die Dyad unterstützt, hat eigene Bedingungen: eine Lizenz „solely for Your personal and / or internal business purposes“, und „Certain features of the Software may be offered for a fee“. Die Modelle behandelt unser Überblick zu LLM-Lizenzen für den kommerziellen Einsatz.

Hinweise für den IT-Dienstleister

• Verwenden Sie Ollama 0.35.0 oder neuer. CVE-2026-103663, am 8. Oktober 2026 veröffentlicht, erlaubt einer nicht authentifizierten Anfrage an /api/pull, eine Datei außerhalb des Modellspeichers zu schreiben; als kritisch (CVSS 9,4) gilt sie dort, wo der Ollama-Dienst in /usr/lib/ollama schreiben kann, weil die Datei dann nach einem Neustart als root läuft, sonst liegt sie bei 6,9.
• Ollama lauscht standardmäßig auf 127.0.0.1:11434, und seine FAQ beschreibt keine Anmeldung an der API. Für mehrere Personen an einer GPU binden Sie es mit OLLAMA_HOST nur an das interne Netz, halten es hinter der Firewall und setzen dasselbe OLLAMA_HOST für Dyad auf jedem PC, das Dyad dann statt localhost verwendet.
• Setzen Sie den Kontext mit OLLAMA_CONTEXT_LENGTH=64000 oder in der Ollama-App und erhöhen Sie OLLAMA_NUM_PARALLEL für die Zahl der Personen; laut Ollamas FAQ wächst der Speicherbedarf mit beiden.
• Dyad läuft unter Windows und Mac; seine FAQ nennt die Linux-Unterstützung experimentell. Für die Vorschau muss Node.js installiert sein.

Unsere Leitfäden zur Absicherung eines GPU-Servers und zum Schritt von Ollama auf dem PC zum KI-Server für die Firma behandeln die nächsten Schritte.

FAQ