Users find AI code generation tools like Cursor unpredictable, especially when trying to add or change features in existing codebases with real constraints and dependencies. They need the tool to better understand and work within these contexts to provide more reliable results.
Why does using AI to help write code sometimes feel like rolling dice? I’ve been thinking about how to make it more predictable. I’ve been thinking about how I use tools like Cursor and why results can vary so much. These are just some ideas, curious if they resonate with others. Like a lot of people, I’m trying to figure out what the next step looks like beyond “ask the LLM to write some code.” At one end, there’s a lot of discussion around spec-driven development and multi-agent systems that can run autonomously for long periods. That work is interesting, and I know some teams are already doing this in practice. For me, the challenge comes when I’m trying to add or change a feature in an existing codebase. The code has real constraints and dependencies, and I want to use Cursor to help without introducing mistakes. If I try to do too much at once, the results can quickly become confusing or unreliable. Breaking the work into smaller, deliberate steps makes the interaction far more predictable and helps me build confidence in what the tool can actually produce. Quick note on Cursor modes Cursor’s modes behave differently. Plan is better for understanding, explanation, and critique. Execute is optimized for producing concrete code changes. Switching between them intentionally has made a bigger difference for me than I expected. A phase-based way of using LLMs Instead of trying to “build the feature” all at once, I break the work into phases and use the LLM differently in each one: 1. Analysis (understand what exists) Goal: shared understanding, not progress Prompts: “Summarize the relevant parts of this code.” “What assumptions does this component make?” Cursor: Plan 2. Design (explore options) Goal: decide how to solve the problem Prompts: “Propose 2–3 approaches and their tradeoffs.” “Which approach minimizes blast radius?” Cursor: Plan 3. Scaffolding (lock in structure) Goal: agree on shape without behavior Prompts: “Define interfaces and file structure only.” Cursor: Plan to Execute 4. Implementation (small steps) Goal: make progress without surprises Prompts: “Implement method X only.” Cursor: Execute 5. Validation / Review (be critical) Goal: surface risks early Prompts: “What edge cases are missing?” “What could break in production?” Cursor: Plan I don’t see this as the end state. It’s just a practical step that’s helped me move beyond basic usage without handing over the whole process. Full disclosure: I used an LLM while thinking this through. Exactly the kind of work I’m describing here. Using the tool to clarify and structure ideas, not to replace judgment. Curious how others are approaching this.