My Mischievous AI Assistant part 2

In my first post, I wrote about my first - and at the same time, big - steps with AI-assisted coding. I didn’t know how dopaminergic a coding session could be when, in a matter of minutes, new features were sprouting from my keyboard and onto my screen. Unfortunately - or rather fortunately - I realized that the grass is not as green as I thought it was, and after taking a few wrong turns, I started heading in the right direction. That didn’t last long, though… It was more difficult to break with this addiction than I thought! In this post, I’ll share one more wrong turn before finally taking the correct course with my AI copilot.

The Struggle Continues

Where did we leave off? Ah yes, the fresh start with Electron.
Unfortunately, my over-reliance on Cursor didn’t stop at having an AI assistant code the solution in a technology I knew close to nothing about. I found a fresh Electron React boilerplate, cloned it, and moved the UI manually. Then, foolishly, I gave the keys right back to Claude and asked it to implement the backend part with IPC this time. Oh, what a sweet mess that was - tons of complicated logic just to handle requests properly. Yet again, I felt like I didn’t truly understand my own codebase, and the parts I understood I simply didn’t like.

You’d think that was my last straw, right? That I’d learn from the mistake and not repeat it? Finally: yes! I did manage to re-implement the entire IPC logic from scratch - writing the first handler, from receiving and sending update calls through handling multiple workers, up to spawning a Python process for the CV task.

And ironically, that’s where I discovered the real power (and an actually healthy use case) of Cursor for me.

My Correct Way of Working with an AI Assistant

After numerous false starts and some codebase heartbreak, I discovered the right approach to using Cursor. It was basically: “Hey, here’s a piece of logic I wrote that already works, here’s an interface for another chunk - implement it.” Then: “Done? Great! Now go use this implementation in this file, hooking it up exactly like we did here and here.”

It’s fast, it’s convenient, and I stay in control of the foundational logic. That, I believe, is the actual healthy use case: laying down the design, the structure, the big pieces of code - then letting the AI fill in the smaller parts.

Embracing Version 1, Then Rewriting for Version 2

Another massive advantage is the sheer speed of iteration. Let’s be honest: version 1 always sucks - no matter if it’s written 100% by my human stupidity or artificial intelligence. It’s usually impossible to come up with “version 2” on the first try. That’s why it’s called version 2! Even Google rewrites its code (maybe more often than we think), because no matter how much talent you have, getting it 100% right the first time is unlikely.

With AI, though, creating a “version 1” is way faster. I had an MVP of my app in just one afternoon. Then, when I realized the limitations, I rewrote the core logic in 1.5 days to avoid all the issues I spotted in the AI-driven approach. If I decide I need to rewrite something, it’s also faster with AI. I just implement the new approach in one place and carefully prompt the AI to adjust other parts of the code.

The Flow I’ve Come To Appreciate

All of this led me to think more deeply about my natural way of working as well: two or three days of intensive R&D and progress, followed by a day of intense refactoring, rewriting, and stabilizing everything. I kind of love it. Seeing visible progress is motivational, but having a neat codebase that doesn’t smell is even better.

Some Nugget-Sized Struggles/Conclusions

1. Composer won’t call you crazy: If I prompt Composer to build an Electron app with an explicit Node.js backend jammed inside, I wish it would protest and say: “You insane? Stop it, get some help!” but it doesn’t. It’ll just do it (or try to).
2. Composer won’t challenge or suggest changes based on recurring problems outside the current codebase context: What do I mean by that? The Testing Nightmare: Trying to introduce proper testing was an endless stumble. I was rusty, so I kept messing up mocking window.electron for unit/integration tests. ChatGPT, Stack Overflow, and certainly not Composer in Cursor could solve it for me based purely on errors. Cursor, in particular, kept insisting on new code changes, swearing it would definitely work “this time.” Many wasted hours later, I remembered: “Oh yeah - OOP gods gave humans the gift of Dependency Injection.” After that, it was trivial. And I wish Cursor had just said, “Hey buddy, you probably can do it this way, but it’s gonna be way easier if you do it the other way; try DI instead!” But it didn’t. Cursor doesn’t reason that way, though it can trick you into feeling like it does.
3. Unintentional code overwrites: Too many times, Cursor’s fix for a snippet would ironically forget or overwrite the rest of my code. Definitely gave me a few panic moments.
4. Changing something else while I asked for a single fix: Like if I wanted a single method replaced, it often decided to refactor random pieces simultaneously and sometimes introduced brand-new bugs.

My Final Thoughts (For Now)

And that’s the gist of it: you can get trapped into thinking these AI assistants are rational, but they’re basically just advanced pattern matchers. Yet, ironically, that’s also their strength. They’ll do the grunt work, spin up the “first version,” and give me more time to think about higher-level decisions.

So yes, my AI assistant is mischievous. But when used properly, it’s also amazing. I guess that’s how partnerships go, right? I just need to remember who’s in charge and that rewriting code from scratch after a chaotic weekend is part of the process.

In the end, I’ll keep using Cursor, keep rewriting my own code, and keep messing up along the way. It’s a journey, but at least now it feels like my journey, not just the AI’s.

Thanks for reading! If any of this sounds familiar or sparks ideas, I’d love to hear about your own experiences wrestling with AI dev tools. Onward and upward!