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

When AI Refactors Your Code, But You Have to Refactor Its Architecture

2025/11/03 13:17

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:

  1. "Can this be removed?" - I asked about every layer, every file, every export
  2. "Why pass this as a parameter?" - When the AI suggested passing hooks, I asked why not import directly
  3. "Where is this actually used?" - I found many files that were just re-exporting
  4. "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.

Disclaimer: The articles reposted on this site are sourced from public platforms and are provided for informational purposes only. They do not necessarily reflect the views of MEXC. All rights remain with the original authors. If you believe any content infringes on third-party rights, please contact [email protected] for removal. MEXC makes no guarantees regarding the accuracy, completeness, or timeliness of the content and is not responsible for any actions taken based on the information provided. The content does not constitute financial, legal, or other professional advice, nor should it be considered a recommendation or endorsement by MEXC.

You May Also Like

The Future of Secure Messaging: Why Decentralization Matters

The Future of Secure Messaging: Why Decentralization Matters

The post The Future of Secure Messaging: Why Decentralization Matters appeared on BitcoinEthereumNews.com. From encrypted chats to decentralized messaging Encrypted messengers are having a second wave. Apps like WhatsApp, iMessage and Signal made end-to-end encryption (E2EE) a default expectation. But most still hinge on phone numbers, centralized servers and a lot of metadata, such as who you talk to, when, from which IP and on which device. That is what Vitalik Buterin is aiming at in his recent X post and donation. He argues the next steps for secure messaging are permissionless account creation with no phone numbers or Know Your Customer (KYC) and much stronger metadata privacy. In that context he highlighted Session and SimpleX and sent 128 Ether (ETH) to each to keep pushing in that direction. Session is a good case study because it tries to combine E2E encryption with decentralization. There is no central message server, traffic is routed through onion paths, and user IDs are keys instead of phone numbers. Did you know? Forty-three percent of people who use public WiFi report experiencing a data breach, with man-in-the-middle attacks and packet sniffing against unencrypted traffic among the most common causes. How Session stores your messages Session is built around public key identities. When you sign up, the app generates a keypair locally and derives a Session ID from it with no phone number or email required. Messages travel through a network of service nodes using onion routing so that no single node can see both the sender and the recipient. (You can see your message’s node path in the settings.) For asynchronous delivery when you are offline, messages are stored in small groups of nodes called “swarms.” Each Session ID is mapped to a specific swarm, and your messages are stored there encrypted until your client fetches them. Historically, messages had a default time-to-live of about two weeks…
Share
BitcoinEthereumNews2025/12/08 14:40
Grayscale Files Sui Trust as 21Shares Launches First SUI ETF Amid Rising Demand

Grayscale Files Sui Trust as 21Shares Launches First SUI ETF Amid Rising Demand

The post Grayscale Files Sui Trust as 21Shares Launches First SUI ETF Amid Rising Demand appeared on BitcoinEthereumNews.com. The Grayscale Sui Trust filing and 21Shares’ launch of the first SUI ETF highlight surging interest in regulated Sui investments. These products offer investors direct exposure to the SUI token through spot-style structures, simplifying access to the Sui blockchain’s growth without direct custody needs, amid expanding altcoin ETF options. Grayscale’s spot Sui Trust seeks to track SUI price performance for long-term holders. 21Shares’ SUI ETF provides leveraged exposure, targeting traders with 2x daily returns. Early trading data shows over 4,700 shares exchanged, with volumes exceeding $24 per unit in the debut session. Explore Grayscale Sui Trust filing and 21Shares SUI ETF launch: Key developments in regulated Sui investments for 2025. Stay informed on altcoin ETF trends. What is the Grayscale Sui Trust? The Grayscale Sui Trust is a proposed spot-style investment product filed via S-1 registration with the U.S. Securities and Exchange Commission, aimed at providing investors with direct exposure to the SUI token’s price movements. This trust mirrors the performance of SUI, the native cryptocurrency of the Sui blockchain, minus applicable fees, offering a regulated avenue for long-term participation in the network’s ecosystem. By holding SUI assets on behalf of investors, it eliminates the need for individuals to manage token storage or transactions directly. ⚡ LATEST: GRAYSCALE FILES S-1 FOR $SUI TRUSTThe “Grayscale Sui Trust,” is a spot-style ETF designed to provide direct exposure to the $SUI token. Grayscale’s goal is to mirror SUI’s market performance, minus fees, giving long-term investors a regulated, hassle-free way to… pic.twitter.com/mPQMINLrYC — CryptosRus (@CryptosR_Us) December 6, 2025 How does the 21Shares SUI ETF differ from traditional funds? The 21Shares SUI ETF, launched under the ticker TXXS, introduces a leveraged approach with 2x daily exposure to SUI’s price fluctuations, utilizing derivatives for amplified returns rather than direct spot holdings. This structure appeals to short-term…
Share
BitcoinEthereumNews2025/12/08 14:20