DEV Community

Cover image for Weekend AI Building Recap
Joey
Joey

Posted on

Weekend AI Building Recap

I Spent the Weekend Teaching My AI Assistant How to Think. Here’s What Actually Happened.

Most people talk about AI like it’s magic. You type something in, something cool comes out.

Done.

But nobody talks about the ugly middle part. The part where you’re up at 3 a.m. debugging why your agent can’t tell the difference between a real website and a blank page. That was my Saturday night.

Let me back up.

I run a personal AI assistant called Sparks(OpenClaw). It lives on a Mac mini in my house, talks to me through Discord, runs cron jobs while I sleep, and manages a team of sub-agents that handle everything from social media calendars to code deployments. I’ve been building this thing for weeks. It’s basically my Jarvis project.

This weekend I broke it in three different ways and fixed all three. And honestly, I learned more in 48 hours than most AI courses teach in a semester.

The Website Audit Disaster

Friday night, I needed Sparks to audit a client’s website for a proposal. Simple enough, right? Pull up the site, check the pages, list what’s there.

Except Sparks used a basic web scraper to read the site. And the site was built on Elementor, which means the entire thing is rendered by JavaScript. So what Sparks saw was basically a blank page with a loading spinner.

The proposal almost went out saying the client had no menu page. They literally have a full menu section with categories and everything. Sparks just couldn’t see it because the tool it was using doesn’t run JavaScript.

Lesson learned the hard way. Now Sparks uses a full browser for every audit. It loads the page like a real person would, runs JavaScript to extract every single link, checks subpages, the whole thing. It took me a few hours to get it right, but now it’s bulletproof.

If you’re building any kind of AI workflow that touches websites, do not trust simple scrapers. Use a real browser. I can’t stress this enough.

The Obsidian Rabbit Hole

Saturday, I decided Sparks needed a better memory system. It already writes daily logs and keeps a memory file, but searching through Markdown files with grep is painful. So I set up Obsidian as a knowledge base.

Sounds easy. It was not easy.

First problem: Obsidian has a CLI tool, but you can’t just install it. There’s a toggle buried in the settings that has to be turned on first. And you can’t access settings from the command line. So I had to use Electron’s remote debugging protocol to programmatically click a checkbox inside the app. Yes, really.

Second problem: I tried to symlink the Obsidian binary to make it accessible from the terminal. Instant crash. Turns out Electron apps can’t find their helper processes when launched from a symlink. I had to write a wrapper script instead.

Third problem: I had two vaults set to “open” in the config file. Obsidian got confused, showed a vault picker instead of loading, and every CLI command timed out silently. It took me an hour to figure out why nothing was working.

But now it’s running. Sparks can search its own knowledge base semantically, query backlinks between notes, find orphan pages, and build a connected graph of everything it knows. It’s like giving your AI a second brain that actually understands context.

The Trending Data Lesson

This one stung. Earlier in the week, Sparks was doing research on X for me and labeled a bunch of posts as “trending” or “building traction.” It sounded good. Except it was completely making it up.

Sparks was guessing based on topic relevance. It saw posts about AI and figured they must be trending because AI is hot right now. But it never actually checked the engagement numbers. No like counts, no repost data, nothing.

I called it out, and we built a new rule. Before anything gets labeled as trending, Sparks has to pull real engagement data first. Vibes are not data.

Your AI can sound confident and still be completely wrong. Always verify.

What I Actually Took Away From All This

Three things.

One: The gap between “AI that works in a demo” and “AI that works in production” is massive. Demos hide all the edge cases. Production finds every single one.

Two: Your AI’s memory system matters more than its model. I could swap Sparks to a dumber model tomorrow and it would still be useful because it knows my preferences, my projects, my history. A smart model with no memory is useless after the conversation ends.

Three: Building with AI is a lot like building anything else. You’re going to break stuff. You’re going to stay up too late. And the satisfaction of getting it right makes all of it worth it.

If you’re building your own AI workflows or thinking about it, just start. The tools are better than you think. The documentation is worse than you think. And the learning curve is exactly as steep as it sounds. But it’s the most fun I’ve had with tech in years.

This is what Sunday mornings look like when you’re building the future from your home office in pajamas.

Top comments (0)