What a Day with DeepSeek Taught Me About How I Code

I spent a day coding with DeepSeek via Cline — partly out of curiosity, partly because I finished my $217 a month for Claude Code in a week and the $300 extra that I spent disappeared within 30 minutes. Six things became clear. Most of them weren't about DeepSeek at all.

My disk was silently drowning in Cline terminal chats

I only found out because iCloud tried to sync my desktop files and told me the disk was full. Forty gigabytes across four Cline chat sessions. Cline accumulates memory aggressively when you don't close terminal windows, and I hadn't been closing them. I hadn't even thought to check.

I asked Claude to diagnose it. It found the cause quickly: open terminals holding context that never got released. I shut them down, watched the memory drop, and then kept going. While I was in there, I deleted .venv, cache folders, and node_modules across 88+ codebases that I'm not actively running every day. Old downloads. iOS simulators I hadn't used in months.

The cleanup took a few hours and recovered more space than I expected. It also forced me to look at what I've actually been building — 88+ codebases worth — and ask which ones still need to exist at all.

DeepSeek is not Claude, and that gap matters for real work

For basic things — generating boilerplate, small isolated tasks, quick lookups — DeepSeek held up fine. It was usable. But the moment I pushed into anything cross-codebase, things got worse, not better. It doesn't infer intent the way Claude does. It needs existing code snippets to copy from or it wanders. It requires more manual supervision at every step.

Cross-codebase work with DeepSeek actively made things worse. Not in a catastrophic way, but in the slow, frustrating way where you spend more time undoing than building. I had to stay much closer to the output, catch more errors, re-explain context I wouldn't have had to explain twice with Claude.

That's not a knock — it's just a different tool at a different capability level. Knowing where the gap is matters. Using it for things it can handle and not asking it to do what it can't is a reasonable strategy. But it's not a drop-in replacement for anything that involves reasoning across files or holding a larger mental model of what you're building.

The surprisingly good part: slowing down inside the code

Here's what I didn't expect. Because DeepSeek needed more from me — more context, more oversight, more correction — I ended up spending more time actually inside the code. Reading it. Understanding what was happening. Running commands myself instead of watching an agent run them.

It felt like going back a year. And for one day, that was genuinely good.

I'd been moving fast enough that I'd started to lose track of my own systems. Letting the AI hold too much of the understanding so I didn't have to. That's fine until something breaks and you don't know where to look. A day of going slower, seeing the boilerplate, actually following the logic — it reminded me what it feels like to know what you're building, not just that it works.

I wouldn't want to work that way full-time. But the day was worth it for that reason alone.

The structural problem: $200 in seven days won't scale

The real issue isn't which model I'm using. It's how I've been using them.

One endless context window per codebase, session after session, until Claude loses the thread or I hit a billing ceiling. I documented, I structured,I wrote plans. But the accumulating conversation still got longer with each text I wrote into it.

That approach worked perfectly for me and very successfully. But the costs did not allow me to continue my approach- unfortunately :D.

What I'm switching to: proper .claude files as structural frameworks per codebase. Rules, plans, mistakes, learnings, progress notes, documentation — written by the AI with every meaningful change, so the next session can start with real context instead of trying to reconstruct it from a 40,000-token conversation. Sessions that end when a feature is done, not when I just feel of adding a new session or run out of credits. A hard habit of closing terminals and resetting between sessions.

I'm also consolidating where it makes sense. Some of those 88+ codebases should be merged. Some should be archived to GitHub with secrets saved separately and then deleted locally. Keeping dead projects on disk costs attention, not just storage.

What this actually changes about how I build

It feels more like work now. There's more setup per project. More intentionality about when to start a session and when to end it. More time spent writing documentation that I would have skipped before because the AI "already knew" the context from the conversation above and I saved it somehere else too.

But that's the adaptation. These tools keep changing — pricing, capability, context limits, how agents handle memory. The builders who stay effective aren't the ones who found one workflow that works. They're the ones who adjust when the ground shifts.

The ground shifted. Forty gigabytes told me that quiet clearly.

This week: I'm setting up .claude files in the codebases I'm actively working in. I'm picking a session length that fits a feature, not a week. And I'm keeping the terminal habit — close it when the session ends, every time, without exception. And then - let's see how that re-structuring pushes down my costs, still letting me have fun and keep letting me produce the results I saw before.