I tested Reverse Engineer Anything (REA) with Claude Code to see how it could help me rebuild features from existing apps, including my own Loom-inspired screen recorder. I break down how it works, a five-step process for using it, and the limitations I ran into. The same approach can help you build better AI skills and workflows by giving your agent clear examples of the output you want.

I’m just pretty new to AI automation and I've built a few small workflows, including a Lead Qualification & CRM Automation coz I found someone is asking for it on upwork so I made one. So far I’ve tried cold email outreach, Posting on reddit, etc. I'm still doing these things. Questions for those who’ve landed clients: 1. With no reviews yet, did you offer a free pilot or a discounted first project? 2. What did you show them (demo, portfolio, video) that made them say yes? 3. How did you lead that convinced them to say yes? Any advice helps, especially from people who started with no network.

I wanted to build routing by meaning. First step was re-running `--report` on the router log, and that's where the plan fell apart. The file-read counter matched brain paths anywhere in the raw transcript. That includes the workspace `CLAUDE.md`, which is attached to every session and has a "Quick map" naming five brain files in prose. So every session logged four or five files it had never opened, and all fourteen "hunts" carried the identical file list. Another 140 sessions got binned as `maintenance` for the same reason, which is why the sample read 19 instead of 100. I rescored counting tool-call inputs only. 147 of 180 rows were recoverable (180 - 147 = 33 transcripts deleted). Result: 10% over the last 30, 8 of 101 lifetime. Threshold was 20%, so no retrieval layer got built. Of the seven recovered prompts, five needed no brain file at all. Two were genuine misses, and each got fixed with one router word, pinned by tests. This is the third time one of my instruments reported confidently while measuring the wrong thing. The other two were the 43% false alarm and a regex hiding 5 of 28 log entries. So a gating number is windowed now and its unit is unit-tested. Its input also stays separated from its context. When a metric decides whether you build something, how do you test that it's counting what the session actually did and not just what it was shown?

Let's get to know each other! Comment below sharing where you are in the world, a career goal you have, and something you like to do for fun. 😊

I had a big build to ship and a Pro plan with a usage window that resets every 5 hours. A long job doesn't fit in one window. It doesn't fit in one context either. Two problems showed up fast: - Token limits. Hit the window and everything stops, mid-task, until the reset. - Continuity. A stopped session loses its thread. A session that runs too long gets heavy and forgets. Either way, I had to re-explain everything. So I stopped trying to keep one session alive. I designed the work so no single session mattered. The idea Put the memory in files, not in the conversation. Then any session, at any time, can die and be replaced without losing anything. The flow - A spec and a plan. The design is written and approved first. The plan cuts the work into small tasks, each self-contained enough for someone who has never seen the project. - A controller. One headless session that dispatches and decides. It doesn't write code, so its context stays small. - Disposable workers. Each task goes to a fresh, unattached session with one job: implement, review, re-check. They return a short summary and are gone. Nothing accumulates. - A ledger. A plain file that records what's done. This is the project's memory. Whoever starts next reads it and continues from the exact point where the last one stopped. - Standing instructions in files. Rules for implementers and reviewers live on disk, so dispatching a task is one short line, not a pasted prompt. - A supervisor. A small script, not an AI. It watches the controller, notices when the limit hits, waits for the reset, relaunches, and notifies me only when it needs a human. It costs zero tokens, because a model watching a model just burns the window you're trying to save. What it looks like in practice I start a stage in the evening. The window runs out at some point. The supervisor waits. After the reset, a new controller starts, reads the ledger, and carries on. In the morning it's merged and waiting for my verification. If one account is exhausted, I log into the second and it continues.