As a seasoned Ruby on Rails developer, I’ve spent the better part of the last decade immersed in server-side logic, database schema design, and the elegant conventions of the Rails framework. Until recently, I never had a reason to write a Chrome extension. But a side project I’ve been working on — as the fractional CTO — finally called for one. So, I dove in. I opened Cursor AI and started prototyping. The process was both challenging and illuminating, filled with technical hurdles and moments of unexpected acceleration.

Before we dive in, a quick note about the project that inspired this journey: HiEnergy Rocket is a platform I’ve been building to help publishers manage their affiliate programs across multiple networks from a single, unified interface. It aggregates data, simplifies reporting, and streamlines research, acting like the “Google Flights” of affiliate marketing. As part of the platform, we recently launched a Chrome extension to make discovery and outreach easier directly from the browser — you can check it out here.

Here’s a breakdown of what I discovered.

The Power of Cursor AI: High Throughput, Context-Sensitive Coding

First and foremost: Cursor AI is a phenomenal tool. Think of it as having a team of junior developers who are available around the clock. It excels at generating code quickly, offering decent structural suggestions, and filling in boilerplate across familiar frameworks. When used effectively, Cursor can enhance developer productivity significantly.

Cursor is especially competent in environments with strong conventions. Its performance in structured ecosystems like Ruby on Rails is outstanding. It understands Rails’ MVC architecture, naming standards, and file layout. This allows it to write meaningful code that integrates smoothly into your app.

I found myself using Cursor not just for generation but as an assistant for iterative design. I’d scaffold basic logic, ask Cursor to generalize it, and watch as it evolved my stub into something testable and efficient.

Limitations and Learning Curves: The Cost of Enthusiasm

There’s no other way to put it — it felt like doing a speed run of the Dunning-Kruger curve. I went from knowing absolutely nothing about Chrome extensions, to thinking I was a genius after getting my first popup working, to hitting the wall of build errors and silent failures. It was a rapid descent from the peak of Mount Stupid into the valley of despair, and it all happened in record time.

That said, Cursor is far from flawless. Much like an enthusiastic but inexperienced intern, it sometimes tries too hard. It tends to:

Overgenerate CSS and JavaScript code
Duplicate logic across files
Refactor parts of your project you didn’t ask it to touch

This became especially frustrating when working with JavaScript. Unlike Rails or React — where patterns are clearer — vanilla JavaScript left Cursor directionless. Edits to one function would sometimes trigger rewrites of unrelated components.

A critical best practice: narrow the context window. The less Cursor sees, the more focused and accurate its outputs will be. And yes — commit often. Every time you get working code, commit it. This prevents loss when Cursor’s next suggestion unintentionally breaks functionality.

The CSS Experience: From Chaos to Clarity

As someone who strongly prefers CSS frameworks, manually writing CSS is something I usually avoid. Cursor doesn’t share that philosophy. Left unsupervised, it created bloated stylesheets filled with conflicting class definitions, verbose selectors, and liberal use of !important.

However, with well-scoped requests, Cursor actually became quite capable at managing CSS. Asking it to simplify or consolidate stylesheets produced well-organized results. Providing examples and asking for reusable class extraction led to a surprising level of coherence.

The takeaway? Cursor can do good CSS work, but it needs boundaries and explicit directives to avoid overwhelming your project with unnecessary styles.

Why Frameworks Matter: Rails and React as Ideal Environments

Cursor performs best in opinionated frameworks. Rails, for example, gives Cursor a clear path to follow. It knows where models go, how to wire controllers to views, and what file structure to assume. Similarly, React gives Cursor enough architectural scaffolding to prevent it from drifting too far off course.

In contrast, environments with fewer constraints — like vanilla JavaScript — make it harder for Cursor to stay on target. The lack of naming conventions or standard directory structures means it often guesses incorrectly or introduces redundant logic.

In my experience, leaning into structured frameworks is key to getting reliable output from Cursor.

Practical Workflow Advice: Treat Cursor Like a Junior Teammate

Here’s one of the most effective strategies I used: ask Cursor to refactor its own code. When it produces a block of convoluted logic or bloated styles, ask it to simplify or extract reusable components. It will usually clean up its own mess effectively.

Think of Cursor as an enthusiastic intern:

Provide tightly scoped tasks
Set boundaries
Ask for improvements or rewrites, not just generation
Assume its changes might introduce regressions

With the right mindset, you can use Cursor to handle repetitive scaffolding, generate first drafts, or translate logic across components while you focus on higher-level engineering concerns.

Navigating NPM and Build Configuration

As a Rails developer, I’m used to tools like rails new doing a lot of the setup for me. But building a Chrome extension introduced me to a very different landscape. Using npm and configuring the build process felt unnecessarily opaque.

To make the extension work, I had to learn:

The nuances of manifest.json (especially transitioning from v2 to v3)
How Chrome handles service workers
How to structure a React-based popup in a compliant way
How to debug silently failing builds with almost no feedback from the browser

Google’s documentation left a lot to be desired in helping make sense of these pieces.

My Issues with Google’s Documentation

Maybe this is sour grapes, because I have interviewed with Google half a dozen times and they never offered me a job, but their documentation is terrible.

Google’s documentation for Chrome extensions presents a number of challenges for developers. While it covers a lot of ground, the experience of using it can feel disjointed. Core concepts like the transition from manifest v2 to manifest v3 are introduced with limited clarity. Terminology—especially around permissions—is inconsistent and sometimes entirely undocumented. The approval process for publishing an extension is far from transparent.

The UI for managing extensions and project access also leaves much to be desired. Navigating the developer dashboard feels unintuitive and overly complex for even the simplest tasks. In my experience, it was often faster and more effective to ask ChatGPT how to perform an action in the console than it was to find that information in Google’s own resources. That says a lot.

It all contributes to the sense that the documentation was written by engineers in silos — there’s little sign of editorial consistency or a unified developer experience strategy.

In stark contrast, Stripe’s documentation exemplifies how developer resources should be done: concise, logically structured, filled with practical examples, and written with empathy for the developer. Marqeta is another standout — their platform documentation is clear, consistent, and thoroughly thought out. Both demonstrate that excellent documentation isn’t just possible — it’s expected in modern developer tools. — their docs are developer-first, consistent, and clear.

Final Reflections and a Quick Plug

Would I build another Chrome extension? Maybe. Would I use Cursor again to help? Absolutely — but with carefully defined guardrails.

Cursor accelerates learning and development dramatically, especially when paired with frameworks that emphasize convention. If you manage scope and version control wisely, you’ll find yourself shipping faster and learning more than you expected.

And if you’re in affiliate marketing: check out my latest platform, HiEnergy Rocket. It’s built to help publishers manage affiliate programs across multiple networks, offering a centralized view and seamless workflow. Think of it as the “Google Flights” of affiliate marketing.

Thanks to Cursor, I walked away not just with a functional extension, but with a better understanding of the modern frontend ecosystem — and a new tool in my dev toolkit.

Building My First Chrome Extension with Cursor AI