Eighteen months is a long time to use one tool daily. After that much time with Claude - including six months using Claude Code for software development - the features that actually change output quality are rarely the ones that show up in onboarding.
The single highest-leverage change most daily users skip: the Projects feature. Most people treat each Claude conversation as disposable - paste context at the start, get output, close the tab. Projects lets you store persistent context (a codebase, style guide, past decisions, recurring reference material) that Claude loads automatically at the start of every new conversation within that project. No re-pasting the same brief every session. One practitioner who figured this out late estimated they'd wasted roughly 100 hours doing it manually first.
What Projects Actually Changes
The practical difference isn't just convenience - it's output quality from the first message. Claude with a fully loaded project context already knows your constraints: you use TypeScript, you prefer direct responses, the API returns ISO 8601 timestamps. Without that context, it guesses or asks. With it, it starts at a higher baseline and stays there.
For Claude Code users, Projects compounds the benefit further. Dropping your repository structure, coding standards, and architectural decisions into project knowledge once means every coding session starts with Claude understanding the codebase rather than requesting five minutes of re-orientation.
Custom Styles: Beyond Bullet Points
Custom Styles - Claude's feature for saving output preferences - typically get used for surface-level formatting: short paragraphs, no markdown headers, plain language. The more useful application is codifying an analytical framework you want Claude to apply consistently. If you always want Claude to identify the top three risks before giving a recommendation, that's a Custom Style, not a formatting preference.
The Claude Code workflow shift practitioners describe most often is learning to specify outcomes rather than steps. Claude Code performs better when given a clear end state and relevant constraints, rather than step-by-step instructions. Those who over-specify the implementation tend to get technically correct but awkward results. Those who describe what they need and why tend to get cleaner work - and the more project context is loaded, the less Claude invents patterns that don't fit the existing codebase.