KI-Entwicklung & Programmierung: Apps bauen mit KI

In der Solo-Entwicklung bleiben viele bei „gebaut, aber wie verdiene ich und welchen Preis setze ich?“ stecken. Dieser Artikel fasst aus Sicht des Solo-Entwicklers praxisnah zusammen: die Wahl des Erlösmodells (gratis/Einmalkauf/Abo/Freemium/Werbung/Spenden), die wertbasierte Preisgestaltung, die nicht von Kosten oder Konkurrenz, sondern vom „Wert, den der Kunde erhält“ ausgeht, den 3-Stufen-Plan Gratis→Pro→Business mit Jahresrabatt als Standard, wie man die ersten zahlenden Nutzer gewinnt, und die Rentabilität, in die man KI-Kosten wie API-Token einrechnet. Ein Beitrag, der die Wachstumsphase des Mutterschiff-Artikels „Roadmap zur Solo-Entwicklung mit KI“ vertieft.

Die größte Ursache, warum Solo-Entwicklung nie fertig wird, ist „zu viel Ausbauen“. Während man immer mehr Funktionen drauflädt, wird es komplex und verschwindet, ohne je veröffentlicht zu werden. Der einzige Weg, das zu vermeiden, ist, das kleinste Produkt, das Wert vermittelt — das MVP — auf eine Funktion eingegrenzt im Höchsttempo zu veröffentlichen. Dieser Artikel erklärt aus Sicht des Solo-Entwicklers, der KI zum Partner macht: das richtige Verständnis vom MVP, die Umfangsentscheidung beim Kürzen von Funktionen, die zwei Routen, mit KI am schnellsten zu bauen (codeloses Vibe Coding / Praxis im KI-Editor), das Erkennen von „fertig“ und den Weg bis zur Veröffentlichung und ersten Nutzung durch eine Person.

Jetzt, da die KI eine „Hand zum Programmieren“ hat, kann schon eine einzelne Person ein Produkt bauen und veröffentlichen. Doch die Informationen sind über die Schritte verstreut, und man verliert leicht den Überblick, womit man anfangen soll. Dieser Artikel ist die Gesamtkarte von der Idee über Entwurf und Implementierung bis zu Veröffentlichung und Monetarisierung: Er ordnet die Solo-Entwicklung in fünf Phasen – Festlegen → Vorbereiten → Bauen → Veröffentlichen → Wachsen lassen – zeigt für jeden Schritt, was zu tun ist und welches Werkzeug man nutzt, und verweist bei Bedarf auf die jeweiligen Einzelanleitungen (Hub-Artikel). Geführt wird auf zwei Spuren: der 🌱 Einstiegsroute fast ohne Code und der 🔧 Praxisroute mit Code im KI-Editor. Von Spec-Driven Development, KI-App-Buildern, Claude Code/Cursor und dem Einbau von KI-Funktionen (API/RAG/Gateway) über Deployment, SEO/AEO-Nutzergewinnung, Monetarisierung und Kostenkontrolle bis zu den 5 Stolperfallen der Solo-Entwicklung mit KI – alles mit Wegweisern zu den bestehenden Praxisanleitungen auf einer Seite.

Sie sind ans wöchentliche Token-Limit von Claude Code gestoßen, doch das Kontingent hat sich vollständig aufgefüllt, bevor sieben Tage vergangen waren — und das mehrfach. Online gibt es sogar „Geheimmechanismus“-Beiträge mit der Behauptung, das wöchentliche Limit setze sich alle 72 Stunden zurück. Stimmt das? Dieser Artikel führt das Phänomen auf Primärquellen zurück. Da Anthropic den internen Reset-Mechanismus aber nicht dokumentiert hat und die Limits sich ständig ändern, kennzeichnen wir klar drei Arten von Informationen: aus offiziellen Quellen bestätigbare Tatsachen, Ereignisse, die mehrere Nutzer reproduzierbar beobachten, zu denen sich Anthropic aber nie geäußert hat, und Einzelquelle-Spekulation. Der Kern: Die frühe vollständige Erholung sind in den meisten Fällen Anthropics unregelmäßige globale Resets (wiederholt von @ClaudeDevs angekündigt); die angezeigte Reset-Zeit ist zudem nachweislich instabil; und der kursierende „72-Stunden-Rhythmus“ beruht auf einer Einzelbeobachtung, ist nicht reproduziert und wird durch eine andere Beobachtung (24 h) widersprochen, kann also nicht als Tatsache gelten. Seit September 2026 gibt es zudem eine neue Form: einen gewährten Reset, den Sie einsetzen, wann Sie wollen („Reset for free“ unter Settings > Usage im Web oder in Claude Desktop; Claude Code im Terminal hat dafür keinen Button). Wo sich etwas nicht aussagen lässt, sagen wir das — eine Untersuchung mit Stand September 2026.

Sie haben auf OpenAI aufgebaut, wollten dann Claude ausprobieren und Gemini vergleichen — und verloren Stunden an die je Anbieter unterschiedlichen SDKs, Formate und Fehlerbehandlung. Ein LLM-Gateway (AI-Gateway / LLM-Proxy) ist ein Relais, das Sie zwischen Ihre App und die Anbieter schieben: es stellt eine einzige OpenAI-kompatible API bereit, um jedes Modell zu erreichen, und übernimmt die querschnittlichen Aufgaben — Fallback, Kostenverfolgung, virtuelle Keys, Caching, Rate-Limiting und Observability. Dieser Leitfaden behandelt, warum Sie eines brauchen, was ein Gateway wirklich ist, die drei Typen (Self-hosted-Proxy = LiteLLM / hosted = OpenRouter / SDK = Vercel AI SDK), wie Sie zwischen LiteLLM, OpenRouter und dem Vercel AI SDK wählen, minimalen Setup-Code, der nur den Endpunkt tauscht, und die Grenzen — ein Latenz-Hop, das Gateway als neuer Ausfallpunkt, Gebühren (OpenRouter berechnet 5,5% auf Käufe), Feature-Verlust und Privatsphäre.

Nachdem du einen KI-Agenten gebaut hast, stößt du immer an dieselbe Wand: „Okay, aber läuft das wirklich?“ Der Mechanismus, mit dem du entscheidest, ob eine Prompt- oder Modelländerung die Sache mit Daten statt Bauchgefühl besser oder schlechter gemacht hat, sind Evals. LLMs liefern für dieselbe Eingabe jedes Mal eine andere Ausgabe, weshalb Exact-Match-Unit-Tests nicht passen. Dieser Artikel legt den Schwerpunkt auf die Schritte, mit denen du Evals tatsächlich baust und betreibst, und behandelt fünf Wege, Qualität zu messen (① Ground-Truth-Abgleich ② regelbasierte Prüfungen ③ LLM-as-judge ④ Regressionstest ⑤ Produktionsmonitoring), die agent-spezifische Bewertung (Aufgaben-Erfolgsrate, korrekte Tool-Aufrufe, Trajektorie, Kosten), wie du klein mit 20 Fehlerbeispielen anfängst, häufige Fallstricke und wichtige Tools (Anthropic Console/Evals, OpenAI Evals, LangSmith, Langfuse, Ragas) — geschrieben für Praktiker.

Die ewige Automatisierungsfrage: „KI-Agenten oder RPA?“ Die Antwort ist kein Entweder-oder – wählen Sie nach Rolle, und das erfolgreiche Muster 2026 ist ein Hybrid aus beidem. RPA sind deterministische „Hände“, die einen festen Ablauf schnell und präzise ausführen (aber abbrechen, wenn sich Bildschirm/Spezifikation ändert); ein KI-Agent ist ein probabilistisches „Gehirn“, das die Lage liest und entscheidet (stark bei Mehrdeutigkeit und Ausnahmen, aber nicht jedes Mal identisch). Dieser Artikel behandelt den Unterschied im Funktionsprinzip, eine Vergleichstabelle (den Kompromiss zwischen Reproduzierbarkeit und Robustheit), die Auswahl (die Achse lautet „lässt es sich vollständig als Regeln ausschreiben?“ – ja → RPA, nicht ausschreibbares Urteilen → KI-Agent), den Trend 2026 (RPA-Anbieter UiPath, Automation Anywhere, Blue Prism werden agentisch – Konvergenz; die Frage ist nicht mehr „welches von beiden“, sondern „wo ist das Schlussfolgern angesiedelt“ = Orchestration-first) und die praktische Antwort: einen Hybrid, bei dem das Gehirn (KI-Agent) Urteilen/Orchestrierung übernimmt und die Hände (RPA) die deterministische Ausführung leisten – setzen Sie keinen Agenten dort ein, wo Determinismus verlangt wird, und koppeln Sie delegiertes Urteilen mit Leitplanken und menschlicher Freigabe. Auf Basis offizieller Anbieterinformationen, mit FAQ.

Claude Fable 5 und Opus 5 sind beide Spitzenklasse, aber die Antwort lautet weder „immer Fable 5“ noch „immer Opus 5“ — wählen Sie nach Aufgabe. Mit dem Erscheinen von Opus 5 am 24. Juli 2026 hat sich diese Antwort spürbar verschoben: Die Vorgängergeneration Opus 4.8 galt als „eine Stufe unter Fable 5, dafür halb so teuer“, während Opus 5 denselben Preis von $5 / $25 hält und Fable 5 bei agentischen Benchmarks erreicht oder übertrifft (Frontier-Bench 43,3 % vs. 33,7 % und OSWorld 2.0 70,6 % vs. 66,1 %, beide aus Anthropics Vergleichstabelle; bei CursorBench 3.2 kommt Opus 5 laut Anthropic bis auf 0,5 % an Fable 5 heran, zu etwa den halben Kosten). Wo der Abstand klein ist, hängt die Reihenfolge von der Tabelle ab: Bei DeepSWE v1.1 führt Fable 5 in Anthropics Tabelle mit 69,7 % zu 68,8 %, in OpenAIs Tabelle Opus 5 mit 73,7 % zu 69,9 %. Kontextfenster (1M) und maximale Ausgabe (128K) sind gleich; den Fast Mode (rund 2,5-fach) gibt es nur bei Opus 5, allerdings zum doppelten Preis und nur über die Claude API, und Opus 5 hat den neueren Wissensstand (Mai 2026). Der Entscheidungsablauf: zuerst Opus 5 probieren und nur dort zu Fable 5 hochstufen, wo es auf ein Plateau läuft. In der Praxis ist „Opus 5 als Basis, Fable 5 für die harten Teile“ optimal, gestützt durch das automatische Umschalten bei Sicherheitssperren in der App und den neuen API-Rückfallmodus „default“. Behandelt Verfügbarkeit (Aussetzung im Juni, erneuter Rollout im Juli), das Vermeiden von Einzelmodell-Abhängigkeit, effort-Tuning für die Kosten und ein FAQ — und verknüpft das Fable-5-Cluster mit dem Leitfaden zum Opus-5-Release.

Die erste Hürde beim Einbau eines KI-Agenten in echte Arbeit ist die Frage, „auf welchem Framework man ihn baut“. Aus der Sicht von Entwicklern und Technologie-Entscheidern vergleicht dieser Artikel sechs wichtige Frameworks — LangGraph, CrewAI, AutoGen (im Microsoft Agent Framework aufgegangen, GA April 2026), OpenAI Agents SDK, Google ADK und Claude Agent SDK — nach Orchestrierungsansatz (gerichteter Graph / rollenbasierte Crew / konversationsbasierter GroupChat / Handoffs / hierarchischer Baum / autonome Werkzeugschleife), Sprache, Lernkurve, Steuerbarkeit, Produktionsreife, Token-Kosten und passendem Anwendungsfall. Der zentrale Vorbehalt: Das Framework, das sich „am schnellsten prototypisieren lässt“ (CrewAI), kann im Produktivbetrieb das teuerste sein — rund das 3-Fache der Tokens (41k gegenüber 18,5k bei LangGraph in einem Benchmark) und nicht-deterministisch, was es für Finanz- und Gesundheitswesen ungeeignet macht. Außerdem erklärt der Artikel, wie 2026 die Interoperabilität über MCP (Werkzeuge) und A2A (Agent-to-Agent) kam, sodass Agenten aus verschiedenen Frameworks nun zusammenarbeiten können und der Lock-in verblasst ist. Mit Leitfaden zur Auswahl nach Anwendungsfall und FAQ.

Ollama ist das erste Tool, das du für lokale LLMs installieren solltest – es nimmt dir die mühsame Einrichtung fast vollständig ab, sodass du ein Modell mit einem einzigen Befehl herunterladen und sofort loschatten kannst. Dieser Einsteiger-Leitfaden führt von A bis Z durch Installation (Win/Mac/Linux), die wichtigsten Befehle, das Beschaffen und Auswählen von Modellen nach VRAM-Größe, GUIs wie Open WebUI, die lokale und OpenAI-kompatible API zum Einbinden in eigene Apps, Anpassung über Modelfile und Umgebungsvariablen sowie Fehlerbehebung – damit du Ollama als „Docker für LLMs“ schnell zum Laufen bringst.

Welches lokale LLM solltest du installieren? Dieser Leitfaden für 2026 ordnet die wichtigsten Modellfamilien – Qwen, Llama, Gemma, DeepSeek, Mistral, Phi und mehr – nach Entwickler, Herkunftsland, Einsatzzweck, Größe und Lizenz, damit du das passende „erste Modell“ für deinen PC findest. Mit einem eigenen Abschnitt zu deutschen und europäischen Modellen wie Teuken-7B (OpenGPT-X/Fraunhofer), Aleph Alpha, den Llama-Feintunings LeoLM und DiscoLM sowie Mistral aus Frankreich – plus klaren Empfehlungen nach VRAM-Größe, praktischen Tipps zur kommerziellen Lizenzierung und dem Hinweis, dass lokal betriebene Modelle deine Eingaben nie nach außen senden.

Du willst ein lokales LLM betreiben, weißt aber nicht, ob dein PC ausreicht? 90 % der nötigen Spezifikation hängt am VRAM – dem Speicher deiner GPU. Dieser Guide liefert eine VRAM-Schnelltabelle nach Modellgröße (7B bis 70B), eine einfache Formel zum Selbstrechnen, die oft übersehene Speicherfalle aus Kontextlänge und KV-Cache sowie realistische Geschwindigkeiten für gängige GPUs und Macs. Am Ende findest du empfohlene Konfigurationen in drei Budget-Stufen, damit auch Einsteiger sicher entscheiden können, welche Hardware sie wirklich kaufen sollten.