← writing

Teaching AI to Solve Problems Teaches You How to Learn

I spent three hours and 130,000 tokens trying to automate adding skills to a Freelancer.com profile. The AI and I tried everything: guessing URL patterns, inspecting DOM structures, attempting different navigation flows. Every single approach failed.

Then I paused and asked a different question: “How do professionals reverse-engineer web applications they don’t have documentation for?”

Thirty seconds of research gave me the answer: Playwright Codegen. A tool that records your browser interactions and generates the exact selectors and code you need. The problem that burned 130k tokens would have been solved in 5 minutes if we’d started with the right question.

The Pattern That Emerged

This wasn’t just about Freelancer automation. It revealed a methodology that works across any complex problem-solving with AI:

1. Break It Down Before You Build

When I first tackled this, I jumped straight to coding:

  • “Let me navigate to the profile page”
  • “Let me click the edit button”
  • “Let me find the skills input”

All guesswork. All wrong.

What I should have done:

  • “What tools exist for recording browser interactions?”
  • “How does Freelancer’s UI actually work?” (search official docs)
  • “What’s the URL pattern for edit mode?” (ask the human who uses it)

The lesson: Decompose the problem into research questions first, execution steps second.

2. Research Beats Assumptions

I had mobile screenshots showing what looked like an autocomplete input. I built an entire interaction pattern around that assumption. Web search of Freelancer’s support docs revealed it’s actually category-based checkboxes.

All that autocomplete code was solving the wrong problem.

The lesson: A 30-second web search can save 30 minutes of coding the wrong solution.

3. The Learning Layer Compounds

Here’s where it gets interesting. After we figured out the right approach, I didn’t just move on. We captured four lessons in a database:

  1. Use Playwright Codegen for unknown navigation
  2. Research UI patterns before coding
  3. Break automation into: docs → record → code
  4. Verify session file paths (we spent time debugging authentication when the session file existed at a slightly different path)

Now when the AI (or any team member) faces a similar automation task, the system can surface these lessons via RAG (Retrieval-Augmented Generation). The next attempt starts from “use Codegen” instead of “guess URLs.”

Why This Matters Beyond AI

The methodology we discovered isn’t AI-specific. It’s just good problem-solving:

Stop and understand before you act.

But working with AI makes this visible in a way solo work doesn’t. When you’re coding alone, you might thrash for an hour, find the answer, and move on. The thrashing feels like “debugging” or “figuring it out.”

With AI, every wrong turn costs tokens. Every assumption that fails generates a transcript. You can see the waste.

And seeing it forces you to ask: “What would have prevented this?”

The answer is almost always: Ask better questions earlier.

Teaching AI Is Teaching Yourself

When you explain to an AI how to solve a problem, you’re forced to be explicit about your reasoning. You can’t hand-wave. You can’t rely on intuition.

You have to say:

  • “First, search for official documentation”
  • “Then, use the recording tool to capture the interaction”
  • “Finally, extract selectors and code the automation”

Writing that down for the AI clarifies your own process. And capturing it as lessons means the next time you (or the AI) face a similar problem, you start from that clarity instead of from confusion.

The Compounding Effect

This session produced four lessons. Those lessons will prevent similar failures in future automation tasks.

But more importantly, they reinforce a meta-lesson: Research → Record → Code.

That pattern applies beyond browser automation:

  • Infrastructure work: Docs → Experiment in sandbox → Deploy
  • API integration: API explorer → Test request → Production code
  • Data pipelines: Sample data → Prototype → Scale

Break it down. Understand before you build. Capture what you learn.

How to Apply This

If you’re working with AI on complex tasks:

  1. Before asking the AI to code, ask it to research. What tools exist? What do the docs say? What’s the standard approach?

  2. When something fails, don’t just retry. Ask: “What would have prevented this?” Capture that as a lesson.

  3. Store lessons in a retrievable format. We use a SQLite database with RAG. You could use a wiki, a notes app, or even a well-organized Notion page. The key is: structured, searchable, reusable.

  4. Review lessons at the start of similar tasks. Before starting browser automation, we now run: “What do our lessons say about browser automation?” The AI retrieves the Codegen lesson and starts there instead of guessing.

The Meta-Skill

Teaching AI to solve problems systematically teaches you to solve problems systematically.

The AI doesn’t bring intuition. It brings consistency. If your process is sloppy, the AI will be sloppy. If your process is rigorous, the AI amplifies that rigor.

And the lessons you capture don’t just train the AI—they train you. Reading “Use Codegen for unknown UI” three months from now will remind you of the right approach faster than trying to reconstruct it from memory.

The Result

We still haven’t finished the Freelancer automation. But we learned something more valuable: a repeatable methodology.

And that methodology—captured, documented, retrievable—compounds. The next automation task will start from those lessons. The one after that will add more.

Over time, the corpus of “how we solve problems” grows. And both you and the AI get better at applying it.

That’s the real win.


This post was written after a 3-hour debugging session that should have been a 5-minute recording session. The lessons are now in the database, ready for next time.

← back to writing