How I use Claude Code (Senior Software Engineer Tips)

Most developers are using AI like a slightly better Google search, but as a senior engineer, that's not how you should be using it. Instead of asking random questions, I use tools like CloudCode to think through problems, explore solutions, and speed up parts of the development process that normally take hours. Hi friends, I'm Maddie. I'm a senior software engineer who previously worked at Google and interned at other big tech companies like Amazon, IBM, and Microsoft. I've been using CloudCode almost every single day for the past couple of months, and trust me, there's a huge huge difference between using CloudCode just as a fancy chatbot that writes code for you and using it as a true force multiplier. In this video, I'll break down exactly how I use CloudCode, the setup, the patterns, and the habits that actually make it useful. From breaking down complex problems, to writing code, to catching edge cases. And by the end of this video, you'll have a concrete workflow you can start using immediately. Let's get into it. Before we talk about how to use it well, let me first clarify what CloudCode truly is at its core. Cloud Code is a command-line AI agent built by Anthropic. Unlike a chat interface where you're copying code back and forth, Cloud Code can read your files, run commands, edit code, and work through problems autonomously, all while staying in the context of your real code base. Let's talk about the setup. So if you're using an IDE like VS Code or Cursor, you can install the Cloud Code extension. It lets you open Cloud Code directly inside your IDE, so if you have a file open in your editor, Cloud automatically pulls it into context. you don't have to manually tag it. You can also open Cloud Code directly in your terminal. When most people install cloud code, they immediately start throwing prompts at it. Don't do this. The first thing I do in any new code base is to run backflash init. This command makes cloud scan your project and auto-generate a file called cloud.md. Think of it as the onboarding document you'd write for a new engineer on your team, except this one's for your AI. A good cloud.md file covers three things, what the project does, where things live, and how work gets done. This means your tech stack, your rules and conventions, your key file paths, and your actual dev commands. Things like how to run tests, how to build, how to live. Without a plot.md file, every time you start a new plot session, it has to re-explore the codebase from scratch. That burns tokens and leads to mistakes. With a solid plot.md, for example, plot already knows your build command is mpm run dev and not yarn, which folders hold your API roots, already knows you use functional components with hooks, and you can include a description of who you are as well to help it code like you. One tip is to keep your plot.md file we need. I've seen people write enormous documents thinking more context is better, but it's not. Stick to the essentials, maybe 100 to 200 lines max. Anything more and you're actually diluting the signal. Your model selection criteria can be quite simple. By default, I run Opus. It's the highest quality model and for complex and nearing tasks, that matters. However, if you start hitting usage limits, Fog will automatically switch you to Sonnet, which is still very capable. You can also use Haiku for super lightweight tasks. Now let's talk about Claude Code's plan mode. In plan mode, before it touches a single file, Claude reads your code base and lays out a full implementation plan. So for example, which files will change, what the logic flow looks like, where the risks are. You can review that plan, push back on it, and even edit it directly before a single line of code gets written. When you skip planning, you often get code that technically works but solves the wrong problem or makes the right change in the wrong place. Then you're going to spend the next hour or more debugging it. I recommend you always go use plan mode before writing a single line of code. Next, let's talk about the backslash clear habit. Use it constantly. So every time you're done with a task and starting something new, type backslash clear. Claude's context window is finite, and when it fills up, the performance degrades immensely. Claude starts making weird decisions, lose tracks of constraints you set earlier, and waste compute trying to summarize all that stale history. A lot of people treat a Claude code session like a running conversation they never want to interrupt. The opposite is actually true. Each task should be a clean session with a fresh context. The up arrow key pulls up past sessions if you need to revisit something, but for new work, clear is your friend. Once your basic setup is solid, you can then start creating custom slash commands. Basically, save prompts that you can then trigger with a single keyword. live in a .clawed commands folder in your project written in plain markdown. So for example, I have a PR summary command that writes me a rear-facing PR description. What changed, why, any risks, and how to test it. The way to think about it is that anything you do more than once a week in your engineering workflow, there should be a slash command for. You should not be rewriting the same prompt every single time. Now let's talk about how to create a self-validation loop. This is about designing a validation harness, a set of automated checks that run after every change Claude makes so it can catch and fix its own mistakes without you babysitting it. Here's the idea. Claude code supports hooks, scripts that fire automatically at specific points in its workflow. What you want to do is wire up three things, your build step, your tests, and your type checker. So they run every time Claude saves a change. So why does this matter so much? Because Claude, like any engineer, makes mistakes. For example, it'll move a function and miss an edge case in the tests. While you can carefully catch that interview yourself, if you have a validation loop, WOD sees that failure output immediately, understands what broke, and fixes it, usually without you having to intervene at all. Setting this up maybe takes 20 minutes. In your cloud.md or your fux config, you tell cloud. After every edit, run the builds, run the tests, run the type check. If anything fails, treat it as a blocker and fix it before moving on. Once that's in place, you can walk away from a session and come back to green CI instead of a pile of errors to debug. The difference in output quality is dramatic. Now let's talk about what I wish I'd set up sooner, parallel cloud code execution. There are two ways to do this. The first is really simple. Just open plot code and multiple panels in your IDE and point each one at a different problem. For example, one handling a bug fix, another one drafting a new component. As long as they're working in separate files, they're not going to conflict. The second approach for more serious parallel work is Git work trees. A work tree lets you check out multiple branches of the same repo simultaneously in different directories, so each plot session has its own clean working tree and they can never step over each other. The workflow looks like this. I create a work tree for each feature or fixed branch, open a separate cloud code session in each one, and let them run while I do other things. Answer Slack, do a code review, have lunch. Then I come back, review what each session produces, and merge. Related to parallel agents but distinct enough to be worth its own mention is sub-agents. While parallel work trees are separate cloud sessions running independently, sub-agents are agents that your main cloud session spins up and delegates to, all within a single workflow. You define them in a dot-cloud. Each one gets its own name, its own set of lab rules, and its own focus instruction set. So instead of your main quad session trying to do everything, it can hand off a security review to a dedicated security viewer agent or a database query to a DB specialist agent. Each sub-agent runs in its own isolated context, does its job, and returns a result, keeping your main session clean and focused. Sub-agents are great to use when you have parallel tasks where each piece is self-contained and isolated work where you don't want one. one agent's reasoning bleeding into another's. Now let's talk about a concept that ties a lot of this together, skills. A skill is a markdown file that encodes a specific workflow. For example, how to do a code review, how to handle refactor, how to run a release, and makes it reusable across sessions, projects, and teammates. The difference between the slash commands we talked about earlier and a skill is scope. A slash command is a quick trigger. One prompt, one action. A skill is a full playbook. It can define multi-step logic, reference other files, and be invoked by sub-agents as part of a larger workflow. You can think of a skill as institutional knowledge that travels with your codebase. One more feature that's worth knowing about, especially as you get deeper into this workflow, is MCP servers, which stands for Model Context Protocol. MCP lets cloud code reach outside your local terminal and talk to external services. So for example, GitHub, Slack, databases, perplexity. You configure them once, And now when you tell Claude to pull comments from a GitHub PR and address them, it can actually do that. When you tell it to text Slack for the latest design feedback on a feature before writing code, it goes and gets that. With MCPs, Claude stops becoming just a code writer and becomes something closer to an autonomous engineer that actually operates in your full work environment. Before I wrap up, I want to talk about three tips that you should apply no matter which of these features you're using. First, be specific in your prompts. Vague prompts produce vague code. The more precisely you describe what you want, which... files to touch, what the constraints are, what the expected behavior is, the better clods output. Second, break work into small steps. It's tempting to hand-clot a massive task and hope it figures everything out. This will go poorly. Instead, create smaller-scope prompts that produce tighter, more viewable diffs. If a change spans 15 files and breaks three things, it's hard to know where to start fixing it. If it spans two files and breaks one thing, you're back on track in five minutes. Third, always follow this sequence. plan, execute, and review. So plan before you touch code, execute in small steps, and review before you merge. Every feature in this video, plan mode, validation loop, sub-agent skills, is really just a tool that enforces one of those three phases. Build the habit, and the tools start making a lot more sense. So to recap, set up your Cloud.md file, use plan mode before writing any lines of code, flash clear between tasks, build slash commands for your repeat workflows, wire up a validation loop, use parallel agents and sub-agents for isolated work, encode repeated workflows as skills, and always follow plan execute review. If you want to go even further, MCP servers are your friend. And that's all I have for you in this video. If this is helpful, hit that like button, hype this video, and subscribe. Thanks for watching, and I'll see you in the next one.

Most developers are using AI like a slightly better search engine.
But tools like Claude Code can do far more than just generate code.

But that’s not how senior engineers actually use AI.

In this video, I break down the exact workflow I use to make AI genuinely useful for coding, including how to structure your environment, manage context, and design systems that let AI catch its own mistakes.

If you're a developer trying to work faster and stay competitive in the AI era, this setup will completely change how you use AI for coding.

Here’s what I cover 👇
✅ Why most developers use AI wrong for coding
✅ What Claude Code actually is and how it works
✅ The importance of a clean CLAUDE.md project context
✅ Why Plan Mode prevents AI from writing bad code
✅ The clear habit that keeps AI sessions accurate
✅ How to create custom slash commands for repeated tasks
✅ Building a validation loop (tests, builds, type checks) so AI fixes its own mistakes
✅ Running multiple AI coding sessions in parallel with Git worktrees
✅ Using sub-agents and skills to automate complex workflows
✅ How MCP servers let AI interact with tools like GitHub and Slack

Timestamps
0:00 Most Developers Use AI Wrong
0:54 What Claude Code Is
1:38 Setting Up CLAUDE.md
2:59 Using Plan Mode
4:37 Building a Validation Loop
5:40 Running Parallel AI Agents
7:50 MCP Servers 
8:24 Practical AI Tips

about me
I’m Maddy, a senior software engineer (prev. at Google), with prior internships at Microsoft, Morgan Stanley, IBM, and Amazon. Sharing my journey here - thanks for watching 🤍

🔗find me on other socials
Instagram https://www.instagram.com/madeline.m.zhang/
LinkedIn https://www.linkedin.com/in/madelinemzhang/
Tiktok https://www.tiktok.com/@madeline.m.zhang

🔔 Subscribe for more tech career tips & coding content!

*disclaimer: views are all my own and do not represent any current / past employer(s)

#softwareengineering #aicoding #claudecode #developers #codingworkflow #programming #aitools #chatgpt #aiagents #mcp #llm #agentica #developerproductivity #softwareengineer #codingtips #techcareer #developerlife