There’s a growing trend in the AI-assisted coding world. People are posting their AGENTS.md, CLAUDE.md, or .cursorrules files on social media and writing blog posts about their “ultimate AI coding configuration”. The configs go viral. Everyone copies them into their own repos. Problem solved, right?
Not quite. Most of these files are stuffed with two things the AI can’t actually use: motivational philosophy (“demand elegance”, “no laziness”) and personal workflow habits (“always use plan mode”, “track progress in todo.md”). Neither tells the model anything about your codebase. A good agent configuration file should read like an internal onboarding doc, not a motivational poster. If yours could be dropped into any repo on GitHub and nothing would change, it’s time for a rewrite.
If you’re like me, you probably love the Claude models. But when you tried Anthropic’s Claude Code CLI on Windows (specifically inside WSL, where most of us prefer to do our coding), the experience felt completely broken.
It was borderline unusable. We’re talking freezing for several seconds at startup, hanging before every / command, and even stuttering while typing. Since coding with AI usually works better in a Linux environment compared to PowerShell (where AI tooling compatibility can be a bit hit or miss), feeling blocked from using WSL smoothly with Claude Code was a huge turn-off.
Well, good news: there is a ridiculously easy fix!
You build a project. It’s clean, well-structured, cohesive. You know every corner of it. Then life happens: the project moves to a different team for day-to-day maintenance. They bring their own style, their own habits. Things start to drift. Not dramatically, just… gradually. The codebase gets a little messier with every handover.
Now drop an AI agent into that codebase. Same story, amplified. It doesn’t know the history, the constraints, the “we do it this way because of that incident three years ago”. Every change it makes risks introducing side effects it can’t even reason about.
You’ve probably experienced this already: you ask AI to do something, it produces code that looks plausible but breaks your style, misses your constraints, creates subtle bugs. You fix it, try again, hit the same wall. And you start to wonder if this AI thing is all hype.
It’s not. But your codebase isn’t ready for it yet.
Lately, I’ve successfully self-hosted a decent private chatbot and even run a near real-time voice-to-text model locally. So I thought: why not try running a local coding model? I have a pretty decent gaming rig, so it should be able to handle it, right?
Well, it turns out: not really. I spent the whole weekend trying to set up a local coding model and ran into a pile of issues. The models are huge and hungry. Even with my gaming rig, I was barely able to get it running, and it was extremely slow. I ended up dealing with more technical issues than coding tasks.
One of the most common questions I get asked is: “Which AI model should I be using with GitHub Copilot?”
Open GitHub Copilot today and you are greeted with a dropdown menu that looks like a wine list. Sonnet? Gemini? Opus? GPT-5? 🤯 It used to be simple, but now it can be paralysing.
Which one is best? It depends on what you are trying to achieve, how complex the task is, and how you want to manage your credit usage.
My rule of thumb is simple:
Start cheap to think and iterate. Pay for certainty when the blast radius is big.
Voice assistants used to be simple, reliable helpers. Well, maybe not truly reliable. They weren’t perfect, but for years, you could count on them to set a reminder, add a calendar event, or play your favourite playlist. They quietly made life easier, even if they never lived up to the sci-fi hype.
