Most developers don’t realize just how many tokens Claude Code wastes by default in just trying to understand your codebase.
Every noisy search result, duplicate reference, and irrelevant file eats into your context before the real work even begins.
Increasing your API costs and slowing down responses significantly.
But luckily, we now have the incredible Language Server Protocol (LSP) integration to fix all this.
It’s one of the least talked about features that dramatically transforms how Claude processes your code and makes changes.
By swapping heavy text searches for instant AST queries, LSP cuts lookup times from 30–60 seconds down to a 50-millisecond response, delivering up to 900x faster code navigation speeds
With LSP Claude Code stops relying on text searches — it directly queries a language server that already understands your project’s structure. What you get is an AI assistant that behaves much more like a modern IDE than a just a chatbot. You get the best of both worlds.
LSP powers many IDE features we’ve been using to code everyday years before AI came around, like:
Go to Definition
Find References
Rename Symbol
Type checking
Error diagnostics
Hover documentation
Rather than treating code as plain text, LSP exposes semantic information such as symbols, types, inheritance, and references.
Imagine asking:
“Where is UserRepository used?”
Without LSP, Claude performs a text search that may return:
the definition
dozens of call sites
comments
documentation
test files
unrelated string matches
Claude must read all of that before determining what actually matters.
With LSP, Claude asks the language server for the symbol’s references and receives only the precise locations where that symbol is used. Instead of searching text, it navigates your code semantically.
The difference becomes even more valuable in large repositories.
Enterprise projects often contain:
thousands of files
millions of lines of code
hundreds of packages
Traditional searches repeatedly scan those files. Language servers already maintain indexes of definitions, references, implementations, and type information. Claude simply queries those indexes, making navigation faster and far more precise.
One of the most underrated advantages of LSP integration is token savings.
Every line of search output consumes tokens, increases latency, and costs money. Text searches often return much more information than Claude actually needs, including comments, documentation, duplicate references, and unrelated matches. Claude has to spend part of its context window filtering that noise.
LSP eliminates most of this overhead. Instead of returning pages of search results, it provides only the relevant semantic information, such as:
the symbol definition
exact references
implementation hierarchy
type information
In large codebases with heavily referenced symbols, LSP-driven navigation can produce tool outputs that are 2–3× smaller than equivalent text searches.
That means:
lower API costs
faster responses
less wasted context
more room for Claude to reason about your code
LSP also makes refactoring much safer.
Suppose you rename a class called PaymentProcessor.
A simple text replacement could accidentally modify comments, documentation, string literals, or unrelated variables. A language server understands symbols rather than text, allowing Claude to rename only the actual class and its legitimate references.
Another major advantage is immediate diagnostics.
After Claude edits a file, the language server can instantly report:
syntax errors
missing imports
unresolved identifiers
type mismatches
Instead of waiting for a build or CI pipeline to fail, Claude can identify and fix problems immediately.
Sometimes people confuse LSP with the Model Context Protocol (MCP), but they complement each other rather than compete.
LSP helps Claude understand your source code.
MCP helps Claude interact with external tools such as GitHub, Slack, databases, and cloud services.
Together they allow Claude to understand both your application and the ecosystem around it.
LSP shifts Claude from simply reading code to actually understanding it. Rather than treating a repository as a collection of files, Claude reasons about symbols, relationships, types, and program structure.
The result is:
faster navigation
safer edits
better refactoring
immediate feedback
lower token usage
LSP integration may not be as flashy as autonomous agents, but as a developer working on real-world codebases, it’s one of the most meaningful ways to level up your Claude Code workflow.
Many developers confuse them a lot — but they’re actually not interchangeably in any way.
They all extend Claude Code but they do it very differently and for very different reasons.
First let’s understand what each of them are on their own.
A Skill is a reusable set of instructions, knowledge, and workflows that Claude can load when performing a task. Skills help Claude apply project-specific standards, follow established processes, and consistently execute repeatable tasks.
Model Context Protocol (MCP) is an open protocol that enables Claude to connect to external tools, services, databases, APIs, and other software systems. MCP servers let Claude discover available tools and interact with connected resources.
A Plugin is an installable extension for Claude Code that packages one or more components — like Skills, MCP servers, Hooks, Agents, and configuration — into a reusable, shareable unit.
Here’s a real-world scenario that illustrates the crucial difference:
Imagine having a chef that learns your family’s special cake recipe.
Skills: the mental playbooks, checklists, and habits stored in your brain.
Now they know how to cook it.
But they still only have the ingredients already in the kitchen.
MCP: The physical tools you use to achieve goals in the real world.
Now the chef gets access to:
the pantry
grocery delivery
refrigerator inventory
supplier catalog
The chef can actually obtain new ingredients.
Plugins: the entire kit containing everything you need to know and every tool you need to achieve your goal.
Instead of manually giving every new chef:
recipes
supplier accounts
kitchen procedures
You hand them one onboarding kit containing everything.
A Skill adds knowledge.
An MCP adds capability.
A Plugin adds distribution.
A skill teaches Claude Code how to do things — specialized knowledge and edge cases it needs to be aware of, and the optimal manner of approach to take in solving a task.
MCP lets Claude Code actually do those things — make pull requests on GitHub, read databases, process analytics data, etc.
Plugins bundle MCPs and Skills into a single package. It can contain multiple mcps and multiple skills.
As a software engineer in your new company:
A Skill is training.
“Here’s how we review pull requests.”
An MCP is company access.
GitHub credentials.
Jira.
Slack.
AWS.
A Plugin is the setup package you get as a new hire:
Laptop.
VPN.
GitHub access.
Internal documentation.
Team tooling.
Training, permissions, and installation are three different problems.
Why you need all of them
Imagine a situation where Claude keeps writing API endpoints differently from your team.
The problem isn’t missing capability — Claude already knows how to write code — it simply doesn’t know your conventions.
That’s where a Skill comes in.
But how about when Claude needs to query your production database?
No amount of instructions can magically let Claude access that database.
That’s where MCP shines.
But then we still need every engineer on your team to receive:
the database connection
deployment workflow
code review standards
security checks
You don’t want everyone configuring these individually.
That’s a Plugin.
Can one replace the other sometimes?
No.
A Skill cannot replace an MCP because instructions cannot grant access to systems Claude cannot reach.
An MCP cannot replace a Skill because having access to a system doesn’t teach Claude your team’s preferred workflow.
A Plugin doesn’t replace either one—it simply packages them together
The easiest way to remember the distinction is this:
This is one of the most essential skills that every developer should have.
The /feature-dev skill plugin makes you write code with far fewer mistakes, spend less time fixing AI-generated code and make much better architectural decisions.
It does this through specialized AI agents that handle different tasks and a structured seven-step workflow that takes you from understanding your codebase to building and reviewing your feature.
1. Multi-agent specialization: Better codebase understanding and fewer mistakes
Normally one AI agent handles everything from reading your code to planning and reviewing it.
Feature Dev uses three specialized agents:
code-explorer: Goes through your codebase to understand how things work and trace dependencies without changing files.
code-architect: Plans the feature and suggests different approaches while spotting possible problems.
code-reviewer: Checks for bugs and type issues. It also looks for security risks and possible regressions.
This lets each agent focus on one task instead of handling everything in the same context.
For us developers this means fewer mistakes caused by missing context. It also reduces duplicate code and the risk of breaking existing features.
2. Seven-step workflow: Less back-and-forth and more predictable development
Feature Dev doesn’t just take your prompt and start coding.
It follows seven steps:
Discovery: Understand what you want to build.
Codebase exploration: Look through your existing code.
Clarifying questions: Ask about anything that’s unclear.
Architecture: Plan how to build the feature.
Implementation: Write the code.
Quality review: Check the code and run relevant tests.
Summary: Explain what changed and prepare the work for review.
This gives you a clear picture of what’s happening at each stage.
Instead of constantly correcting the AI with new prompts you get a more organized process. You can review important decisions and catch problems early.
3. Upfront clarification: Less rework and fewer wasted hours
One frustrating thing about AI coding tools is how quickly they make assumptions.
Say you ask Claude to add file uploads to your app.
It should first ask questions like:
What file types should users upload?
What’s the maximum file size?
What happens when an upload fails?
Where should the files go?
A regular AI assistant might make these decisions without asking you.
Feature Dev asks questions before writing code so you can clear up missing requirements early.
This means less time fixing misunderstood requirements and fewer unnecessary code changes.
It’s easier to answer a few questions upfront than to rewrite several files because the AI made the wrong assumptions.
4. Architectural trade-offs: Less technical debt and more control
Instead of choosing one approach and immediately writing code the code-architect agents explore different ways to build your feature.
They compare things like:
Complexity: How difficult is the solution?
Maintainability: How easy will it be to change later?
Existing code: How much needs to change?
Trade-offs: What do we gain or lose?
You then choose what makes the most sense for your project.
Say you’re adding caching. You might prefer a simple in-memory solution instead of Redis depending on your app’s needs.
This helps us avoid unnecessary complexity and technical debt while keeping you in control of the architecture.
5. Persistent artifacts: Easier handoffs and less lost context
One problem with AI coding sessions is losing track of decisions when you pause your work or hand it over to a teammate.
You can make Feature Dev more useful by pairing it with Markdown files like:
proposal.md: What we’re building and why.
design.md: How we’ve decided to build it.
tasks.md: What’s done and what’s left.
Feature Dev doesn’t create these files by default. But you can combine it with tools like OpenSpec or your own instructions.
This makes it easier to resume work and share plans with teammates. You can also review code against the original design without digging through a long AI conversation.
Final thoughts
Feature Dev gives us a clearer process and more control over how we build features with AI.
You might not need it for small fixes. But for complex features it can save time and help you avoid unnecessary mistakes.
The goal isn’t just to write code faster. It’s to spend less time fixing mistakes and more time building the right thing.
This Claude Code command will save you from many painful bugs.
Yes we already know how good Claude Code is at making code work…
But what happens after several prompts, fixes, and changes of direction?
Your working code quietly accumulates duplicated logic, unnecessary abstractions, inefficient operations, and remnants of abandoned approaches.
And this is why the /simplify Claude Code command is so important.
With /simplify, Claude will rapidly review your recent changes, finds opportunities to make them simpler and more efficient, and applies the improvements automatically.
The code becomes easier for both you and your agent to understand — which dramatically reduces the odds of a buggy change being made in the future.
1. Parallel agents attack your code from different angles
This is one thing that really sets it apart — from just asking Claude to simplify your code.
When you trigger /simplify, Claude doesn’t just run a one-shot cleanup prompt.
It spawns multiple parallel review agents on the fly — at least three — each examining recently modified code from a different angle:
Code reuse and duplication: Finds duplicated logic, redundant abstractions, and opportunities to reuse existing code.
Quality and readability: Looks for unnecessary complexity, deeply nested conditionals, convoluted expressions, poor naming, and code that could be clearer.
Efficiency and footprint: Searches for unnecessary work, dead code, redundant helpers, and potential memory or performance improvements.
Claude combines their findings and applies the resulting improvements.
You’re essentially getting specialized code-review team dedicated entirely to cleaning up what was just built.
2. Specifically designed to fight AI-generated code bloat
AI agents can produce messy code even when the final result works perfectly.
Claude creates an implementation. You change a requirement. Claude modifies it. A test fails. Claude patches it. Another edge case appears. Claude patches that too.
Eventually, layers of individually reasonable changes can stop forming the simplest overall solution.
That’s why /simplify is distinct from a traditional bug-focused review. Its focus is cleanup: reuse, simplification, efficiency, and overall implementation quality.
The question isn’t necessarily:
“Does this code work?”
It’s:
“Now that it works, is this still the code we actually want?”
3. It looks for code Claude should have reused
One of /simplify’s explicit review dimensions is reuse.
That’s especially important as codebases grow.
An AI agent can generate a perfectly reasonable solution — without realizing that somewhere else in the repository there’s already a helper, utility, abstraction, or established pattern that solves essentially the same problem.
The new code isn’t necessarily bad.
It’s simply unnecessary.
And unnecessary code means more maintenance, more opportunities for implementations to diverge, and more context future AI agents have to understand.
/simplify gives Claude another chance to understand the broader repository and consolidate code instead of continuously adding more.
4. It doesn’t just review your code
This is an important difference between /simplify and conventional AI code review.
It doesn’t simply produce a report.
After reviewing the changed code, Claude applies the fixes it discovers.
That makes /simplify closer to an automated refactoring stage than a traditional reviewer.
Anthropic even separates these responsibilities into three separate commands:
/diff
/simplify
/review
/diff shows what changed.
/simplify improves the implementation.
/review performs deeper read-only analysis.
Instead of leaving developers with another list of suggestions to manually implement, Claude can clean up its own work before the final review.
5. It follows your project’s rules — not just generic “clean code”
/simplify isn’t limited to Claude’s general idea of what good code should look like.
Its review can also account for your CLAUDE.md, Claude Code’s persistent project instruction file.
That file can define architectural rules, coding conventions, preferred libraries, constraints, and other repository-specific instructions.
So simplification can remain grounded in how your particular codebase is supposed to work.
A refactoring might look cleaner in isolation while violating an architectural rule you’ve established for the project.
/simplify can account for both.
So the question becomes more than:
“Can I make this code cleaner?”
It’s also:
“Can I make it cleaner while keeping it consistent with the rest of this project?”
As AI agents write increasingly large portions of software, generating more code isn’t necessarily the difficult part anymore.
Keeping all that generated code coherent might be.
It’s incredible how many people don’t realize this — there is no .claudeignore file. Claude Code does not natively recognize any such file.
And even your .gitignore is not as strictly respected as you might think — there are much stronger ways to reliable ignore files and avoid revealing sensitive information and wasting tokens on irrelevant file data.
Yes we already have .dockerignore and .npmignore and other kinds of .[x]ignore — so it sounds like .claudeignore is a real thing.
But it really isn’t.
But this misconception has spread across the internet — even models like Claude have recommended a .claudeignore file even though it doesn’t do anything.
And what’s the problem with .gitignore?
Claude Code does respect .gitignore for some file discovery.
It can hide ignored files from things like @-mention autocomplete. Claude Code also has settings that control whether tools like Glob respect .gitignore.
This helps keep things like node_modules, build files and other junk out of normal searches.
But.gitignoredoes not stop Claude from reading those files directly.
If you tell Claude to “read .env” or “check dist/output.log” it can still try to read them.
Claude can accidentally read sensitive files like API keys and production credentials. It can also read huge ignored files like logs or generated output. That can waste a lot of tokens and fill the context window with useless data.
So .gitignore can help with file discovery. It does not give you a hard security barrier.
These rules can stop matching tool calls instead of simply asking Claude to behave.
This is what you want for .env files, private keys and other secrets.
Just remember that Claude can use other tools too. If you let it run Bash then a command like cat .env creates another way to read the file. For important secrets you should lock down every path that could expose them.
2. UseCLAUDE.md (or AGENTS.md) for files that waste context
Not every file needs a hard block.
Maybe you just don’t want Claude wasting tokens reading build files, logs or dependencies.
In that case add simple rules to CLAUDE.md:
Plain textCopied!
## Context & File Rules
- Do not read files inside `dist/`, `build/` or `node_modules/`.
- Ignore `.log` files unless I ask you to read them.
Claude Code reads CLAUDE.md as project instructions.
This works well for context management. But it’s still an instruction to Claude. It does not block the file at the tool level.
3. Use a PreToolUse hook
If you really want .claudeignore then you can make it work with a hook.
Community tools like claude-ignore use Claude Code’s PreToolUse hooks. The hook checks a file path before Claude reads it. It compares the path against patterns in .claudeignore and blocks the tool call when it finds a match.
So .claudeignore can work.
But only when you install something that actually reads and enforces it.
The easiest way to think about all of this is:
.gitignorehelps with discovery.CLAUDE.mdtells Claude what to avoid.permissions.denyactually blocks tool access. Hooks let you build custom ignore rules.
But .claudeignore on its own?
Don’t trust it.
That’s what makes this whole thing so interesting. People and AI made up assumptions of a feature that sounded so real that developers started using it and telling other people to use it too.
When secrets are involved you can’t rely on something just because Claude says it exists.
The I Have ADHD Skill massively upgrades the quality and clarity of Claude’s responses by encouraging it to communicate in a much more direct, structured, and action-oriented way.
It removes all the fluff and goes straight to the point — saving you so much token costs and improving your mental model of the task at hand — which let’s you move faster and get things done.
The crucial problem it’s here to solve
AI coding assistants often answer simple questions with long explanations before getting to the solution.
That style can be useful for learning — but when you’re debugging, shipping features, or reviewing code, it creates unnecessary friction.
The “I Have ADHD” skill solves that by encouraging Claude to prioritize the next action instead of lengthy context.
How the Skill works
The skill dramatically changes how Claude structures its responses.
Instead of long introductions, it’s encouraged to:
Start with the immediate next step.
Break work into numbered tasks.
Remove unnecessary filler.
Show progress throughout a task.
Finish with one clear next action.
You end up getting an AI that isn’t just intelligent, but also extremely easy to work with.
Why so many developers love it
The project quickly gained over 10,000 stars on GitHub within days of launch.
Because it addresses a frustration many developers have long had with AI assistants: too much explanation and not enough execution.
Whether you’re debugging, refactoring, or navigating a new codebase, concise responses reduce cognitive load and help you stay focused.
How to get started with the I Have ADHD skill
Install it easily with these commands:
JavaScriptCopied!
claude plugin marketplace add ayghri/i-have-adhd
claude plugin install i-have-adhd@i-have-adhd
Then type /i-have-adhd in a Claude Code session to activate it — all the responses will be structured according to the rules of the skill for the rest of the session:
How to use it to transform your workflow (5 practical use cases)
1. Debugging production issues
Without the skill
Plain textCopied!
There are several reasons your API could be returning a 500 error. Let's begin by understanding how Express middleware works before we explore possible causes...
With the skill
Plain textCopied!
1. Check server logs.
2. Verify DATABASE_URL.
3. Run:
curl http://localhost:3000/health
4. Report the output.
Why it matters: When production is down, you need the next action — not a lesson.
2. Refactoring legacy code
Without the skill
Plain textCopied!
There are multiple approaches to refactoring this codebase. Before making changes, let's discuss architecture, design patterns, and technical debt...
Why it matters: Breaking work into milestones makes large refactors feel manageable.
3. Building large features
Without the skill
Plain textCopied!
Let's build a complete authentication system. First, here's the architecture...
[Hundreds of lines covering models, JWTs, middleware, RBAC, testing, deployment, and security.]
With the skill
Plain textCopied!
Phase 1
✓ User model
✓ Login endpoint
Phase 2
□ JWT middleware
□ Refresh tokens
Phase 3
□ Role middleware
□ Permissions
Why it matters: You stay focused on one phase instead of being overwhelmed by the entire implementation.
4. Learning an unfamiliar codebase
Without the skill
Plain textCopied!
This project uses a layered architecture with controllers, services, repositories, middleware, utilities, shared modules, and configuration files...
Let's walk through every directory.
It’s somehow like the multi-agent teams feature — but much simpler and more straightforward.
It’s perfect for those large-scale changes that can easily be broken down into smaller tasks — like mass refactoring and codebase migration.
It spins up multiple AI agents to work simultaneously across the codebase — giving you an immense boost in productivity.
Let’s look at the key features that make it so invaluable when working with Claude Code — from autonomous testing and pull requests, to how it combines brilliantly with other Claude Code commands to build a comprehensive engineering workflow.
The foundation of /batch is its ability to break large requests into smaller, independent units of work.
When you invoke /batch, Claude Code:
Analyzes the repository.
Understands the requested objective.
Identifies logical boundaries within the codebase.
Decomposes the work into 5–30 independent work units.
Rather than editing files sequentially, Claude distributes work across multiple agents that can operate in parallel.
For example, a framework migration might be divided into:
Shared UI components
Authentication modules
Routing logic
API integrations
Testing infrastructure
By separating work into distinct scopes, /batch can scale far beyond the limitations of a traditional single-agent workflow.
2. The /batch and /simplify power combo
One of the more interesting aspects of /batch is how it complements Claude Code’s /simplify command.
While /simplify focuses on reducing complexity and unnecessary abstractions, /batch can coordinate improvements across an entire codebase.
The combination gives us several advantages:
Identifies overly complex patterns at scale.
Reduces unnecessary abstractions and indirection.
Improves code readability and maintainability.
Creates greater consistency across modules.
Eliminates repetitive manual refactoring work.
Instead of simplifying files one by one, you can use /batch to coordinate the effort across dozens of components simultaneously. This makes large-scale codebase cleanup and standardization significantly faster and more manageable.
3. Git worktree isolation: parallelize without conflicts
A key feature of /batch is its use of Git worktrees.
Every subagent receives its own isolated worktree instead of sharing a single working directory.
This enables:
Concurrent development
Independent validation
Isolated dependency management
Reduced merge conflicts
Because each worker operates in its own environment, changes made by one agent do not interfere with another.
A component migration can run in one worktree while another agent updates tests or refactors utilities elsewhere in the repository.
This isolation is what makes large-scale parallel execution practical and reliable.
4. Autonomous testing and pull requests
/batch is more than a code-editing tool.
Each subagent behaves like an autonomous developer responsible for its assigned scope.
Subagents can:
Implement code changes
Run test suites
Detect failures
Fix localized issues
Validate completed work
Create commits or pull requests
Instead of producing one massive repository-wide change, /batch generates smaller, self-contained outputs that are easier to review and merge.
The result is less manual coordination and a cleaner development workflow.
5. Plan-first execution
Before making any changes, /batch generates a structured execution plan.
The plan outlines:
How the task was divided
Which files or directories belong to each work unit
The responsibilities assigned to each subagent
The proposed transformation for each area of the codebase
Developers review and approve the plan before execution begins.
This approval stage:
Provides visibility into the process
Prevents unexpected repository-wide changes
Keeps humans in control of major modifications
Rather than blindly applying edits, /batch follows a plan-first approach designed for large-scale engineering work.
Final thoughts
Claude Code’s /batch command represents the broader shift single-agent coding assistance to coordinated multi-agent software engineering.
With key features like:
Intelligent task decomposition
Parallel AI execution
Git worktree isolation
Autonomous testing
Pull request generation
Human approval checkpoints
It enables repository-wide transformations at a scale that would traditionally require significant manual effort.
Software is no longer being built by a single AI agent, but now by a coordinated systems of specialized agents working together toward a common objective.
Claude Code is powerful out of the box, but the right skills can make it so much better.
Skills give Claude reusable workflows for specific tasks. Instead of simply asking an AI to “build this feature,” you can give it a process for planning, designing, questioning assumptions, and remembering previous work.
Here are five Claude Code skills every developer should know.
1. feature-dev: Build features with a process
One of the biggest mistakes with AI coding agents is jumping straight from an idea into implementation.
You say:
“Add team invitations.”
And suddenly Claude is editing eight files before fully understanding the architecture.
feature-dev introduces a more structured workflow:
Understand → Plan → Implement → Test → Review
Claude can first explore the relevant parts of your codebase, understand existing patterns, develop an implementation approach, and then start making changes.
This becomes especially useful for features that touch multiple files, APIs, database models, or unfamiliar parts of a repository.
The goal is simple: don’t use Claude as a fast typist. Use it as an engineer responsible for the entire change.
2. frontend-design: Escape generic AI design
AI can build functional interfaces remarkably quickly.
The problem is that they often look… AI-generated.
Huge headline. Purple gradient. Three rounded cards. Glowing background.
Anthropic’s frontend-design skill pushes Claude toward more intentional, production-quality interfaces. Instead of immediately generating components, it considers things like typography, layout, visual hierarchy, color, motion, audience, and overall aesthetic direction.
So instead of simply asking:
“Build a dashboard.”
Claude can think about what the dashboard is for, who uses it, what information deserves attention, and how the interface should feel.
It’s especially useful for landing pages, dashboards, React components, product interfaces, and prototypes.
The real advantage isn’t better CSS. It’s better design decisions before the CSS gets written.
3. karpathy-guidelines: Make Claude precise and focused
AI coding agents can produce a lot of code very quickly.
Sometimes that’s the problem.
The community-built karpathy-guidelines skill packages ideas inspired by Andrej Karpathy’s observations about common LLM coding mistakes.
The principles are straightforward:
Think before coding. Keep solutions simple. Make surgical changes. Verify your work.
If you’re fixing one bug, Claude shouldn’t unnecessarily refactor three unrelated modules.
If requirements are ambiguous, it should surface the ambiguity instead of silently guessing.
And if it claims something works, there should be a test or another way to verify that claim.
The result is less unnecessary code and fewer “while I’m here…” changes.
4. claude-mem: Give Claude long-term memory
Monday: you explain your architecture to Claude.
Tuesday: you explain it again.
Wednesday: Claude rediscovers something it already learned Monday.
claude-mem tackles this problem by creating a persistent memory layer around Claude Code.
It can preserve useful observations from previous sessions — architectural discoveries, important files, implementation context, and other project knowledge — and surface relevant information later.
That means when you return to a project, Claude doesn’t always have to start its investigation from zero.
For large repositories and long-running projects, this can be a huge productivity boost.
The larger your codebase becomes, the more expensive forgetting becomes.
5. grill-me: Make Claude challenge your idea
This might be the most underrated skill.
Sometimes Claude’s implementation isn’t the problem.
Your idea is.
grill-me forces you to answer difficult questions before implementation begins.
Say you’re building an API usage billing system.
Claude might ask:
What happens when the same usage event arrives twice?
Can events arrive late?
Are usage limits hard or soft?
What happens when billing data disagrees with internal records?
Suddenly, you discover architectural decisions you hadn’t considered.
That’s valuable because AI has made implementation incredibly cheap. You can generate thousands of lines of code before realizing the underlying idea wasn’t properly thought through.
grill-me introduces useful friction before that happens.
Combine them
The real power comes from combining these skills.
Start with grill-me to challenge the idea.
Use karpathy-guidelines to keep the solution simple.
Use feature-dev to plan and implement it systematically.
Bring in frontend-design when you’re building the interface.
And let claude-mem preserve what Claude learns along the way.
For the past few years until now it’s been all about Large Language Models (LLMs).
From generating code to drafting essays, LLMs showed us their remarkable ability to work with language and solve complex problems.
But inside modern AI-powered software systems, an interesting problem emerged.
Today, as developers we increasingly use large conversational models for tasks that don’t need any conversation at all:
deciding which action an automated agent should take next (like which button to click on a page)
tagging and sorting text data
deciding the next step of an AI-powered workflow
routing customer-support tickets
checking whether content violates a policy
In these situations, the application doesn’t need generated text. It needs a decision. It needs cold hard data — and fast.
That is the problem that Jev, a new trending model from TypeSafe AI, is here to address.
Jev represents an emerging category of non-autoregressive decision models.
Instead of generating natural-language responses, these models take application state and return constrained, probabilistic decisions.
They skip the LLM conversation layer entirely to focus on pure processing logic and decision making, which makes it much faster, among other benefits.
1. Much lower latency in AI model processing
Traditional LLMs generate responses autoregressively, producing one token after another. That makes sense for paragraphs or code, but it is inefficient when the goal is simply to “approve or reject” or “choose one of these categories.”
Jev-like models instead produce bounded decisions directly.
According to performance claims associated with Jev, this faster processing can take roughly 70–300 milliseconds — as much as 40x to 200x faster than using conversational LLMs to do it.
This makes AI decisions much more practical for UI automation, interactive applications, automated agents, and other latency-sensitive workflows.
2. Fewer parsing problems
LLM developers know the familiar instruction: “Respond ONLY with valid JSON.”
Yet models can still occasionally return Markdown, extra explanations, unexpected fields, or invalid values. Developers compensate with validation, constrained outputs, and retry logic.
Jev takes a different approach by eliminating arbitrary text generation. Its interface is based on constrained primitives like:
Choice: Select an option from a predefined set.
Noul: Evaluate a boolean condition with a probability.
Score: Evaluate input against an ordered scale.
Because it knows all its outputs in advance, applications can avoid many of the parsing and formatting problems associated with free-form generation.
3. Lower model processing costs
Cost becomes especially important when AI operates as invisible infrastructure.
A chatbot might receive a handful of requests per user — but a backend model could be invoked hundreds of times during automated workflows.
TypeSafe AI lists Jev’s input processing at approximately $0.042 per million tokens — and without an output-token charge — because it does not generate text.
We’re getting reports of cost reductions of roughly 40× to 400× for some structured classification workloads compared with generative LLMs.
The underlying idea is simple: if an application needs a classification rather than a sentence, paying to generate that sentence may be unnecessary.
4. Usable confidence scores
Conversational models often express incorrect answers with the same confident tone as correct ones. For automated systems, that makes uncertainty difficult to interpret.
Decision models can instead expose probabilities directly and optimize for calibration. Jev uses an approach called Reinforcement Learning for Calibrated Decisions (RLCD).
In principle, well-calibrated probabilities allow us as developers to create practical automation thresholds. High-confidence decisions might execute automatically, medium-confidence cases could go to human review, and low-confidence cases could be escalated.
That turns uncertainty into something application code can actually use.
5. Parallel evaluation
Software often needs multiple judgments about the same input — for example determining a document’s compliance status, sentiment, risk level, priority, category, and routing destination.
Rather than making separate generative calls, we can potentially evaluate multiple decision targets together with non-autoregressive models.
TypeSafe AI describes this approach as speculative fan-out, reducing the overhead involved in repeatedly processing the same application state.
The bigger picture
Models like Jev are not necessarily replacements for conversational LLMs. They address a different layer of the AI stack.
Generative models remain valuable for open-ended reasoning, writing, coding, and synthesis. Decision models are designed for something simpler:
state in → probability or decision out.
That could lead to a more specialized AI architecture, where powerful generative models handle difficult reasoning while fast decision models manage the thousands of routine judgments underneath.
It’s the world where AI becomes more than something users talk to.
Where it’s part of the software itself—routing requests, evaluating conditions, selecting actions, estimating risk, and determining when more expensive reasoning is actually necessary.
CLAUDE.md is so much more than most developers realize.
It’s supposed to be a special file for providing persistent instructions and context to Claude Code.
But many developers think they can just dump whatever they like inside it — some feel it’s just a fancy way to avoid writing the same prompts over and over.
Some don’t even ever use it — missing out on one of the most powerful ways to shape how Claude behaves inside a project.
The reality is that CLAUDE.md is far more nuanced than it appears. Understanding a few non-obvious facts about it can completely change how you work with Claude Code, and the results it produces for you.
Here are five things every developer should know about CLAUDE.md.
1. It’s not a README or project summary
Actually not a very good CLAUDE.md:
A README exists to explain a project.
A CLAUDE.md exists to guide an agent working inside that project.
The most effective files don’t try to document everything. Instead they focus on specific expectations, workflows, constraints, and preferred ways of working.
For example:
Particular project-specific commands to run — or NOT run
What must happen before code is merged
Which patterns should be avoided when responding to prompts
How tasks should be approached
Thinking of CLAUDE.md as documentation often leads to bloated files. Thinking of it as a behavioral contract usually leads to better results.
2. It’s not a system prompt
One common misconception is that CLAUDE.md functions like a system prompt.
It doesn’t.
Claude Code loads the contents of the file into the model’s normal user context — it’s treated as important guidance rather than an untouchable source of truth.
It’s not an unbreakable instruction layer that reigns over every other context.
This is why clear, specific instructions tend to work much better than vague recommendations.
3. There can be more than one CLAUDE.md
Many developers assume there is a single CLAUDE.md at the root of a project.
But actually Claude Code supports a layered memory system.
Instructions can exist at multiple levels and be combined as Claude works through different parts of a codebase.
This makes CLAUDE.md less like a project configuration file and more like a hierarchy of contextual instructions that shapes behavior in different situations.
4. Claude can automatically generate your first CLAUDE.md
A surprising number of developers still start from a blank file.
Claude Code includes an /init command that can inspect a repository and generate an initial CLAUDE.md automatically.
The generated file won’t be perfect, but it provides a useful starting point and can save time by capturing common project information that would otherwise need to be written manually.
For many teams, it’s the fastest way to establish a baseline memory file.
5. CLAUDE.md is only one layer of Claude’s massive memory system
Perhaps the most important thing to know is that CLAUDE.md is not Claude Code’s entire memory system.
It’s just one layer.
Claude can draw context from user-level memory, project-level memory, session context and many other memory sources.
So when Claude successfully remembers how your team works, that behavior is often influenced by more than a single file.
The most interesting thing about CLAUDE.md is that it represents a new way of programming behavior.
Traditional software is configured through code and settings. Claude Code introduces the idea of configuring an agent through natural language instructions.
That’s why two developers can use the same model and get very different outcomes. The difference isn’t the model — it’s the behavior defined by the memory and instructions surrounding it.
