I compared my Claude Code workflow to a beginner's, and some of my habits were making things worse

Published Sep 30, 2026, 4:00 PM EDT Mahnoor Faisal is a tech journalist covering AI and productivity tools with bylines at XDA, SlashGear, MakeUseOf, Laptop Mag, and Android Police. She's been writing professionally since she was sixteen, and has since penned hundreds of articles. This includes in-depth coverage of AI tools like NotebookLM to breaking news across the AI space. Her passion for technology started when she received her first iPod Touch (4th generation) on her 8th birthday, and she's been deep in the tech world ever since. Currently pursuing a degree in computer science, Mahnoor brings both a journalist's eye and a technical foundation to her coverage of how AI is reshaping the way we work and learn. Initially, you'd scroll through social media (or Google) and come across the occasional AI tip or clever prompt someone swore changed their workflow. Occasional is, well, no longer the word I'd use. Now, every other person is a self-proclaimed AI expert. You'll find endless advice on how the right prompt should be structured, what features should be enabled and disabled, which tools you absolutely need to install, and which workflows will supposedly turn an AI coding agent from decent into indispensable. Now, I'm someone who puts on two hats when I'm testing these tools. I'm either using them as a regular user trying to get work done with them or as a journalist who writes an insane amount of articles daily on AI trying to look for something worth writing about. The first version of me is naturally curious about every new trick, plugin, workflow, and “you’re using it wrong” post I come across. The second just wants Claude Code to do the job well without turning the setup itself into a project. I've now reached a point where those two versions of me are starting to clash. My Claude Code setup has accumulated enough extras over time that I can no longer tell which ones are actually helping and which ones are just there because someone, somewhere, convinced me they were essential. So I decided to strip things back and compare my usual setup against something much closer to what a beginner would use. I was keeping far too many MCP servers around More tools, more problems I've talked a bunch about how one of the best ways to bring AI into your actual day-to-day workflow is by connecting it to the tools you use every day. Most AI tools, including Claude Code, give you two ways to do that. You can either rely on built-in integrations where they're available, or connect external services through something called Model Context Protocol (MCP). Well, I sort of went overboard with MCP servers. You can't blame me, though! Once you realize how many services can be wired into Claude Code, it's very easy to start treating every new connection like an upgrade. At one point, I had MCP servers hooked up for practically everything I could think of. There were community-built ones for NotebookLM, connections for tools like Adobe, Canva, Notion, Slack, and Gmail, and then all the more obvious developer-focused ones for GitHub, databases, Vercel, and Playwright. I even had some tied into tools I use for meetings, like Read AI. The problem is that more connections don't automatically make Claude Code better. Every server adds more tools Claude potentially has to choose between, and when several of them overlap, that can make tool selection messier rather than more useful. Before Claude Code's Tool Search started deferring tool definitions until they were actually needed, this could also eat a huge chunk of context before you'd even typed a prompt! I kept adding memory layers Claude Code didn’t need Turns out, forgetting can be useful Speaking of MCP servers and adding more, memory was another area where I fell into the same trap. I figured the more Claude Code remembered about my projects and previous sessions, the better it would get. So I ended up with tools like claude-mem and claude-memory sitting on top of Claude Code’s own built-in memory features. Not only were these memory-related plugins contributing extra instructions, Skills, and agents before I’d even typed a word, the bigger issue was the usefulness of that memory itself. A memory system can preserve something that was true three sessions ago but no longer reflects the current state of a project. At that point, Claude has to spend time reconciling what it remembers with what’s actually in the repo, and there’s always the risk that stale context nudges it in the wrong direction. Besides, a lot of the tasks I'd use Claude for would be in the same directory, but there really weren't that many useful connections between them. Just because two sessions touched the same project didn't mean context from one was going to help with the next. In a lot of cases, it was simply more information for Claude to sift through! I was stuffing far too much into CLAUDE.md My instructions needed instructions I've written a lot about CLAUDE.md files. They're one of the easiest ways to shape how Claude behaves across a project and, as someone who has gotten tired of Claude Code forgetting my instructions, I naturally kept adding more to mine. Coding conventions, workflow preferences, reminders, edge cases, things Claude got wrong once that I never wanted it to get wrong again, and so on. You'd genuinely find everything in there. Unlike MCP servers, the CLAUDE.md file is something that's carried into the project context every time, which means bloating it has a much more direct cost. I started noticing that the longer the file got, the less reliable some of those instructions became. Important rules would get buried among dozens of things that had nothing to do with the task at hand, old guidance would stick around long after it stopped being relevant, and instructions written for one kind of work would bleed into completely unrelated tasks. That lines up with Anthropic's own guidance too. It recommends keeping CLAUDE.md files relatively short, since longer ones consume more context and can actually hurt instruction adherence! So, I've gone back to the basics of using mine for the things Claude needs to know every time rather than as a permanent archive for every preference I have. Not every Claude Code task needs Plan mode I was planning two-minute tasks like product launches Claude Code's Plan mode is something I've always appreciated. Even when a good chunk of the developer community seemed to be against it just a few months ago, I still liked having Claude stop, think through what it was about to do, and give me a chance to catch a bad approach before it touched anything. The problem is that I started using it almost by default. No matter what task I was opening Claude Code for, I'd automatically switch to Plan mode before sending the prompt, even when the job in front of me was simple enough that Claude could have just inspected the files and gotten on with it. In cases like the above where the task was super simple, I was essentially paying for an extra round of thinking without getting much in return. Claude would spend time outlining a plan for something that only needed a couple of edits, then go ahead and make those same edits anyway. While tips you'll find on the internet can absolutely help you get more out of Claude Code, blindly piling every “advanced” tweak into your setup isn't the same thing as making it better. Given that I audit my setup fairly regularly, the examples above are still fairly modest compared to how cluttered things could have gotten. However, they're enough to make the broader point clear. In a lot of cases, the better setup is simply the one that gives Claude exactly what it needs and nothing more!