I agree, that was a weak analogy. Magnus stays employed because chess fans value watching humans compete, not because engines didn't replace his capabilities.

I've updated the post title to "Train with coding assistants like Magnus Carlsen trains with chess engines" to focus on the main point: the methodology. Magnus uses chess engines as sparring-partners to improve his game after matches. Same can be done by developers who will use coding assistants to level up their skills.

Thanks for calling this out.

This is advanced/cyborg chess in a nutshell (https://en.wikipedia.org/wiki/Advanced_chess)

Companies automate the parts that are commodity. On messy product work (drifting specs, integration, liability), human + AI + good process > AI alone. The machine proposes; the human sets goals, constrains risk, writes/reads tests. That combo ships faster and with fewer costly mistakes than letting an ai free-run.

Productivity replaces people, if you get more done from a team of 5 than your old team of 10 you generally fire 5 people.

Programmers have significantly higher unemployment than the general workforce today, but it’s hitting a wide swath of white collar jobs and that’s not going away. The industrial revolution replaced manual labor, so people moved to more mentally challenging jobs but AI can eventually replace anybody from CEO’s on down.

Or you keep your team of 10 and produce more things.

Demand isn’t doubling economy wide any time soon. So you might keep a team of 10 if you’re outcompeting a different team of 10 and getting all of them fired.

Even if you’re keeping your job expect huge downward pressure on wages.

I've never worked at a place where I have any shortage of work to do. Usually the roadmap is several years out.

Meanwhile, I’ve been let go several times for finishing major projects. Steady long roadmaps depend on slow moving projects.

Yes, chess engines review your games and point out blunders. They also suggest moves you'd never consider. Like when you're analyzing a position and the engine recommends a move that flips the eval from -1.5 to +1.8. Similarly, coding assistants might suggest a solution you'd never considered.

Both teach something new.

Time is measurable, but they're measuring the wrong interval. Speed to first draft means nothing if every subsequent change takes longer because the code is unmaintainable. The technical debt from slop compounds: you're not saving time, you're borrowing it at a terrible interest rate.

In the long run, the LLM that produces less slop per request wins.

I've definitely thought of that clip during my own debugging sessions.

Don't run "npm run dev" during development

(I'm running it myself in a separate terminal window, otherwise there is going to be too many dev servers running simultaneously)

Well, Apple declared it an obsolete product, I doubt they will start selling them again

i have the 12" or is it 13" (the current small one m4)

Thanks for the feedback! Most techniques actually work across all coding tools, though you're right I use Claude Code in examples since I'm using it mostly in real life. Which tool do you use? Happy to add more diverse examples.

Lately Google Jules. Because it has a free tier, and a nice workflow for prompt to pr.

I pulled ideas from posts by Simon Willison, Orta Therox, the Anthropic team, Indragie Karunaratne, Chris Dzombak, and others, then tried them on real projects with Claude Code and Codex CLI. This page keeps only what proved useful, organized by stage (planning → coding → debugging → tests → refactoring). New techniques and real‑world experiences welcome.