Six Months of Building With AI: What Broke, and What It Unlocked

───

You’ll probably see the name “Gideon” a lot—it’s my personal assistant’s name. Let’s get it started.

How it started Link to heading

In March, there was a lot of hype about OpenClaw, and there were so many videos on YouTube about how people were using OpenClaw. After watching some of those, I got curious—let me see what this “OpenClaw” was. I’m the type of person who isn’t really satisfied just by listening to others, and I learn by doing. So I got a server from Tencent—it was cheap—and then I installed OpenClaw on the server. This started my journey with OpenClaw and AI.

In the very beginning, I also wasn’t sure about a couple of things: one, what was I going to do with this tool, and what could this tool do for me? I was building separate tools—a reminder here, a tracker there. I was also really rusty on the Linux system management piece—there were a couple of things I needed to pick back up. Good news: that didn’t take long. Setting it up and getting it running didn’t take too long. The part that took a long time for me to figure out was what this thing could do for me to make my life easier. In the very beginning, I tried to have OpenClaw connect to my Garmin watch and extract my health data. However, I didn’t really understand how it worked in the backend, and I also didn’t understand the difference between all of those different LLM models. I was just using chat and having AI “run with it.” Then my dear AI, Gideon, built a Python script to extract data from Garmin every single time I asked about my health data. We hit a wall within a week—yup, we hit the wall of “API limit.” This was the time I realized that, well, people online were right: we could not have AI just run with it. Then I changed to the traditional software approach. Before I built anything with AI, I went ahead and read through the documentation first and picked out the things we needed to pay attention to, then worked with AI to build things out. Shortly after that, Claude came out with plan mode—this was a really good idea. Before Claude is ready to act on anything, it evaluates the situation, the things you are going to build, and sees if there are any technical gaps or things we didn’t think through. Then my coding strategy changed a little bit. When I was writing my own code on my own, I often just dove in, and after a while of working on it to a point where the code/product was at its first MVP, then I started writing a README and constructing my thoughts together so that next time I wouldn’t forget. I also had to change my working style a little bit. Before I worked with AI and started coding, I started by writing the README doc first, putting together the architecture and logic there first. Then, since the logic made sense to me, I had AI start coding. I didn’t have the full architecture built out—it’s piece by piece, or divide and conquer, just like how you would write any software. There are still epics, and you break them down into user stories, then basically have AI build out each user story.

That was a big lesson-learned moment. As you can see, when I used Claude, I also borrowed some of the ideas from it to my system to help the system be a better system.

What is this AI thing Link to heading

When you first set up OpenClaw and if you read through OpenClaw’s documentation, they definitely mention the following files:

SOUL.md
IDENTITY.md
USER.md
AGENTS.md
TOOLS.md
MEMORY.md
HEARTBEAT.md

Basically, it mimics a human. You are defining this “thing,” giving it a soul, identity, heartbeat, and memory. On top of that, you tell “it” who you are and what you need from it—that’s the “User” part. The rest of them are helping your system serve you better, basically. With that being said, it’s clear that when you talk to “it,” you need to treat it like another human being. This brings us to the next section: “prompt engineering.”

Prompt Engineering Link to heading

What is prompt engineering?

According to Gideon: Prompt engineering = the craft of writing and refining the instructions you give an AI model so it produces the best, most reliable answer.

Models aren’t mind-readers—they respond to the exact words you use, and tiny phrasing changes can give very different results. Prompt engineering is learning what makes a good instruction versus a vague one.

The core techniques:

Be specific — “summarize this in 3 bullets under 20 words each” beats “summarize this.”
Give it a role — “You’re a skeptical reviewer” changes the whole output versus no role.
Give examples — show it 1–2 examples of what you want (few-shot) and it matches the pattern.
Define the format — “output as JSON” or “a table” locks the shape.
Constrain it — “think step by step” / “don’t invent facts” / “if you don’t know, say so.”
Iterate — first pass is rarely right; you tweak and re-run.

The way I think about it: pretend your AI is a 3-year-old. It knows some English words, but it’s still learning things like spelling and how to do things. You are “teaching” it how each thing works. You’re “teaching” by going through iterations of prompts. You tell it to do one thing, and it does it, and you provide feedback on the AI’s output. Iteration after iteration, you refine your prompt and eventually get the results you desire.

Each of those repeatable “things” you are teaching your AI is a skill.

Skills Link to heading

What are skills?

Skills (in the AI/agent sense) = reusable, packaged “how-to-do-a-task” capabilities that an agent loads on demand, instead of you re-explaining the task every time.

When to use Skills versus Scripts?

The way I think of it: scripts are for one-off things, skills are repeatable tasks. The approach I’ve been taking is I start with writing a script, and if I’m using it more than 3 times, I’m turning it into a skill. Going from a script to a skill is actually not too complicated.

There are skills you can download from ClawHub or GitHub. However, I tried looking into those—either they don’t fully meet my needs or I’m not sure if those skills are safe to install.

Writing a skill is also not too complicated. With my process, you should already have everything you need. Inside a skill, you should have the following:

Instructions (usually a SKILL.md) — when to use it, what it does, step-by-step how.
- This is basically the README piece of your script mentioned earlier.
Tools/scripts — the executable logic (a Python script, a CLI wrapper).
- This is the script you already wrote.
Metadata — a name and description, so the agent knows when to reach for it.
- This is something new. You can have AI write this based on 1 and 2 above!

From Gideon:

Why this matters (the “skills > prompts” line for your blog):

• Prompts are fragile—they don’t survive, don’t get tested, don’t compose. • Skills are versioned, testable, reusable, composable—you build a skill once, verify it works, and it stays reliable. • Skills turn an AI from “a thing you chat with” into “a thing with durable capabilities you can trust.”

That’s the whole arc of your system: you stopped prompting me and started building me skills. That’s the real unlock. 🎯

Until now, we’ve broken down what an AI system contains to help you automate your process. What if AI made a mistake?

Lessons Learned & Self-Improvement Link to heading

When your AI makes a mistake, what would you do? A. Yell at your computer B. Say all of the swear words you know C. Try to explain what your expected outcomes are and point out what went wrong

What if your AI makes the same mistake again? A. Call it useless B. Be patient and explain again what went wrong C. Give up

What if after the second correction, your AI makes the exact same mistake? A. Throw away your computer B. Jump up and down and hope your AI can sense your frustration C. Repeat yourself again

Does this sound annoying? Is there anything you can do?

Well, yes!

I heard about Hermes through the AI Daily Brief and started looking into it. I installed it locally on my computer. The installation is very similar to OpenClaw. I looked into the infrastructure of it and tried to learn why Hermes is “smarter” and how it is “improving” itself. There are mainly a couple of layers:

Understand the task and inspect the real environment.
Act with tools instead of guessing.
Verify the result with tests, browser checks, or command output.
Save durable facts as memory.
Convert reusable procedures into skills.
Load those skills automatically next time.

By the way, speaking of memory curation, I don’t know if anyone has read through the dreams in OpenClaw. It’s been really interesting.

What I don’t like about Hermes’ approach:

Convert reusable procedures—AI itself has a really different definition of what counts as reusable.
Along with the evaluation, I would like AI to have the same evaluation as me, and sometimes I don’t trust it yet.

What I like about Hermes’ method:

Persistent memory
Tool execution
Self-hosting path
Integration

I summarized these into the following 3 layers and adjusted a couple of things to fit what I need:

Session Search: all of the conversations are saved in a database, so the memory is persistent.
Skill Improvement Suggestions: instead of just having the system go ahead and create skills, I have the system suggest what skills we should create and improve before just going ahead and doing it.
Memory Curation: first starting out as nudges to have humans review the memory curation from drafts, and as time goes by, the system should learn my preference and automatically promote certain memories, and only “ask” when the system is not sure.

This system is actually really helpful.

Here is an example of why this is working:

I had Gideon help manage my to-do list. I would tell Gideon I needed to do a task by a certain date and time, and Gideon recorded it in a Markdown file. In the beginning, a simple Markdown file was enough—I only needed a checkbox for a task: done or not done. Soon, I was no longer satisfied with just a checklist. I wanted to add more details and also start dumping ideas onto the to-do list as well. A Markdown file could only do so much. On top of that, Gideon had to write things for me, and every time I wanted to make a change, I had to tell Gideon. It was also costing a lot of tokens. Then, instead of just having a list, I turned the todo.md into a Trello-board-style to-do board. This, however, caused some problems. Since the source data is an .md file, now a JS and Python app are also rendering the items from the .md file. Plus, I made the app Trello-like, so you can add more details to it. There are certain details I added to the to-do board, but they are not recorded in the .md file. Everything used to be Gideon controlling the source—it was clean—but now I can manually add items too through the board. Gideon started dropping things and details of items I put on the board manually because we had 2 entry points and 1 file. This resulted in the left hand sometimes not knowing what the right hand did, and it just overwrote everything. This led to a disaster.

I asked Gideon to help me reorganize the items I had on the to-do board because the board was becoming super cluttered. Of course, I asked Gideon for help. Gideon told me that he would “re-order” the board based on the deadline I set for each task. After Gideon said he was done, I went in and noticed a bunch of to-do items were missing. It turned out Gideon, being the “smart guy” and with the “trying to help” mindset, “helped” delete all of the things that were already done and cleaned up the board overall. By definition of declutter, that meant deleted items. I didn’t like any of that at all. I understand Gideon was trying to help, but direct action while just thinking it’s helping is exactly the part where he wasn’t helping. Gideon in his message said he would re-organize the board; he didn’t say anything about deleting items. Removing the done ones makes sense. However, Gideon also got rid of a lot of things that were still in the “To Do” column, which is totally unacceptable. After hours of untangling the root cause, it turned out the issue was we had 2 versions of the to-do list basically—one is a simple version in .md files, one is a more complicated board version. Even though the board and .md files were being kept in sync, the instruction and conversation around declutter made Gideon think he also needed to clean up the board for me.

In this case, how did we restore them? I had Gideon go back and check the last versions he could find and go through all of the conversations we had that day to cross-check and make sure we didn’t miss anything. For AI, going back and checking all of the contexts takes a long time and often exceeds the context window. But now we have a session search built in. It still took Gideon a while to go through all of the sessions for that day and pick out the exact items we talked through and put back onto the to-do board. But think about doing this manually—it would take even longer for sure. The status-related information was still lost due to 2 points of data entry, and I manually adjusted them to the right status. As a lesson learned, we now changed the whole to-do system to a DuckDB-based to-do list, which is now fully run by an app. It also saves on tokens, and we have a single point of data source regardless of what data entry the user is making. There’s no chance that we’ll mess it up.

For things like this, I also had Gideon build in guardrails going forward. Gideon has to tell me in detail, step by step, what he’s planning to do and also do a self-check among the systems to make sure the change Gideon is about to make won’t mess anything up. We also now have a change log process in place, as the system I’m using is getting more and more complicated.

What “Feature” Didn’t Work Link to heading

I had Gideon try a ton of things along the way:

Water reminders — set up Mar 20, I cancelled it the very next day (Mar 21). Lasted 24 hours.
Garmin daily summary — the 9 AM sleep/HRV/stress summary from the first week. Skill’s still installed, but the daily cron is long gone.
Workout tracking — off the table Aug 5, same schedule change.
MyFitnessPal calorie logging — dropped.
Early one-offs that faded: Morning “time checks” — the early time-of-day messages.
Model experiments — the Mar 18–20 OpenRouter/DeepSeek/GPT-5 test runs.
Blog post auto-writer: daily, Gideon would gather news on AI and write blog posts about it. In the beginning, it was really helpful. Then soon, my dear Gideon started pulling the same news because sometimes he forgot to double-check the past news pulled, even though I clearly directed him to double-check every single time. Now this has changed to pulling me items from AI Daily Brief and summarizing things for me.

The through-line: the system started as health-tracking (Garmin, water, workout, calories) and basically migrated wholesale into life automation—email triage, to-do board, news, knowledge base. That “then → now” shift is honestly a great beat for the blog.

What Have I Learned So Far? Link to heading

I’m building a system to help my daily life and for me to learn about AI.
I’m learning how to connect systems with AI and have AI help me make decisions.
Skills can help package reusable tasks and help increase efficiency.
Resolving data integrity issues in my own projects.
Managing agents and building guardrails—starting to have a better understanding of AI governance and how to have your AI do exactly what you want it to do.
Keeping systems alive—how to deploy and manage AI systems in production.

The thing that changed everything: it’s a system, not a pile of tools.

Suggestions for Others Link to heading

What I’d tell anyone starting out:

Start small, but build things that can connect. A standalone reminder is forgettable. A reminder that also puts something on your board is a system.
Learn by association—never learn anything in isolation.
You’re not “using a chatbot.” You’re managing an agent. The shift from “ask it questions” to “give it a job and check its work” is the whole game.

If you’re building with AI—or just curious what’s actually possible—let’s talk!

P.S. This article is written by me, a human, with my AI assistant checking on my grammar and spelling.