The end of the honeymoon
If Article 1 was about the magic, this one is about the hangover.
After those first amazing days, I started noticing something strange. I'd ask the AI to add a simple feature, and suddenly something else that had been working perfectly stopped working. I'd fix that, and then something else would break.
At first, I thought it was me. Maybe I'd asked the wrong thing. Maybe I'd given too little context. But eventually, curiosity won, and I decided to look under the hood. Until that point, I hadn't even opened the code. Why would I? Everything was working.
When I finally opened the main file, I froze. 5,000 lines of code. In one single file.
Welcome to spaghetti town
It was like finding a monster in the closet.
- Everything was in one place.
- Functions, views, event listeners, random variables.
- Whole chunks of HTML jammed directly inside JavaScript strings.
- A single onclick on the entire app, trying to figure out which button you pressed.
I went from feeling like a magician to feeling like the parent of the messiest child on Earth.
The good parts (to be fair)
I don't want to sound ungrateful. AI did a lot of things right.
- Setting up the Electron and React boilerplate? Lightning fast.
- Integrating with Google OAuth? Minutes, not days.
- Adding small features like tasks, actions, categories, or the people module? Immediate results.
- Debugging simple errors? Copy the error, paste it into the prompt, done.
When AI had a clear, small, contained job, it was brilliant. It felt like having a super-fast teammate who never gets tired.
The bad parts (and the frustrating ones)
But when the job wasn't crystal clear, AI fell apart.
- Inconsistent solutions: One day it created a neat dynamic module loader, the next day it forgot about it and hardcoded everything again.
- Lazy fixes: Every async problem was solved with setTimeout, like putting duct tape on a leaking pipe.
- Weird hacks: Whole views created with innerHTML. Event listeners on the entire app. Things that looked clever for five seconds but caused bugs for five weeks.
- Breaking the past: I'd ask for a small change and suddenly features I loved stopped working.
The speed that felt magical at the start now felt dangerous. I was building on quicksand.
My role had to change
At the beginning, I was the CEO and CPO. I gave directions, and AI built the features. Simple.
But once the app started collapsing under its own weight, I had to change hats. I became the Tech Lead, the one who reviews code, enforces rules, and says "no" when the junior developer wants to add another setTimeout.
I spent weeks splitting the giant file into smaller ones, moving functions around, creating folders, and trying to impose some kind of order. It wasn't pretty. Honestly, the architecture I ended up with was something I'd never approve at my company. But it was enough. Enough to stop the bleeding. Enough to regain control.
The frustrations
I won't lie. This part was rough.
- I'd fix one bug, and two others would appear.
- I'd spend hours cleaning up code that looked fine at first glance but was hiding nasty surprises.
- I'd try to enforce rules, but the AI would sometimes ignore them and go back to its bad habits.
The worst part? The feeling of losing that addictive speed I had in the first week. It was like flying at full speed and then suddenly hitting a wall. I missed the magic.
But I also realized something important: if I didn't step in, the project would die under its own chaos.
The new workflow
I adjusted my strategy. Instead of asking AI to "just add this feature", I started writing prompts like I was talking to a junior developer:
- Be specific. "Only touch these two files."
- Give rules. "Don't use setTimeout. Use proper async/await."
- Demand explanations. "Show me what changed and why."
- Review everything. No more blind trust.
It slowed me down at first, but it gave me confidence again. And slowly, the speed came back, this time with guardrails.
Lessons from the mess
- AI is fast, but messy. You can't just let it run wild.
- You have to lead. If you don't review, refactor, and set rules, the codebase will collapse.
- Frustration is part of the process. Accept it, or you'll burn out.
- Clear prompts = clear code. The more context you give, the better the results.
Closing
Working with AI felt like hiring the fastest junior developer in the world, someone who can build a feature in minutes, but who also rearranges your kitchen drawers and breaks your coffee machine while doing it.
It wasn't the smooth ride I imagined, but it was still worth it. The key was learning how to manage the chaos, to accept my role as Tech Lead, and to build enough structure to keep moving without losing everything. Despite all the challenges, Sortit.Now became a real, working product that I'm proud to have built.
In Part 3, I'll show how I tackled the architecture problem head-on and built something scalable enough to grow. Because if there's one thing I learned, it's this: speed is amazing, but without structure, speed alone will eventually kill you.