Auditing Your Own Claude Code Setup Against What Actually Shipped

The abstract for this session is a twenty-minute summary of what shipped in Claude Code recently, why the team built it, and how to get started. I want to take the framing further, because a "what's new" talk is not just a feature tour. It is the cheapest possible audit of your own setup.

I run a Claude Code setup that I tune every few weeks. Even with that frequency, every time I sit through one of these update talks I find something I have been working around for months. Either a feature I missed, a setting I configured wrong, or a workflow that the team has officially deprecated and I have not noticed because the old path still functions. That is the value of the format. You walk through someone else's tour of the product and find your own gaps.

Three things to take away

1. A "what's new" talk is an audit prompt, not an announcement. The point is to leave with one concrete change to your own setup.
2. The framing the team uses for each feature tells you where engineering investment is going. Watch the framing, not just the demo.
3. Your .claude/ directory has a half-life. If you set it up six months ago, parts of it are already wrong.

The audit, not the announcement

The mistake I see most people make with these talks is to treat them as news. They watch the talk, get impressed by the demos, retweet something, and go back to the workflow they had yesterday. That is wasted time.

The right way to watch is with your own setup open in another window. Every time the speaker mentions a feature, you check whether you are using it. Every time they show a configuration pattern, you compare it to your own configuration. Every time they explain a feature in a way you have not heard before, you ask whether your usage matches their framing or whether you have been holding it wrong.

The talk takes twenty minutes. Your audit takes the rest of the afternoon. The talk is the prompt, not the work.

What to look for in your own directory

When I do this audit on my own setup, four directories matter.

The .claude/ directory in the project. This is where the project-scoped instructions, skills, and commands live. The contents reflect what I cared about when I set up the project. If the project has been running for more than a quarter, parts of that file are stale. I have CLAUDE.md instructions that compensated for behaviors the model no longer has. I have skill descriptions that point to old paths. I have permission grants that are wider than I need now.

The global ~/.claude/ directory. This is where my personal defaults live: my voice, my preferences, the things I tell every project. This file is the slowest to drift because I do not edit it often, but that is also why it is the most likely to be wrong. If I set up my global preferences before subagents were a standard pattern, my preferences probably do not account for them.

My slash commands. Each one is a frozen artifact of how I used to think about a task. Some are still good. Some are doing what the model now does for free. Some were written before skills existed, and would be cleaner as skills.

My MCP servers. Each MCP server I have wired up represents a decision I made about which external tools the model needs access to. The list grows easily and shrinks rarely. Most teams I work with have at least one MCP server in their config that they have not used in months.

The audit is simple. Open each of these. For each item, ask: is this still pulling its weight? If not, remove it.

Reading the framing

The second value of a "what's new" talk is harder to extract but more useful. It is what the framing tells you about where the product is going.

If a feature gets framed as "for agentic workflows," that signals where the engineering investment is heading. Agentic workflows is the team's way of saying "long sessions where the model is doing most of the work and the human is reviewing the output." Features in that bucket are getting more attention because the team thinks that is the dominant usage pattern. If your usage is still very interactive, every prompt curated by hand, every diff reviewed line by line, you are using the product in a way the team is investing less in.

If a feature gets framed as "for production teams," that tells you where the polish is going. Production framing means observability, cost tracking, permission controls, multi-user setup, integration with existing CI and security tooling. If you are building toward production, these features are the ones to adopt first, because the team is going to keep refining them.

If a feature gets framed as "for advanced users" or "for power users," that is a soft warning that the team thinks the surface area is too high and they are still figuring out how to make it default-safe. You can use it, but be ready for the API to change.

The framing is a forecast about which features will be load-bearing in a year, and which are still experimental. That is worth more than the demo.

Subagents, skills, and the orchestration layer

The pattern I have seen most teams underuse is subagents. A subagent is a Claude session spawned by your main Claude session, with its own context, its own scope, and its own tools. You use them when a task is big enough to deserve its own context but not so big it needs to be a separate project.

Six months ago, subagents were a power-user feature. Today, they are how serious users get work done at any meaningful scale. If you are still running everything in a single context window, your sessions are getting longer than they need to be, your context is getting noisier than it should be, and you are paying tokens to scroll past work that is already done.

The right setup is to identify the task types that recur in your work, write subagent definitions for them, and let your main session delegate. Code review, research summarization, test generation, doc updates, dependency audits. Each one becomes a small spawned agent that does one thing well and returns.

Skills sit alongside subagents as the other half of the orchestration layer. A skill is a procedure encoded as a directory the model can find and use. The difference is scope. Subagents are about parallelism and context isolation. Skills are about repeatable procedures. They compose. A subagent can use a skill. A skill can be invoked from either the main session or a subagent.

If your .claude/ directory does not have at least a handful of skills and a clear story for when you spawn a subagent, you are behind on the patterns. Catching up is not a project. It is a weekend.

MCP as connective tissue

The other piece worth auditing is your MCP setup. Model Context Protocol has become the standard way to connect Claude Code to your tools, your data, and your platforms. If you set up your tooling before MCP, you probably wrote integrations the hard way. If you set it up after MCP, you probably have a few MCP servers but have not pruned the list in a while.

The audit for MCP is: which servers do I actually use, which ones do I have configured but never trigger, and which integrations am I still doing by hand because I never wired the MCP server up?

The third bucket is the interesting one. Many teams have a Slack integration they paste into manually, a Jira flow they describe to the model in prose, a GCP or AWS dashboard they screenshot and paste. Each one is a place where an MCP server would let Claude do the work directly. If the official MCP server exists and you have not adopted it, that is your first install.

One change per week

The discipline I have settled on, after watching enough of these talks to know I am bad at acting on them, is one concrete change per week.

The week after a "what's new" talk, I pick one feature I do not currently use and run it for a full week as a forced experiment. Sometimes the experiment confirms that my old workflow was fine. Sometimes it reshapes how I work permanently.

The bar is not "should I adopt this forever." The bar is "have I actually tried it." The talks are useless if you sit them out. They earn their twenty minutes when they cost you one week of small inconvenience and give you back months of compound benefit.

That is the only test that matters when you watch one of these. Did the talk change what is in your .claude/ directory by Friday? If yes, the talk worked. If not, you watched a video.

Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.

This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.

My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.

Source talk: What's New in Claude Code at Code with Claude London 2026. https://youtu.be/sRvUXLquiRg

← All articles