Two Weeks With Claude Code

This started as a presentation I gave to our IT App Development team at the office. I’m sharing an adapted version here.

The Trigger

I wanted to see how far AI could actually take me. Not just in writing code, but in creative work too. Could I give it something ambitious and get useful results, or would the reality fall short of the demos?

So I gave myself two weeks to explore Claude Code, use it for real work, and see what happened.

Getting Started

Claude Code can meet you wherever you work:

CLI / Terminal — full control from the command line. I use this all the time
IDE extensions — if you wanna use within your code editor
Desktop app — standalone application. Sometimes I use this when doing research

First thing I tried was /init. It analyzed my codebase and generated a CLAUDE.md with dependencies, conventions, and test commands. You can extend CLAUDE.md further, at the project level (.claude/CLAUDE.md) or globally (~/.claude/CLAUDE.md). From then on, Claude had some project context before I even started asking questions.

Then i got into concept of context. Context works a lot like a conversation partner’s memory. Good context means sharper answers and faster iteration. Bloated context means slower, more confused ones. When a session starts feeling foggy, /clear wipes the slate, and /compact compresses a long conversation back within limits without losing the thread. It took me a few days to learn when to use each one, but it changed how usable long sessions felt.

Four things eventually made it click:

Skills — reusable workflows
Hooks — automated commands
MCP — connecting external tools
Model and thinking effort — matching the horsepower to the task

Picking the Right Model

The available models roughly fit different jobs:

Haiku — fastest and cheapest, good for simple tasks
Sonnet — the balanced daily driver for coding and agentic work
Opus — better for complex, long-horizon problems
Fable — for the hardest problems

Thinking effort works the same way, dialed up as the problem gets harder: Low for quick answers, Medium as the default, then High, XHigh, and Max when you want full reasoning depth and cost isn’t the concern.

At first, I didn’t really understand the tradeoff. I ran Opus for basically everything and noticed that I was burning through tokens way faster than I needed to.

That experience taught me more than the documentation did. Once I saw a cheaper model struggle with a genuinely difficult task, the tradeoff finally made sense.

What I Discovered

After a few sessions, three things started changing how I worked,

Skills. Matching a skill to a task meant I didn’t have to explain the same workflow from scratch every time.

MCP. Having Jira, Bitbucket and Sentry available in the same workflow reduced a lot of tab-switching and context copying.

Model selection. This ended up being the biggest lesson. Not every task needs the most powerful model, and using one everywhere gets expensive fast.

Programmer coding at a desk with several monitors Photo by Jakub Żerdzicki on Unsplash

Real Work, Real Results

This was the part I cared about most. Learning commands is interesting, but I wanted results I could actually point to. Here are some things I’ve done with it,

Performance and SEO

I gave Claude Code context about one of our web apps and asked it to find and fix some performance and SEO issues. Once it was done, I checked the Lighthouse score and saw an improvement of more than 50%.

What impressed me wasn’t just the number. Claude could actually inspect the codebase instead of giving me a generic performance checklist. Giving it the right context made a big difference.

Jira Ticket to Implementation

I also gave Claude a Jira ticket and let it read requirements from the ticket along with the codebase.

The biggest win wasn’t necessarily better code. It was removing the friction between understanding a requirement and starting the implementation.

This Presentation

This article started as the presentation I gave to our team. I generated the deck using /frontend-slides, without needing to manually design each slide.

That was interesting because most of my experiments had focused on software engineering. This showed me that the same workflow can help with communication and visual work too.

Extras

A few more things I picked up that didn’t fit neatly into the main story.

For token usage, I tried these:

rtk for reducing command output
tokensave for understanding codebase structure
headroom for compressing bloated conversations
ponytail for simplifying inputs and outputs

I also tried Superpowers, which turns workflows like brainstorming, planning, and debugging into reusable skills.

On the safety side, I used a Destructive Command Guard hook to block things like git reset --hard and rm -rf before they run. Once an agent can interact with your actual environment, those guardrails become pretty important.

What Stuck With Me

Two weeks in, five things kept coming back:

Start with /init
Write your CLAUDE.md early.
Manage your context like a conversation, not a dump.
Skills unlock the real magic.
Optimize your tokens.

I set out to answer one question: how far can this actually go? Two weeks wasn’t enough to find the ceiling. It was enough to stop wondering whether the hype was justified and start figuring out how to use it well.