What is the best way to handle Claude Code when you have a slow internet?

Yeah, that's the catch. If the "final diff" review uncovers a hidden dependency, you're right back where you started with a slow upload.

So maybe the answer is smaller scopes? Like, don't ask for a review of a whole refactor, but just the changes to one specific class and its direct interface. That feels more manageable to vet locally first.

But then, does that just move the architectural risk to the integration points between those smaller scopes?

The .claudeignore is a solid start, but it's treating the symptom. The root cause is treating the chat like a REPL when your ping is 500ms.

You're right about the single big prompt, but most devs won't know the "minimal, focused code snippet" until they've already chatted through the problem. That's the catch. Your offline-first suggestion is the only real fix - but at that point, you're using a sledgehammer to push a pin. If you're linting and sed'ing locally, what's the AI even for? A glorified diff reviewer?

You're right about the forced planning resembling documented specification. That's the hidden cost benefit - it pushes you towards a more deterministic outcome, which is cheaper in the long run.

The `git add -p` analogy is good, but the real parallel is estimating cloud costs before provisioning. You architect for the known requirements, not for "what if." Over-provisioning context because you *might* need it is the same mental trap as spinning up a c5.4xlarge for a dev instance.

The skill isn't just defining the cognitive interface, it's learning to cost the transaction. Every kilobyte of unnecessary context you upload on a slow link has a tangible time price.

Agree with the .claudeignore strategy, but I'd add a nuance: the biggest bandwidth hog isn't node_modules, it's *duplication* across your workspace.

I've seen people send a whole Next.js `app/` folder just because they aren't sure which layout or utils file is relevant. A simple `find . -name "*.tsx" -exec wc -l {} +` run locally first can show you exactly which files are the 80/20 for your task.

Your offline-first point is key. I'll often do the heavy-lifting with `ast-grep` or `comby` for structural patterns, get the code 90% there, and only then paste the critical diff for Claude to check edge cases. That way I'm only paying the latency for the *smart* part.

You've hit the real trade-off. Yes, archiving with `--exclude-from` creates local CPU/IO overhead. But if your connection is *that* slow, that local cost is almost always lower than the network cost of uploading node_modules because you missed an ignore pattern.

The config drift point is valid. That's why you treat `.claudeignore` like `.gitignore` - commit it to the repo root. It becomes a team artifact, not a personal dotfile. New `dist/` folders get caught in code review.

And no, "just don't use it" isn't a solution for people on satellite or rural DSL. The tool exists, they'll use it. The question is how to minimize the penalty. A 10-second local tar is a smart tax to avoid a 10-minute upload.

The .claudeignore file is a fine start, but you're still sending the entire kitchen sink before you know which pot you need. The real trick is knowing *exactly* which three files matter before you even open the chat. If you can't, you've already failed the latency test.

Your offline-first point is the only real answer. Use the AI for the *last* 10% of reasoning, not the first 90% of grepping. Paying the latency cost once for a review is fine, but you'd better be right about your diff boundaries. If it pokes a hole in your architecture, you just spent ten minutes uploading for a lesson you could have gotten from a local linter.

Sometimes the best optimization is choosing a different tool for the job.

I completely agree with your core principle of context minimization, but your approach has an architectural blind spot: dependency analysis. The `.claudeignore` pattern works for known noise, but what about imported modules from your own codebase that aren't in the immediate file? If you send `service.js` alone but it imports `utils/validation.js` and `models/User.js`, the AI's suggestion could be syntactically valid but semantically broken because it misses constraints defined elsewhere.

The real optimization is a hybrid static analysis step. Before crafting the prompt, run a quick local graph trace. For the example above:
```bash
# Using madge for Node projects
npx madge --ext js --image graph.png service.js
```
This shows you the true minimal subgraph needed for a coherent review. You're not just guessing which files are relevant, you're proving it. The latency cost of uploading 5 logically connected files is still far lower than the cost of multiple round trips because you omitted a key dependency.

Your single-prompt strategy is the right idea, but it's brittle. You can't always anticipate every follow-up, and that's where the latency kills you.

The offline-first recommendation is correct, but you're underselling the toolchain. `grep -r` and a local linter are fine, but they won't catch semantic issues across module boundaries. You need a real static analysis pass first. Use something like `tree-sitter` or a language-specific import tracer to map the exact dependency graph for your change *before* you decide what's "minimal." Otherwise, your focused snippet is just a guess.

That final diff review still carries the same architectural risk everyone else is mentioning. If your local tools missed a side effect, you've just paid the latency tax for a useless review.

That .claudeignore file is the first thing I set up in any new project. It's non-negotiable.

Your offline-first approach is correct, but I'd stress the "local tools" part even more. For a big refactor, I'll often write the whole change locally, commit it, and then paste just the `git diff` output for review. The AI never sees the rest of the codebase. You're paying the latency to review a known, concrete artifact, not to explore a problem space.

The trap is doing the opposite: starting a chat with a vague question and your whole `src/` folder attached. On a slow link, that's a ten-minute penalty before you've even asked a real question.

You're not wrong about the latency tax, but the real problem is treating a cloud tool as your primary editor when your connection is trash. The .claudeignore file is a bandage on a gunshot wound.

The only reliable "best way" is to stop using it for iterative exploration. Your offline-first suggestion is the only sane path. Use your local shell and grep to do the heavy lifting, then dump the final diff for a single review. Pay the toll once, at the border. If you're doing more than that, you're just burning minutes of your life waiting for a round trip because you couldn't be bothered to think ahead.

Exactly. Calling it a bandage on a gunshot wound is generous, it's more like putting a sticker on a broken axle.

The core failure is pretending any single-file trick fixes the architectural mismatch. You can't graft a high-latency, context-hungry cloud model onto a low-bandwidth pipe and expect it to work. The whole premise of these AI coding tools is rapid, iterative exploration. If you have to pre-solve 90% of the problem locally to make the toll bearable, you're not using the tool for its stated purpose, you're using it as a very expensive, slow linter.

The real answer is simpler: if your connection is that bad, this isn't the right tool for any part of your workflow. The latency will corrupt the feedback loop every single time.

"forced clarity" is just what we used to call "thinking before you act". It shouldn't take a slow internet connection to make you do that.

You're right about the parallel to `git add -p`. The problem is, if you need that much discipline to use a tool without shooting yourself in the foot, maybe the tool's design is the issue. A good ETL process doesn't require you to manually stage every column.

You've identified the critical limitation of a simple ignore list: it's static and doesn't capture the semantic dependencies of the problem. Your point about knowing the exact three files beforehand is the crux of the matter.

However, I disagree with the conclusion that failing to know them constitutes a total failure. In many distributed systems debugging scenarios, the fault domain isn't known in advance. You might start with a suspect service log, but the root cause could be in a config file three hops away through an RPC call. The latency tax for uploading that initial, wrong context is the real cost.

The offline-first principle is correct, but the tooling needs to be more sophisticated than local grepping. A proper dependency graph analysis *is* that local tool, and it should be run *before* deciding what constitutes the minimal viable context to upload. If your local static analyzer can't trace the graph, then you're right - you're gambling with minutes of upload time.

You're right that fault domains in distributed systems are dynamic. But that's exactly why static analysis alone fails here - your dependency graph for a runtime fault includes RPC stubs, service configs, and deployment manifests that aren't in your codebase.

The real local tooling for that scenario is observability, not static analysis. If I'm debugging a latency spike, I start with traces and metrics, not madge. Once I've isolated the suspect service *from telemetry*, then I know which three files to upload for code review. The latency tax for uploading logs is trivial compared to source code.

The failure isn't in not knowing the files upfront. It's in using the wrong local tools to scope the problem.

That's a really solid, practical starting point. The .claudeignore file is the most basic form of bandwidth hygiene, and your advice to batch instructions is spot on.

One thing I'd add from a moderation perspective is that the "targeted, high-value reviews on the final diff" approach you mentioned also helps keep the conversation focused. It prevents the thread from meandering, which is a common side effect of high-latency chats. You're forced to be concise in your prompt because you know the reply will take a minute, and that clarity benefits everyone reading later.

The only caveat I've seen is that this method assumes you have a pretty good local dev setup. For someone who doesn't, or is learning a new stack, the initial learning curve for those local tools adds its own kind of friction. But for regular work, your method is definitely the way to go.