Ich bin kein Vollzeit-Entwickler, ehrlich gesagt war ich das auch nie. Seit Jahren bin ich als technischer Product Owner unterwegs und habe ein gewisses Verständnis für unsere Setups, aber Programmieren ist definitiv nicht mein Tagesgeschäft. Genau deshalb wollte ich herausfinden, wie weit man mit einem Tool wie Cursor kommt, wenn man einfach mal selbst ein kleines internes Tool baut – ohne den Anspruch, ein „richtiger“ Entwickler zu sein.
Mein erster Reflex: „Wenn schon, denn schon.“ Früher (so um 2010) habe ich lokal mit MAMP gearbeitet; heute weiß ich: wir fahren Docker/Podman, Services sauber getrennt, alles Container. Also habe ich mich an unseren Projekten orientiert und Cursor eine „erwachsene“ Kombi vorgeschlagen: Postgres als DB, Next.js für den API-/Backend-Layer, React fürs Frontend.
Cursor hat das auch prompt auf die Straße gesetzt – nur leider ist die Straße dabei ständig weggebrochen. Mal startete ein Container nicht, mal war das Routing im Eimer, mal blockierte irgendein Nebencontainer den Rest. Und während unsere Dev-Maschinen mit 64 GB RAM darüber müde lächeln, lief meine brave Management-Büchse heiß: fünf parallele Container, um … eine Startseite zu rendern. Ernsthaft?
Erstes Learning: „Architektur abspecken“ per Prompt klingt gut, funktioniert aber selten. Cursor behauptet, er könne das; wenn ein Projekt aber einmal in die falsche Richtung losgerannt ist, ist wegwerfen und neu starten fast immer schneller und sauberer. Meine Budget-App habe ich fünfmal komplett blank neu aufgesetzt. Das Wissen bleibt ja im Kopf – der Code darf weg. Die Idee war, eine App zu entwickeln, die automatisch einen Überblick über alle Budgets im Unternehmen liefert, indem sie Daten aus unserer Zeiterfassung und den verschiedenen Angeboten nutzt. So kann ich auf alle relevanten Informationen zugreifen, ohne die einzelnen Projekte manuell durchsuchen zu müssen.
Nach dem Big-Bang-Fehlschlag kam die nächste (falsche) Idee: „Ist doch KI – wenn ich ihr noch mehr Kontext gebe, wählt sie schon eine kluge Architektur.“ Tat sie auch. Formal korrekt. Praktisch unbrauchbar. Cursor baute engagiert los, fügte Schicht um Schicht hinzu, und nach zwei Stunden war das Einfangen aufwendiger als neu anfangen.
Also habe ich die Richtung gedreht: Schritt für Schritt statt Masterplan. Meine erste wirklich funktionierende Cursor-App war deshalb nicht die Budget-App, sondern ein kleines Monitoring-Dashboard fürs Team.
Klar, unsere Teams brauchen so einen Monitor eigentlich nicht. Wir sind schon vor Jahren auf sinnvolle Alarmierungsstrategien umgestiegen – gerade beim mobilen Arbeiten ist ein Bildschirm im Büro, der rot blinkt, nicht das praktikabelste Mittel. Aber zum Einstieg ins Cursor-Prompting braucht man einen Use Case, der überschaubar ist und trotzdem Nutzen bringt. Und ehrlich: Es hat was Beruhigendes, durchs Teamzimmer zu gehen und grüne Statusanzeigen zu sehen – auch wenn ich weiß, dass bei Fehlern sowieso alle anders benachrichtigt werden.
Der Prompt war radikal simpel: „Nimm diese API und zeig mir das Ergebnis auf einem Dashboard an.“ Kein Architekturessay, keine Datenbankdiskussion. Und plötzlich lief es: Node.js im Backend, React im Frontend, Datenspeicherung erstmal ganz pragmatisch in JSON, weil ich noch keine persistente Ablage brauchte. Nicht hübsch, nicht final – aber das erste echte Erfolgserlebnis.
Nachdem das Dashboard stand und die ersten grünen Anzeigen liefen, kam natürlich die Frage: „Okay, was mache ich jetzt damit?“ Der nächste Schritt war der Zugriff auf echte Systeme – bei mir GitLab und Uptime Kuma – also brauchte ich API-Keys.
Und da wird es für jemanden wie mich, der kein erfahrener Entwickler ist, plötzlich spannend: Zugriffe und Berechtigungen sind kein Nebenthema. Klar, als Geschäftsführer habe ich relativ umfassende Accounts, aber ich bin nicht geübt darin, sensible Daten über APIs oder Datenbanken zu handhaben. Genau hier hilft Austausch mit erfahrenen Entwickler:innen enorm – damit man nicht aus Versehen zu großzügige Zugänge vergibt oder etwas baut, das man später bereut.
Mein persönlicher Guardrail: nur lesende Schnittstellen. Ich habe Cursor ausdrücklich immer wieder gesagt, er solle keine schreibenden Endpunkte generieren. Noch besser: API-Keys, die serverseitig nur Lesezugriff haben. So kann ich gar nicht erst versehentlich Live-Daten verändern.
Lokal lief die App, und ja, ich war stolz wie Bolle. Aber klar: Nur auf meinem Rechner bringt das niemandem etwas. Also musste das Ding „ins Teamzimmer“, sprich: auf einen Server.
Hier hat KI dann wirklich daneben gelegen. Ich habe versucht, das Projekt mit Cursor direkt auf einen unserer proServer zu bringen. Was dann passierte, war, freundlich gesagt, spooky: Cursor bediente sich ziemlich ungefragt meiner SSH-Keys, las in der Server-Doku nach und schien sogar zu erkennen, welcher Pro-Server sudo hat und welcher User nur normaler Anwender ist – und hat dann mit den „richtigen“ Usern angefangen, auf dem Server rumzuschrauben. Zum Glück war das ein leerer Server, den ich nur für diesen Zweck genommen habe.
Das Ergebnis? Irgendwie war die App da, irgendwie lief auch etwas – aber im Browser kam nichts Gescheites an. Richtig stabil wurde es nicht.
Am Ende bin ich zu unseren DevOps-Kollegen gegangen. Die haben das sauber hinter einen Reverse Proxy gestellt, auf Sicherheit geachtet und generell mal geschaut, was die App eigentlich treibt. Fazit: Produktiv-Deployment nur mit Cursor war ein Schuss in den Ofen – das mache ich so nicht wieder. Gerade beim Ausrollen gilt: Sicherheit > Geschwindigkeit.
Genau an der Stelle wurde uns klar: Wenn Menschen, die nicht täglich entwickeln, mit solchen Tools arbeiten, brauchen wir klare, management-kompatible Leitplanken zusätzlich zu den bestehenden Engineering-Standards. Also haben mein Geschäftsführungskollege – der wirklich ein sehr guter Entwickler ist – und ich uns hingesetzt und intensiv ausdiskutiert, was muss sein, was kann sein, wie gehen wir damit um. Das ist dann Stoff für einen separaten Blogpost.
👉 Wenn du herausfinden möchtest, wie du in deinem Unternehmen Räume für solche Experimente schaffst – mit klaren Services im Hintergrund und sicheren Leitplanken – dann sprich uns gerne an.
👉 Und wenn du Lust hast, dich direkt mit mir über Cursor, AI-Coding und den praktischen Nutzen für Projektmanager:innen auszutauschen, melde dich ebenfalls gern – ich teile meine Erfahrungen und freue mich auf den Austausch.
