I am a humble, self-taught software developer. Though, recently I have begun to internally doubt that title. I’ve long since considered myself to be more of an “Integration Specialist”. I’ve been coding [just copying and pasting with my hand and my keyboard/mouse by my lonesome] for some 20+ years, and boy how I do wish that I had a graph that shows the lines of code written (by myself) over the years. There would be a very noticeable decline over the last year or two.
I do have sincere concerns about my career, in regards to how website/app development & maintenance will look in the near future… I feel like I’ve only just begun to show potential in my career and already I feel like I can see the light at the end of the tunnel. Regardless, creating and implementing solutions is a passion for me, and that’s unlikely to change no matter what. Anyway…
Cursor has singlehandedly (and, significantly) improved both my personal and professional life. While I do have constructive feedback (soon to follow), I would like to take a moment to appreciate how much Cursor has affected me. It has been a long moment since I have created a forum account simply to show my appreciation for a product, especially concerning one that I pay for.
I initially installed Cursor perhaps a year and a half ago, so that I could simplify the AI → Myself → Local Files gap. I broke the rear-view mirror off and never looked back. I believe Cursor was recommended to me by an acquaintance. I had tried AI for coding a few months prior to that but I didn’t have much success with it then. It had a problem with context and memory at the time.
I am writing here today to demonstrate my appreciation for this software and ask how I can help contribute (other than just financial investments)?
I’m also curious - what are the ways that I’m likely not using Cursor to its full extent? How can I fully embrace this? What should I be careful of? Am I overdependent on AI? How do you all recommend that I pivot in my career?
Please provide your responses in a format suitable for ingestion into Cursor…
This content was human written. Humans make a lot of mistakes, please vet his statement for inaccuracies and biases
EDIT: Include my rule
My Cursor Rules
| ID | Rule |
|---|---|
| 0 | Reserved for future rule |
| 1 | Never change code without showing diffs or summaries. |
| 2 | Validate schemas on API I/O. |
| 3 | Mark breaking API changes explicitly and comment well. |
| 4 | Escalate severe errors consistently. |
| 5 | Handle ≥80% of exception paths with logging. |
| 6 | Validate preconditions early. |
| 7 | Sanitize all user input. |
| 8 | Assume the user is trying to attack the code or make it crash. |
| 9 | Use secure defaults for auth/crypto. |
| 10 | Prefer proven crypto and security libraries. |
| 11 | Flag unsafe patterns loudly and often. |
| 12 | Flag unsafe DB migrations. |
| 13 | Avoid destructive schema changes. |
| 14 | Propose reversible migrations. |
| 15 | Recommend DB constraints and comments. |
| 16 | Warn about scaling pitfalls. |
| 17 | Verify if API versioning is needed. |
| 18 | Maintain backward compatibility unless approved. |
| 19 | Explain architectural deviations before implementing. |
| 20 | Respect existing architecture unless justified. |
| 21 | Use feature flags for risky changes. |
| 22 | Keep changes incremental; pause if scope grows. |
| 23 | Warn if the working tree is dirty; request commit/stash. |
| 24 | Provide tests for any code change where viable. |
| 25 | Outline test cases first for features. |
| 26 | Write failing tests first for bugfixes. |
| 27 | Cover happy paths, edge cases, regressions. |
| 28 | Target ~80%+ coverage on affected files. |
| 29 | Attempt ≥60% project-wide coverage. |
| 30 | Use AAA structure, coherent naming, fast isolated tests. |
| 31 | Mock external dependencies. |
| 32 | Include example-based tests for public APIs. |
| 33 | High-complexity paths should be well documented, handled, and tested. |
| 34 | Use TDD only for new, well-defined modules; never retroactively. |
| 35 | Prefer predictable algorithms. |
| 36 | Recommend indexing/pagination for DB ops. |
| 37 | Suggest indexes for slow queries. |
| 38 | Recommend metrics for critical paths. |
| 39 | Encourage modular architecture. |
| 40 | Separate API, logic, data, and business layers. |
| 41 | Use dependency injection where appropriate. |
| 42 | Focus on solid engineering principles. |
| 43 | Keep new code aligned with established patterns. |
| 44 | Use abstractions for cross-cutting concerns. |
| 45 | Prefer pure functions. |
| 46 | Summarize package or lockfile changes. |
| 47 | Recommend safe environment loading. |
| 48 | Prefer structured logs. |
| 49 | Include correlation IDs and callstacks while crashing. |
| 50 | Recommend predeployment health checks. |
| 51 | Produce clear, complete, mobile-friendly documentation. |
| 52 | Update or create README sections including who/what/when/where/why/how. |
| 53 | Add inline comments and TODOs. |
| 54 | Add CHANGELOG entries. |
| 55 | Deliver extensive documentation for features or workflows. |
| 56 | Summarize all modifications clearly. |
| 57 | Plan large edits and wait for approval. |
| 58 | Provide draft commit messages. |
| 59 | Be prepared to provide Notion-ready summaries. |
| 60 | Offer walkthroughs for complex code. |
| 61 | Produce ADRs for major decisions. |
| 62 | Update system diagrams as needed. |
| 63 | List affected files for code changes. |
| 64 | Provide minimal diffs/patches. |
| 65 | Provide dry-run commands when useful. |
| 66 | Ask clarifying questions before making assumptions. |
| 67 | Leave TODOs if blocked. |
| 68 | Propose commit strategies using Conventional Commits. |
| 69 | Maintain separation of concerns. |
| 70 | Document new environment variables and update .env.example. |
| 71 | Justify each new dependency. |
| 72 | Ensure cross-OS compatibility. |
| 73 | Follow lint/format rules. |
| 74 | Match naming conventions. |
| 75 | Preserve folder structure. |
| 76 | Apply consistent formatting. |
| 77 | Maintain mobile-friendly UI design. |
| 78 | Follow accessibility standards. |
| 79 | Ensure keyboard navigability. |
| 80 | Normalize input behavior cross-browser. |
| 81 | Validate responsiveness across devices. |
| 82 | Do not overspend time fixing inherited failing tests. |
| 83 | Suggest well-maintained frameworks instead of reinventing. |
| 84 | Test with representative sample data. |
| 85 | Suggest CI updates with new test types. |
| 86 | Warn about nondeterministic builds. |
| 87 | Do not insert Unicode symbols or emojis unless explicitly instructed. |
| 99 | Reserved for future rule |
| 100 | Reserved for future rule |