Forem: Rad Code

The Case of the Missing Proxy: When Multiple Valtio Instances Broke My App

Rad Code — Sun, 09 Nov 2025 14:24:55 +0000

This debugging story is from the do-not-stop project - a full-stack Web3 app with React frontend, React Native mobile frontend, Node.js backend, and multi-blockchain smart contracts.

The Mystery Begins

It all started with a crash in @reown/appkit-react-native. While debugging that crash, I noticed something weird happening with valtio. The subscribe() function seemed to work fine, but proxy() wasn't behaving as expected. I decided to dig into the library code itself and added some debugging directly in node_modules/valtio/vanilla.js.

I printed proxyStateMap.get(proxyObject) in both functions, and that's when things got interesting:

In proxy(): Got the correct value ✓
In subscribe(): Got undefined ✗

Wait, what? They were completely different WeakMap instances from different valtio module instances! The proxy object was being stored in one proxyStateMap, but when subscribe() tried to find it, it was looking in a completely different proxyStateMap from a different valtio instance. That's like putting your keys in one drawer and looking for them in another.

A Quick Note on Debugging Library Code

Before I continue, here's something I had to remember: when you're adding console.log statements to library code in node_modules, your logs might not show up because modules get cached. I spent way too long wondering why my logs weren't appearing before I remembered to run:

pnpm start --reset-cache

Adding logs directly to library code is actually super helpful when you're dealing with weird behavior - you can see exactly what's happening inside the library, trace the execution flow, and peek at internal state that's not exposed through the public API. Just don't forget to clear that cache!

Going Back in Time

At this point, I was stuck. The code was working before, so what changed? I did what I should have done from the start: I checked git history.

I went through past commits one by one until I found a commit where everything worked. Then I compared the diff between the working state and the broken state. Bingo - there it was, a single line change in .npmrc:

+ node-linker=hoisted

That one line was the culprit.

What Actually Happened

After adding node-linker=hoisted, pnpm switched to a flat structure similar to npm, and that broke the sharing mechanism by creating separate valtio instances:

node_modules/valtio (version 1.13.2)
node_modules/@reown/appkit-core-react-native/node_modules/valtio (version 2.1.8)
node_modules/@reown/appkit-react-native/node_modules/valtio (version 2.1.8)

Why did this happen? A few reasons:

Version mismatch: The root had 1.13.2 (some transitive dependency), while the nested packages needed 2.1.8
No virtual store: With node-linker=hoisted, pnpm doesn't use the .pnpm virtual store structure that ensures proper symlinking
pnpm kept them separate to avoid conflicts

Since they were using different valtio instances, and each instance had its own proxyStateMap WeakMap, the proxy object stored in one proxyStateMap wasn't found when subscribe() looked in a different proxyStateMap.

The Fix

The solution was to force all valtio dependencies to use the same version. I added this to my root package.json:

{
  "pnpm": {
    "overrides": {
      "valtio": "2.1.8"
    }
  }
}

Then ran pnpm install, and that was it. This:

Unified all valtio to 2.1.8
Allowed pnpm to hoist it to the root
Removed the nested instances
Made all packages share the same proxyStateMap

Alternatively, I could have just removed node-linker=hoisted to go back to pnpm's default virtual store, which handles this automatically. But I needed the hoisted structure for other reasons, so the override approach worked better for me.

Key Takeaways

Check git history first - When something breaks, see what changed. The diff often reveals the root cause immediately.
Adding console.log to library code is a good debugging habit - When you encounter weird library behavior, adding logs directly in node_modules can reveal exactly what's happening inside the library. Just remember to use --reset-cache when debugging library code in node_modules to see your changes.
Multiple package instances can break singleton-like behavior - Libraries that rely on WeakMaps, module-level state, or singletons can fail when multiple instances exist. This isn't just a valtio thing - it can happen with any library that maintains internal state.
Version mismatches prevent hoisting - Even with node-linker=hoisted, pnpm will keep separate instances if versions differ. Use pnpm.overrides to force consistent versions across your workspace.

Happy debugging!

React Native, pnpm, and Monorepos: A Dependency Hoisting Journey

Rad Code — Wed, 05 Nov 2025 05:16:50 +0000

TL;DR

When working with React Native and pnpm, just use node-linker=hoisted instead of trying to selectively hoist individual packages. It will save you hours of debugging mysterious codegen errors and Kotlin compilation issues. (If you're in a monorepo, you'll also need to update build.gradle paths to point to the root node_modules.)

The Setup

I'm working on a React Native 0.82 project in a pnpm monorepo. The structure looks like this:

do-not-stop/
├── mobile/          # React Native app
├── frontend/        # Web app
├── backend/         # API server
├── packages/        # Shared packages
└── package.json     # Root workspace

The Problem

During an Android build, I encountered this error:

Error: Cannot find module 'E:\git\do-not-stop\mobile\node_modules\@react-native\codegen\lib\cli\combine\combine-js-to-schema-cli.js'

The build was failing at the generateCodegenSchemaFromJavaScript task for @react-native-async-storage/async-storage. Classic React Native codegen issues.

The Initial "Solution" (That Didn't Work)

Following the conventional wisdom, I added the missing packages to mobile/package.json:

{
  "dependencies": {
    "@react-native/codegen": "^0.82.1",
    "@react-native/gradle-plugin": "^0.82.1"
  }
}

This seemed logical - the build needs these packages, so let's add them as dependencies. Right?

Wrong.

The Rabbit Hole Deepens

After adding these dependencies, I started getting Kotlin compilation errors:

Unresolved reference 'NativeRNWalletConnectModuleSpec'
'getName' overrides nothing
'getTypedExportedConstants' overrides nothing

The errors were coming from @walletconnect/react-native-compat, which was trying to use codegen-generated classes that weren't being found.

Attempting Selective Hoisting

I tried selective hoisting - first with a simple hoistPattern in package.json (which created even more issues with inconsistent paths and module resolution), then with a more sophisticated public-hoist-pattern configuration in .npmrc that others claim works. Here's the more comprehensive example:

# .npmrc

# so gradle / metro can see my local package
hoist-workspace-packages=true
public-hoist-pattern[]=@myOrg/sharedPackage

# so gradle and metro can see various cli tools and settings
public-hoist-pattern[]=@react-native-community/*
public-hoist-pattern[]=react-native
public-hoist-pattern[]=@react-native/codegen
public-hoist-pattern[]=@react-native/gradle-plugin
public-hoist-pattern[]=@babel/runtime

# i happen to be using this, and it has a complex native build step that didn't work without this hoist.
# might be true for other packages that have native build steps
public-hoist-pattern[]=react-native-gesture-handler

This configuration uses public-hoist-pattern (instead of hoistPattern in package.json) and includes workspace packages, a broader set of React Native packages, and packages with native build steps. But it still didn't work for me. This is exactly the problem with selective hoisting - even configurations that work for others can fail in your specific setup because:

React Native versions differ
Dependency trees vary based on your packages
Build tools evolve and change their expectations
Native modules have different requirements

If a configuration this comprehensive still fails, it's a clear sign that selective hoisting is fragile and outdated. The fact that it works for some but not others is precisely why full hoisting is the safer choice.

The Real Solution

After hours of debugging, I finally gave up on selective hoisting and went nuclear:

Added .npmrc at the root:

node-linker=hoisted

The hoisted linker ensures all packages are in a single node_modules directory, which React Native's build system expects.

For pnpm monorepos specifically, updated mobile/android/app/build.gradle to point to the root node_modules:

react {
    // Point to root node_modules since we're using hoisted linking in a monorepo
    reactNativeDir = file("../../../node_modules/react-native")
    codegenDir = file("../../../node_modules/@react-native/codegen")
    cliFile = file("../../../node_modules/react-native/cli.js")

    autolinkLibrariesWithApp()
}

The paths go up three levels because:

mobile/android/app/build.gradle → mobile/android/ → mobile/ → root

Note: If you're using pnpm with a standalone React Native project (not a monorepo), you only need the .npmrc change. The build.gradle modifications are only necessary when your React Native app is nested in a monorepo structure.

The Lesson

Selective hoisting in React Native projects using pnpm is a false optimization. You might think: "Couldn't I just track down all the React Native-related packages that need hoisting?" Technically, yes - you could spend hours finding @react-native/codegen, @react-native/gradle-plugin, @react-native/metro-config, @react-native/babel-preset, and all the other RN packages. But React Native's dependency structure changes frequently between versions. What works today might break tomorrow when you upgrade React Native or one of its tooling packages. You'd be playing whack-a-mole with your hoist patterns every time you update.

React Native's build system expects a certain structure. When you have Gradle looking for codegen, Metro bundler resolving modules, native code trying to import generated classes, and multiple tools working together, you need consistency, not clever path resolution. Hoisting everything gives you that consistency, and it's future-proof.

That said, if you really want to save disk space and are willing to maintain a selective hoisting configuration with pnpm's hoistPattern or public-hoist-pattern and symlinking strategies, it's technically possible. But this requires deep knowledge of React Native's dependency graph, ongoing maintenance as packages update, and potential debugging time when things break.

If you've successfully set up selective hoisting for React Native with pnpm and want to help others, please share your configuration in the comments! Include your .npmrc settings, package.json hoist patterns, and any build.gradle modifications you made.

Conclusion

Next time you're setting up a React Native project with pnpm, just hoist everything from the start. Your builds will be reliable, and your debugging time will be spent on actual features, not dependency resolution.

This article is part of the do-not-stop project - a full-stack Web3 playground with React Native mobile support.

Have you had similar experiences with React Native and pnpm? Share your horror stories (and solutions) in the comments!

Why AI Needs Human Oversight for Architecture: A Real Refactoring Story

Rad Code — Sun, 02 Nov 2025 10:37:21 +0000

How a simple authentication refactor taught me that AI assistants are great at code, but need human guidance for architectural decisions

This article is based on my experience refactoring the authentication system in the heyradcode/do-not-stop project.

The Task

I had a shared authentication package (@do-not-stop/shared-auth) that was being used by both my frontend (React web) and mobile (React Native) apps. Interestingly, this package was originally created by my AI assistant during a "vibe coding" session - I was just going with the flow and letting it build the structure. The code had some duplication - both projects were manually wiring up the same hooks and API clients. Simple task: consolidate the duplicated code.

What the AI Suggested First

When I asked my AI assistant to consolidate, it immediately jumped to a factory pattern:

// AI's first suggestion
export const createEthereumAuth = ({ apiUrl, storageAdapter }) => {
  const apiClient = createAuthApiClient(apiUrl);
  const useNonce = createUseNonce(apiClient);
  const useVerifySignature = createUseVerifySignature(apiClient, onTokenSuccess);

  const AuthProvider = createAuthProvider({
    useAccountHook: useAccount,
    useSignMessageHook: useSignMessage,
    useNonce,
    useVerifySignature,
    storageAdapter,
  });

  return { AuthProvider, useNonce, useVerifySignature };
};

At first glance, this seems reasonable. It removes duplication, right? But it's still passing everything around. The AI assistant kept adding layers:

Factory functions that return other factories
Parameters that get passed through multiple levels
"Backward compatibility" exports "just in case"
Bridge files that re-export things

The Human Intervention

When I looked at the code, I kept asking simpler questions:

"Why do we need createAuthProvider? Can't we just use AuthProvider directly?"

"Why pass apiClient when we can set it globally and reuse it?"

"Why re-export hooks through bridge files when we can import directly?"

Each question stripped away another unnecessary layer.

The Final Solution

Instead of factories and parameters, we used global configuration:

// config.ts - configure once
setApiBaseUrl(API_URL);
setTokenSuccessCallback(callback);
setStorageAdapter(adapter);

// AuthContext.tsx - just use directly
import { useAccount, useSignMessage } from 'wagmi';
import { useNonce, useVerifySignature } from '../hooks';

export const AuthProvider = ({ children }) => {
  const { address } = useAccount();  // No parameters!
  const { signMessage } = useSignMessage();
  // ...
}

// App.tsx - simple import
import { AuthProvider } from '@do-not-stop/shared-auth';

The difference:

❌ Before: Factory pattern, 6+ parameters, bridge files, re-exports
✅ After: Global setters, direct imports, zero parameters

The Final Architecture I ended up with:

packages/shared-auth/
  ├── api.ts              # Singleton API client
  ├── hooks/
  │   ├── useNonce.ts     # Direct hook (uses shared client)
  │   └── useVerifySignature.ts
  └── contexts/
      └── AuthContext.tsx # Direct component (uses hooks directly)

frontend/src/config.ts    # setApiBaseUrl(), setStorageAdapter()
mobile/src/config.ts      # Same, different adapter

App.tsx                   # import { AuthProvider } from 'shared-auth'

Zero factories. Zero parameters. Zero bridge files.

What I Learned

The breakthrough questions I kept asking were all about simplification:

"Can this be removed?" - I asked about every layer, every file, every export
"Why pass this as a parameter?" - When the AI suggested passing hooks, I asked why not import directly
"Where is this actually used?" - I found many files that were just re-exporting
"What's the minimum I need?" - I stripped it down to just configuration + direct usage

Conclusion

AI is excellent at:

Writing code
Implementing patterns it's seen before
Fixing syntax errors
Refactoring within existing patterns

AI struggles with:

Questioning whether patterns are needed
Simplifying beyond existing patterns
Understanding when "less is more"
Architectural judgment

The solution? Use AI for implementation, but keep a human in the loop for architectural decisions. When AI suggests adding complexity, ask: "Can I do this more simply?"

The best code is often the code you don't write. AI doesn't always know that.

This article is based on my real refactoring session with an AI coding assistant while working on the heyradcode/do-not-stop project. The authentication system works great now, and the codebase is simpler than when I started.

Surviving pnpm + React Native: How I Finally Stopped Metro from Screaming About `@babel/runtime`

Rad Code — Thu, 30 Oct 2025 12:53:21 +0000

Do-Not-Stop is a continuously evolving Web3 frontend playground — built with Vite, React, TypeScript, viem, and wagmi.

It’s designed to grow, adapt, and experiment with the latest in Ethereum, Solana, and React Native development — a living project that explores how a single modern codebase can span web and mobile in the Web3 space.

Naturally, I used pnpm workspaces. They’re fast, clean, and perfect for sharing code between multiple projects.

Until Metro — React Native’s bundler — decided it hated my setup.

🏗 The Setup

do-not-stop/
├─ frontend/              ← web (Vite + React + wagmi)
├─ mobile/                ← React Native
├─ packages/shared-auth/  ← shared logic between web & mobile
└─ pnpm-workspace.yaml

The goal was simple: import packages/shared-auth into both web and mobile.

Everything looked good — pnpm install was blazing fast, dependencies deduped — until Metro threw this:

Error: Unable to resolve module @babel/runtime/helpers/interopRequireDefault

Even though mobile/node_modules/@babel/runtime clearly existed.

🧩 Where Everything Fell Apart

Here’s the thing about pnpm: it doesn’t install packages “flat” like npm or yarn.

Instead, it builds a virtual store under .pnpm/ and links everything through symlinks.

Example:

mobile/node_modules/@babel/runtime
  → ../../node_modules/.pnpm/@babel+runtime@7.x/node_modules/@babel/runtime

Node can follow that fine, but Metro’s resolver often doesn’t.

It just climbs directories until it finds a node_modules, so it ends up loading stuff from the workspace root, not from the mobile app’s local copy.

🧠 I Tried Everything First

When you start googling “pnpm react native @babel/runtime,” you end up in GitHub issues and Stack Overflow threads full of half-solutions.

I tried disabling hoisting:

hoistPattern: []

Then isolating linkers:

node-linker=isolated

Then the nuclear option:

shamefully-hoist=true

Each time, something else broke — either the mobile build, or the shared packages stopped linking, or Metro just refused to cooperate.

Nothing really fixed it.

⚙️ The Real Fix — Teach Metro to Understand pnpm

The problem wasn’t pnpm.

The problem was Metro’s assumptions.

It expects a flat node_modules world, but pnpm builds a smart, symlinked tree.

So instead of forcing pnpm to behave like npm, I made Metro understand pnpm.

Here’s the final working metro.config.js inside my mobile/ folder:

const path = require('path');
const { getDefaultConfig, mergeConfig } = require('@react-native/metro-config');

/**
 * Metro configuration for pnpm monorepos
 * (do-not-stop project)
 *
 * - Lets Metro follow pnpm's symlinks
 * - Always prefers the mobile app's own node_modules
 * - Watches the monorepo root so shared packages rebuild correctly
 */
const defaultConfig = getDefaultConfig(__dirname);

const config = {
  watchFolders: [path.resolve(__dirname, '..')],
  resolver: {
    ...defaultConfig.resolver,
    unstable_enableSymlinks: true,
    unstable_enablePackageExports: true,
    extraNodeModules: new Proxy(
      {},
      {
        get: (_target, name) =>
          path.join(__dirname, 'node_modules', String(name)),
      }
    ),
  },
};

module.exports = mergeConfig(defaultConfig, config);

🧪 Bonus: Using Shared Packages

Because watchFolders includes the repo root, Metro can detect changes in packages/shared-auth/ (or any shared package).

If you want finer control:

watchFolders: [
  path.resolve(__dirname, '..', 'packages', 'shared-auth'),
  path.resolve(__dirname, '..', 'packages', 'utils'),
],

🧠 Takeaways

pnpm’s layout isn’t broken — it’s just smarter than Metro expects.
Disabling hoisting or flattening installs only hides the issue.
The real solution lives in Metro’s resolver config, not your package manager.
When mixing web + mobile in a single repo, configure your tools to coexist — not compete.

🎉 Conclusion

This setup now powers do-not-stop:

A React web app (frontend/)
A React Native app (mobile/)
Shared code in packages/shared-auth/
All managed by pnpm

Do-Not-Stop isn’t just a playground anymore — it’s an evolving multi-platform Web3 stack that grows alongside the latest in Ethereum, Solana, and modern React development.

After a week of battling hoisting, symlinks, and Babel errors, I stopped fighting pnpm and just made Metro smarter.

If you’re running React Native inside a pnpm monorepo, drop this config in your app and get back to building 🚀

How to Build a Persistent Solana Docker Dev Setup (No WSL!)

Rad Code — Sat, 11 Oct 2025 03:10:10 +0000

Chapter 1 — The Goal

The objective was to create a reliable, persistent Solana development environment that runs natively on Windows, without depending on the Windows Subsystem for Linux (WSL).

While WSL can be useful, it often introduces file system latency, permission inconsistencies, and integration issues with Docker Desktop. The goal was to achieve a seamless workflow using Docker alone — fully isolated, reproducible, and stable.

This setup is now part of the do-not-stop project — a long-term initiative to define a consistent, modern development standard for Web3.

The project aims to demonstrate how ecosystems such as Ethereum, Solana, and eventually Cardano can coexist within a unified, practical environment that supports real-world development workflows.

Chapter 2 — The Starting Point

The foundation came from the tchambard/solana-test-validator image — a prebuilt Solana development image that includes:

Solana CLI
Rust toolchain
A fully functional solana-test-validator

Credit goes to @tchambard for providing this image. It’s lightweight, well-prepared, and an excellent baseline for any Solana development workflow.

Initially, the idea was to isolate responsibilities across multiple Docker services — one for the validator, another for Solana CLI, and perhaps a third for project logic. However, Solana’s toolchain and CLI are tightly coupled. Separating them would introduce unnecessary complexity, requiring multiple shared volumes and synchronized builds.

Consolidating everything into a single service proved more effective. It ensured that the validator, CLI, and supporting dependencies operated in a consistent and predictable environment.

Chapter 3 — The Permission Model

The first issue encountered involved filesystem permissions when working with bind mounts from Windows.

The container was configured to mount the project source:

- ./cryptozombies:/home/ubuntu/cryptozombies

However, any write operation — such as building or generating artifacts — resulted in permission errors:

EACCES: permission denied, mkdir '/home/ubuntu/cryptozombies/target'

This occurs because NTFS-based volumes mounted through Docker Desktop are owned by the root user inside the Linux container. The default ubuntu user inside the image lacks write privileges for these mounts.

The solution was straightforward and justified:

user: root

Running as root allowed the container to write to bind-mounted directories, resolving the issue without introducing unsafe behavior.

This is not a workaround — it is the correct approach when dealing with Docker bind mounts on Windows, where file ownership cannot be translated directly from the host.

After this change, the environment functioned as expected. Builds, validator logs, and temporary files all wrote correctly to the mounted project directory.

Chapter 4 — The Platform Tools Discovery

The next challenge appeared when repeatedly running Solana commands inside the container.

Each time solana-test-validator or a build was executed, Solana re-downloaded large SDK archives such as:

tmp-platform-tools-linux-x86_64.tar.bz2

The downloads were redundant. Even after adding a named volume to persist Solana’s installation directory, the issue persisted.

- solana-install:/home/ubuntu/.local/share/solana/install

This volume behaved as expected: Docker seeded it with the Solana CLI that already existed inside the base image. The CLI itself worked correctly after each restart — a clear sign that the seeding process was functioning as intended.

However, the platform toolchain and SDK assets continued to be re-downloaded on every startup.

To understand why, the next step was to trace the actual file paths used by Solana during installation.

Inside the install directory, the following path appeared:

/home/ubuntu/.local/share/solana/install/releases/2.3.7/solana-release/bin/platform-tools-sdk/sbf/dependencies/platform-tools

On inspection, this path was not a directory but a symbolic link:

platform-tools -> /root/.cache/solana/v1.48/platform-tools

This detail was critical.

While the main Solana binaries lived under the persisted install directory, the SDK and toolchains were stored separately under /root/.cache/solana.

Because /root/.cache was not mounted as a volume, it was cleared each time the container restarted. As a result, the symbolic link pointed to a non-existent path, prompting Solana to re-download all dependencies.

The resolution was simple:

- solana-cache:/root/.cache/solana

This ensured that Solana’s cached SDKs and platform-tools persisted across restarts, eliminating unnecessary downloads and improving startup performance dramatically.

Chapter 5 — The Final Configuration

Below is the finalized Docker Compose configuration that encapsulates the complete solution:

services:
  solana-dev:
    image: tchambard/solana-test-validator:latest
    container_name: solana-dev
    user: root
    ports:
      - "8899:8899"
      - "8900:8900"
      - "9900:9900"
    volumes:
      - ./cryptozombies:/home/ubuntu/cryptozombies
      - solana-cache:/root/.cache/solana
    working_dir: /home/ubuntu
    command: >
      sh -c "
        solana-test-validator --reset --rpc-port 8899 --bind-address 0.0.0.0 &
        sleep 10 &&
        tail -f /dev/null
      "
    environment:
      - RUST_LOG=warn
      - TMPDIR=/tmp
    networks:
      - solana-network
    healthcheck:
      test: [ "CMD", "curl", "-f", "http://localhost:8899/health" ]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 30s

networks:
  solana-network:
    driver: bridge

volumes:
  solana-cache:

This configuration delivers a self-contained Solana development environment with persistent volumes for both the Solana installation and its cached toolchain. It’s efficient, reproducible, and compatible with Docker Desktop on Windows without WSL.

Chapter 6 — The Broader Vision

This setup now serves as part of the do-not-stop project — a practical foundation for cross-chain Web3 development.

The goal is to provide developers with a consistent environment that supports multiple blockchain ecosystems simultaneously, ensuring that:

Toolchains remain stable and cached between runs.
Source code is editable directly from the host machine.
Builds and validators execute identically across operating systems.

This approach promotes a unified development experience that reduces friction and eliminates environment drift.

Key Takeaways

WSL is not required. Docker Desktop provides sufficient isolation for Windows-based Solana development.
Running as root is the correct approach for handling NTFS-mounted volumes.
Persist both:
- /home/ubuntu/.local/share/solana/install (Solana CLI)
- /root/.cache/solana (SDKs and platform-tools)
Docker’s named volume seeding ensures that existing image content is copied into new volumes on first run.

Conclusion

This setup represents a methodical exploration of how Solana’s toolchain interacts with Docker under Windows.

By identifying the symbolic link to /root/.cache/solana and ensuring that both the installation and cache directories are persisted, the environment achieves complete reproducibility and fast startup times.

The resulting configuration is stable, efficient, and ready to serve as a reference for modern Web3 developers.

It’s one step toward the broader goal of do-not-stop — establishing clear, reliable examples of how Web3 infrastructure should be built.

The Reality Check: Why AI Coding Assistants Still Need Human Oversight

Rad Code — Tue, 23 Sep 2025 09:48:43 +0000

A cautionary tale about trusting Cursor's AI too much and the importance of understanding your tools

The Setup

Recently, I was working on a Web3 authentication flow using React, wagmi, and a Node.js backend. The goal was simple: connect wallet → sign message → verify signature → get JWT token. Sounds straightforward, right?

The Problem

The authentication flow wasn't working correctly. When users clicked "Sign Message & Login", the backend verification API was being called immediately, before the user had actually signed anything in MetaMask. This was clearly wrong.

The AI's "Solution"

I asked Cursor's AI assistant to fix this issue. Here's what happened:

First Attempt: The Async/Await Mistake

// AI's initial "fix"
const signature = await signMessage({ message });

The AI assumed signMessage was an async function and tried to await it. This was completely wrong.

Second Attempt: Still Not Getting It

// AI's second attempt - still wrong
const { signMessage, isPending } = useSignMessage();
// ... later
const signature = await signMessage({ message }); // Still trying to await!

The AI was still treating signMessage as if it returned a Promise, even after I pointed out it wasn't async.

Third Attempt: Finally Understanding the Hook Pattern

Only after I explicitly explained that signMessage is a function from a React hook (not an async function) did the AI implement the correct pattern:

// Correct implementation
const { signMessage, isPending, data: signature, error: signError } = useSignMessage();

// Use useEffect to listen for signature completion
useEffect(() => {
  if (signature && pendingNonce && address) {
    handleSignatureComplete(signature, pendingNonce, address);
  }
}, [signature, pendingNonce, address]);

// Trigger signing (non-blocking)
const handleSignAndLogin = async () => {
  // ... get nonce
  signMessage({ message }); // This triggers MetaMask popup
  // Don't await this - it's not async!
};

Why This Happened

1. Pattern Recognition vs. Understanding

The AI recognized common patterns (async/await for API calls) but didn't understand the specific React hook pattern for useSignMessage. It applied the wrong mental model.

2. Lack of Context Awareness

Even when I mentioned "wagmi hook", the AI didn't connect this to the specific behavior of React hooks that trigger side effects rather than return promises.

3. Overconfidence in Initial Solutions

The AI presented its first solution with confidence, making it seem like the correct approach. This can lead developers to trust the solution without questioning it.

The Correct Solution

Here's how the authentication flow should actually work:

const { signMessage, isPending, data: signature, error: signError } = useSignMessage();

// Listen for signature completion
useEffect(() => {
  if (signature && pendingNonce && address) {
    handleSignatureComplete(signature, pendingNonce, address);
  }
}, [signature, pendingNonce, address]);

const handleSignAndLogin = async () => {
  setLoading(true);
  try {
    // Get nonce from backend
    const { data } = await axios.get('/auth/nonce');
    const { nonce } = data;

    // Store nonce for later use
    setPendingNonce(nonce);

    // Create message to sign
    const message = `Sign this message to authenticate: ${nonce}`;

    // Trigger signing (shows MetaMask popup)
    signMessage({ message });

  } catch (error) {
    setLoading(false);
    // Handle error
  }
};

const handleSignatureComplete = async (signature, nonce, address) => {
  try {
    // Verify signature with backend
    const { data: authData } = await axios.post('/auth/verify', {
      address,
      signature,
      nonce
    });

    if (authData.success) {
      // Store JWT and update UI
      localStorage.setItem('authToken', authData.token);
      setUser(authData.user);
      setIsAuthenticated(true);
    }
  } catch (error) {
    // Handle verification error
  } finally {
    setLoading(false);
    setPendingNonce(null);
  }
};

Conclusion

Cursor's AI assistant is a powerful tool, but it's not a senior developer. It can help with:

✅ Code generation
✅ Pattern suggestions
✅ Boilerplate reduction
✅ Documentation

But it struggles with:

❌ Complex architectural decisions
❌ Domain-specific patterns
❌ Understanding context deeply
❌ Making critical business logic decisions

The key takeaway: Use Cursor's AI as a powerful junior developer that needs constant oversight, not as a replacement for understanding your code and your tools.

Always question, always test, and always understand what you're building. The AI might write the code, but you're responsible for making sure it works correctly.

Have you had similar experiences with Cursor or other AI coding assistants? Share your stories in the comments below!

Comparing Web3 Wallet Onboarding: Dynamic.xyz, Web3Auth.io, and Privy.io

Rad Code — Tue, 23 Sep 2025 07:20:36 +0000

Wallet onboarding solutions have improved significantly over the last couple of years. While Dynamic.xyz has been a popular option, there are some differences in behavior across platforms that are worth noting.

Observed Behavior on Disconnect

One example is how wallet disconnections are handled in MetaMask. In @dynamic-labs/sdk-react-core@4.32.0, the useIsLoggedIn() hook does not update to false when disconnecting a wallet. This behavior is noticeable not just in code but also on the Dynamic.xyz demo website, where disconnecting the wallet does not log out the user automatically.

In contrast, both Privy.io and Web3Auth demos handle disconnects as expected, updating the state and logging the user out when the wallet is disconnected.

Why Web3Auth and Privy.io Are Favorable Choices

Web3Auth

Developed by the Metamask team.
Offers reliable wallet disconnection handling.
Supports social login flows alongside decentralized wallets.
Provides cross-platform support including browser, mobile, and Unity.

Privy.io

Developed and backed by Stripe.
Handles wallet disconnections reliably.
Supports account abstraction and embedded wallets.
Focuses on privacy-first authentication and encrypted data management.

From a personal perspective, backing by well-known teams adds confidence in terms of long-term support and reliability.

Summary Comparison

Feature	Dynamic.xyz	Web3Auth	Privy.io
Wallet disconnect sync	Does not update	Yes	Yes
Social login	Limited	Yes	Yes
Account abstraction	Partial	Optional	Default
Reliability	Generally good	Strong	Strong
Backed by popular teams	Medium	Metamask team	Stripe

Conclusion

All three platforms offer wallet onboarding capabilities, but Web3Auth and Privy.io provide additional confidence with reliable disconnect handling and backing from prominent teams. They are favorable choices if you want consistent user experience and support for both social and decentralized login flows.

Dynamic.xyz Demo | Web3Auth Demo | Privy.io Demo

Treat ChatGPT Like a Junior Dev: Helpful, But Needs Review

Rad Code — Thu, 18 Sep 2025 16:56:17 +0000

AI coding assistants like ChatGPT are everywhere now. They can scaffold components, generate test cases, and even debug code. But here’s the catch: they’re not senior engineers. They don’t have context of your project history, and they don’t automatically spot when the tests themselves are wrong.

In other words: treat ChatGPT like a junior dev on your team — helpful, but always needing review.

My Experience: Fixing Legacy Code Against Broken Tests

I was recently working on a legacy React form validation feature. The requirements were simple:

Validate name, email, employee ID, and joining date.
Show error messages until inputs are valid.
Enable submit only when everything passes.

The tricky part? I didn’t just have to implement the form — I had to make it pass an existing test suite that had been written years ago.

I turned to ChatGPT for help, thinking it could quickly draft a working component. It generated a solution — but when I ran the tests, they kept failing.

At first, I thought maybe I had misunderstood the requirements, so I asked ChatGPT to debug. We went back and forth multiple times. I provided more context, clarified each input validation rule, and even explained what the error messages should be. ChatGPT suggested fixes each time, but none of them worked.

It wasn’t until I dug into the test suite myself that I realized the real problem: the tests were wrong.

The Test That Broke Everything

One test hard-coded "2025-04-12" as a “future date”:

changeInputFields("UserA", "user@email.com", 123456, "2025-04-12");
expect(inputJoiningDate.children[1])
  .toHaveTextContent("Joining Date cannot be in the future");

The problem? We’re already past April 2025. That date is no longer in the future, so the expected error message would never appear. The component was fine — the tests were broken.

I had to dig through the logic, analyze the assumptions, and rewrite the test with relative dates, like so:

// Corrected test using relative dates
const futureDate = new Date();
futureDate.setDate(futureDate.getDate() + 30); // always 30 days ahead
const futureDateStr = futureDate.toISOString().slice(0, 10);

changeInputFields("UserA", "user@email.com", 123456, futureDateStr);
expect(
  screen.getByText("Joining Date cannot be in the future")
).toBeInTheDocument();

This small change makes your test time-proof, so it will work regardless of the current year.

Lessons Learned

AI will follow broken requirements blindly ChatGPT can’t tell that a test is logically invalid. It will try to satisfy the failing test, even if the test itself makes no sense.
Treat output like a junior PR ChatGPT’s suggestions were helpful as scaffolding, but it struggled to see the root cause. I had to step in, dig through the legacy code, and analyze the tests myself.
Tests can rot too Hard-coded dates, magic numbers, or outdated assumptions make test suites brittle. If the tests are wrong, no amount of component fixes will help.
Relative values keep tests reliable Replace absolute dates or values with calculations relative to today. This ensures your tests work across time.

How to Work Effectively With AI Tools

Give context, but don’t rely on it to reason like a senior dev.
Ask “why”, and inspect its explanations carefully.
Validate everything yourself — especially when working with legacy code.
Iteratively refine — use AI as scaffolding, but you own the fix.

Closing Thoughts

My experience taught me a simple truth: AI can accelerate coding, but it cannot replace human judgment, especially when dealing with messy, legacy code and outdated tests.

Treat ChatGPT like a junior teammate:

Helpful, eager to please, fast.
Sometimes confidently wrong.
Needs review, oversight, and occasionally, a reality check.

If you keep that mindset, you’ll get the productivity boost without blindly following bad guidance — and you’ll know when to dig in yourself.

💡 Takeaway: When working with code, the human developer is still the ultimate problem-solver. AI is there to assist, not to replace your reasoning.