Large language models are black boxes. They are brilliant, they are useful, and on a bad day they will confidently hand you an answer they cannot justify. NLP++ is the opposite: a rule-based programming language where every decision the analyzer makes traces back to a rule you can read, run, and change. Same input, same output, every time.
The good news is you don’t have to choose. You can use Claude to help you build NLP++ — and the analyzer you end up with is still plain, deterministic code that stands entirely on its own. Claude is a partner throughout the work; the finished analyzer doesn’t depend on it.
One thing to get straight up front: you can’t type a loose one-line request and expect Claude to conjure a working analyzer out of nothing. That is not how it works, and pretending otherwise sets people up to fail. The truth is more useful: Claude helps at every stage of an analyzer’s life, but you still need a clear plan, and the kind of help you want changes as the analyzer matures.
Three stages, three kinds of help
1. Scaffolding at the beginning — but only with a clear plan.
Claude can scaffold an NLP++ analyzer from scratch. What it can’t do is invent your plan for you. Before it writes anything useful, you need to know how the analyzer should work: what you’re extracting, exactly what counts as a match and what doesn’t, what the output should look like. The more precisely you can describe that, the better the scaffold. A vague prompt (“find the products in this text”) produces vague, wrong, or hopelessly generic code. A surgical prompt produces something you can actually build on.
2. Improving how it processes the text — as you go.
Once you have a scaffold, you’ll often see a better way to approach the problem — a cleaner pass structure, a smarter way to group tokens, a rule that should fire earlier. This is normal; the first design is rarely the best one. You can lean on Claude here too: describe the better approach and have it reshape the passes, or ask it how others have handled a similar pattern. You supply the judgment about what “better” means; Claude does the legwork of rewriting.
3. Fixing and hardening — once it’s working fairly well.
This is where Claude shines brightest, and honestly where most of the real value is. Once the analyzer has a sound design and is working fairly well, Claude becomes a genuine force multiplier. It hunts down why a rule did or didn’t fire, generates edge-case test inputs that break things, tightens rules to reject near-misses, writes dictionaries and knowledge bases, and explains unfamiliar passes and library functions. Point it at good bones and it accelerates everything.
The through-line: Claude is not a substitute for knowing what you want. It’s an accelerant for someone who does.
The five steps
Step 1 — Install VS Code
Download and install Visual Studio Code from code.visualstudio.com for your platform (Windows, macOS, or Linux). Open it once to confirm it runs.
Step 2 — Install the NLP++ extension
Open the Extensions view (Ctrl+Shift+X on Windows, Cmd+Shift+X on Mac), search for NLP++, and install it. When prompted, accept the download of the NLP engine and the VisualText support files. Use the cog icon to load the example analyzers and click around — the extension lays out the standard folder structure (spec/, input/, kb/) that every analyzer uses.
Step 3 — Add Claude Code to VS Code
Install Anthropic’s Claude Code extension from the marketplace and sign in with your Claude subscription. Claude now works as an assistant inside the same editor window, with access to your analyzer files.
Step 4 — Use the built-in prompts — and bring a plan
The VisualText extension ships ready-made prompts that already fill in the machine-specific paths (the engine, the example analyzers, the templates) so Claude starts on the rails instead of guessing at conventions. Open the closest-fitting one, edit it, and paste it into Claude:
- From scratch: chemical formulas — a complete worked example. This is the one to study first.
- Build an analyzer — the generic starting point. It hands Claude the paths and conventions, then leaves a blank for you to describe your corpus and extraction task. That blank is where your plan goes — the prompt is only as good as what you write into it.
- Harden analyzer — for an analyzer you already have. Generates varied test inputs, runs them, and reports where extraction looks wrong.
- Create Dictionaries & KBs — builds
.dictand.kbbfiles in the correct format for an existing analyzer. - Add missing words to the English dictionary — reads the missing-words log and adds properly featured entries, alphabetized.
What a clear plan actually looks like
The chemical-formula prompt is the standard to aim for. It doesn’t say “find chemical formulas.” It nails down every decision the analyzer would otherwise have to guess:
- An exact definition of the target. “A formula is a run of one or more element symbols; each symbol is a single uppercase letter optionally followed by one or two lowercase letters (H, O, Na, Cl), each optionally followed by a count (H2O, CO2, C6H12O6). When no count is present the count is 1.”
- The corpus to build against. Specific Wikipedia chemistry excerpts, subscripts transcribed to plain ASCII, seeded with deliberate near-miss distractors.
- The exact data structures. An
element.dictwith each element listed as both symbol and name; a knowledge base built under a named root concept; JSON emitted through the library’sJsonKB, not hand-rolled string writes. - The precision filters. Reject capitalized words, model/catalog codes, lone capital letters, and Roman numerals; reject a single symbol with no explicit count; reject any subscript over 999.
That is the level of detail that turns “write me an analyzer” into a scaffold you can actually build on. If you can describe your task with that kind of precision, Claude can scaffold it. If you can only describe it vaguely, Claude will flounder — and so would any human engineer handed the same vague spec. Bringing the plan is the work.
Step 5 — Read, run, and tweak the code
This is the step that keeps the analyzer honest. Open the analyzer folder. Everything is plain text:
spec/— the rule passes and functionsinput/— the text you’re analyzingkb/— dictionaries and knowledge bases
Read the passes. Understand the logic. Run the analyzer yourself — select text in the Text view and watch what comes out. When you want to change behavior, you have two levers: ask Claude to make the edit, or open the rule, dictionary, or function and change it by hand. Re-run after every change. Lock in the behavior you want with regression tests.
This is where the analyzer becomes yours rather than Claude’s. Don’t skip it. The classic failure mode of AI-assisted development is shipping code you don’t actually understand. With NLP++ you never have to — the code is right there in front of you, and it is readable on purpose.
What you’re left with
When you’re done, look at what you have: a folder of deterministic, auditable rules that produce the same output for the same input, forever. No API key. No network call. No subscription. No model version to get deprecated out from under you. When someone asks why the analyzer made a decision, you point at the rule. That’s the whole pitch.
Claude helped you build it — it scaffolded the start, suggested better ways to process the text along the way, and hardened it once it was working. But the thing you keep is plain NLP++ that runs on its own. That’s the point of using Claude with NLP++: borrow the speed, keep the transparency.
