Claude Code can solve a lot of problems on its own, but it gets much stronger when the person steering it keeps applying their own problem-solving and software engineering skills.
This is part four of a series that walks through all 50 Claude Code tips in YK Sugi's claude-code-tips repo, and the first part of the intermediate group. It covers five tips that involve no configuration at all, only how you think: numbers 3, 30, 39, 40, and 35.
Across all five tips, you never hand over a whole problem and wait; you keep adjusting the size of the problem, the depth, and the pace as you go.
Why break large problems into smaller ones?
When Claude Code can't one-shot a hard problem, ask it to split the problem into smaller parts and see whether it can solve each one. If a part is still too hard, split it again, until every piece is solvable. Instead of going straight from A to B, you go from A to A1, A2, A3, and then B.
The repo calls this one of the most important concepts to master, and it is no different from traditional software engineering: the best engineers already know how to break problems down, and that carries over to Claude Code unchanged. The repo's example is a voice transcription system. The full requirement is heavy: let the user pick and download a model, take keyboard shortcuts, start transcribing, put the text at the user's cursor, and wrap it all in a nice UI.
The approach was to build separate programs. First, one that only downloads a model and does nothing else. Then one that only records voice. Then one that only transcribes a pre-recorded file. Each was finished in turn before everything was combined. I think this is the most memorable tip in the whole series, because it answers "what if Claude can't do it?" without any extra tooling.
What level of abstraction should you read AI-written code at?
There is no fixed level. For a one-off project or a non-critical part of the codebase, staying at the vibe coding level is fine, and you don't need to worry about every line. For more important code, you go progressively deeper: the file structure and functions, then individual lines, and sometimes the dependencies too.
And the choice is not binary. Some people say vibe coding is bad because you don't know what you are doing, but sometimes it is completely fine. Other times you need your software engineering skills to understand code at a granular level, or to copy a specific piece of code or an error log and ask Claude Code very specific questions about it.
The image to keep is exploring a giant iceberg. At the vibe coding level you fly over the top and look from a distance. Then you come in closer, switch to diving mode, and go deeper and deeper, with Claude Code as your guide. The skill lies in knowing when to dive, not in diving every time.
How much planning is enough, and when should you prototype?
Enough is when Claude Code knows what to build and how to build it. That means the high-level decisions come early: which technology to use, how the project is structured, where each piece of functionality lives, and which files things go in. The earlier those decisions are right, the better.
Prototyping helps you make them. A quick, simple prototype lets you conclude "this technology works for this purpose" or "that one works better". The repo's example is a diff viewer: the first prototype was a bash script with tmux and lazygit, and the second was a custom git viewer built with Ink and Node. The project ran into all sorts of trouble and nothing was published, but the lesson was clear: planning a little better before letting Claude write code makes it much easier to guide.
You still have to guide it throughout the coding, but letting Claude plan first is well worth it. There are two ways: press Shift+Tab to switch to plan mode, or simply ask Claude Code to make a plan before it writes any code.
What do you do when Claude overcomplicates the code?
Ask questions and tell it to simplify. Claude Code has a bias toward writing more code than needed, and sometimes changes things you never asked for. The code may still work if you have followed the other tips, but it will be hard to maintain and hard to check, and if you don't review it enough it turns into a nightmare.
You can fix it yourself, but you can also just ask Claude to simplify. The two most useful questions are "why did you make this particular change?" and "why did you add this line?" Some people argue that if you only write code through AI, you will never understand it. That is only true if you don't ask enough questions. If you make sure you understand every single thing, you can actually understand code faster than otherwise, because there is always an AI to ask, especially in a large project.
The same habit shows up in prose. Claude Code often summarizes the previous paragraphs in its last paragraph, or the previous sentences in its last sentence, which gets repetitive. Sometimes it helps, but most of the time you will need to ask it to remove or simplify that part.
How do you get braver in unfamiliar territory?
By solving problems iteratively and controlling the pace of that iteration yourself. Using Claude Code heavily tends to make people bolder with things they don't know well. The repo's example: on starting at Daft, the author spotted a problem in the frontend code despite not being a React expert. Instead of avoiding it, the author started asking questions about the codebase and the problem, and eventually solved it by knowing how to iterate with Claude Code.
A harder case came while writing a guide for Daft users: cloudpickle not working with Pydantic on Google Colab, and a separate issue in Python with a bit of Rust, where output didn't print correctly in JupyterLab even though it worked in the terminal. The author had never worked with Rust. The easy route was to open an issue and let other engineers handle it. Claude Code's first solution wasn't very good. A colleague suggested simply disabling that part, but the author didn't want a regression and wanted to find something better.
What followed was a back-and-forth: Claude Code proposed root causes and fixes, the author experimented, and when some turned out to be dead ends they changed direction. Throughout, the human set the pace: faster when letting Claude explore different solution spaces or parts of the codebase, slower when asking "what does this line mean exactly?" The result was a fairly elegant fix. My takeaway: the core skill is no longer knowing the answer in advance, but knowing when to speed up and when to stop and ask.
Which skill keeps its value?
Breaking problems down is the one to practice first. The other four tips rest on it: choosing a level of abstraction is choosing which piece deserves a deep dive, planning is splitting before coding, simplifying is cutting the pieces you didn't need, and working in the unknown is splitting an unfamiliar problem into questions small enough to ask.