DEV Community: Miitobow | Building apps with AI

Claude Code kept cutting out mid-task. I counted the causes and got it down to 3.

Miitobow | Building apps with AI — Fri, 17 Jul 2026 04:39:37 +0000

I use Claude Code every day building a Windows app. Right when a task was flowing, it would just stop. Mid-call, no error, nothing.

The first few times, I just restarted and moved on. Eventually I started paying attention, and the causes turned out to fall into three clean patterns.

The pattern

Every tool call gets wrapped in a fixed marker — a closing tag the model writes right after it finishes describing what to run. Every single time this happened, the cutoff landed right after that marker. Same behavior on my Windows build and on an Android build, regardless of which project I was in. It wasn't about the app. It was about how I was phrasing the request.

Cause 1: backgrounding a shell command

Shells have an operator that kicks a process into the background and lets you move on to the next line immediately. Using it inside a request reliably cut the call off right after.

Fix: don't background it manually. Use the tool's own way of running something in the background instead.

Cause 2: cramming multiple jobs into one instruction

Asking for an analysis, then a display check, then a save — all in one shot, back to back. That combination reliably broke the call.

Fix: one instruction, one goal. Splitting it up cost nothing and fixed everything.

Cause 3: pasting a big block of text directly into an instruction

Handing over a long chunk of raw text as part of the instruction itself sometimes broke the call's structure entirely.

Fix: write the content to a file first, then reference the file in a separate instruction. Feels like a detour. It's actually the most reliable path.

A Windows-only gotcha

Anything touching path conversion between shells could break the call too. Routing Windows-specific commands through a separate execution path — instead of passing raw paths straight through — cut this down a lot.

Honestly, not all of it adds up

I've had it stop right at the start, with nothing crammed in, nothing backgrounded, nothing pasted. No idea why. Even the model itself doesn't always know.

When none of it works

If all three fixes don't help, resetting the conversation from scratch usually does. Sometimes chasing the root cause costs more time than just starting fresh.

I used to panic every time this happened. Not anymore.

I write more about this kind of thing — solo dev + AI, the wins and the messes — on Threads.

I asked another AI to doubt my work. Twice in one session, it found real problems.

Miitobow | Building apps with AI — Wed, 15 Jul 2026 06:44:27 +0000

A while back I wrote about catching 3 bugs by making my AI review its own code as a skeptical stranger instead of trusting its own "done."

This time it happened again. Twice, in the same session, on two completely different kinds of work — and neither one was code.

First, a false alarm (so you know I don't cry wolf)

I was migrating my dev environment from one drive to another. Partway through, one folder was missing about 12,000 files. My assistant flagged it as a possible migration accident.

Turned out it wasn't. That folder was a virtual environment — a disposable toolbox rebuilt per project — and it was deliberately excluded from the move (it was sitting right there in .gitignore, with a note to rebuild it fresh at the new location). The files were missing because they were supposed to be missing; they were hardcoded to the old path and would've been dead weight anyway.

I checked before assuming the worst. Worth mentioning, because everything after this is the opposite: two cases where something looked fine, and wasn't.

Case 1: a security checklist with 3 holes I couldn't see

I'd just finished writing an audit checklist meant to apply across several of my apps — the rules an AI should follow when checking for security issues. I read it over, it looked solid, and I almost called it done.

Instead, I handed just the ruleset to a second AI and asked it to try to break it.

It came back with three holes:

Every finding was treated as an automatic blocker. That sounds strict, but it actually creates an escape hatch: the more annoying a finding is, the more tempting it is to just redefine it as "out of scope" and wave it through. A rule with no nuance quietly invites self-approval.
"Marked as resolved" didn't require evidence. Nothing stopped a check from being marked fixed just because it felt checked, with no actual proof attached.
Permission settings were graded on whether they were "enabled," not on what they actually did. A permission can be technically on and still be configured so loosely it lets anything through. You have to actually test access, not just read a config flag.

None of these occurred to me while I was writing the checklist. All three were obvious once someone read it who hadn't written it.

Case 2: a style summary that quietly drifted from its source

The next day, separate task: I'd read a style guide on writing clearly and boiled it down into a short set of rules — sentence length, paragraph breaks, that kind of thing.

I asked the same second-opinion process to check my summary against the original source, line by line.

Two things came back:

I'd written "around 20 characters per sentence." The source actually said "20 characters or fewer" — a soft suggestion turned into a hard limit I'd invented.
I'd added a second number — a 50-character cap for a "unit of meaning" — that didn't exist anywhere in the source at all. It was something I must have half-remembered from somewhere else, and it had quietly merged into my notes as if the source had said it.

And this wasn't a vibes-based objection — it was backed by an actual line-by-line count of the source document. Average sentence length: 13 characters. Only 4 lines out of the whole document exceeded 20, and one of those was a line intentionally written as a bad example.

Why does this keep happening?

Neither of these was code. One was a rule I wrote, the other was a summary I wrote. Same result both times.

My best explanation: when you're the one who wrote something, you're reading it through the intent you had while writing it. You're checking "does this match what I meant?" — not "was what I meant actually correct?" A number you copied from memory feels like it came from the source, because in your head, it did.

A second reader has no such memory to protect them. They just read what's actually there.

The takeaway

This isn't a one-off. It's now just something I build into how I work: nothing gets marked "done" until it's been read once by someone (or something) that didn't write it and has no stake in it being right.

Twice in one session, on two unrelated kinds of work, that one extra step is what caught it. I don't think that's a coincidence anymore.

I write more about this kind of thing — solo dev + AI, the wins and the messes — on Threads. I also wrote up the original code-bug version of this story here.

The same input gave me a different translation every time. The bug wasn't where I thought.

Miitobow | Building apps with AI — Tue, 14 Jul 2026 03:33:27 +0000

I kept re-running the exact same input through my translation app. Same code. Same model. Same everything.

And the word "machines" kept flipping between two different translations. Sometimes it came out as "機械" (machine). Sometimes as "あなたのPC" (your PC). No code changed between runs. No input changed either.

My first assumption was a race condition somewhere in my pipeline. It wasn't.

Where I actually looked

I checked the obvious suspects first: caching, threading, anything stateful that could make the same input behave differently on different runs. All clean.

So I went one level deeper, into how the model picks the winning word. Translation models score every candidate word and pick whichever scores highest. When I logged the actual scores for "machine" vs "your PC" on this input, they were almost exactly tied.

That's the part that mattered. When two candidates are separated by a tiny margin, the order floating-point operations get summed in can nudge the score just enough to flip which one wins. Same math, same inputs, different accumulation order between runs — and a near-tie flips sides.

Nothing was actually random. It was deterministic all the way down. It just wasn't deterministic in a way I could predict, because the thing that decided the winner was rounding noise several layers below anything I was testing.

The fix wasn't "make it deterministic"

Forcing strict floating-point determinism across an ML pipeline is its own rabbit hole, and not one I wanted to go down for one word.

Instead, I looked at why the tie was so close in the first place. "Machine" and "your PC" were close enough in meaning, in this context, that the model wasn't confident either way. So I widened the margin instead of trying to eliminate the noise: I swapped the input word choice from "machines" to "equipment," which the model was much more decisively confident about.

Scores stopped being close enough for rounding noise to matter. The flip-flopping stopped.

I want to be honest about a trap I almost fell into here: my first instinct was to just blanket-replace every instance of "machines" with "equipment" everywhere. That would've been wrong — in plenty of other sentences, "machines" was already translating correctly and consistently. A global find-and-replace would've quietly broken correct translations to fix one flaky one. I only changed it in the specific context where the tie actually existed.

What I'd tell someone hitting this

If the exact same input gives you different output on different runs, and you've ruled out caching, threading, and anything stateful — look for close scoring ties, not randomness. "Nothing changed" and "nothing is random" can both be true at the same time; the instability can live in rounding order underneath a scoring step you're not even looking at.

And once you find a fix, don't trust it from a single passing run. I re-ran the same input across multiple sessions before I believed the fix actually held, since the whole bug was runs disagreeing with each other in the first place — one clean run doesn't prove anything if the failure mode is "some runs differ."

I write more about building this translation app (and the bugs it keeps teaching me) on Threads.

I had my AI review its own code, and it found 3 bugs it had just written

Miitobow | Building apps with AI — Mon, 13 Jul 2026 07:38:17 +0000

Do you trust the code your AI assistant just wrote for you?

I did. More than I should have.

Lately, right after my AI (I use Claude Code) writes something, I ask it one more thing: pretend you didn't write this. Review it like a skeptical senior engineer who's never seen it before.

Last week, that one extra step found 3 bugs. In code the same AI had written minutes earlier. Bugs it hadn't noticed at all when it wrote it.

Turns out, the person who writes something can't see its flaws. And apparently, that's true for AI too.

The bug that started it

I'm building a Windows app that translates screenshots on the fly. Paste a screenshot, it OCRs the text and overlays a translation.

One screen type kept beating it: white text on a dark navy header. Buttons like "Sign up" or "Help" — completely skipped. Not mistranslated, just never even detected as text.

The cause: the OCR pipeline decided "dark background = ignore this region" and threw the whole header away before even trying to read it.

I asked Claude Code to fix it — detect dark regions, invert them locally, then run OCR. That part worked. "Sign up" and "Help" started translating correctly.

I thought I was done.

Then I made the AI doubt itself

Here's the habit: I never let the AI mark its own work "finished." Right after it writes something, I ask the same AI to switch roles — become a skeptical reviewer who's never seen this code, and rip apart the diff it just wrote.

This time, it found 3 real bugs in the fix it had just shipped:

1. "Anything long and thin must be a button"
The button-detection logic was missing a width check. A single thin vertical stroke of text got mistaken for a button edge — splitting words like "DASHBOARD" into fragments and making them unreadable.

2. The noise-removal rule was too aggressive
A rule meant to clean up small artifacts was matching a much wider range than intended, and it was quietly deleting text it should have kept.

3. Brightness was measured the wrong way
The logic deciding whether to invert a region measured brightness by looking at how much of a character's ink was bright — so a bold white letter (lots of bright pixel area) got misread as "this is a bright button," and the region never got inverted at all.

None of these were caught when the code was written. Everything looked like it worked.

Why does the same AI catch its own blind spots when you just... ask differently?

This is the part I keep thinking about.

The model that wrote the code and the model that reviewed it are the same model. Nothing changed except the role I asked it to play.

My best guess: writing code and reviewing code point your attention in different directions. When you're writing to satisfy an intent, you're checking "does this match what I meant to do?" Whether the intent itself was wrong barely enters your field of view.

Reviewing flips that. You start from "is this intent even correct?" — no assumption that the goal was right in the first place.

It's the same reason a second human catches a bug in code you just wrote, instantly, that you missed for an hour. You remember what you meant. That memory is exactly what blinds you.

One more thing: don't trust the review either

Switching the AI's role produces a lot of findings. Not all of them are real bugs. Some are intentional design choices getting flagged as "wrong." Some are just misreadings.

So I never apply a finding straight from the review. Everything gets triaged first: real bug, intentional, or false positive — with the reasoning grounded in the actual code, not a guess. Only confirmed real bugs get fixed, and only with the smallest change that doesn't break the original intent.

Skip that step and you'll end up thrashing perfectly correct code because an overeager review said so.

The actual takeaway

The person who wrote it can't see its flaws. That's not a human-only limitation — it applies to AI too.

So now, every time I have an AI write or fix something, I make it play a second role before I call it done: someone who's never seen this code, whose job is to find what the author missed.

Since I started doing this, I catch noticeably more bugs before a user ever does.

I actually use two specific prompts every time I do this — one to force the "skeptical reviewer" review itself, one to triage what comes back so I don't blindly apply every finding. If people want the exact prompts, let me know in the comments — I might put together something more detailed with the full toolkit.

I post more of this kind of thing (solo dev + AI, the wins and the messes) on Threads.