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
4분 읽기
이 콘텐츠에 대한 의견이나 우려 사항이 있으시면 crypto.news@mexc.com으로 연락주시기 바랍니다

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.

시장 기회
플러리싱 에이아이 로고
플러리싱 에이아이 가격(SLEEPLESSAI)
$0.01871
$0.01871$0.01871
+3.02%
USD
플러리싱 에이아이 (SLEEPLESSAI) 실시간 가격 차트
면책 조항: 본 사이트에 재게시된 글들은 공개 플랫폼에서 가져온 것으로 정보 제공 목적으로만 제공됩니다. 이는 반드시 MEXC의 견해를 반영하는 것은 아닙니다. 모든 권리는 원저자에게 있습니다. 제3자의 권리를 침해하는 콘텐츠가 있다고 판단될 경우, crypto.news@mexc.com으로 연락하여 삭제 요청을 해주시기 바랍니다. MEXC는 콘텐츠의 정확성, 완전성 또는 시의적절성에 대해 어떠한 보증도 하지 않으며, 제공된 정보에 기반하여 취해진 어떠한 조치에 대해서도 책임을 지지 않습니다. 본 콘텐츠는 금융, 법률 또는 기타 전문적인 조언을 구성하지 않으며, MEXC의 추천이나 보증으로 간주되어서는 안 됩니다.

$30,000 in PRL + 15,000 USDT

$30,000 in PRL + 15,000 USDT$30,000 in PRL + 15,000 USDT

Deposit & trade PRL to boost your rewards!