Cursor am Limit: Entwickler setzt Arbeit mit Grok fort
Als das Nutzungslimit von Cursor erreicht war, übernahm der Autor die laufende Entwicklungsaufgabe einfach mit Grok Bot, das zuvor nur für Recherchen genutzt wurde.
Vor ein paar Tagen stieß ich auf ein vertrautes Problem: Ich hatte mehr Entwicklungsaufgaben zu erledigen, aber mein Nutzungslimit bei Cursor war erreicht.
Normalerweise hätte das bedeutet, eine Pause einzulegen oder auf das Zurücksetzen des Limits zu warten.
Dieses Mal entschied ich mich, etwas anderes auszuprobieren.
Ich hatte Grok Bot zur Verfügung. Ich hatte es bisher vor allem für Recherchen, Code Reviews und technische Audits genutzt, wusste aber, dass es auch mit Code arbeiten kann.
Grok verband sich mit meiner lokalen Entwicklungsumgebung, arbeitete direkt mit dem Git Repository, führte die erforderlichen Checks aus und committete und pushte die Änderungen.
Es steuerte dabei weder Cursor an noch leitete es Aufgaben an einen anderen Coding Agent weiter. Es erledigte die Arbeit selbst.
Ich hatte bereits zuvor mit Grok als Coding Agent experimentiert.
Seine technische Arbeit war gut, aber es neigte dazu, Abkürzungen zu nehmen. Manchmal traf es Entscheidungen, die ich nicht freigegeben hatte, oder übersprang Teile meines Entwicklungsworkflows, um schneller zum Ergebnis zu kommen.
Der Code mochte in Ordnung sein, aber der Prozess war es nicht.
Genau daran arbeite ich mit MAGDC (MAG Development Center), einem System, das ich entwickle, um KI-gestützte Softwareentwicklung zu verwalten.
Vor diesem Experiment hatte ich die MAGDC Skills aktualisiert, die Grok verwendet. Diese Skills helfen dem Agent, die aktuellen Projektregeln zu finden, seine Aufgaben-Grenzen zu verstehen und zu wissen, wann er anhalten und eine Entscheidung einholen muss.
Grok blieb innerhalb des zugewiesenen Umfangs, befolgte die erforderlichen Checks und stoppte, wenn eine Aufgabe meine Freigabe benötigte, statt eine eigene Lösung zu improvisieren.
Auf diese Weise schloss es mehrere Entwicklungsaufgaben ab.
Natürlich beweisen ein paar erfolgreiche Durchläufe nicht, dass dieser Ansatz immer funktioniert. Ich muss ihn noch mit unterschiedlichen Aufgabentypen testen.
Die größte Überraschung war nicht, dass Grok Code schreiben konnte.
Vielmehr, dass ich KI-Coding-Tools wechseln konnte, ohne meinen gesamten Entwicklungsprozess um einen anderen Assistant herum neu aufbauen zu müssen.
Die Projektanforderungen, Entscheidungen und Regeln blieben im Repository erhalten. Die nächste Aufgabe war bereits definiert.
Cursor bleibt weiterhin mein Hauptentwicklungswerkzeug, und ich habe nicht vor, es zu ersetzen. Aber diese Erfahrung hat mich anders darüber nachdenken lassen, wie ich AI Agents nutze.
Vielleicht sollte das Ziel nicht sein, einen perfekten AI Coding Assistant zu finden.
Vielleicht geht es darum, einen Workflow aufzubauen, in dem verschiedene Agents am selben Projekt arbeiten können, ohne die wichtigen Entscheidungen und Regeln zu verlieren.
Mich interessiert: Hast du jemals mitten in einem Projekt den AI Coding Agent gewechselt? Ist der neue Agent deinem bestehenden Workflow gefolgt, oder musstest du wieder alles von Grund auf erklären?
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
A few days ago, I ran into a familiar problem: I had more development work to do, but I'd reached my Cursor usage limit.
Normally, that would mean taking a break or waiting for the limit to reset.
This time, I decided to try something different.
I had Grok Bot available. I'd mostly used it for research, code reviews, and technical audits, but I knew it could work with code too.
Grok connected to my local development environment, worked directly with the Git repository, ran the required checks, and committed and pushed the changes.
It wasn't controlling Cursor or forwarding tasks to another coding agent. It was doing the work itself.
I'd already experimented with Grok as a coding agent before.
Its technical work was good, but it had a habit of taking shortcuts. Sometimes it would make decisions I hadn't approved or skip parts of my development workflow to reach the result faster.
The code might be fine, but the process wasn't.
And that's something I've been trying to solve with MAGDC (MAG Development Center), a system I'm building to manage AI-assisted software development.
Before this experiment, I'd updated the MAGDC skills used by Grok. These skills help the agent find the current project rules, understand its task boundaries, and know when it needs to stop and ask for a decision.
Grok stayed within the assigned scope, followed the required checks, and stopped when a task needed my approval instead of improvising its own solution.
It completed several development tasks this way.
Of course, a few successful runs don't prove that this approach will always work. I still need to test it across different types of tasks.
The biggest surprise wasn't that Grok could write code.
It was that I could switch AI coding tools without having to rebuild my entire development process around a different assistant.
The project requirements, decisions, and rules remained in the repository. The next task was already defined.
Cursor is still my main development tool, and I'm not planning to replace it. But this experience made me think differently about how I use AI agents.
Maybe the goal shouldn't be finding one perfect AI coding assistant.
Maybe it's building a workflow where different agents can work on the same project without losing the decisions and rules that matter.
I'm curious: have you ever switched AI coding agents in the middle of a project? Did the new agent follow your existing workflow, or did you have to start explaining everything again?