Understanding Code with Claude

Claude Code helps me write code and acts as a reasoning partner for understanding complex systems. When working in unfamiliar code, I start by asking Claude Code to explain what the code does and how it works, including diagrams where helpful.

As I get a better understanding of the code, I have Claude trace specific scenarios through the codebase: "What happens if this config option is set but the feature flag is disabled?" It walks through the state transitions, surfaces edge cases I wouldn't have thought to check, and I end up with a behavior matrix I can turn into tests.

Git Worktrees for Parallel Work

This is the workflow change I'd recommend to anyone. Instead of constantly stashing and switching branches, I use git worktrees, so each branch lives in its own directory. Claude Code operates in whichever worktree I point it at.

The real value comes with stacked PRs. I work in chains of dependent PRs, a bug fix, then a feature built on top of it, then gating logic on top of that. When an earlier PR merges, I rebase the downstream ones.

Some specific patterns I use daily:

Conflict resolution. Conflicts are inevitable with rebasing stacked PRs. I tell Claude exactly how to resolve them: "Keep my changes for the test files, accept theirs for the generated files." It handles the conflicts without me re-reading every single one.

Branch verification. Before Claude Code does anything significant, I check what branch we’re working in. In a multi-worktree setup, this has saved me more than once from changes ending up in the wrong place. I have the branch name as part of my terminal prompt for easy reference.

ITerm tabs: Use them! I have a tab for each active Claude Code session. I use a column layout so I can quickly scan what I’m working on and which session needs my attention.

My iTerm setup with tabs for each active claude code session

MCPs are your friend: I use the datadog mcp to query logs, the Slack mcp to ping me in Slack when Claude Code needs my attention, the Playwright mcp to test front end changes, and more.

Skills: Claude.mds are good but skills are a game-changer when it comes to processes you repeat often. I have a skill that hunts for bugs in my code, one that cleans up stale local branches and worktrees, the code review plugin, and my new favorite frontend design skill. I appreciate being able to spin up nice looking UIs with minimal effort.

Claude: When in doubt ask Claude! Claude knows how to use Claude Code and what tools and skills it has available. It has the history of the session. If you have way too many active sessions and forget which is which, just ask Claude!

Claude code on the web/ in Slack: When I'm on the go and remember something I need implemented or someone reports a bug in Slack, I kick off a remote Claude Code session from either Slack or the web to implement my random idea or fix the bug and create the PR from the web UI.

Write, Test, Review, Iterate

My development loop with Claude Code is:

Write. I describe what I want with specifics, not "fix this" but "This function should add disabled items to the blocklist, but it's silently dropping them instead. Please fix." The more precise the problem statement, the fewer iterations needed. Steer Claude and reject its proposed edits if they are incorrect. You're still the engineer in charge. Claude is really good, but in many cases you have more context than it does.

Test. I start by asking what tests already exist and what they cover. Then I describe the behavior I want to verify and let Claude write the test. For complex code, that usually means a matrix of inputs and expected outcomes. I describe the expectations and Claude generates the full test suite.

Review. I have Claude self-review before pushing. I prompt "Use the code review skill on the code in this branch." It then invokes my code review skill and catches nil handling gaps, comment/code mismatches, test assertion contradictions, regressions etc. Once it’s addressed all issues, I review the code.

Iterate. I make updates to the skills and docs as needed, so Claude can do better the next time. More often than not, I make these updates by telling Claude to reflect on what we did and update the skills/ docs accordingly.

The models are improving fast enough that my workflow from three months ago already feels dated. What used to require careful hand-holding now just works. With Opus 4.5 & 4.6 I've been delegating larger chunks of work to Claude Code and letting it autonomously drive the full development cycle. Stay curious, keep experimenting, and be ready to let go of more than feels comfortable.

I've been using Claude Code a lot lately, and I continue to be both amused and impressed at how well its grep-based agentic search works. It seemed counterintuitive to me at first. RAG (Retrieval-Augmented Generation) is often talked about as the standard for AI knowledge retrieval. So why was this simple grep-based approach working so well?

The thing I didn't appreciate until recently is that a codebase is technically a giant DAG, where nodes represent a file, class, module, or library, and directed edges represent a dependency (e.g., file A imports a function from file B, so A depends on B). Having that built-in graphical structure makes them functionally equivalent to knowledge graphs for the purpose of code navigation and retrieval… even if the relationships are simpler and more limited in type.

By searching through the files, reading import statements and function implementations, Claude is able to "understand" the relationships in the codebase and pull the relevant snippets and files into its context.

The Difference with Documents

Traditional text files or documents don't inherently have this graphical structure. You may get some of it when one document references another, but most documents don't.

Without that graph structure, an AI agent has three options: read all file content into context to understand relationships (bloats the context window and is slow), build a knowledge graph on top of the files (notoriously hard to maintain and keep updated), or use RAG.

TLDR

Code already encodes its relationships in a graph. Imports, function definitions, dependencies... it's all there, explicit and parseable. When that structure exists, the agent can just follow it… much like how humans do when exploring a code base. No indexing overhead, no staleness when code changes, no security concerns about where an index lives.

For unstructured content like documents where relationships aren't explicitly encoded, RAG absolutely makes sense. But for code? The graph is already there.

Everyone told me I was doing it wrong. "You need to cast a wider net," they said. "It's a numbers game." But that approach has never worked for me. It's exhausting and inefficient.

About six weeks into my new job, I found myself reflecting on whether I'd made the right choice. I decided to grade myself against my own criteria from this post:

• Does this place have the steepest learning curve? Absolutely! So much to learn, so much value to add.

• Will I be surrounded by my people? Still early, but so far everyone I've worked with has been incredible at what they do with refreshingly low egos about it. Very high density of exceptional talent and just people I enjoy working with.

• Can I continue pushing the boundaries of what's possible with AI? Yes! The team I joined was my first choice when I was job searching particularly for this reason. We're at the intersection of product and research within a frontier AI lab that's focused on building AI safely and responsibly. I struggle to think of many other places that could check this box as well as my team does.

I've now been at Anthropic, my top choice, for three months working on features like file creation in Claude and my grading still stands. The truth is, the whole process started long before I sent those five applications.

Finding the right puzzle

I'll caveat upfront that this approach may not be feasible for everyone, and I appreciate that I had the luxury of being able to take time off work to rest and then dedicate focused energy to my job search.

I view the job search as finding the right puzzle. I see myself as a single, perhaps quirky, piece. My shape is defined by my strengths, the value I bring, and the environments where I thrive (or, crucially, where I don't). My entire goal is to find the puzzle where my piece can truly fall into place, contributing to the incredible, developing picture it's revealing.

This meant quality over quantity. I applied to five jobs and gave each one the attention it deserved.

My Job Search Framework

1. Tap Into Your Network (Strategically)

I reached out to people I knew and trusted and asked them what companies or sectors they were excited about and what working at these places was like. This wasn't about asking for referrals right away. It was about gathering information about the companies and their cultures.

Once I narrowed down jobs and companies that aligned with what I was looking for, then I reached out to my network to see if they knew of opportunities that matched.

I also used TrueUp to get notifications for jobs I was interested in. I found it had the best signal-to-noise ratio for what I wanted.

2. Journal Your Way to Clarity

This was probably the most valuable thing I did. Writing down and reflecting on my career helped me identify patterns. Identifying when I was happiest, what I enjoyed, what I valued etc. This clarity was especially important for Anthropic's culture interview, which requires you to have a deep understanding of your values and what's important to you.

I found that without this reflection work, I would have struggled to articulate why certain opportunities excited me and others didn't.

3. Build a Comprehensive Resume, Then Customize

I created a comprehensive resume braindump where I didn't care about page limits or formatting. I just wrote down all my past roles and everything I could remember that was significant. Then I used Claude (yes, really) to help me pick and choose what to showcase for each specific job.

I tend to get in the weeds and focus on what I did without tying it to why or the outcome/impact. Claude was incredibly helpful for reframing my accomplishments to highlight the right achievements for each role. This made a real difference in how I presented myself.

4. Build Interview Momentum

I started by interviewing with companies I cared less about to get the nerves out of my system and get a feel for what kinds of questions were being asked. This was more valuable than I expected. Companies seemed to have more involved processes than I remembered, with a wide range of interviews: LeetCode-style coding, speed coding, debugging, OOP, architecture design, project walkthroughs. It was all over the place.

I focused on one company at a time so I could prepare for whatever wildcard interview they had in addition to the standard coding, system design, behavioral, and leadership questions.

Out of five applications: I got rejected from two, I rejected two, and I accepted Anthropic.

5. Prep, Prep, and more Prep

Coding prep: I did 100 questions on Grind75 (39 easy, 60 medium, 1 hard) because 100 felt like a good place to stop. But when I first started, I quickly realized I needed a refresher on LeetCode question patterns. I signed up for Educative.io and worked through the coding portion of their personalized interview prep plan. I highly recommend this. After going through the topics there, I was able to breeze through the Grind75 questions and felt much more confident about coding interviews.

System design and storytelling: I used HelloInterview. I really loved the guided practice for system design interviews. Speaking and drawing my answers in a time-bounded environment felt more representative of actual interviews. I initially tried just watching YouTube videos, but they gave me a false sense of confidence. I thought I knew the material but struggled to reason through details under time pressure.

I highly recommend their delivery framework. It made it easier to focus on the core parts during interviews and helped interviewers follow my thought process. Their story builder was somewhat useful but a little clunky. What I appreciated was how it helped me narrow down to a few core stories and figure out how to piece them together to answer different questions and highlight my skills in a level-appropriate way.

6. Track Everything (Including Red Flags)

I kept a Google Doc where I logged information and outcomes from interviews with each company. If there were yellow flags, I noted them so I could get clarity during the interview process. If there were things I could improve upon in how I structured my answers, I noted those too so I could work on them for the next interview.

And if there were red flags, like the one interview where I walked away thinking "working with this person feels exhausting," I noted it and immediately pulled myself from the process. This might sound dramatic, but life's too short to ignore clear signals about culture fit.

Reflections on the Journey

Looking back, the biggest lesson is this: know yourself, and trust that knowledge. The time I spent journaling and clarifying what I actually wanted wasn't wasted. It was the foundation that made everything else work.

The "quality over quantity" approach only works if you genuinely understand what quality means for you. For me, it meant a steep learning curve, exceptional people, and the ability to push boundaries in AI. For you, it might be something completely different.

I'm excited to have found the right job for me and am looking forward to the journey ahead. If you're in the middle of a job search right now, I hope some of these strategies are helpful. And if you've found approaches that worked well for you, I'd love to hear about them.

Should I stick with the very early-stage startup world I knew so well? Or was it time to try something more established? The current hiring environment wasn't exactly encouraging, but I decided to put on my founder hat and focus on what I could control: figuring out exactly what I wanted and how I'd go after it.

Finding Clarity

I was having one of those meandering career conversations with my mentor when they dropped two pieces of advice that completely reframed how I was thinking about my search. These weren't groundbreaking revelations, but they helped me articulate what had been bouncing around in my head.

"You want the place with the steepest learning curve" and "Find your people."

Simple? Yes. But hearing someone else say it out loud made everything click into place.

What Actually Matters to Me

Once I had that clarity, I realized there were three non-negotiables for whatever came next:

• Staying in the AI Space

  I wanted to continue working in AI, and not just because it's the hot thing right now. I genuinely believe this technology is going to fundamentally change how we live and work. I wanted to be somewhere I could thoughtfully push the boundaries of what's possible with AI and build products that actually matter to people.

• The Steepest Learning Curve

  This one came straight from my mentor's mouth, but it resonated because it captured what I loved most about being a startup founder. As a solo technical founder, I was constantly getting thrown into domains way outside my comfort zone - go-to-market strategy, UX design, branding, fundraising. You name it, I probably had to figure it out on a Tuesday afternoon.

  That experience was incredibly valuable. I knew I brought this unique blend of technical expertise, product intuition, team leadership, and entrepreneurial thinking to the table. I wanted a place that would not only value that mix but give me room to keep growing and pushing myself into new territories.

• Finding My People

  This was the second piece of mentor wisdom, and honestly, it might be the most important one. I was going to be spending a significant chunk of my time with these people, I owed it to myself to make sure I actually wanted to work with them.

  I've learned that I do my best work alongside people who are incredible at what they do but have low egos about it. I was looking for folks who seemed grounded yet genuinely excited about the customers they serve and the mission they're pursuing. People who are comfortable admitting they don't have all the answers but have the drive to tackle bold problems anyway.

  Most importantly, I wanted to work with people who believe we'll go further together - where everyone's unique perspective actually gets heard and valued.

Once I had this clarity, I was able to focus on what actually mattered to me. Instead of getting lost in job titles or company valuations, I had a filter I could apply to any opportunity. Three simple questions:

• Does this place have the steepest learning curve?

• Will I be surrounded by my people?

• Can I continue pushing the boundaries of what's possible with AI?

Key Takeaways on Product-Market Fit (PMF)

1. PMF is Obvious in Hindsight but Not During the Journey. As you build, you may sense a shift in momentum when hitting certain milestones, but it’s usually only with time that you can tell if you've truly achieved PMF or just experienced a fleeting surge of luck. That said, PMF has multiple levels: starting with a small group of happy, engaged customers, progressing to consistently exceeding many more users’ expectations, feeling a strong “pull” of demand, and ultimately solving the problem effectively while achieving economic viability.

2. Most Companies Never Achieve PMF. That’s the reality of it.

3. Product-channel fit (PCF) is equally important but often overlooked. Nailing PCF ensures you're consistently reaching the right audience, increasing your chances of converting them into customers and solving their problems effectively. Closely related is Founder-Market Fit, which refers to the alignment between a founder’s background, skills, passion, and experience with the market or problem they’re tackling. When this fit is strong, it becomes easier to identify the right channels, craft compelling messaging, and spot valuable opportunities.

4. Measuring PMF: Quantitative vs. Qualitative. Quantitative metrics aren't helpful in the early stages due to low volume, you have fewer customers and less data points to analyze. Qualitative measures, focusing on how users feel and if your product exceeds their expectations, are more valuable. This is achieved by understanding your users' expectations and use cases. Watching their actions and behaviors is the most effective way to learn, followed by talking to them and asking the right questions.

5. Pre-qualify Your Users. This is crucial especially in the early days. Determine a good Ideal Customer Profile (ICP), big enough to have the problem but small enough for you to help consistently. Then, say no to everyone else.

6. Avoid Becoming Consultants in Disguise. This is such an easy trap to fall into, especially as an early stage startup. Protect yourself from becoming a consultant, especially with design partners. Ensure that any manual work you take on can be productized across clients and that these partnerships consistently create value.

7. Trust Your Instincts. They’ve brought you this far as a founder, so there’s clearly value in them. Your unique perspective on the market and your product comes from your experiences and interactions with customers and your target audience. Lean into that insight and let it guide you.that.

This illustration below of how PMF relates to exceeding user expectations was extremely helpful for me. It's worth noting that after achieving PMF, growth comes from increasing user satisfaction. User expectations continue to grow over time, and as a company matures, it can adjust factors that influence the growth rate at the cost of revenue.

Breaking Down the Syntax

String slicing in Python uses the [start:stop:step] syntax. Here’s what each part does when reversing a string:

• Start (:): Specifies the starting index. It defaults to the beginning of the string.

• Stop (:): Specifies the stopping index. It defaults to the end of the string.

• Step (-1): Determines the step size. A negative step, such as -1, means take one step backwards.

Let’s take the string a1b2c3 . To reverse it, we’d use:

>>> "a1b2c3"[::-1]
'3c2b1a'

The fun part is you can use the step size to extract just the numbers or just the letters from this string. Let’s explore:

Extract every second element (letters only):

>>> "a1b2c3"[::2] 
'abc'

Extract every second element starting from index 1 (numbers only):

>>> "a1b2c3"[1::2] 
'123'

We can use negative step sizes to extract specific parts of the string in reverse order.

Reverse and grab every second character (numbers):

>>> "a1b2c3"[::-2] 
'321'

Reverse and grab every second character starting from the second-to-last position (letters):

>>> "a1b2c3"[-2::-2] 
'cba'

Recently, a team member left the comment above on my pull request. It brought to mind a similar comment from an engineer at my previous job—a person whose opinion I valued. He had said that my code read like a story and was great to review.

This experience reminded me of a valuable lesson I learned early in my career, one that I sometimes overlook but is crucial: the importance of leaving positive feedback in code reviews. It can make such a huge difference to the PR author.

This is especially true for larger pull requests or ones where the author may have faced significant challenges. A simple "nicely done" or acknowledging an elegant solution or praising well-chosen names for variables and functions can boost a developer's confidence and make their day—naming, as we all know, can be particularly tricky.

Many developers, including myself, find submitting code for review to be a vulnerable experience, especially since reviews often have no face-to-face interaction. As a reviewer, it’s easy to focus solely on what needs to be improved, filling a review with suggestions and change requests. However, remembering the effort that went into the code can transform the review process into a more positive and constructive experience. Especially for more junior engineers, a thumbs up or “neat solution!” can go a long way in building confidence and camaraderie. It’s a small reminder that we’re in this together and we all win by writing better code.

If you couldn’t tell already, the compliment made my day because code readability is something I not only value but have spent a lot of time thinking about. Having worked in startups where product directions frequently change, I've seen how vital it is that the code reflects current assumptions and product state. In my previous role I joked that our code base contained all the hopes and dreams of our startup. Good readability leads to better quality feedback during reviews, and makes it easier for reviewers to focus on higher-level issues. They spend less time and mental energy deciphering your code, variable names, and code organization. Instead, they can think about how the code fits into the larger system and consider more complex scenarios and edge cases.

Moreover, readable code is easier to maintain. A well written pull request provides an effective way to share context, ensuring that team members understand the changes and can contribute to that area of the code more effectively.

For a comprehensive guide to effective code reviews and best practices, I highly recommend Google's engineering practices documentation on code reviews. I've used it as a guide throughout my career because it's simple, to the point, and thorough. I’ve adapted it to help create code review best practices and guidelines at the last few companies I’ve worked at, and now at Nexel.

Remember, kind words can be a superpower in code review, I’m still talking about one comment many years later! Have you ever received a piece of positive feedback during a code review that had a significant impact on you? Or perhaps you have tips on how to give constructive, positive comments? I’d love to hear it! Share your stories and suggestions in the comments below.