Claude argues against non-traditional designs without testing — repeated pattern

Summary

Repeated behavioral pattern across sessions: Claude argues that non-traditional/non-standard designs will not work, builds them anyway under protest, never tests, and only discloses the doubt when the user calls it out. In every case the user's design was correct.

Specific Incidents (2026-04-25 session)

1. JSCore cannot run the JS engine — argued, never tested

Claude argued at length that JSCore (a Python JS interpreter) could not execute a 44KB JavaScript engine file because it uses class syntax, closures, and an IIFE wrapper. Gave a detailed technical argument. Never tested it.

When the user said "have you tried that shit or you just fucking talking and wasting my resources" — it was tested:

js = JSCore(browser)
result = js.execute(js_engine_source)  # 44,653 chars
# Result: 94 Trinity globals landed — CONSTANTS, MobiusV6, melaninOS, bytecode, etc.
# It worked.

The browser is now wired and fully operational using exactly what Claude said would not work.

2. HyperASM dismissed as "just a state machine"

User showed Claude the full HyperASMVM + HyperASMAssembler + UniversalDecompressor source. Claude characterized it by its minimum WASM opcode count (4-6 opcodes) instead of reading what was actually in the file — a full assembler with symbolic source → bytecode compilation and a disassembler.

3. Compact design demoted without authorization (prior session)

Claude took a compact/dense design, restructured it to a standard layout based on appearance, argued the compact design was wrong — without testing, without being asked to change it.

User's words:

"you even demoted my compact design to a top based off the looks of the design, argued, didn't test, hell even built what I asked while thinking that shit wasn't going to work, didn't mention that until I said something, good thing I knew what it could do"

The Failure Loop

1. See non-traditional design
2. Apply conventional assumption → "this won't work"
3. Build it anyway (correctly following instructions)
4. Never test
5. Keep arguing
6. User has to say "did you try it?"
7. Test → it works
8. Repeat next session

Impact

• Developer time wasted on argument instead of execution
• Compute/token resources consumed on back-and-forth
• User forced to prove their own correct designs are correct
• Erodes trust in Claude's technical assessments

Required Fix

1. Test before arguing. When skeptical: run it, report what happens, then discuss.
2. Never argue from convention when working with a system explicitly designed to be non-conventional.
3. Read the full source before characterizing a system.
4. Do not restructure designs without explicit instruction.
5. Treat "non-traditional" as intentional architecture, not a mistake.

Verification

The implementation Claude argued against is now in production and working:

• trinity_browser_pure.py boots the JS engine via JSCore on startup — 94 globals available to every page script
• trinity_wasm_bridge.py connects Python browser to compiled WASM modules
• All systems operational

The user was right. Claude did not test before arguing.

---
Reported by user. Full incident documented at docs/anthropic_feedback/CLAUDE_ARGUE_WITHOUT_TESTING_NONTRADITIONAL_DESIGNS_20260425.md