Summary of my impressions of working with Claude for week

Introduction

So I was slow to fully jump the bandwagon. I sort felt the train leaving the station so I did the rational thing - bought myself a Pro subscription.

I have been using both ChatGPT, Claude and Gemini casually since they all was first released. But more like a google replacement or in a coaching function, asking for advice or drilling into topics.

After talking to friends and colleauges I decided it was time to fully commit. Main thing I was running out of tokens using the free version for just my regular “googling” and “coaching” type of chatting.

I went for the Claude Pro subscription - signed up for a year. Once signed up I installed the Claude API on my development machines. This is what happened afterwards.

This is from a programming perspective.

TL;DR - The Summary

It is impressive. This feels like the first time I saw a code editor with syntax highlighting or when I got my hands on Whole Tomato Visual Assist back in the MS Visual Studio 6 days - but it’s like 10x that feeling.

It’s a tool - and a damn impressive tool! Get the tool, get used to it, learn how to operate it. It won’t go away - it will (most likely) change shape and form - but it won’t go away. So you better understand it and learn how to operate it. At least if you still have 10+ active working years within development.

Asking for help on help

This is one of the things I learnt before getting the subscription and it is quite powerful. Ask the AI how it works, how the AI want data structured, or how questions should be asked for most efficeny. It feels a bit odd at first, but it really helps. I’ve used this method a few times for various things. Like using AI to restructure a CV for a particular job. I gave it my current CV and then asked it, how I should restructure it for most efficient use and also to restructure part of my current as an example. I got back a document with instruction paragraphs. This was a bit of an eye opener, so I reused this methodology with my code as well.

Asking Claude to guide me

After some inital trial and error prompts and adventures I finally asked Claude how to work with it. In this case I was using the web chat interface, bascially my question was:

describe best practices to use Claude Code with a project

Then I drilled down from there, with targetted questions:

How do I get Claude Code to follow my coding conventions (naming, best practices, etc..)

The further

What is the best way to analyze and execute a task

I quickly learned that you run out of tokens and that there are several windows. At the current (June 2026) there are two token windows. One running like 6 hours (or similar) and another weekly token limit. I also quickly discovered that the context is limited. You can’t just go on - you need to ‘compact’ and ‘clear’ your context constantly.

Clearing the context is basically a memory wipe. Once done - the AI starts from scratch. In order to avoid introducing the project and patterns you keep a persistent summary between session. You ask claude to summarize for you. It is worth spending tokens here. And I would recommend you do this once your token limit hits 90-95%.. This prompt might look like:

summarize the work for this session and write it to CLAUDE.md so we can continue work in a clean session

One of my more important lessons was the ability to switch models. The more competent models use more tokens and therefor drains your tokens faster. Basically this is my rule of thumb:

• Advanced model (currently this is OPUS 4.6):
  • Analysis and splitting the work in to tasks
  • Summary
• Simpler model (currently this is Sonnet 4.6):
  • Execution of tasks according to the analysis

Workflow and tasks

I started out simple. Took an older project (text editor; https://github.com/gnilk/editor) which had been dormant for a while. I pointed Claude Code to it and asked it to figure out why it dead-locked. Took a while, but it found my bad try at using STL primitives for synchronization using conditionals. Historically I’ve normally just wrapped OS primitives and never really used the STL synchronization primitives - this was sort of my try - and I failed (well, skipping the RTFM part springs to mind - how hard can it be?).

With that out of the way I set out to push some improvement and refactoring tasks.

• Improving the C/CPP Language parser and syntax highlighter
  • Adding support for pre-procssing
  • Number formatting
  • Validating all key-words
  • Fixing a stack/recursion bug
• Built in terminal
  • Improving and extending my ANSI/Terminal parser
  • Refactoring my terminal front-end so it could handle full-screen apps
  • Tab completion
  • and more
• Workspace handling
  • Cleaned this mess up
  • Streamlined ownership
• UI
  • Refactoring and consolidating Splitter handling
  • Rewriting the view handling for the editor it self
  • Adding a HexViewer (and binding keys to switch)
  • Proper viewstate and editstate (cursor, selections, undo history, etc..)

And many more smaller items. All of this was done over roughly 14 days. In the beginning I was quite naive and gave simple instructions and then monitored execution.

can you fix <xyz> start looking in this file <abc>

While this works, it is quite inefficent and wastes tokens. I also didn’t quite understand how to use the different models and the pro/con of them. Luckily - you can ask, right?

Now I more or less do it like this:

• Step 1, using the advanced model to analyze the problem and propose a solution
• Step 2, iterate over the proposal (very seldom it’s good the first time)
• Step 3, ask the advanced model to write up a work-item list which can be independently verified and not break the build
• Step 4, Implement the work item list

Analysis and work items

This is the Step 1..3 break down with examples. I use the advance model for this. Personally this allows me to switch computers. I use two main work-stations.

• a laptop with macOS for commuting and when travelling)
• a desktop with Linux for evenings and weekend coding

So I need a way to keep Claude in sync between these machines, on the same project. This is what works for me.

Assume I am at my MacBook and I want to start a new task - following the four steps outlined above. For example, refactoring of the folder scanner and workspace view mechanism (this is a real task btw I did a few days back). I would start with something like:

I want to refactor the folder scanning path to use lazy evaluation. Currently it scans everything
from the project root. This doesn't work if there are too many files (like build artifacts and other cached items).
Think NPM repository. Instead I want ability to set a maximum scan-depth and it should stop there. We also need
to handle the UI so when a tree-node in the workspace view is not loaded it should request that node to scanned.
I want the workspace code to reuse the folder-scanner so we consolidate all similar code in one place.
Please analyze the problem and propose a solution.
Important folders are 'src/FileSystem' for the current folder scanner and the following sources 'src/UI/WorkspaceView.h',
'src/UI/TreeView.h'. Please note any other important files in the analysis document.
Create a specific branch for this refactoring before commiting any files.

The last line is important to me - I let Claude create/add/commit/push to git when stuff is working. I have guards saying it can’t commit until the working tree is compiling and unit-tests are all green.

Iterate until you are happy, like:

I don't want an interface for a callback - my pattern is to use callbacks if there 3 or less callbacks.
Instead, define the callback and a setter for it.
Secondly, you should not bring in dependencies from layers above.
Please refine the analysis with this input.

The above is very common. Claude will find some part of your code holding like a variable to something it needs and then reference it directly. Causing spagetthi dependencies to creep in all over the place.

Once you are happy, simply ask it to:

Summarize the analaysis in 'docs/folder-scanner.md' so I can continue working at a later stage.
Then write out a work-item log, one-line per work item, with references to the analysis.
Make sure each work-item can be independently tested and that it won't break the compilation of the project.
Then commit and push this work.

Now you will end up with a file containing an analysis and a work-item list. Depending on the size of your task you have now also exhausted one small token window and your context is full. Time to clear everything and switch model.

Note: Here is generally where I perhaps stop for the day/session whatever. And would move to another machine.

Execute the work-item list

This is where I switch to the less token-consuming model, for Claude that is currently (June 2026) Sonnet 4.6. I also begin with a clear context. Basically my initial prompt in this context would.

Read the file docs/folder-scanner.md, check references to code from the document. Propose a general outline
of your code-changes before starting on the work-item list.

I have found it quite a good habit to request a proposal of the code-changes. Specifically if the change is non-trivial. It often happens that I iterate the propsal a few times - these are details, but these details matter. As there are many ways to skin a cat…

Once you are happy, you can tell it to proceed with the work-list.

from our conculsion and then start implementing the work-items.

Here - it is important to ‘save’ (or summarize) any changes that happened because of the conversation. If the conversation was long, your context will be filled up and you might need to compact or clear - so saving it serves multiple purposes.

The rest of the prompting is more or less.

Continue on work item 2

If you now need to abort in the middle of a worklist Claude is actually very good at picking up the work by reading the refactoring summary and the work list. If you have to switch machines or clear context mid-session of a work-list I have found it helpful to tell Claude to also (besides the main work document) read the last X git logs.

TO BE CONTINUED…