middle ground

debugging the inner self

February 3, 2025

My Mischievous AI Assistant part 1

by Piotr Filipp

My Mischievous AI Assistant

Do you also have a mischievous AI assistant?

It won’t be a big revelation for the advanced ladies and gentlemen in this space, but coding AI assistants can be very mischievous and often cause more headaches than they solve in the long run - especially if you think you know what you’re doing but you do not.

Imagine this: you work on a project with another dev, have a nice working codebase with perfume code, and you ask your co-dev to implement a new feature. You get back to the codebase after the weekend and half of the logic has been rewritten. The code now smells of tuna, has bugs, and some functionality is suddenly missing. Sound familiar? I had this experience at work with human “ninja” developers (probably I also committed this code crime at some point 🙈) and now I have flashbacks after working with AI assistants! This is my story of several wrong turns to finally steer clear from code-related self-imposed harm and destruction.

Dipping My Toes Back Into Programming

Over the past few weeks - actually, at this point, a couple of months - I started dipping my toes back into coding. Or rather, I took a deep plunge!

From the beginning of this re-entry journey, I had an amazing assistant in the form of AI-assisted IDEs: Cursor and ChatGPT Plus (with model 4o) to answer multiple queries around architectural decisions, library usage, or which frameworks to pick to quickly get something rolling.

Initially, I was super rusty around pretty much every possible corner of coding. But with the new Companion option in Cursor, it could literally build out a PoC of what I had in mind in a matter of minutes! The fact that it could produce a working, browser-ready result after just a few short instructions blew me away.

I’d almost describe my initial phase of working with Cursor as an inverted relationship. I was basically the Copilot, and Cursor was the main developer. Looking back, I have mixed feelings about that approach, but I think it was helpful at the very start - especially when you’re trying out new tech or frameworks and you don’t know how far an AI assistant can take you. Back then, I had no idea, and I remember being flat-out amazed that I could write a few sentences and have a WORKING(!!!) result that transpiled and opened in my browser.

The First Signs of Trouble

Another query here, another query there, changing this layout, that layout, refactoring, extracting, file splitting - voilà! The mess was ready, steaming hot, and served. Compilers and code in general, unlike LLMs, do exactly what you tell them. But an LLM will do what it decides might be the best approximation of your request, or what was most common in the codebases it was trained on.

Very quickly, I noticed that while building prototypes was bread and butter for Cursor, getting past that phase felt like being in some rap battle in the prompt window. I even got frustrated enough to type mean words to Claude inside Cursor - sorry, Claude!

To give a bit more context: I started building an app to solve a digital asset management problem and anchored my solution in Computer Vision. I knew almost nothing about Python except that everything is a module by default, they use something called Django, and that it’s a hot language for machine learning and data science. That’s about it. But with that useless knowledge, I wrote down the problem statement. After solving a few errors in the terminal, I had a working prototype in maybe an hour. It felt overwhelming but also head-spinning. I actually felt invincible with this tool!

That godlike sensation wore off quickly. Whenever I needed to tune something properly, I just couldn’t get it to work. On top of that, Claude (in Cursor) doesn’t exactly do what you ask; it does what it interprets. If I asked it to build a UI, it whipped out PyQt. Suddenly, I felt like I was being left behind by my own code.

Realizing I Needed a Fresh Start

The problem with tuning started being a real pain. I had issues with multithreading - my app kept crashing, no matter how hard I tried. And by “trying,” I mean reading on Stack Overflow to solve the problem and then telling Claude to fix the code. Eventually, I admitted that I couldn’t maintain or grow it. I needed a fresh start.

So, I searched online and chatted with ChatGPT about the best approach. Between Electron and Tauri, the first one rang a bell, so I decided to go with Electron. Once again, I knew zero about Electron, but I typed a prompt like: Take current code and migrate it to Electron with a React frontend and an Express backend. In my head, it sounded logical…

Whoever knows Electron is probably facepalming now. Yes, it’s absolutely not how you build Electron apps. A few more hours of prototyping later, I finally opened some documentation and learned about Electron’s structure, IPC, and how processes communicate. I felt like I was on my way to regain control over my own repository!

To be continued…

You’d think I’d have learned my lesson and now I’m out of the woods, but I already tried this drug called AI-based prototyping, and it’s a nasty habit. In part 2, I’ll share how I took yet one more wrong turn before finally steering clear of the danger. What did I learn? What are the pros and cons for my use cases? Finally: what is my credo for working with AI assistants? Stay tuned ;)

perfectionismsoftware engineeringcuriositypersonal developmenttech industryself-reflectionLLMailearning