I had a working prototype in a few hours. It ran. It looked like something real.
I deleted it anyway.
Not because it was broken — because I couldn't explain what it was doing. And that felt worse than having nothing at all.
The Build and the Discard
The project was an AI API Cost Optimizer — monitor usage across multiple LLMs, route requests by cost, handle fallback logic when a model fails. Solid concept. Portfolio-worthy.
Cursor generated the structure fast.
Then I sat down to actually review it. I could read the code. I couldn't explain it. There's a difference. If someone had asked me why a specific routing decision was made, or what happens when two circuit breakers trigger at once — I would've guessed. And I wouldn't have known if I was right.
I deleted it entirely. Not to fix it slowly and hope comprehension would come. Just: delete, start over. Felt more honest than shipping something I couldn't own.
One Lost Day
Laptop issues. Service center. Hours of waiting.
I knew the day was gone by mid-afternoon and didn't force it. Some days are just the cost of having a life outside of building.
The Rebuild — One Piece at a Time
I started over with Claude. But the tool wasn't really the point.
What changed was how I worked.
The first time: described the full project, let the AI generate most of it in one pass.
The second time: one small piece at a time. Got the basic API connection working and understood it before touching the next part. Then routing logic — built it, read it, asked questions, moved on. Then fallback handling. Each piece had to make sense before I added the next one.
Slower. But the project grew in a way I could actually follow.
By end of day, the MVP was rebuilt and deployed. Same project, same concept — but this time I could explain every decision in it.
That's the difference between a project you built and a project that was built for you.
The Next Project — and a Deployment Reality Check
The next one was a RAG Knowledge Assistant: upload a document, ask questions, get answers grounded in its content. Dev went smoothly.
Deployment did not.
Free-tier hosting limits. Unexpected constraints. Hours debugging infrastructure that had nothing to do with the AI logic. The kind of problems tutorials skip because they assume everything just works.
It shipped. But the real lesson wasn't about RAG pipelines — it was that getting something running locally and getting it running somewhere real are completely different skills. That gap doesn't get talked about enough.
What I'm Actually Changing
AI speed is real and useful. But speed without understanding creates a problem — you end up with things you can't maintain, can't debug, and can't honestly call your own. The impressive-looking project you can't explain in an interview isn't an asset.
I'm not generating whole projects anymore. I build in pieces, stay at the edge of what I understand, and use AI to push that edge forward — not jump past it entirely.
The goal isn't to ship fast. It's to understand what I'm shipping.
Have you ever accepted generated code you didn't fully understand just to keep moving — did you ship it anyway, or did something make you stop? Let's talk in the comments 👇