We’re about to learn a painful lesson about delayed gratification in software engineering.
New data from China, 26,811 students tracked January 2023 through June 2025. Students using AI for homework saw their scores jump 20 percent. Completion time dropped nearly half. They aced the assignments.
Then exam season came. Those same students scored 20 to 40 percent worse when they couldn’t use the tool.
The homework phase is over. The exam phase is coming.
We’re doing this in software right now. Vibe coding feels incredible. Features ship fast. Nobody’s asking what happens in Month 18 when the original dev has left and nobody understands the codebase.
Commercial pilots fly with autopilot for most of every flight. They’re required to maintain manual flying proficiency regardless. If the system fails mid-air and the pilot can’t take over, people die.
Most teams using AI right now have forgotten how to fly manually. They’ve become passengers in their own systems. The autopilot flies, nobody checks instruments, and the first sign of trouble will be a breach notice or outage.
Three rules:
- Command the mission. Define architecture before prompting. Ambiguity kills in code and in flight. Delegate selectively. Offload mechanical work. Keep design and security reviews human. Verify everything. Audit before production.
- Never trust the automation without checking instruments.
- Quick wins feel good. Sustainable engineering feels boring. Boring keeps systems standing.
Organisations surviving the next two years won’t ship the fastest. They’ll be the ones who remember how to fly without the aids.
people insisting that you actually be skilled, independently of your tools, doesn’t make them Luddites. Rather, being unable to do so makes you a phony.
Local models on a gaming PC are already a viable replacement for a Claude subscription, and are rapidly improving, so the idea that we will have powerful open models running on our phones isn’t at all far-fetched. It’s exactly the same situation as with a calculator like you said.
I wouldn’t call 48GB of VRAM a normal gaming PC, and even with that memory you’re not getting claude intelligence or performance. It’s still much more viable than ever before though. Are you running local models with limited vram with good results?
I have a 7900 XTX with 24GB of VRAM where I am running Qwen 3.8 27B at 4 but quant with 200k context. I traded in my RTX 3070 and got it for around $700 recently. That model performs pretty similarly to Claude Sonnet 5 in performance for coding and certain other tasks and it “feels” similar to Sonnet 5 that I use as a daily driver at work. I was running Qwen 3.6 35B-A3B on the 3070 before and I still run it on my server with a 4060 and 32GB of RAM, and that model is more like Claude Haiku.
I expect 3.8 35B-A3B should be released pretty soon and provide a nice bump in performance.
I regularly follow this guy’s YouTube channel, and his latest video is about running a 177B model on his RTX 3060 via SSD offloading and getting Opus-like performance for certain tasks: https://m.youtube.com/watch?v=IH8XmxiwliQ.
Supposedly, open weight models that run in a data center are like 4 months behind the frontier at this point, and what can run on a gaming PC is progressing rapidly as well while the exponential gains at the frontier have largely turned into incremental gains at this point.
Maybe this is good enough for small projects but if you deal with a large codebase the small context starts be becoming a problem. In my day job I frequently keep maxing out the 1M context of Opus and Fable when I am dealing with any mildly complex task. I can’t imagine how a fully local setup could even start being viable on my 16 GB GPU. And yes I know about RAM offloading and it is really damn slow, at least from my own tests.
This might be the case for an absolutely massive codebase where code files are also huge. Even with Claude, though, you’re supposed to compact regularly well before you hit 1M, or you’re otherwise paying a higher price for the oversized context. That generally means breaking down the work into smaller tasks, which is a useful practice anyway. I also find it useful to have the agent write any detailed info that will help needed later to a markdown file that can be re-read after compaction and r in a new session when needed.
I’m mostly working with smaller, personal codebases locally, though. With my 24GB GPU, I hit a hard wall with my configured 200k context and have to compact in OpenCode to continue, which I don’t mind. I do have to micromanage context to a higher degree than with Claude, though, since Anthropic will gladly charge a higher price when your context gets large instead of cutting you off.
Yes, I do that a ton. And yes, I am aware of the additional cost for when the context exceeds 150K. Still though, I try to avoid compacting too much because I found that sometimes the agent starts chasing its own tail. Also, the more of the codebase you can fit in the context the more you benefit from the cache. If you are doing a large refactoring job on a legacy codebase it really helps.
This is great info! I’ve been using OpenCode Go because I only have 16GB to work with and their limits are pretty generous. Looking forward to tiny, competent local models. Thanks o7
I’m going to stick with OpenCode Go, but the available models keep getting more expensive and the DeepSeek peak hours is annoying to deal with
The 0.4.0 release of llama.cpp just added the n-cpu-ffn flag for offloading weights for dense models to the CPU to complement the existing n-cpu-moe flag for MoE models. If you have a 16GB GPU and some extra RAM to spare, you might even be able to run Qwen 3.8 27B at a usable speed after some experimentation. I don’t own a 16GB card, so I haven’t tested it myself, and it might not work as well as I am imagining.