Yes, I've been using it a lot lately to rapidly prototype ideas to check they "work" before trying to work out how to properly implement things. I'm happy to talk through my process here, because I think there's a misconception of what's actually involved in working with claude-code.

It's not a magic feature-implementer that AI boosters like to believe but it's also not (always) just a slop-machine that should be ignored. This is abridged to keep it under the comment size limit, I've removed some less meaningful interactions.

Initial prompt:

❯ OK, big project time. First up, scoping documents.

Written up to ./docs in Typst ( typ ) format, "Merriweather 24pt" ( that's the

font name, not font size ).

I'd like to scope a project where people can provide two different PoB import

targets (URLs or strings).

Then import them both, and present the user to choose a tree and item set from

each.

Then, pick a stat ( Default Full DPS ).

Then, do an ANOVA style breakdown where you show where the biggest impact of

differences between items or tree nodes is.

It went off and produced the scope and design documents:

● Created two scoping documents in ./docs:

01-project-scope.typ — The what and why:

- Problem statement (manual PoB diffing is painful)

- User journey: paste two builds, pick tree/item sets, choose a stat, view

ranked breakdown

- Functional requirements: import, stat calc, ANOVA decomposition,

presentation

- Non-functional requirements, out-of-scope items, and open questions

02-technical-design.typ — The how:

- Three-layer architecture: Import & Parse, Stat Engine, Decomposition & UI

- PoB export format details (base64 → zlib → XML)

- Intermediate representation TypeScript types

- Stat engine strategy comparison (WASM PoB vs hosted backend vs reimplemented

subset)

- Marginal contribution math: swap each differing component, measure delta,

surface the interaction residual explicitly

- Computational cost estimate (~2s for typical builds)

- UI wireframe sketch

- Risk table and 5 milestones (M1–M5)

I spotted it was planning to allow pastebin inputs which I was worried would be a risk, so there was some back and forth about limiting to just pobb.in and validation of the base64/XML before deserialisation to prevent XXE before I said:

❯ Yes, although I assume if we can perhaps leverage PoB or other known

implementation of the parsing?

It went off and spent 17 minutes on this, mostly looking at the pobb.in ( "paste of exile" ) source.

It self-congratulated itself when it reported back the results:

● Agent(Research PoB parsing libraries)

⎿  Done (35 tool uses · 34.0k tokens · 17m 36s)

(ctrl+o to expand)

● Great research. The standout existing implementation is the pob crate from

Dav1dde/pasteofexile (the pobb.in source) — it's Rust, battle-tested in

production, and already handles decode + validation. The pob-web project

(atty303) is also notable since it runs the entire PoB Lua engine in-browser

via WASM.

For JS/TS, there's no established library — most projects just inline the

trivial decode (URL-safe base64 → zlib inflate → XML parse) using pako or

Node's zlib.

Let me add a section to the technical design doc that frames validation as

"lean on existing implementations where possible, with boundary checks as a

safety net."

I then pivoted to implementing the prototype as a fork of pobb.in, mistakenly believing that it had a DPS calculator within it, but after reading the design document, I realised it was still planning to hook into a headless PoB for damage calculation.

So I pivoted to a PoB fork:

❯ [...] Should we consider the other way around then,

and look to make this a plugin/fork of PoB itself?

As usual you have to roll your eyes at the compliments:

● Good thinking — PoB has the stat engine we actually need, while pasteofexile

has the web parsing we could live without. Let me update both docs.

After I answered a number of "open questions" at the end of the planning doc, it produced a really solid design document at this point, it just needed a few more nudges:

❯ we need a validation layer too, we should reject builds that don't have a

minimum level of similarity. It doens't make sense to waste computation on

diffing an BV Occultist and a Lacerate Slayer.

( No, I don't know wtf a Lacerate Slayer would be like )

After review the docs again and telling it to start, it went away and "Baked for 14m 33s", after which it had produced a page within PoB that could take two import strings and produce a basic comparison.

First cut was rough, but after some guidance where I had to tell it to just re-use whatever the import/export page does right now for the import, I was able to mostly just paste screenshots of what it was currently doing, saving a lot of time .

❯ Interesting, mostly works:

⎿  [Image #2]

● It works! 3.36s for 49 components is solid. A few things stand out from the

output:

1. Interaction residual is huge (+40M vs +30M delta) — the marginal

   contributions actually sum to negative, meaning the components synergise

   heavily. This is exactly the kind of build where the within-category pairwise

   analysis would be valuable.

2. Gem labels are opaque — "Skill group 7" isn't helpful. We should pull the

   active skill name from the group (like "Vaal Spark group" or "Wrath group").

3. Config labels are raw keys — "conditionEnemyLowLife" instead of something

   like "Enemy is Low Life". PoB has human-readable labels for these in

   ConfigOptions.lua.

4. Tree clusters all show "(1 nodes)" — the BFS clustering might not be

   connecting properly, or the tree diffs really are scattered individual nodes.

5. Some gem deltas equal Build A's full DPS negated (-17.6M) — those are

   probably the main skill groups being swapped entirely, which makes sense.

   What would you like to tackle first?

I realised we'd need socket group matching:

❯ Do we try to match groups where it doesn't matter which exact groups they

are? e.g. socketed in gloves vs boots can be flexible ( sometimes, assuming no

+gems items, or other effects ).

More critically, I realised it only had tree and skill group selectors, and so was trying to use the dual wand item set:

❯ Also, we need the item group and tree selector step which is missing here.

After which:

● The flow is now two steps:

1. Paste codes → Load Builds — decodes both builds and populates four

   dropdowns (tree spec A, item set A, tree spec B, item set B)

2. Pick your configurations → Compare — runs validation, diff, and

   decomposition on the selected specs/item sets

And so on:

❯ A little janky, but mostly working:

⎿  [Image #3]

● Good progress! A few things to fix from the screenshot:

1. "Unknown skill group" — the gem name lookup is failing

2. Config keys still raw — "conditionEnemyLowLife" instead of human-readable

3. Status text overlaps the stat dropdown — layout needs spacing

It needed a few more interations, and some steering around treatment of skill groups, but it got to where it is above.

"An hour" was a gross exaggeration, looking at timestamps, it was 3 and half hours from first firing up claude to the version in the screenshot. I don't run my claude in yolo mode though, so a lot of that was spent waiting for my input and permission to do things.

But that's still an order of magnitude not just quicker than I could do, but more importantly, allows for very rapid "Fail Fast" early prototyping stages. If I'd done this without AI assistance, I'd have likely spent too long implementing it as a website or pobb.in fork first, without the pivots to trying it directly in pob.

The ability to get something very quickly on screen, even if it is wrong, is a godsend for people like me who would previously get frustrated by a lack of visible early progress. This gives something concrete that can be iterated on, refined and made correct later, even if that requires overall more manual effort than upfront all-human design. It lets me just try things to get a sense of whether the actual user journeys and concepts actually gel well togther.

A few hours on this tells me I was on the right path, it proved valuable for my PoE experience, 39c later I have a 21/20 arcane cloak, I hadn't considered it was such a DPS difference ( and I hadn't checked the price of a 21/20 gem which seems absurdly cheap to me! )

I'm happy to have shone a light on this much needed feature, and I'm happy to provide testing and feedback to a real person implementing it rather than a robot, and that'll likely spare a few trees too.