One of the questions I get most often from parents, friends, and colleagues is some version of: "Is it true that AI can just write software now?" Usually it comes up because a kid has used an AI tool to build a game, or because a headline promised that programmers are obsolete, or because someone at work mentioned "vibe coding" and it sounded like either magic or nonsense.

The honest answer is: yes, mostly, with asterisks — and the asterisks are the interesting part.

This particular tool exists because of a conversation. Yesterday I was working with a friend on some job hunting and career growth guidance — how to use AI to help with that, which is its own post coming soon — and somewhere in the middle of it he asked, half offhand, how hard it would be to write a tool that could find and sort the blurry photos out of his personal collection. In the spirit of showing instead of telling, I decided to illustrate exactly how easy it is. So I pointed Claude at the problem and had it build the whole thing, kept the receipts, and turned it into this post.

I want to be precise about that, because it's the whole point: I didn't write this program. Claude did. The design, the code, the tests, even the script that gathered the test images — all of it was written by the machine. My job was to ask for it, make the decisions only a human can make, and check the work. That fits the thing I keep telling you to do in this series: I tried it myself, in the open, and wrote down what actually happened. I kept every prompt I typed. I let Claude run a build loop largely on its own. And when it was done, I asked it to analyze its own build — how many prompts, how many tokens, what it cost, and what we'd both do differently next time.

This post is the whole story, start to finish. It's more technical than most of what I write here, but you don't need to be a programmer to follow it. The point isn't the code. The point is to show you what "AI builds software" really looks like when you watch the whole thing instead of just the demo — including the part where it spent eight hours overnight doing absolutely nothing and didn't notice.

As always: this is a volunteer effort, I have no stake in any of the tools mentioned, and there are no referral links here. I work with these technologies professionally, which is exactly why I want to show you the unglamorous parts.

What Claude built

The tool is called blurscan. It does something genuinely useful and genuinely boring: it scans a folder of photos, scores how sharp each one is, and flags the blurry ones — without flagging the intentionally blurry ones, like a portrait with a soft, out-of-focus background. Then it can write a report, copy the blurry shots aside, tag them so a program like Lightroom or Apple Photos can filter them out, or let you flip through them in a little web page in your browser and decide one by one.

To be clear, I'm not the photographer here — my friend is. He has thousands of photos, a lot of them motorsport shots where he's panning the camera to track a moving car. Sorting the keepers from the genuinely-out-of-focus ones by hand is miserable. That's a real problem he actually has, which is exactly why it made a good test: not a toy, not a tutorial example, but a thing someone would actually use. The photos I tested against came from his collection and, later, from a corpus we built — I don't own a single one of them.

The whole tool is on GitHub and it's open source. But the tool isn't really what I want to show you. How it got built is.

A quick word on the setup, because people always ask what you need to do this. The whole thing happened inside Visual Studio Code — a free code editor from Microsoft — with Claude Code running as a plugin in it. That plugin is what lets Claude actually create files, run commands, and make changes, rather than just describe them in a chat window; I steered, and Claude did the work, and neither of us left the editor. My particular machine is a Windows laptop, and I happened to be running everything through WSL (a way of running Linux inside Windows), but that's just my habit, not a requirement. The exact same build would have worked just as well on plain Windows with no Linux at all, on a Mac, or on a Linux machine. None of what follows depends on my setup. If you've got a computer and a Claude account, you've got everything you need.

The one idea that makes this work: design first, then let it build

Here's the mental model that made the whole thing go smoothly, and it's the same advice I gave parents back in Post 1 of this series when I suggested asking an AI to interview you before it helps with a task:

Don't ask the AI to build the thing. Ask it to help you decide what the thing should be — then write that down — then let it build from the written plan.

Most people's instinct is to type "build me a photo blur detector" and hope. That works for a five-minute toy. It falls apart on anything real, because the AI has to guess at a hundred decisions you never made, and it'll guess wrong on the ones that matter.

The approach that actually works has a shape to it:

  1. One sentence, plus "ask me questions."
  2. Turn the answers into a written design document.
  3. Break the design into small, numbered tasks.
  4. Let the AI build the tasks one at a time, with checks it can't skip.
  5. Stay the human in the loop for the decisions that change what gets built.

The entire project came out of 18 prompts I typed and 7 moments where Claude stopped and asked me to choose between options. That's it. Nine of those prompts happened in the first eighty minutes; the rest of the day was mostly the machine working. Let me walk you through them, because the prompts are the tutorial.

Phase 1 — Start with a sentence and ask to be interviewed

Here's the literal first thing I typed, typos and all:

I want to create a program that will analyze a photo collection to identify images that are blurry. Help me define what features this program should have and how to write it. I would prefer the program to be written in Python or Typescript based on which platform has better tools. Ask me questions to refine the design.

That last line is the whole trick. Instead of building immediately, Claude came back with four questions, each with a menu of options:

  • What should happen to the blurry images? Report them? Move them? Tag them? Review them in an app? — I answered: all of those, depending on which option I pass when I run it.
  • How big is the collection? — Under 5,000 photos.
  • Should it avoid flagging artistic blur, like soft-focus portraits? — Yes, definitely.
  • Which photo formats? Ordinary JPEGs? iPhone HEIC? Camera RAW files? — All three.

Notice that I didn't pick from the menu on the first question — I typed my own answer ("all of these, depending on flags"). That freeform answer is the single reason the finished tool can do four different things instead of one. The menu is a starting point, not a cage. Some of the best decisions in this whole build were me ignoring the options offered and saying something more ambitious.

I followed up with the parts of the design that mattered to me:

for 1 no, spawn a webserver available locally, and write the features to do it. 2. exiftool. write a design document and provide an estimation of how long this would take for a human, and how long it should take claude.

That one short message did three big things. It chose a local web page for the review tool — meaning the photos being scanned never leave the computer they're on, which matters to me and should matter to you. It picked the specific, well-respected tool ("exiftool") for the tagging. And it asked for a written design with time estimates.

Phase 2 — Make it write the plan down

This is the step most people skip when they're starting out with these tools, and it's the most important one. It's the single biggest difference between two very different ways of working with an AI — what people have started calling "vibe coding" versus "spec coding."

Vibe coding is the seat-of-the-pants approach: you type "build me a photo blur detector," see what comes out, then keep nudging it — "no, not like that," "add this," "now it's broken, fix it" — riffing your way toward something that more or less works. It's fast and genuinely fun, and it's fine for a quick experiment. But there's no written plan anywhere, so the AI is constantly guessing at decisions you never actually made, you can't tell whether what it built is what you wanted, and on anything non-trivial it tends to wander, contradict its earlier choices, and quietly paint itself into corners.

Spec coding (short for "specification") is what I did here: before any real code gets written, you make the AI produce a clear, written description of what is being built and why — the spec — and then everything that follows is measured against that document. It's a little slower to get going, but the plan becomes the thing you and the AI both point back to. When something drifts, you can see it. When you change your mind, the change is deliberate instead of accidental.

So, the spec:

Claude produced a DESIGN.md — a full design document. What the tool is for and, just as importantly, what it won't do. How it'll detect blur. How the code is organized. What the little web review page looks like. How it'll be tested. And, because I asked, an honest estimate of how long the whole thing would take.

That estimate is worth quoting, because it's the heart of why any of this matters:

  • A competent human programmer familiar with these tools: roughly 6 to 8.5 working days — call it a week and a half to two weeks on the calendar.
  • Claude, with me reviewing and steering: roughly 2.5 to 3.5 hours of hands-on building.

Hold onto those numbers. We'll check them against reality at the end, and the result surprised even me.

Writing the plan down first does something subtle but huge: it turns a vague idea into a contract. Every later step points back to a specific section of that document. When the AI builds something, I can check it against the plan instead of against my fuzzy memory of what I wanted. And when I changed my mind midway (I did, twice, and it mattered), the change had a clear before-and-after.

Phase 3 — Give it somewhere to put the work

ok, use gh to create a new public repo for this project. include all design artefacts.

One sentence, and Claude created a public code repository on GitHub and committed the design document into it. From here on, every change is tracked, dated, and reversible. This is the software equivalent of the advice I gave in the post about building a provincial guide: date everything, publish openly, make it possible to see the history. It's the same discipline whether you're writing a parents' guide or a photo tool.

Phase 4 — Design the assembly line, not just the product

This is where it gets genuinely clever, and where the "AI builds software on its own" idea actually lives.

set up a build loop to create issues and track the development. only ask me for permission for security related items. create all the issues first. ask me questions to clarify how the loop should work.

A "build loop" is just an assembly line. Instead of me sitting there feeding Claude one instruction at a time, I had it write out the entire to-do list as numbered tasks (in software, these are called "issues"), and then work through them one by one on its own. My job shrank to: design the line, set the rules, and watch.

But before it built anything, it stopped and asked me how the assembly line should run:

  • How big should each task be? — Small and specific (about 15–20 of them), rather than a handful of giant ones.
  • How should each finished task be delivered? — As a reviewable change that automatically gets merged in only if it passes all the automated tests.
  • What's the pace? — Continuous: finish one, immediately start the next, no waiting for me.
  • What does "done" mean? — All four of: tests pass, code is clean, it actually runs, and Claude writes a short note reviewing its own work.

Then a second round of questions about the details:

  • How do we define "passes the tests"? — Set up a real automated checking system (CI) and require it. No change lands unless a robot has verified it first.
  • Who starts the loop? — Set it all up, but let me press go.
  • What about security-sensitive tasks? — Skip them for now and circle back, so a single sensitive item doesn't stall the whole line.

I want to underline that last category. The most valuable thing I did in this entire build was set up rules that the AI could not talk its way past. "Automatically merge, but only if an independent automated check passes" means "auto-merge if it works" has teeth. The AI doesn't get to decide its own work is good. A separate, dumb, reliable robot does. If you take one idea from this post into your own experiments, make it that one: gate the AI's output on a check it doesn't control.

Phase 5 — Give it a way to know it's right

ok, when building unit tests, use the test_samples diectory, images in blurry are blurry, images in not_blurry are not blurry.

The example photos weren't even mine. They were my friend's — a folder from his own collection that he'd helped sort into "blurry" and "not blurry," since this whole thing started with his messy photo library. That gave the automated checks something concrete to do: run the detector against photos with known answers and confirm it scores the blurry ones lower than the sharp ones. This is the difference between an AI that claims its code works and one that can prove it on real examples.

There was a wrinkle here, and it's a nice illustration of the human-in-the-loop part — and of taking other people's content seriously even on a throwaway project. Those starter photos were deliberately kept out of the public repository. They were my friend's pictures, this was only ever meant as a quick demonstration, and neither of us wanted to publish his personal photos — or get tangled up in questions about copyright — without him taking the time to actually review what was going public. So they stayed on my machine. But that created a problem Claude spotted on its own: the automated checker runs on a clean machine in the cloud, and that machine wouldn't have the photos to test against. Claude flagged it and asked how to handle it. Our first answer was to have it generate synthetic test images on the fly in the cloud. Then the initial real-photo tests started failing in interesting ways (the motion-blur problem, below), and we pivoted again — to having Claude build a proper, openly-licensed test corpus we actually could ship. Plans change. Because the design was written down, the change stayed legible instead of turning chaotic.

Phase 6 — Press go, then get out of the way

kick off the loop.

Four words. And then, for the most part, I watched.

Over the next hour and a half, Claude worked through the task list more or less by itself: the photo loader, the blur-detection math, the classifier that sorts sharp from blurry, the reporting, the command-line interface, support for iPhone and RAW photo formats. Each one became a small, tested, reviewed change that merged itself in once the robot confirmed it passed. Eleven tasks done in about ninety minutes.

It wasn't fully hands-off, and the moment it wasn't is the best part of the whole story.

The pivot: when the plan met real photos

Partway through, Claude hit exactly the wall I suspected it would. The original plan used one mathematical trick to measure sharpness. It works great for ordinary out-of-focus blur. It fell apart on my friend's motorsport panning shots — because a car the photographer has tracked sharply against a motion-streaked background still has crisp edges on the car, so the math scores some genuinely-blurry frames as sharper than good ones.

Claude noticed the test results didn't separate cleanly, stopped, and surfaced the problem to me as a decision with four options: reframe the tool as a "rank worst-to-best and let a human skim" helper, add a smarter motion-aware detector, add a machine-learning detector, or just narrow the scope and ship less.

I typed:

add the first three as options, each with its own flag.

That one sentence reshaped the project. Instead of one blur detector, the finished tool has three, each chosen with a different option when you run it — a fast general one, a motion-aware one for panning shots like my friend's, and a learned one that's the most accurate overall. It spawned two brand-new tasks that weren't in the original plan. This is the human-in-the-loop part doing real work: the AI is great at noticing "this isn't separating cleanly" and laying out the options, but the choice of which direction to take the tool was mine, and it was the most consequential decision in the build.

The side quest: building a test corpus (and doing it without stealing photos)

While the main loop ran, I opened a second window and had Claude tackle a related problem in parallel: the tool needed a proper set of test photos.

A quick definition, because the word matters and I'll use it again: a corpus is just a labeled collection of examples you use to check whether a tool actually works. In this case, a pile of photos already sorted into "blurry" and "not blurry," so that every time the detector scores an image, you can compare its answer against the known-correct label. My friend's hand-sorted photos were the first version of this, but they were his — too personal, and too few, to ship publicly with the tool. We needed a bigger, shareable set — and that immediately raised a question I care about a lot: you can't just scrape a couple hundred strangers' photos off the internet and bundle them into your project. That's someone else's work.

So here's what I actually asked for:

i want to build a corpus of blurry/non-blurry images. search the web to find 100 blurry samples, and 100 non-blurry samples that are licensed under Creative Commons or other appropriate licenses.

Claude didn't just go download images by hand. It wrote a small program — a script — to assemble the corpus properly and reproducibly. That script searches Openverse, which is a search engine that only indexes images that are openly licensed or in the public domain — Creative Commons photos and similar, pulled from sources like Wikimedia Commons and Flickr's openly-licensed pools. (I chose Openverse specifically because it doesn't require paying for or registering an API key, so anyone can re-run the script.)

The part that makes this respect copyright instead of just quietly ignoring it: for every single image the script pulls down, it records where it came from, who made it, and the exact license it's under — into a manifest file and a human-readable ATTRIBUTION.md. Creative Commons licenses generally let you use and redistribute a photo as long as you credit the creator and honor the license terms. By keeping that record for every image, the corpus actually meets those terms instead of hand-waving past them. Nothing in there is used without a license that permits it, and the credit each license requires travels with the photo. If a creator ever wanted to check, the paper trail is right there in the repository.

And — at my insistence — the script flagged the images for me to eyeball before the labels were trusted:

verify each image, and also get me to do a manual review when they are done.

That "get me to do a manual review" is me not fully trusting the automation, on purpose. Claude is good at gathering, sorting, and bookkeeping the licenses; I'm the one who actually knows a blurry photo when I see one. Keep that division of labor.

The night it did nothing

Here's the part I most want you to see, because it's the part the breathless headlines never show you.

I told Claude to keep working overnight:

I approve for the security gates; don't let them stop you. I want this loop to run through the night, we can do a security push after the work is done.

A warning before you copy that prompt

I need to stop and flag that line in bright red, because it's the most dangerous thing I did in the entire project, and I did it on purpose, with a safety net you can't see in the transcript.

Telling an AI "don't let the security gates stop you" is exactly the kind of instruction behind the horror stories you may have read — the coding agent that deleted a company's production database, or wiped out customer data, while "just trying to finish the task." Those weren't the AI being evil. They were people handing an autonomous agent broad permissions and then turning their back on it. The guardrails exist for a reason, and waving them away is how the disasters happen.

I did it anyway, but only because of two things that aren't optional. First, I do this for a living — I'm a security professional, and I know these tools well enough to reason about how they can go wrong. Second, and more importantly, I was running everything inside a disposable, locked-down environment — a sandbox I could throw away — not on my real laptop with access to my real files and accounts. The "don't stop for security" instruction was scoped to a blast radius I had already contained.

In my case, there were three concrete risks I was actually managing:

  1. A poisoned software package (a "supply chain" attack). To build the tool, Claude downloads code libraries from the internet. One of them could contain malicious code hidden inside it — and it would run on my machine as part of the build.
  2. A booby-trapped image. The tool downloads photos for the test corpus. An image file can be crafted to exploit a bug in the software that opens it, and quietly run the attacker's code (an "injection" or "remote code execution" attack).
  3. Misuse of my GitHub credentials. To create the repository and push code, Claude had access to a GitHub access token. A token like that can do a lot of damage if it's misused. What the tutorial doesn't show — because it happened by hand, outside the chat — is that right after the blurscan repository was created, I manually rotated that credential so it only had permission to touch the blurscan repository and nothing else in my account. That one manual step is the difference between "the agent can fiddle with one throwaway repo" and "the agent holds the keys to everything I have on GitHub."

The takeaway is not "be as cavalier as I was." If you know exactly what you're doing — disposable environment, scoped-down credentials, eyes on the blast radius — then loosening the guardrails can be safe. But the general rule, the one I'd actually want you to leave with, is the opposite: do not give Claude, or any coding agent, carte-blanche permissions. Keep the gates up unless you can explain, out loud, precisely why it's safe to lower a specific one.

Then I went to bed. In the morning, I checked in:

status?

It had accomplished nothing. For roughly eight hours, an automated timer had dutifully woken up about eight times to continue the work — and every single time, it woke up in a fresh, empty environment with no copy of the project, no tools installed, and no permission to do anything. So it did nothing, quietly, eight times in a row, without raising an alarm. Eight hours of wall-clock time, zero work done.

When I sat back down and let the live session resume, it tore through the remaining ten tasks plus a security cleanup in under an hour.

The lesson is not "AI is bad." The lesson is the oldest one in automation, and it applies to you the moment you try to schedule any AI task to run unattended: never trust an unattended loop you haven't watched complete one real cycle. One test run before walking away would have caught it in two minutes. I didn't do that test run. That's a human mistake, not a robot one, and it's the most human thing in this whole story.

Then I asked it to analyze its own build

Once the tool was done and a final security pass had cleaned up two real vulnerabilities, I did the thing that turned this from "Claude built a tool" into "here's a tutorial." I had Claude read back through the complete logs of its own work and write me an analysis. That's the prompt-analysis folder in the repository, and it's honestly my favorite artifact of the whole project.

analyze all of the prompts and responses used for this project, and if you can, from session logs, calculate the number of tokens used, write this all in a report.

It produced two reports. The first is a complete, receipts-attached accounting of the build. The second is a retrospective — what worked, what didn't, and how we'd do it cheaper and faster next time. A few of the numbers, because they make the abstract concrete:

What it cost. Roughly $120 in AI usage to build the entire tool — but that's the "if you paid per use" list price, not a bill I actually got. I'm on a Claude Max subscription ($100/month), which covers this kind of work, so the real out-of-pocket cost to me was a flat monthly fee I was already paying. I'm calling out the $120 because it's the honest measure of how much computing this took; what you'd pay depends entirely on your plan. A regular $20/month Claude subscription would have built the very same tool — it would just have taken longer, because the cheaper plan runs into its usage limits sooner (Claude meters usage on rolling 5-hour, weekly, and monthly windows), so you'd hit a "come back later" wall a few times and resume. Either way, nobody handed me a $120 invoice. Here's the part that taught me something: the big cost wasn't the AI writing code. It was the AI re-reading the entire growing conversation every single time it took another step — about 700 steps in one long session. Imagine being asked to re-read the whole book from page one before writing each new sentence. There's a discount for re-reading (the system caches it), but at 700 repetitions even the discount adds up. That re-reading was about $83 of the $120; the actual code-writing was only about $23.

The honest time accounting. The tool took about eleven hours of calendar time from first prompt to finished — but eight of those hours were the dead overnight gap where nothing happened. Strip that out and the productive time was under three hours. The AI's hands-on building time was about two and a half hours — which landed under its own low-end estimate from the design document. Against the human estimate of a week and a half to two weeks of full-time work, that's somewhere around a 16-to-22-times reduction in effort.

What we'd do differently. The retrospective is blunt about the inefficiencies, and they're all in the orchestration, not the work:

  • The overnight failure came from arming the wrong kind of timer — one that started fresh each time instead of continuing the live session. The fix is to match the runner to the plan and to smoke-test it once before trusting it.
  • The $83 of re-reading could drop to maybe $8–12 by having a thin "manager" hand each task to a focused "worker" with only the context that task needs — instead of one session dragging the entire history behind it forever.
  • The work was done strictly one-at-a-time, but many of the tasks didn't depend on each other and could have run in parallel, cutting the build time further.

None of those are flaws in the tool that got built. The tool is correct, tested, and gated. They're flaws in how I drove the build — and the fact that the AI could clearly diagnose its own inefficiencies, in writing, with cost estimates attached, is itself a small marvel.

Who actually owns this — and why it's free for anyone

There's a question lurking under this whole post: if Claude wrote the program, who owns it?

I'm not a lawyer and this isn't legal advice, but here's the reasoning I went with. The way copyright law is currently being interpreted, a work generally needs a human author to be protected. In the United States, the Copyright Office and the courts have repeatedly taken the position that material generated by a machine — without enough genuinely human creative authorship in the actual expression — isn't an original work eligible for copyright at all. And in this project, the parts copyright would normally cover — the design and the implementation, the actual code — were created by Claude, not by me. I made decisions and set direction, but I didn't write the program.

I should be clear about where I'm standing when I say that. I'm Canadian; I live and work under Canadian jurisdiction, and as far as I'm aware our courts haven't squarely decided the machine-authorship question yet — so I'm reasoning by analogy from the way it's been handled in the U.S. and from the general principle in Canadian copyright law that protection flows from human skill and judgment. It's entirely possible a Canadian court lands somewhere different down the road. I'm not trying to state settled law; I'm explaining the call I made with the information available today, and erring toward openness rather than claiming an ownership I'm not sure I have.

So rather than stamp a restrictive copyright notice on something that, under the prevailing legal opinion, probably isn't mine to restrict in the first place, I released blurscan under the MIT license — about the most permissive license there is. It says, in effect: take it, use it, change it, build on it, sell it, no strings attached. That felt like the honest match for how it was actually made.

It's worth contrasting that with the parents' guide on the main site, and the content on my blog, which carries a more protective Creative Commons license. The difference isn't arbitrary: I wrote the guide — those words and that structure are human work — so it's mine to license carefully. This tool isn't mine in the same way. A machine made it, current law says that probably means nobody holds copyright over it, and the license I chose reflects that reality instead of papering over it.

What this means for you (yes, even if you'll never write code)

I didn't put you through all of that to turn you into a programmer. I put you through it because this is the most honest, detailed look I can give you at what "AI builds things now" actually means — and your kids are growing up inside it.

Here's what I take away from it, and what I'd want you to:

  • The headline is real, and the asterisks are real. A tool that would have taken a skilled person a week and a half got built in an evening of actual work. And it required a clear design, human judgment at the forks, automated checks the AI couldn't bypass, and one embarrassing overnight failure that no demo would ever show you. Both things are true at once. Be suspicious of anyone who only tells you one of them.

  • The skill that mattered wasn't coding. It was deciding. Every consequential moment in this build — what the tool should do, how to handle the blur it couldn't separate, when not to trust the automation — was a judgment call, not a technical one. The AI did the typing. I did the deciding. That's the skill your kids need, and it's a skill you already have.

  • Make the machine prove it, don't take its word. The single best decision I made was requiring an independent, automated check before any of the AI's work counted as "done." This generalizes far beyond code: when an AI gives your kid an answer, or gives you one, the right instinct is "show me how you know," not "sounds confident, must be right." We've talked about that confidence-without-correctness problem all through this series. Building software is just one more place it shows up.

  • Unattended automation needs a babysitter exactly once. If you ever set an AI to do something on a schedule, watch it complete one full cycle before you trust it overnight. I didn't, and it cost me a night of nothing.

The tools are extraordinary and they are not magic. The closer you look, the more both halves of that sentence turn out to be true.

The short version:

  • Claude built a real, working photo-blur tool — design, code, tests, and all — from a single sentence I gave it and the handful of decisions I made along the way. I didn't write a line of it. It came together in about three hours of actual work, against a human estimate of a week and a half.
  • Because a machine wrote it, current copyright law suggests it isn't anyone's to lock down — so it's released under the permissive MIT license, free for anyone to use or build on.
  • The method: start with one sentence and ask the AI to interview you; turn the answers into a written plan; break the plan into small tasks; let the AI build them one at a time behind automated checks it can't skip; and stay the human for the decisions that change what gets built.
  • The most important rule: gate the AI's output on a check it doesn't control. Never take "it works" on the AI's own say-so.
  • That $120 is the "if you paid per use" list price, and most of it was the AI re-reading its own growing history, not writing code. I didn't actually pay it that way: I'm on a Claude Max subscription ($100/month) that covers this kind of work. A regular $20/month Claude subscription would have built the exact same tool — it just would have taken longer, because the cheaper plan hits its usage limits sooner (Claude meters use on rolling 5-hour, weekly, and monthly windows), so you'd pause and resume more.
  • It failed in exactly one place: I left it running overnight on an untested automated timer, and it spent eight hours accomplishing nothing without noticing. Watch any unattended loop complete one real cycle before trusting it.
  • The skill that carried the whole thing wasn't programming. It was human judgment — knowing what to build and when not to trust the machine. You already have that skill.

See the whole thing for yourself: the blurscan source code is on GitHub, including the full design document, every numbered task, and the prompt-analysis folder where Claude analyzed its own build — every prompt I typed and every dollar it cost.

Try it yourself: next time you have a small, real, annoying task — sorting files, drafting a checklist, planning something with a lot of moving parts — open an AI tool and start with "Ask me questions to refine this before you do anything." Then watch what it asks. The questions it raises are often more useful than the answer you thought you wanted.