DEV Community: Gjøran Voldengen

I Stopped Reading Diffs. Here's What I Review Instead.

Gjøran Voldengen — Mon, 30 Mar 2026 06:47:00 +0000

AI coding tools made me 3x faster at writing code. But I'm not shipping 3x faster. I spend more time than ever waiting for reviews and handling review feedback. The bottleneck moved.

This is the second article in a series about how I use Claude Code. The first covered persistent execution plans and external memory.

Code Review tools handle the automated side well. Claude Code's built-in review dispatches multiple agents to catch bugs and flag style issues when a PR opens. That's useful, but it's not where the time goes. The time goes to the human review cycle: giving thoughtful feedback on a colleague's design decisions, responding to comments on your own PR, the back-and-forth that turns a draft into something mergeable. Some of that is pure wait time: a PR sits idle while reviewers are busy. The skills in this article speed up the other part, what happens when you actually sit down to review or respond.

The answer isn't to review faster. It's to change what you're reviewing. Instead of reading diffs line by line, I review Claude's assessment of the changes in context of the full codebase. I focus on whether the analysis is right, whether it missed something, and whether the design makes sense. Two custom Claude Code skills handle the mechanics, one for each side of the review cycle.

Reviewing others' PRs

I run /gh-review-pr owner/repo#123. Claude checks out the PR branch, reads the diff with full codebase access (it can follow imports, check how changed functions are used, and understand how the PR fits into the larger architecture), and presents findings grouped by severity:

Must fix
- src/api/handlers.go:47: Missing auth check on the new endpoint.
  All existing endpoints use requireAuth middleware.

Should fix
- src/api/handlers.go:62: Similar pagination logic exists in listUsers.
  Consider extracting a shared helper.

Nit
- Test name on line 15 could be more descriptive.

Praise
- Clean error handling throughout. The custom error types are well done.

The most useful thing the skill does is search the repo and the broader GitHub org for prior art before forming its review. If someone adds a caching layer, it checks whether there's already an established pattern elsewhere in the org. This catches the "we already have a way to do this" issues that are invisible from a diff alone, and it's the biggest gap in existing review tools, including the built-in ones.

That cross-repo context is what makes reviewing at a higher level possible. I'm not scanning the diff for problems. I'm reading a structured assessment and deciding whether the analysis is right, whether it missed anything, and which findings are worth posting.

A few other details that compound over time. If I'm the PR author (self-review before requesting others), the skill detects that and keeps findings in the conversation instead of posting comments on the PR. If I've already reviewed and the author pushed fixes, it focuses on what changed since my last review rather than re-reviewing everything. I confirm which comments to post and what review action to take. Claude submits them as a single batched review.

Responding to review feedback

The other side of the bottleneck. Someone reviewed my PR and left comments. Before this skill, handling that meant reading each comment, context-switching to the code, making the fix, writing a reply, going back to GitHub to resolve the thread, then doing it again for the next comment.

Now I run /gh-review-respond. Claude reads all unresolved threads and presents them in three categories:

Fix needed (2)
- @sarah: "Missing null check on line 34" → add guard clause
- @sarah: "This query needs an index" → add database index

Discussion (1)
- @sarah: "Why not use the existing UserService here?"

Disagree (1)
- @sarah: "This should be a separate microservice"

The categorization is the key step. I review Claude's assessment: yes, fix those two, they're real issues. The UserService question needs context, so I explain my reasoning and Claude drafts the reply. For the microservice suggestion, I disagree. The current approach is simpler and we can extract later if the need becomes clear. Claude writes a response that acknowledges the concern and explains the tradeoff.

Getting the tone right on disagreements matters. A dismissive response can derail a productive review. The skill handles the diplomacy; I focus on the substance.

After I confirm, Claude applies the code fixes, replies to each comment on the PR, and resolves all addressed threads in a single batch. Then it commits. One detail that matters more than you'd expect: for human reviewers, it always creates a new commit so the reviewer can see exactly what changed. For bot reviewers (like Copilot), it squashes into existing commits since nobody needs those diffs.

The mechanics change. The judgment doesn't.

These skills automate the mechanical parts of the review cycle: reading diffs in context, posting comments, resolving threads, choosing commit strategies. What they don't automate is the judgment. Deciding that a missing auth check is a blocker but a naming suggestion isn't. Recognizing when feedback improves the design vs. when it's a preference. Knowing when to push back and how to frame it. The time I used to spend on mechanics, I now spend on those decisions.

In the first article in this series, I described the core pattern as "the edge is judgment, not config." The same applies here. The skills handle the cycle. The decisions are still yours.

I've published both skills at claude-review-skills. If your review workflow is different, or you review in a domain with specific requirements (security, API compatibility, accessibility), Claude Code's /skill-creator can build custom review skills from a description of your process.

I'll cover more patterns in future posts.

Claude Code Doesn't Remember. Here's How I Fixed That.

Gjøran Voldengen — Mon, 09 Mar 2026 09:29:28 +0000

Claude Code is remarkably capable. It can read codebases, write code, run tests, create pull requests. But it struggles with continuity. You can resume a conversation with claude -r, but as conversations grow longer, auto-compaction drops earlier context, token costs rise, and response quality degrades. Finding an old conversation is surprisingly hard, too, since Claude Code's conversation management is minimal. The result: complex tasks that span multiple sessions tend to lose their thread.

Over the past several months, I've built two patterns that changed how I work with Claude Code. The first turns multi-step tasks into structured execution plans that survive across sessions. The second gives Claude persistent knowledge about any codebase, even repos you don't own. They're simple to set up, and they compound over time.

Plans that survive across sessions

Real work rarely fits in a single conversation. A feature might span several files, require multiple commits, and take days. Claude Code starts fresh every session, so you lose the thread. You end up re-explaining what you've already done, what's left, and what decisions were made along the way.

I solved this with GitHub issues as execution plans, managed by a set of custom Claude Code skills (I've published these skills at claude-plan-skills).

The workflow has four stages:

Create a plan (/gh-create-plan): I describe the work to Claude, and it creates a structured GitHub issue with a description, steps as checkboxes, and relevant links. The issue becomes the single source of truth for the task.
Implement the plan (/gh-implement-plan): Claude reads the issue, presents the steps, and works through them in order. After each step, it commits the changes and checks off the checkbox on the issue. If something is unclear, it stops and asks rather than guessing.
Update the plan (/gh-update-plan): As work progresses, decisions change, or new information surfaces, the plan issue is updated with session notes. A new conversation can pick up exactly where the last one left off.
Close the plan (/gh-close-plan): When the work is done, the issue gets a summary and is closed. It then serves as documentation: what was built, why, and what decisions were made along the way.

The plan isn't a one-shot document. I typically run /gh-update-plan several times before implementation starts, refining the scope, adding decisions, and updating steps as the approach becomes clearer. By the time I run /gh-implement-plan, the hard thinking is already done.

Here's a simplified view of what a plan issue looks like:

## Description
### What
Add a new `validate` subcommand that checks config files for syntax errors before deployment.

### Why
Users currently discover config errors only at deploy time, which wastes CI minutes and blocks releases.

## Steps
- [x] Add CLI argument parsing for `validate` subcommand
- [x] Implement config file parser with error reporting
- [ ] Add unit tests for valid and invalid configs
- [ ] Update help text and README

The checked boxes show where a previous session left off. When I start a new conversation and run /gh-implement-plan, Claude reads the issue, sees that two steps are done, and picks up at "Add unit tests." No re-explaining needed.

The plan issues also include diagrams, generated as Mermaid blocks. When I describe the work, Claude produces both the issue structure and a diagram to visualize the flow. Because Mermaid is plain text, the diagrams live inside the issue body, are version-controlled like everything else, and render natively on GitHub:

This is text in the issue, not an uploaded image. Anyone reading the issue sees the rendered diagram. Anyone editing the issue sees the source. Claude can update it as the plan evolves.

Personal context for every project

The plan cycle solves the "losing the thread" problem. But there's a second kind of context loss that's more subtle.

Claude Code reads CLAUDE.md files for project context, and you can generate one with /init. But CLAUDE.md is a shared, committed file. It's the team's context. I often need personal context on top of that: my custom test commands, the modules I specialize in, details about my expert areas that are too specific for the shared file. And for open-source projects where I'm a contributor but not a maintainer, I can't commit a CLAUDE.md at all.

Claude Code also reads a file called CLAUDE.local.md from the project directory. It works just like CLAUDE.md, but it's meant for personal context that you don't commit. This is the key to the pattern.

I keep a private repo called ai-memory that holds CLAUDE.local.md files for every project I work with:

ai-memory/
  claude/
    some-oss-project/
      CLAUDE.local.md
    my-teams-service/
      CLAUDE.local.md
    infra-tools/
      CLAUDE.local.md

Each file contains what I need Claude to know beyond what's in the shared CLAUDE.md: how I run tests, which modules I own, architecture details relevant to my work, conventions I've learned from code review. Here's a simplified example:

# CLAUDE.local.md

## My test commands
Run the integration tests I usually work with:
`mvn test -Dtest=ClassName#methodName -Pintegration`

## Areas I work on
- The config parser module (src/main/java/config/)
- The validation pipeline (src/main/java/validate/)

## Conventions I've learned
- Commit messages: conventional commits (feat:, fix:, chore:)
- PRs must reference an issue number
- No wildcard imports

I symlink these files into each project's checkout:

~/git/some-oss-project/CLAUDE.local.md
  → ~/git/ai-memory/claude/some-oss-project/CLAUDE.local.md

Now when I open Claude Code in any project, it picks up my personal context automatically alongside the project's shared CLAUDE.md. No re-explaining. The ai-memory repo is private and version-controlled, so the knowledge accumulates. When I learn something new about a project, a test quirk, a build flag, a convention I picked up from code review, I add it to the file. Every future session benefits.

Beyond these two patterns

These two patterns are the foundation, but they're not the whole setup. I also use a granular permission model that controls what Claude can do without asking, an instruction that prevents it from speculating about code it hasn't read, and skills that handle the back-and-forth of GitHub PR reviews, some of which I'll cover in a future post.

Scribe coding: the edge is judgment, not config

I've come to call this approach scribe coding, the deliberate counterpart to vibe coding. Where vibe coders feel their way through, scribe coders write their way through. You do the thinking in markdown; the AI does the typing in code.

Everything I've described here is simple to set up. A private repo with markdown files. GitHub issues with checkboxes. A few custom skills. None of it is technically impressive.

The value isn't in the mechanism. It's in knowing what to put in a CLAUDE.md file, how to break a task into steps that Claude can execute reliably, and when to let Claude work autonomously vs. when to stop and redirect. That judgment comes from using these patterns daily and refining them based on what actually works.

If you try scribe coding, you'll develop your own version of that judgment. The config files are the starting point, not the destination.