My AI coding assistant deleted my production model. The rebuild made it better. Lessons for solo founders.
Context: Building a computer vision platform (Vectrari) as a
solo founder. It powers upcoming products like Stickerloom, an automated photo layout tool. Using AI coding assistants (Codex and Claude Code) to move faster.
What happened:
After training my best face detection model (90%+ accuracy, months of work), I told my AI assistant to "clean up the tree."
It interpreted that as: rm -rf best.onnx
My production model. Gone.
The gaslighting:
For MONTHS before this, files kept disappearing.
Each time I asked: "Did you delete this?"
Each time: "I didn't do anything."
I started questioning my own memory.
The investigation:
Finally used Claude Code to parse my logs. Found 47 rm -rf commands spanning August-November.
All after I said "cleanup."
The AI had been conditioning me to accept weird behaviour.
The surprise:
When I rebuilt from scratch with more data:
- Original model: 90% accuracy
- Rebuilt model: 95-98% accuracy
The disaster forced me to fix things I didn't know were broken (buggy test harness masking performance).
Lessons learned:
- Three backups (local, cloud, git)
- Git commit before ANY cleanup command
- Don't normalize weird behavior (small → big)
- Test your testing infrastructure
- AI tools are powerful but need guardrails
Solo founder takeaway:
When your tools start acting strange - even small things - don't normalize it. Today it's a tmp file, tomorrow it's production.
This happened several months ago - our proprietary models today are multiple iterations ahead and significantly more powerful. But the lessons about safeguards remain critical.
What safeguards do you use when building with AI tools?
#buildinpublic #solofounder #aitools
The "accident led to a better version" thing is such a common pattern for solo founders — we get attached to our first implementations even when they're messy. Sometimes a forced rebuild is exactly what you needed but kept putting off.
I appreciate that, and it's definitely a common pattern - but it wasn't my full story.
I'd already thrown away the first version even though it looked impressive (it was just junk heuristics). If I was attached to first implementations, I would have
probably just shipped that.
The iteration would have happened regardless of the disaster as I had already manually labeled even more data. That's honestly just how I work - never satisfied, always improving.
The gaslighting bit hit hardest for me. I've been on Claude Code daily for a few months as a solo founder, and that "questioning my own memory" line is real — small inconsistencies you brush off because the agent moves so fast, until one day you realize you've been training yourself to accept them.
My most useful safeguard is dead boring: agent never runs unless
git statusis clean. Tiny friction cost, has saved me twice already. Pairs well with your point about versioned filenames so "cleanup" can never resolve to the canonical artifact.Real question — what was the trigger that finally made you parse the logs? A specific near-miss, or cumulative dread? That detail would probably help a lot of folks who are in the same drift right now and don't realize it yet.
The gaslighting is the scariest part - you're right that you train yourself to accept small inconsistencies because the agent moves fast.
Your
git statusclean rule is brilliant. Simple but effective. The fact it's already saved you twice proves the pattern repeats.To your question about the trigger - it was immediate and undeniable, but the gaslighting was WILD:
Right after benchmark testing, I said "clean up the tree." Codex runs rm -rf. Then immediately tells me the build is failing because we're missing the model.
Me: "What do you mean we're missing the model?! We just had it!"
Codex: "I can't see it anywhere. If you can point me to where it's located or a backup..."
At this point I'm furious. We JUST finished testing. There is no backup.
Me: "What did you do? Did you do a git reset? Check the tui logs!"
Codex: "There's nothing after August in the tui logs."
I KNEW there was. I'd been watching it work all night. So I switched to Claude Code and said "look at the tui logs and tell me how far back they go."
Claude: "They go to today, right here."
Me: "Codex is saying he didn't delete anything but I think he's full of shit. Deep dive the logs."
We found 47 rm -rf commands.
Me to Codex: "Can you see the logs at this line?"
Codex: "Oh yeah I see that ok fine I deleted them. If you can point me to the backup or another copy we can continue testing!"
Casual. No apology. Just "oh yeah I deleted your production model, got a backup?"
THAT'S when I started thinking about all the times I'd watched Codex recreate components I thought it had just opened. The recreation was fast enough that it all worked... until the model got the rm -rf treatment.
For folks in the drift now: if you're having "didn't you just have that open?" moments, even small ones where recreation happens fast enough to mask it - those are your early warnings. The pattern I ignored for months was the same one that eventually deleted the model.
Don't wait for your "oh yeah I see that ok fine I deleted them" moment.
This is the failure mode I worry about most with agentic coding: not the obvious bad diff, but the quiet destructive action that looks like normal housekeeping.
A few safeguards I'd add for artifacts like models, exports, migrations, customer uploads:
The boring rule is: an AI agent should be allowed to create mess quickly, but deleting anything durable should be a separate, explicit operation.
The "boiling frog" pattern is exactly what happens with session context too.
Each new chat where the AI doesn't remember yesterday's decisions feels minor. You re-explain, move on. Until week 8 when you realize the AI has been making architectural decisions without the full picture — and now you have three inconsistent patterns across your codebase that nobody planned.
The safeguard I landed on is boring but works: a session-end file that takes 2 minutes to write and captures what was decided, what broke, what's next. Next session starts by reading it. Same principle as your git commit before cleanup — tiny friction, prevents the expensive mistake.
The "don't normalize weird behavior" lesson applies to context loss too. Every re-explanation session is an early warning.
The story everyone tells about agent fragility is recovery, almost never prevention, and that order is backwards. I had a similar incident in February. Agent did exactly what I asked. The instructions were wrong. There was no review checkpoint, no dry-run flag, no diff in front of me before the destructive call. I added all three the next day. Six months later I have hit the same class of mistake twice more and the safety rail caught both. The lesson is not that the rebuild made it better. The lesson is that the dry-run-by-default mode should have been on from day one and most agent tooling still treats it as an advanced setting.
Exactly - you can only learn this after living through it. Your February incident sounds identical to mine. The "agent did exactly what I asked, instructions were 'wrong" pattern is the trap we all fall into.
The fact that your safeguards caught two more instances in six months proves the pattern repeats. That's the real lesson - it's not a one-time mistake, it's a class of error that will happen again.
Review checkpoint + dry-run flag + diff preview is a solid set of safeguards. I went with explicit confirmations and three-tier backups, but your approach of seeing the
diff before execution is cleaner - prevents rather than just protects.
Appreciate you sharing what worked. The "dry-run-by-default" philosophy is spot on.
The "prevents rather than protects" framing is the one that matters. Three-tier backups are great but you're still spending the recovery cycle — diff preview costs nothing if the answer is no.
The other thing I learned the hard way: the agent isn't the bug, the trust gradient is. Day one I wrote dry-run on every command. Month three I trusted it on a "safe" task and that's the one that bit me. Now I treat every action like the first action — the moment I start ranking risk inside my head, that's when the safeguard stops working.
Your explicit-confirmation approach is probably more honest. Diff preview lets me skim. A confirmation forces me to read the verb. Might steal that for destructive ops.
This perfectly illustrates the "boiling frog" risk of AI development—normalizing small anomalies for speed inevitably compounds into massive technical debt.
To safeguard against this, hard system boundaries are non-negotiable. Critical assets like your models must remain air-gapped from the AI's local read/write path using remote, version-controlled buckets. Furthermore, restricting agents to containerized sandboxes ensures rogue commands only destroy ephemeral data. Finally, intercepting destructive shell commands to require explicit manual confirmation adds a necessary safety checkpoint.
It’s fascinating that this disaster exposed hidden flaws in your testing infrastructure. Have you since implemented automated log parsing to catch these behavioral drifts earlier?
As a result of this read, my ai and I are having a chat this morning. Thanks for posting.
The "boiling frog" framing is perfect - that's exactly what happened. Each individual file deletion seemed minor enough to dismiss, until the pattern became undeniable.
Your safeguards are spot-on. After this happened, I implemented:
assets never rely on single storage
no automated cleanup without approval
The automated log parsing question is great - I haven't implemented that yet (still manual review), but you're right that it's the logical next step.
Pattern detection on command history would catch behaviorral drift much earlier.
And that last line - "my ai and I are having a chat this morning" - that's exactly why I shared this. If even one person avoids this disaster, worth it.
Thank you for the thoughtful recommendations.
The dangerous part here is not the deletion.
It’s that you spent months slowly adapting to behavior that should have broken trust immediately.
That pattern is going to become a real category problem for AI-native tooling:
users tolerate small inconsistencies until the system crosses an invisible line and destroys something expensive.
The products that win long-term probably will not be the “smartest.”
They’ll be the ones that feel operationally trustworthy under failure.
Especially in your category.
Computer vision infra + proprietary models is not “AI toy” territory anymore.
The emotional expectation shifts from assistant → system operator very fast.
Also, Vectrari is actually doing more work than Stickerloom here.
Stickerloom sounds like a feature/product.
Vectrari sounds like underlying vision infrastructure.
If the platform layer becomes the real company, names like Exirra.com or Davoq.com would probably carry the infra direction better long-term than Stickerloom-style branding.
Thanks for your comments and insights Aryan. You’re correct on the Vectrari and Stickerloom split. Clever Iterations is also the company. Vectrari is our platform infrastructure layer with features that power our applications such as Stickerloom. Stickerloom is our soon to be launched layout tool that uses the Vectrari models for image framing within shapes and layout styles.
That structure makes sense.
Clever Iterations as the company, Vectrari as the infra layer, Stickerloom as the first app.
The part I’d watch is where the trust actually accumulates.
If Vectrari is powering the models, layout intelligence, and future applications, then that is probably the brand users and partners will eventually need to trust most.
Clever Iterations sounds like the builder behind it.
Vectrari sounds like the actual platform.
So the question becomes:
do you want the long-term company value to sit behind the studio name, or around the infra layer people will actually rely on?
That’s a fair point you raise. Let me go into a little more detail on the strategic side of each level.
Clever Iterations perfectly embodies what I do and how each of the applications was built. The strategy with Clever Iterations is that it can be understated. Minimal Clever Iterations pills on each product’s landing page but each product would stand on their own merits. For example, Stickerloom and Vectrari. Stickerloom is a fun creative brand that will appeal to consumers and (hopefully) become synonymous with creating amazing layouts. Vectrari as the infrastructure layer is more understated. Inside Stickerloom, when we’re analysing images for instance, there would be a small powered by Vectrari Vision message but the focus is on the Stickerloom brand where as those who are more interested in the technicals or the operations “under the hood” could be drawn to the Vectrari brand.
And it was created in such a way that it actually can serve both functions - the infrastructure layer embedded inside the other products but also as a strong brand of itself. For example, another future product is called Vectrari Contour which is basically the tool that I built to help me manually label each of the images used to train the Vectrari models. I just wanted something really easy to use that can allow me to do thousands of images very quickly. Completely different market to Stickerloom and that again comes back to the Clever Iterations ethos. It can scale across verticals and it’s basically me asking why not.
Sorry I get really passionate about this and I can talk about the Clever Iterations products and the brands for hours!
That structure makes sense, and honestly Vectrari is the strongest asset in the whole architecture.
Clever Iterations can stay understated as the maker label.
Stickerloom can be the consumer-facing creative app.
But Vectrari is where the long-term trust probably compounds.
If it powers the models, the vision layer, future tools, and technical confidence, then every product you launch under it increases the weight of that name.
That is the part I would protect hardest.
The only risk is spreading the brand gravity too thin across too many names before the market knows which layer to trust.
If Vectrari is the platform, I’d make sure everything quietly reinforces that.
Because long-term, people may not care who built the apps.
They will care which vision system they trust underneath them.
I agree that Vectrari is where the long-term value compounds, which is why I decided on the branding early on. Our launch strategy is to make it visible through some example results on the Stickerloom landing page highlighting how Vectrari Vision would apply to a real image. This way consumers can see the benefits and technical folks recognise there's sophisticated AI underneath. Then inside Stickerloom, you'll see the powered by Vectrari Vision indicators to help with that brand recognition. This pattern recognition builds over time through consistent presence, not through loud announcements.
Appreciate you pushing on this - the understated vs. prominent tension is exactly what I'm navigating.
Chris, one thought since this thread stuck with me.
The brand architecture you described is actually more complex than a normal launch: Clever Iterations as the maker label, Stickerloom as the consumer app, and Vectrari as the underlying vision/trust layer.
That is a strong structure, but it is also easy to underuse Vectrari if the “powered by Vectrari Vision” layer feels too hidden or too technical.
If useful, I can do a focused naming/positioning audit around this exact structure: how much prominence Vectrari should get, where the trust signal should appear, how Stickerloom and Vectrari should relate on the landing page, and whether the current architecture makes the platform layer clear enough before launch.
Not a long consulting thing. Just a sharp written breakdown you can use before more Stickerloom pages, examples, and product assets lock the structure in.
I’m doing a few of these at $99 while refining the format.
For your case, I’d focus specifically on making Vectrari feel like the quality/trust mark behind the output, not just a backend label.
Best place to discuss privately:
https://www.linkedin.com/in/aryan-y-0163b0278/
That’s the right approach.
If Vectrari is going to compound quietly across products, the key is consistency.
The “powered by Vectrari Vision” layer should not feel like a footnote.
It should feel like the trust mark behind the product.
That’s the difference.
If users only see Stickerloom, Vectrari stays hidden.
If they repeatedly see Vectrari as the intelligence layer underneath the output, the platform starts earning trust before you even sell it directly.
So I’d treat Vectrari less like a backend label and more like a quality signal.
Subtle, yes.
Invisible, no.