Monkey Ideas

Monkey Ideas: Ideenkraft mit KI, 100% lokal

Mit Monkey Ideas wollte ich untersuchen, ob ich die Vorarbeit für Entwicklungsprojekte bereits besser an den neuen Entwicklungsprozess mit KI anpassen kann. Es geht darum, dass Ideen für z.B. Softwareprojekte gesammelt, verwaltet und weiter ausgearbeitet werden können. Monkey Ideas bildet einen Funnel ab, der von der vagen Idee bis zur Umsetzung führt.

KI-Einsatz im Ideenmanagement? Warum?

Ganz einfach: Die Welt hat sich verändert. Heute lassen sich mehr Ideen schneller umsetzen als je zuvor. KI-Agenten in der Entwicklung werden zum Alltag, doch auch diese benötigen sinnvolle Anforderungen, um sinnvolle Ergebnisse zu erzeugen. Somit setzt Monkey Ideas vor der Umsetzung an und fokussiert auf die Ideenfindung und Herausarbeitung von Backlogs, die Maschinen und Menschen gleichermaßen bearbeiten können.

Warum wird die effiziente Arbeit an Ideen wichtiger? Weil mehr Ideen zur selben Zeit abgearbeitet werden können. Für ein Tool wie Monkey Ideas benötige ich etwa zwei Wochen, um es gemeinsam mit KI-Agenten zu entwickeln. Vor zwei Jahren hätte ich dafür deutlich länger gebraucht. Natürlich hängt der Aufwand auch jetzt von der Komplexität, der Technologie und den Anforderungen ab, aber die eigentliche Umsetzungphase verkürzt sich erheblich.

Umso relevanter wird es in Konsequenz, dass bei der Ideenarbeit auch effizienter und systematischer vorgegangen wird. Einerseits muss ich meinen Innovationsprozess auch an eine neue Umgebung anpassen, andererseits muss ich theoretisch mehr Konzepte verwalten und vorbereiten (wenn ich den Durchsatz bei der Umsetzung ausnutzen möchte). Dies ändert auch den Prozess und die Betrachtung bei der Umsetzungsvorbereitung. Mir war es bei Monkey Ideas wichtig, KI direkt in den Prozess einzubinden – also auch als kooperative Funktionsebene vorzusehen.

Dabei wurde mir klar

… dass ein neuer Ansatz für die Ideenarbeit, Konzeption und Umsetzungsvorbereitung nicht nur für mich, sondern auch für andere wertvoll sein könnte.

• Für Entwickler, die immer mehr zum KI-Stakeholder werden und sich stärker darum kümmern müssen, das Geplante zu artikulieren, so dass die richtigen Dinge in der richtigen Weise erfolgen.
• Für Nicht-Entwickler, die gute Ideen haben, aber noch nie Umsetzungstalent hatten, weil die technischen Skills fehlten; nun aber hier neue Code-Magie einsetzen könnten, um Ideen zu verwirklichen.
• Für klassische Produktleute (wie mich), die einfach systematischer und evtl. interaktiver mit Planung, Ideen, Backlogs arbeiten möchten und dabei KI als Sparringspartner nutzen möchten. Z.B. um bestimmte Aspekte am Konzept (Business, Legal, etc.) zu prüfen.
• Für Solche, die nicht Software, sondern Content entwickeln möchten und gleichermaßen eine moderne Ideenpipeline aufbauen und effizient verwalten möchten.

usw.

Frühe Erkenntnisse im Projekt

Nach 1-2 Tagen Arbeit an der Materie bemerkte ich, dass ein klassischer Innovationsfunnel für Monkey Ideas nicht zielführend wäre. Traditionellere Ansätze (wie ein Stage-Gate-Prozess) gehen mitunter davon aus, dass die Investitionen, das Risiko und die nötige Umsetzungszeit mit allen möglichen am Prozess beteiligten Menschen ausdiskutiert werden. So, dass sich dann in der Organisationsrealität etwa auf einen MVP-Scope, ein Budget und ein Zeitrahmen und den Einsatz der Mittel und Prozesse geeinigt werden kann. Das erschien mir hier allerdings irgendwie grundverkehrt. Denn im vorliegenden Ansatz würde ich verstärkt auf die Kooperation mit KI-Agenten und KI-Tools setzen, lieber mehr Lösungsmöglichkeiten adressieren, als ewig im Vorfeld zu diskutieren, welche Lösung ’theoretisch’ perfekt sei. Lieber würde ich also direkt 10 Varianten parallel umsetzen, prüfen welche die beste ist, als vor der Realisierung einen überladenen Prozess zu installieren.

Also bin ich hier einen anderen Weg gegangen und habe vieles darauf ausgerichtet, dass Ideen schnell für die direkte Umsetzung vorbereitet werden können. Bei Monkey Ideas gibt es aktuell nur Ideen, Backlogs und funktionales Zierwerk, wie etwa eine Prompt-Verwaltung und MCP (Model Context Protocol) Features, so dass derzeitige ‘KI-Entwicklungstools’ wie Cursor die Idee direkt ver- und bearbeiten können.

Wichtig war mir: so viel wie möglich soll auf einem lokalen Rechner laufen

Mit Abstrichen ist dies gelungen:

a) Die App als Solche kann vollständig lokal installiert und genutzt werden, wodurch kein Projekt von einem SaaS Dienst abhängt. Das Intellectual Property bleibt lokal und ich benötige keine SaaS-Lizenz. b) Alle Daten liegen in einer lokalen, file-basierten Datenbank. Das mindert Abhängigkeiten. Wenn weitere Anforderungen an die Datenbank ins Spiel kommen, kann die Datenbank weitestgehend abstrahiert angesteuert werden. Ein Wechsel auf Postgres (z.B. auf einem Server im Netzwerk) wäre somit auch kein Problem. c) Alle ’nativen’ Monkey Ideas KI-Feature hängen nur von lokalen Modellen ab, die über Ollama angesteuert werden. Ich nutze also keinen API Key für Modelle, die irgendwo betrieben werden. d) Ein lokaler MCP ‘Server’ kann zur Authentifizierung von lokalen Clients (wie Cursor, Agenten oder AI Chat Interfaces) verwendet werden. Der wird komfortabel aus dem Tool heraus als separater Prozess gestartet.

Für die MCP Integration gilt allerdings (die erwähnten Abstriche):

Wenn ein Client-Tool (wie etwa Cursor oder Claude) mit einem Modell interagiert, dass nicht lokal bereitgestellt wird (z.B. Claude Sonnet 4 oder GPT-4 etc.), dann werden Daten natürlich auch über die Grenzen des lokalen Rechners hinweg ausgetauscht. Aber erst durch den Client, nicht durch Monkey Ideas selbst. Somit hängt die Möglichkeit alle Daten lokal zu belassen stark von der Wahl der Mittel bei der MCP-Integration ab. Die Integration geschieht übrigens mit einem Auth Token für die Client-Authentifizierung und im Tool können Freigaben definiert werden, so dass ein clientseitiger Agent nicht unlimitierten Zugriff hat.

Der aktuelle (MVP) Workflow

Das Herzstück von Monkey Ideas ist die schlanke Transformation von vagen Ideen in vollständige(re) Produktkonzepte.

Ideen

… können manuell erfasst werden. Anhand weniger Hinweise können Ideen auch über die lokale KI generiert werden. Ideen können stets weiter bearbeitet werden, man kann sich KI-Feedback einholen (z.B. für die Business Seite oder Legal Aspekte einer neuen SaaS Idee) und man kann die ‘Stage’ / den Status einer Idee ändern, um den Mini-Innovation-Funnel zu steuern. Es gibt die Phasen: neu, review, selected, mvp und trash … sehr schlank also. Diese Phasen können einsetzt werden, um z.B. die Sichtbarkeit einer Idee für einen Code-Agent zu steuern. Man könnte einstellen, dass nur Ideen in der MVP stage für einen Code-Agenten sichtbar sind. Also z.B. alles, was in einen MVP überführt werden soll.

Backlogs

Backlogs sind die Ergebnisse der Ideenverfeinerung. Sie können manuell erfasst werden, aber auch über die lokale KI passend zu der initialen Idee generiert werden. Backlogs können stetig editiert werden, man kann sich zudem KI-Feedback einholen (z.B. aus UX Sicht oder aus Stakeholder Sicht). Die Backlogs bestehen (in Anlehnung an klassische Zeiten) aus Sprints und Items. Items können in einem allgemeinen ProductBacklog liegen, was gleichbedeutend ist mit: keinem Sprint zugeordnet bzw. nur als Kandidat platziert. Sprints, welche als inkrementelle Schritte für die Umsetzung genutzt werden können, haben optionale Meta-Daten wie z.B. Sprintziele. Items können (je nach Tradition) wie Kanban- oder Scrum-Items beschrieben werden, sind aber kurz gefasst, um die Struktur zu vereinheitlichen. Aktuell habe ich noch bewußt darauf verzichtet, User Stories oder bestimmte Ticket-Arten zu unterscheiden. Denn ich bin noch nicht sicher, ob man das eigentlich benötigt.

Die KI kann man also hier einsetzen, um das Backlog zu optimieren, komplett neue Sprints und Items generieren, bestimmte Aspekte zu verfeinern, wie etwa Akzeptanzkriterien, Value & Impact, User Experience, etc.

MCP-Integration

Das MCP-Konzept macht es nun möglich, dass Tools wie Cursor oder Claude direkt mit den Ideen oder ganzen Backlogs interagieren können. Der Agent bzw. das Modell können Items verstehen oder die zugrundeliegende Idee verarbeiten. Backlogs können z.B. durchsucht werden oder ein fertig gestelltes Backlog-Item kann autonom von dem KI-Agent als ‘Done’ markiert werden. Diese Information würde dann direkt im entsprechenden Monkey Ideas Backlog aktualisiert werden. Ich sehe also, welche Schritte abgeschlossen worden sind. Meine lokale Dev-Crowd (Agents) setzt also Ideen um, die ich ihnen nun viel komfortabler vorbereiten und mitteilen kann. Mir gefällt dies besser, als rein auf Chat zu setzen oder alles immer wieder in einem Code-Repository neu zu beginnen. Vorteile sind auch, dass 2-3 Tools und Agents etwa gegen das selbe Monkey Ideas Projekt arbeiten können, aber jeweils in verschiedenen Repositories bzw. DEV-Teilprojekten unterwegs sind. Dies sei gesagt, um Möglichkeiten im praktischen Einsatz zu verdeutlichen.

Damit aber auch andere Prozesse weiterhin möglich sind, gibt es ein paar Export-Funktionen in Monkey Ideas. Diese erzeugen z.B. ein Developer-Briefing-Dokument oder eine Management Summary im Markdown-Format. Direkt also maschinenlesbar. Ein solches Format ist dann auch völlig asynchron zu verwenden (ohne MCP) und bleibt optimal durch LLMs verarbeitbar.

Nützliche Addons

Ein paar weitere Funktionen habe ich für die erste Version vorgesehen, um bestimmte Abläufe zu vereinfachen:

1. Prompts können verwaltet, erstellt (manuell oder KI-generiert) werden und stehen auch MCP-seitig zur Verfügung. Z.B. als Blaupause für die Projektdokumentation, die ersten Schritte im Repository, das Analysieren der Backlogs usw. Es gibt einen MCP-Befehl, über den ein Prompt gewählt und direkt ausgeführt werden kann. Damit kann ich meine individuellen Best-Practices aus einer IDE herausziehen und übergreifend anwenden.
2. Generell echt gut: KI-Feedback zu Ideen und Backlogs. Hier fallen oft Schwachstellen auf, die man dann ausbessern kann. Das Feature ist als Quick-Win entstanden und war eigentlich nicht auf dem Radar. Mir gefällt es.
3. Nötig natürlich: Konfiguration des lokalen MCP-Servers inkl. Token-Generierung.
4. Nötig für lokale KI: Konfiguration des lokalen Ollama-Servers und des Modells (inkl. Parametern wie Temperatur, MaxToken …) - hier können auch andere IPs im Netzwerk angegeben werden und nicht nur ’localhost’.
5. Einfache Verwaltung von Tags, um etwas Ordnung durch Klassifikation zu schaffen. Etwa, um Ideen zu sortieren.
6. Ein Dashboard zur schnellen Übersicht der letzten Ereignisse, dem Zustand des Ideation-Funnels oder der am häufigsten verwendeten Prompts. Hier soll man sich schnell einen Überblick verschaffen können.

MCP näher betrachtet

Grundlegende Informationen zum Model Context Protocol:

https://modelcontextprotocol.io/docs/getting-started/intro

🤖 MCP Server mit KI-Tools für die Ideenarbeit

Monkey Ideas verfügt über einen lokal start- / stoppbaren MCP Server mit diversen Tools, die Agenten benutzen können:

🔍 Such- und Listen-Tools:

• search_ideas - Durchsuche Ideen mit Filtern und Status
• search_prompts - Finde Prompts nach Kategorie, Inhalt oder Tags
• list_ideas - Durchstöbere alle Ideen mit optionaler Status-Filterung
• list_backlogs - Zeige alle Backlogs mit Suchfunktionalität

etc.

⚡ Ausführungs-Tools:

• execute_prompt - Führe Prompt X mit Kontext und Variablen aus
• get_idea_details - Hole detaillierte Informationen zu einer spezifischen Idee
• get_prompt_details - Hole vollständige Informationen zu einem spezifischen Prompt
• get_backlog - Hole detaillierte Backlog-Informationen mit Items und Sprints
• update_backlog_item_status - Aktualisiere Backlog-Item-Status via MCP

etc.

🚀 Beispiel-Einsatz: Nahtlose Cursor-Integration

Ein-Klick-Setup für Cursor:

1. Man geht in Monkey Ideas auf das MCP-Dashboard unter /mcp
2. Klickt auf “Start Server”
3. Lädt die MCP-Konfiguration herunter
4. Fügt sie Cursor hinzu
5. Startet Cursor neu - kontrolliert ggfs. die Einstellungen -fertig!

Der Code Agent sollte nun Zugriff auf die Monkey Ideas MCP Kommandos haben und bestenfalls wissen, wofür diese da sind. Im Chat kann nun einfach ein MCP-Befehl eingegeben werden, der dann ausgeführt wird. Der Agent kann diese aber auch selbst ausführen, wenn er die Kommandos kennt.

Mit list_ideas würde der Cursor agent etwa alle Ideen samt relevanter Infos (z.B. Ideen-Rating) abrufen können, wenn diese in einer der freigegebenen Phasen (z.B. MVP Stage) liegen. Durch die Freigabe kanalisiere ich z.B. die Umsetzung und lenke den Fokus im Kontext des LLM. So wird der Kontext nur mit dem befüllt, was aktuell relevant ist.

Ist der MCP-Ansatz sicher?

Ja, das ist sicher. Solange man weiß, was man macht.

Wenn der Server aus Monkey Ideas gestartet wird, sind Kommandos/Tools von Clients nutzbar, die über einen Token authentifiziert worden sind. Sichtbarkeiten können über die Phasen von Ideen (Stages im Funnel) gesteuert werden und sollten dann auch entsprechend genutzt werden. Das Tool bevormundet aber nicht. Wenn man also alle Phasen freigibt, können alle Informationen aus allen Phasen verwendet werden.

ABER: Wenn man Daten lokal über MCP abruft und dann in Anwendungen wie Cursor verwendet, haben diese wiederum Interaktionen mit externen Servern. So verlassen Daten in dieser oder jener Form sehr vermutlich den Rechner. Dessen muss man sich immer bewusst sein. Das Denken und den Prozess mit anderen Tools kann Monkey Ideas somit selbsredend nicht kontrollieren. Man kann aber selbst sicherstellen, dass Daten nur ‘im Tool’ und auf dem lokalen Rechner verbleiben.

🔒 Local-First Security

Mir war aber eine local first Strategie wichtig.

Datenschutz durch lokale Verarbeitung bedeutet hier:

• SQLite lokale Datenbank - Keine Cloud-Abhängigkeiten
• Monkey Ideas App - läuft lokal und ‘offline’ (kann aber grundsätzlich auch produktiv gehostet werden und verfügt über User-Verwaltung + Authentifizierung)
• Datensouveränität / Zero Cloud Dependencies alles auf dem lokalen Rechner, keine SaaS-Abhängigkeit etc.
• MCP-Authentifizierung - tokenbasierte Client-Authentifizierung für lokale Verbindungen, Zugriff konfigurierbar
• Ollama Support - Flexible Modell-Konfiguration (lokal via localhost oder im Netzwerk), so dass lokale KI-Feature möglich werden

Einschränkungen

Limits lokaler LLM-Modelle

Herausforderung: Lokale LLMs haben z.B. begrenzte Kontext-Längen, sind an die Hardware gekoppelt und können komplexe Aufgaben nicht immer optimal lösen. Trotz der neuen GPT-OSS-Modelle sind die Modelle nicht so universell einsetzbar und potent wie die Monster-Modelle, die man via API nutzen kann. Man muss die damit verbundenen Limits kennen und smarte Workflows entwickeln. In dem vorliegenden Tool habe ich allerdings keinerlei Probleme mit Limitierungen in diesem Anwendungsbereich festgestellt, selbst nicht mit kleinen Modellen wie Llama 3.2:3b Allerdings habe ich auch keine multimodalen Modelle eingesetzt.

Lösungsansätze: Iterative Aufgabenverteilung, optimierte Kontextverwaltung, Ausnuntzung meherer Ressourcen im Netzwerk usw.

Qualitätssicherung

Herausforderung: KI-generierte Inhalte müssen nicht immer sinnvoll oder korrekt sein. (Disclaimer: Das gilt aber übrigens auch für menschliche Inhalte)

Lösung: Review von KI-generierten Inhalten und DYOR gilt auch hier. KI sollte nicht das Denken ersetzen, sondern neue Optionen anbieten und bei stupiden Aufgaben unterstützen. Dennoch können im konkreten Monkey Ideas -Ansatz ‘Stages’ und phasenbezogene Abläufe auch bei der Qualitätssicherung und Aussondierung von z.B. konzeptuellen Schwachstellen helfen. Realisierte Softwarelösungen sollen funktionieren und hierfür gibt es harte Kriterien. Bei Ideenarbeit empfinde ich Freiheitsgrade und kreativen Raum allerdings sogar als nötig und vorteilhaft, insbesondere dann, wenn Ideenumsetzung immer weiter automatisierbar wird. So können irgendwann die besten Lösungen aus n Lösungen gewählt werden. Aus diesem Grunde will ich KI-Halluzinationen oder generativen Unfug auch nicht zu stark einschränken, wenn wir uns im Reich der Ideen aufhalten. Denn manchmal kommt so auch ein nützlicher, ungeahnter Entwurf oder eine neue Perspektive zustande.

Team-Integration

Herausforderung: Local ‘First’ führt aktuell naturgemäße Limits ein: Z.B. dass ich lokal ohne Cloud-Abhängigkeit nicht viele Menschen zu Feedback einladen könnte. Damit das funktioniert, müsste ich das Paradigma ändern und doch immer mehr 3rd Party Abhängigkeiten einziehen. Der Fokus liegt aber zunächst auf der lokalen Infrastruktur und der Datensicherheit / -Souveränität. Eine Monkey Ideas SaaS Variante könnte hier viel weiter gehen.

Lösungsoptionen / Workaraounds: Exporte können leicht weitergereicht werden, um Feedback zu erhalten.

Ausblick und Weiterentwicklung

Geplante Features

• Git-Integration: Direkte Repository-Erstellung und History aus Backlogs
• Visuelle Elemente: Support von Assets wie Wireframes und Mockups (bedingt allerdings auch lokale Modelle mit visuellen Fähigkeiten)
• Team-Kollaboration: Multi-User-Features für Produktteams (wie oben bereits erörtert) als optionale oder dezentrale Komponenten
• 10-20 Kandidaten aus der Shortlist: Aktuell sind ca. 20 Featurekandidaten in der Shortlist. Da wird jedoch hier noch nicht gespoilert. Sagen kann ich nur, dass auch KI gute Weiterentwicklungsideen für die Shortlist beigesteuert hat ;)

Was ist mit bestimmten Tool-Integrationen?

• Jira-Integration: Nein - zu klassisch / auch wenn mir die Verbreitung bewusst ist
• Slack-Integration: Vielleicht (als optionaler Client), vielleicht aber auch Discord
• Figma-Integration: Vielleicht
• OpenAI-Integration: Nein - local LLMs sind hier zunächst ausreichend

usw.

Der Fokus liegt insgesamt aber aktuell auf der Kernfunktionalität und nicht den Randbereichen oder den Satelliten. In der KI’fizierten Ideen- und Produktentwicklung muss mancher Prozess (meiner bescheidenen Meinung nach) vollständig neu gedacht werden. Mit Monkey Ideas will ich gut funktionierende Kernprozesse beleuchten und weiter optimieren.

Fazit

Monkey Ideas demonstriert, wie lokale KI im Produktentwicklungsprozess eingesetzt werden kann. Arbeit mit Ideen muss nicht zügellos über 1-2 große AI-Anbieter erfolgen, vieles kann sehr sehr gut in lokalen Infrastrukturen realisiert werden.

KI als Bauteil ermöglicht ganz andere Sichtweisen auf die bestehenden Prozesse und Feature. Es macht wenig Sinn, neue Tools so zu denken wie vor 20 Jahren. Dieses neue Terrain muss dringend genau untersucht werden, um das Wesen neuer Werkzeuge verstehen und gut einsetzen zu lernen. Für mich persönlich war die Entwicklung von Monkey Ideas ziemlich lehrreich und spannend.

Einige Erkenntnisse:

• KI als Produktpartner: Sprachmodelle verändern die Produktarbeit definitiv und man kann sie nützlich einsetzen
• MCP-Integration: spezialisierte Tools für nahtlose KI-Integration bieten lokal erhebliches Potenzial
• Ideenverwaltung verändert sich: KI verändert Prozesse und den Weg von der Idee zur Lösungsumsetzung (denn die Metriken ändern sich)
• Local-First & Security: Vollständige Datensouveränität ohne Cloud-Abhängigkeiten trotz mächtiger Feature ist ziemlich cool
• Verrücktes passiert: Wenn ich neue Ideen zu Monkey Ideas in Monkey Ideas bei der Implementierung via MCP an Monkey Ideas pflege, dann wird’s weird!

Ich liebe dieses Projekt auf jeden Fall und werde sicher noch häufiger Updates zu oder Outputs von Monkey Ideas veröffentlichen.

Verfügbarkeit von Monkey Ideas

Monkey Ideas dient aktuell meiner eigenen ‘Roadmap’.

Bei Interesse am Thema (wie man sowas realisiert, ob ich bei Beratung oder Entwicklung von vergleichbaren Lösungen helfen kann, wann und wie es vielleicht doch verfügbar wäre) stehe ich für einen Austausch gerne zur Verfügung.