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 service@support.mexc.com 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

CME Group to launch options on XRP and SOL futures

CME Group to launch options on XRP and SOL futures

The post CME Group to launch options on XRP and SOL futures appeared on BitcoinEthereumNews.com. CME Group will offer options based on the derivative markets on Solana (SOL) and XRP. The new markets will open on October 13, after regulatory approval.  CME Group will expand its crypto products with options on the futures markets of Solana (SOL) and XRP. The futures market will start on October 13, after regulatory review and approval.  The options will allow the trading of MicroSol, XRP, and MicroXRP futures, with expiry dates available every business day, monthly, and quarterly. The new products will be added to the existing BTC and ETH options markets. ‘The launch of these options contracts builds on the significant growth and increasing liquidity we have seen across our suite of Solana and XRP futures,’ said Giovanni Vicioso, CME Group Global Head of Cryptocurrency Products. The options contracts will have two main sizes, tracking the futures contracts. The new market will be suitable for sophisticated institutional traders, as well as active individual traders. The addition of options markets singles out XRP and SOL as liquid enough to offer the potential to bet on a market direction.  The options on futures arrive a few months after the launch of SOL futures. Both SOL and XRP had peak volumes in August, though XRP activity has slowed down in September. XRP and SOL options to tap both institutions and active traders Crypto options are one of the indicators of market attitudes, with XRP and SOL receiving a new way to gauge sentiment. The contracts will be supported by the Cumberland team.  ‘As one of the biggest liquidity providers in the ecosystem, the Cumberland team is excited to support CME Group’s continued expansion of crypto offerings,’ said Roman Makarov, Head of Cumberland Options Trading at DRW. ‘The launch of options on Solana and XRP futures is the latest example of the…
Share
BitcoinEthereumNews2025/09/18 00:56