"While doing a solo side project, pair programming with AI revealed problems I would never have discovered on my own"
Introduction: The Reality of Side Projects
I was building an Electron-based video editing app as a personal side project. The Agent Server (Fastify + Prisma) and Electron app were running smoothly, and then I thought, "Why not add a user login feature?"
Existing architecture:
- Electron app (Next.js): User interface
- Agent Server (Fastify): Business logic, file processing
- Database (PostgreSQL + Prisma): Data storage
Being a solo project with no requirements and flexible timeline, I casually thought, "I'll just add Google login." But reality was different.
Chapter 1: The Beginning of Vibe Coding - Starting with Problem Definition
🤔 "What exactly am I trying to implement?" - Defining Requirements
Instead of starting with Google searches, I first asked Claude Code:
Me: "I want to add Google login to my Electron app. What should I consider?"
Claude: "Let's first organize the specific architecture and security requirements."
Me: "Good. Please analyze this in ultrathink mode."
From this point, I began systematically organizing requirements with AI:
📋 Defined Requirements:
1. User login with Google account
2. Only authenticated users can access Agent Server APIs
3. Maintain login state (even after app restart)
4. Security: Tokens must be stored securely
5. UX: Simple login flow, not complex
First Advantage of Vibe Coding: When thinking alone, I'd start looking for "how to implement," but conversing with AI helped me clearly define "what to implement" first.
💡 ultrathink Usage Tip: This feature, which only works in Claude Code, shows its true value in CLI environments when coding. When you need complex architectural decisions or security analysis, using the "ultrathink" keyword allocates up to 31,999 tokens of thinking resources for deeper analysis.
🧠 ultrathink: The Hidden Weapon I Discovered in Claude Code
At this point, I began actively utilizing Claude Code's ultrathink feature. This isn't just a simple keyword but an actual built-in feature that operates through the thinking budget system. According to Anthropic's official documentation, it progressively allocates more computational resources in the order of "think" < "think hard" < "think harder" < "ultrathink".
ultrathink actually allocates 31,999 tokens, providing the highest level of thinking resources for the most complex problem-solving.
Me: "Please ultrathink and compare different methods for implementing OAuth in the current architecture."
Claude's ultrathink result:
Method 1: Agent Server-centered OAuth
- Pros: Leverages existing architecture
- Cons: Token transfer issues between Electron ↔ Agent Server
Method 2: Direct Electron OAuth
- Pros: Security
- Cons: Increased complexity
Method 3: Hybrid approach
- Analysis needed: Security considerations for each step
Difference between Googling vs AI Conversation: If I had googled, I would have found "Electron OAuth tutorial" and followed it. But by conversing with AI and requesting "please ultrathink", I could systematically analyze multiple options tailored to my specific situation.
Chapter 2: The First Wall and Quick Fix - "Let's just make it work"
💥 "next is not a function" - First Obstacle
I tried the most "obvious" method first:
// 🤔 "This must be the standard way, right?"
server.get('/auth/google', passport.authenticate('google', {
scope: ['profile', 'email']
}));
Result:
{"statusCode":500,"error":"Internal Server Error","message":"next is not a function"}
🔧 Quick Temporary Solution: "Let's just make it work"
Me: "Why is this error occurring?"
Claude: "It's a compatibility issue between Fastify and Passport.js. Wrapping it with Promise will solve it."
// 🔧 Temporary fix - at least the error is gone
server.get('/auth/google', async (request, reply) => {
return new Promise((resolve, reject) => {
passport.authenticate('google')(request, reply, (err) => {
if (err) reject(err);
else resolve();
});
});
});
My mindset at this point: "Great, the error's gone! Let's move to the next step"
Actually, at this point, I was just passively leaving it to Claude Code without much thought. It was too passive to be called vibe coding.
Chapter 3: The Mystery of OAuth Flow - "What exactly is Google sending where?"
🤯 Understanding OAuth Flow: An Endless Series of Questions
From this point, problems started arising. The code seemed to work, but something felt off. And I started not understanding what OAuth was actually doing.
Me: "Shouldn't the redirect URI be 'http://localhost:3003/api/auth/google/callback'?"
Claude: "It must match the redirect URI set in Google."
Me: "Good. As you mentioned, let's remove unnecessary server intermediate communication. But before that, I'm curious - can custom protocols be directly registered in GCP? I don't quite understand this part."
🔄 Repeated Doubts and Confirmation: "Do I really understand?"
From this point, I started continuously asking different questions about the same flow. There was something that didn't make sense:
Me: "Alright. But then in step 1, the agent-server exposes the Google login API to the Next client, but only acts as a redirect to the Google login page for the client, right? After that, Google calls the agent-server's oauth/callback endpoint, and then the agent-server passes the authentication value to the Electron client, right? Did I understand correctly? Are there any security issues?"
Claude: "You understood the flow correctly. However, there might be security issues in the token delivery method in the last step."
But something still felt off. I asked again:
Me: "Steps 1 and 5 are slightly confusing to me. Wouldn't it be fine for the existing agent-server to handle this role? For future MSA-like separation of concerns, would it be okay for a temporary server to handle this? The agent-server should have a way to know if the token is a valid token, right?"
From another angle:
Me: "Good. So the client directly opens a browser where the user logs in to Google server, and the agent server only verifies that authentication value later? The approved redirection URL is the URL where users are sent after successful login through the browser, right?"
🤔 "I don't understand the flow"
I finally spoke honestly:
Me: "I don't understand the flow."
Then another question arose:
Me: "But I'm curious - in the Electron app, we're using Next for the UI, but since we're using code like window.electron, this can't be deployed as a Next server, can it? Besides SSG build, is server deployment also possible? If so, does this app actually have 2 servers?"
💡 The Value of Persistent Understanding
Why did I keep asking the same thing repeatedly?
Looking back, I think I instinctively felt that OAuth flow wasn't simply "log in with Google and get a token". At each step:
- What does Google do?
- What does Agent Server do?
- What does Electron do?
- What gets passed where at each step?
- Why is it so complex?
Actual Google OAuth Flow (finally understood version):
1. User: Clicks "Google Login" button
2. My app: Generates Google auth URL and redirects to browser
3. Google: Requests user to log in
4. User: Logs in to Google and grants permissions
5. Google: Sends authorization code to my app's callback URL
6. My app: Exchanges authorization code for access token
7. My app: Requests user info from Google using access token
8. My app: Processes login with received user info
Real reason for repeated questions: OAuth is a complex 8-step flow, but initially I thought "just log in and it's done," so it kept feeling strange.
Effect of learning through questions: Instead of simply looking up "OAuth implementation," I could understand each step one by one and figure out how it applies to my architecture. I also realized how important it is to keep asking questions until I understand.
🧠 The Beginning of System 2 Thinking
Here System 2 thinking began. This is a concept presented by psychologist Daniel Kahneman - unlike System 1 (fast and intuitive), System 2 is slow but careful and logical thinking.
- System 1: "OAuth? Just use passport.js"
- System 2: "How do I ensure security at each step in my Electron architecture? Where and how should tokens be stored?"
Evolution of Vibe Coding: From this point, "correct understanding" took priority over "quick implementation."
Chapter 4: Discovering the Real Problem - "Wait, the token isn't coming?"
🤷♂️ Something's wrong...
The OAuth flow seemed to work, but something kept feeling off:
[Log] Google OAuth callback received
[Log] Token exchange successful
[Log] User info acquired
[UI] OAuth initialization failed...
Actual error messages:
When attempting login, it sends to http://localhost:3000/login/?error=oauth_init_error,
but this path returns a 404 error?
The UI displays "OAuth initialization failed. Please check Google OAuth settings."
💡 Starting to Suspect Something's Wrong
At this point I started suspecting something was wrong:
"Wait, could the problem not be Passport.js compatibility but rather token delivery from Agent Server to Electron?"
Me: "When running the app, it doesn't seem to redirect the URL to the correct path."
From this point, truly systematic approach began. I started discussing implementation plans properly before modifying code.
🔄 Change in Vibe Coding Pattern
Before (Chapter 2): Passive resolution
Problem occurs → Request solution from AI → Apply code → Next step
After (Chapter 4 onwards): Active analysis
Problem occurs → "Something's wrong?" → Discuss implementation plan → ultrathink analysis → Identify root cause
Key difference:
- Problem understanding takes priority over code modification
- Shift from "let's just make it work" to "let's understand exactly why it doesn't work"
- Use AI as a thinking partner rather than a code generator
From this point, conscious and systematic approach began!
Chapter 5: Token Delivery Dilemma - Claude's Suggestion and My Suspicions
🤷♂️ "Wait, how do we deliver the token?"
OAuth authentication succeeded, but a new problem arose.
Me: "The Agent Server received the token, but how do we pass it to the Electron app?"
Claude: "There are several methods. Let me suggest the Exchange Code approach."
💡 Claude's Exchange Code Suggestion
Claude's first suggestion:
// 🟡 Exchange Code method (suggested by Claude)
const exchangeCode = crypto.randomUUID();
global.authTokens.set(exchangeCode, { token, user });
return reply.redirect(`/auth/complete?code=${exchangeCode}`);
Claude: "This passes a one-time code instead of the actual token. It's more secure."
🤔 I First Suspected Security Issues
But when I actually implemented it, it kept failing. Then I was the first to sense something was wrong:
Me: "Hmm... if the token is exposed in the URL in the current implementation plan, we should consider postmessage bridge or cookie method. But isn't the postmessage bridge unrelated to the server hiding the token during transmission? Should we ultimately use cookies? Since login functionality is directly related to security, even if it seems like over-engineering, I think we should go with certainty. Let's ultrathink and derive a conclusion."
Claude: "You've pointed out a very important security point. Let me analyze..."
Only then did security risks start to be organized:
- Risk of storing tokens in URL history
- Risk of tokens being recorded in server logs
- Possibility of token theft during XSS attacks
- Instability due to timing issues
🔄 Cookie and XSS Attack Concerns
Me: "But doesn't this also have the risk of session ID theft during XSS script attacks? What are the best practices? If it's really difficult, should we go with the exchange code method but check if it's the same login environment as the Google-logged-in user, and immediately neutralize that session if the exchange API is called twice in a row? Please ultrathink sufficiently."
The trap of systematic approach: If I were alone, I would have ended with "it's not working, let me find another method," but when I first suspected security and asked questions, serious issues started to become visible.
Chapter 6: Industry Standard Analysis - How Did VS Code and Discord Do It?
🔬 Industry Standard Analysis Request
Me: "I understand that custom protocol is the most recommended method. But I'm not sure if Google OAuth allows redirection to custom protocols. When users log in through the browser, even if it ultimately sends to custom protocols via redirect, shouldn't there be a separate address prepared to relay this? Please megathink whether I understood Google OAuth and the current architecture well, organize it, and give your opinion."
Claude: "Let me analyze how the industry actually solves this."
🎯 Discovering VS Code Method
Me: "Good. Then for the final strategy to deliver tokens to the Electron app, please megathink and review which method would be good by referring to the Electron community and official documentation."
Claude's megathink analysis:
VS Code Method (Main Process HTTP Server):
✅ Complete token isolation: Bypasses renderer process
✅ No need for Agent Server: Direct communication with Google
✅ Complete XSS blocking: Token not in web context
✅ Simple implementation: Just add one HTTP server
Discord Method (Deep Link):
✅ Agent Server reuse: Maintains existing structure
✅ Complete token isolation: Deep link only to main process
✅ User experience: Automatically switches to app
Hybrid Method (Via renderer + security enhancement):
✅ Maximum utilization of existing structure
✅ Session tracking with device fingerprinting
✅ Immediate session invalidation on double calls
⚠️ Remaining XSS risk due to renderer bypass
💡 My Proposed Hybrid Method
Actually, I had proposed a method that goes through the renderer layer but maximizes security:
My proposal:
// Session tracking with device fingerprinting
const deviceFingerprint = generateDeviceFingerprint();
const sessionId = crypto.randomUUID();
// Token exchange API design
POST /api/auth/exchange-token
{
"code": "exchange_code",
"device_fingerprint": "...",
"session_id": "...",
"timestamp": "..."
}
// Security rules
- Immediate invalidation if called twice from same session
- Reject if device fingerprint doesn't match
- Only allow calls within 5 minutes
But after hearing Claude's analysis, I chose the VS Code method.
🤔 Final Decision Process
Me: "Good. The VS Code method looks good. All authentication communicates only between our server-less Google and local temporary server? Then how can the agent server determine authorization for all subsequent APIs, and determine which accounts have signed up for our service? Please ultrathink this part in detail as well."
This question was the core of the Token Exchange Pattern.
Chapter 7: Solving Architecture Dilemma - Birth of Token Exchange Pattern
🤔 New Questions
When I tried to choose the VS Code method, new questions arose:
Claude's ultrathink analysis:
Your core problem recognition is perfect!
Current architecture dilemma:
Current: Electron ↔ Agent Server ↔ Google
VS Code: Electron ↔ Google (bypassing Agent Server!)
But afterwards:
Electron ↔ Agent Server (video processing, AI features)
Agent Server will ask: "Who are you? Are you an authenticated user?"
💡 Token Exchange Pattern Derivation
Through these questions, the final solution emerged:
[Electron Main Process] ←→ [Google OAuth] (Acquire Google token)
↓
[Agent Server Token Exchange API] (Google token → Our JWT)
↓
[All subsequent API calls] (Authentication with our JWT)
🏗️ Token Exchange API Design
Final API design:
// 1. Google token → JWT exchange
POST /api/auth/google-exchange
{
"google_tokens": {
"access_token": "ya29.a0...",
"refresh_token": "1//04...",
"expires_in": 3600
},
"user_info": {
"id": "12345",
"email": "user@example.com",
"name": "John Doe"
}
}
Response:
{
"vivid_tokens": {
"access_token": "eyJhbGciOiJIUzI1NiIs...", // Our JWT
"refresh_token": "rt_abc123...",
"expires_in": 900
},
"user": {
"id": "user_vivid_123",
"email": "user@example.com",
"name": "John Doe"
}
}
// 2. JWT refresh
POST /api/auth/refresh-jwt
{
"refresh_token": "rt_abc123..."
}
// 3. Logout
POST /api/auth/logout
{
"access_token": "eyJhbGciOiJIUzI1NiIs..."
}
🔒 Security Enhancements
Agent Server security verification:
// Origin verification
const electronOrigin = request.headers['x-electron-origin'];
if (!electronOrigin) {
return reply.status(403).send({ error: 'Invalid origin' });
}
// Replay attack prevention
const requestTime = request.headers['x-request-time'];
const timeDiff = Math.abs(Date.now() - parseInt(requestTime));
if (timeDiff > 30000) { // Only allow requests within 30 seconds
return reply.status(403).send({ error: 'Request timeout' });
}
// Google token verification
const isValid = await GoogleTokenVerificationService.verify(google_tokens.access_token);
if (!isValid) {
return reply.status(401).send({ error: 'Invalid Google token' });
}
Core of systematic approach: Instead of simply finding implementation methods, questioning helped us consider and optimize the entire architecture.
Chapter 8: Actual Implementation - Writing Code with Systematic AI Collaboration
📝 Main Process OAuth Service Implementation
Me: "Now let's implement this. Please write code to create an HTTP server in the Main Process."
// vivid/electron/services/google-oauth.service.ts
export class GoogleOAuthService {
private server: http.Server | null = null;
private port: number = 0;
async startOAuth(): Promise<OAuthResult> {
// 1. Start temporary HTTP server
this.server = http.createServer();
this.port = await this.getAvailablePort();
return new Promise((resolve, reject) => {
this.server.listen(this.port, () => {
// 2. Generate Google OAuth URL directly
const authUrl = this.generateGoogleAuthUrl();
// 3. Proceed with OAuth using system browser
shell.openExternal(authUrl.toString());
// 4. Handle callback
this.server.on('request', async (req, res) => {
try {
const result = await this.handleCallback(req, res);
resolve(result);
} catch (error) {
reject(error);
} finally {
this.cleanup();
}
});
});
});
}
🔄 Continuous Feedback and Improvement
Me: "The code looks good, but are there any security aspects we're missing?"
Claude: "There are several improvement points..."
// 🔐 Security enhancement code
private async handleCallback(req: http.IncomingMessage, res: http.ServerResponse) {
// CSRF prevention - State parameter verification
const url = new URL(req.url, `http://localhost:${this.port}`);
const state = url.searchParams.get('state');
if (!this.validateState(state)) {
throw new Error('Invalid state parameter');
}
// Origin verification
const referer = req.headers.referer;
if (referer && !referer.startsWith('https://accounts.google.com')) {
throw new Error('Invalid request origin');
}
// Timeout handling
const timeoutId = setTimeout(() => {
res.writeHead(408);
res.end('Request timeout');
}, 30000);
try {
// ... actual processing
} finally {
clearTimeout(timeoutId);
}
}
🔒 Token Exchange Service Implementation
// vivid/electron/services/token-exchange.service.ts
export class TokenExchangeService {
static async exchangeGoogleTokens(
googleTokens: GoogleTokens,
userInfo: GoogleUserInfo
): Promise<TokenExchangeResult> {
try {
const response = await fetch(`${AGENT_SERVER_URL}/api/auth/google-exchange`, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-Electron-Origin': process.pid.toString(),
'X-Request-Time': Date.now().toString()
},
body: JSON.stringify({
google_tokens: googleTokens,
user_info: userInfo
})
});
// Immediately delete Google tokens (security)
Object.keys(googleTokens).forEach(key => {
delete googleTokens[key];
});
const result = await response.json();
return {
success: true,
vividTokens: result.vivid_tokens,
user: result.user
};
} catch (error) {
return {
success: false,
error: error.message
};
}
}
}
Advantage of systematic approach: Even while writing code, I could continuously receive security reviews and improvements.
Chapter 9: Final Blind Spot Check - "Is it really secure?"
🔍 Final Security Verification
Me: "Good. Finally, let's check if there are any overlooked security issues and establish a work plan. Please ultrathink sufficiently so we don't miss anything, integrate well with the current architecture."
Claude's ultrathink final security analysis:
// ✅ Complete token isolation architecture
[Main Process] ←→ [Google] (Acquire Google token and immediately incinerate)
↓
[Agent Server] (Verify Google token → Issue JWT)
↓
[Secure Storage] (Encrypt and store JWT with safeStorage)
↓
[Renderer Process] (No token access, only user info access)
🎯 Final Security Architecture
// vivid/electron/services/secure-storage.service.ts
export class SecureStorageService {
static async storeAuthData(tokens: VividTokens, user: VividUser): Promise<boolean> {
try {
const { safeStorage } = require('electron');
if (!safeStorage.isEncryptionAvailable()) {
throw new Error('Encryption not available');
}
const authData = {
tokens,
user,
deviceFingerprint: await this.generateDeviceFingerprint(),
lastUpdated: new Date().toISOString()
};
// Encrypt and store JWT
const encrypted = safeStorage.encryptString(JSON.stringify(authData));
const authPath = path.join(app.getPath('userData'), 'auth.encrypted');
await fs.writeFile(authPath, encrypted);
// Immediately delete tokens from memory
Object.keys(tokens).forEach(key => delete tokens[key]);
return true;
} catch (error) {
console.error('[SecureStorage] Storage failed:', error);
return false;
}
}
}
🔐 Final Security Verification Points
Completed security system:
- ✅ Complete XSS blocking: Never expose tokens to renderer process
- ✅ CSRF prevention: Request verification with State parameter
- ✅ Replay attack prevention: 30-second time window
- ✅ Origin verification: Process ID-based request authentication
- ✅ Encrypted storage: Using Electron safeStorage
- ✅ Immediate token incineration: Complete deletion from memory after use
- ✅ Device fingerprinting: Multi-session tracking
Chapter 10: Core of Systematic AI Collaboration Methodology
🎯 Characteristics of Conscious Development Approach
1. Cultivating the Habit of Suspicion
- "How to implement?" → "What should I implement?" → "Is this really right?"
- "Make it work" → "Make it secure" → "Is it really secure?"
- "Quick implementation" → "Correct implementation" → "Did I miss anything?"
2. Actively Using plan mode and ultrathink
- Plan mode (Shift+Tab twice): "Architect mode" that only conducts research and planning without code modification
- Auto Accept mode (Shift+Tab): "YOLO mode" that automatically executes without user approval
- For complex problems, first analyze in plan mode, then decide whether to execute
- "Please ultrathink" explicit requests to induce deep analysis
3. Repetitive Blind Spot Finding
- "What are the problems with this method?"
- "Are there any security issues I'm missing?"
- "Are there other approaches?"
- "Something seems off, ultrathink this"
4. Architectural Perspective Thinking
- Consider the entire system, not partial solutions
- Analyze the impact of current choices on the future
- Compare with industry standards
🚀 Systematic Approach vs Traditional Vibe Coding
| Traditional Vibe Coding | Systematic AI Collaboration |
|---|---|
| Intuitive coding → Quick fixes | Conscious analysis → Systematic solutions |
| Works = OK | Consider security/scalability |
| Debug when problems occur | Prevent problems before they occur |
| Think alone | Systematic pair programming with AI |
💡 Actual Effects
1. Discover problems you couldn't find alone
Me: "How about the Exchange Code method?"
AI: "There's still URL exposure risk."
Me: "Ah, right. What about other methods?"
2. Systematic security review
Me: "Are there security blind spots in this implementation?"
AI: "Let me review from these 5 perspectives..."
3. Learn industry standards
Me: "How did VS Code implement this?"
AI: "Let me analyze VS Code's method and suggest application to your current architecture."
Chapter 11: Project Completion and Results
📊 Final Implementation Results
Security Level: 🟢🟢🟢🟢🟢
- Complete token isolation (no renderer process bypass) ✅
- XSS attack blocking ✅
- URL/log file exposure prevention ✅
- Industry standard security pattern application ✅
Code Quality: 🟢🟢🟢🟢
- Scalable architecture ✅
- Easy addition of other OAuth providers ✅
- Testable structure ✅
- Clear separation of responsibilities ✅
Development Experience: 🟢🟢🟢🟢🟢
- Smooth progress without getting stuck ✅
- Clear verification at each step ✅
- Prevent future problems in advance ✅
- New technology learning effect ✅
🎓 Insights Gained from Systematic AI Collaboration
1. Importance of Problem Definition
- Clarify "what to implement" rather than implementation methods
- Systematic approach possible even in side projects without requirements
2. Value of Complete OAuth Flow Understanding
- Not just "implement login" but understand security at each step
- Deep learning through questioning
- Customization for my architecture
3. Security from Design Phase
- "Add security later" is impossible
- Working code ≠ Secure code
- Consider security at architecture level
4. Correct AI Utilization
- Not a simple code generator but a thinking partner
- Use deep analysis with "please ultrathink" explicit requests
- Sufficient review before execution with plan mode
5. Evolution of Vibe Coding
- Traditional vibe coding: Intuitive but superficial
- Conscious systematic approach: Slow but deep and safe
- Habit of questioning to continuously point out blind spots
6. Value of Industry Standards
- Analyze success stories like VS Code, Discord
- Don't reinvent the wheel
- Actively utilize proven patterns
Conclusion: For Developers Starting Systematic AI Collaboration
🚀 Getting Started Guide for Conscious Development Approach
1. Ask questions before implementing
❌ "Write Electron OAuth code for me"
✅ "Please ultrathink and analyze security considerations when implementing OAuth in Electron"
2. Understand complex flows like OAuth step by step
"What exactly is Google sending where?"
"Are there security risks at this step?"
"How does this apply to my architecture?"
3. Make blind spot finding a habit
"What are the problems with this method?"
"Are there any security issues I'm missing?"
"How does the industry solve this problem?"
4. Actively use Plan mode
"Before complex changes, activate plan mode with Shift+Tab twice"
"Sufficient review and analysis before execution"
"Think from an architectural perspective"
💪 High-Quality Code Even When Working Alone
The biggest advantage of systematic AI collaboration is achieving team-level development quality even in solo side projects.
- Colleague developer's code review → AI's blind spot identification
- Senior developer's architecture advice → AI's industry standard analysis
- Security expert's review → AI's security risk analysis
🎯 Final Advice
OAuth implementation isn't just a simple authentication feature. It's a core security feature handling users' personal information.
Things to remember when developing with systematic AI collaboration:
- Don't stop questioning: Don't end at "it works?" - keep asking questions
- Completely understand the flow: Grasp the meaning and security issues of each OAuth step
- Prioritize security: Safe implementation over quick implementation
- See the whole picture: Architectural-level solutions, not partial solutions
- Use AI well: Request deep analysis with plan mode and ultrathink
- Avoid vibe coding traps: Prioritize systematic analysis over intuition
Most importantly, don't compromise on quality just because you're developing alone. You can definitely create high-quality code through conscious and systematic AI collaboration.
Safe and enjoyable coding! 🔒✨
The complete implementation process and code for this project can be found in the GitHub repository.
Vibe Coding Resources
- Claude Code Download - CLI tool with ultrathink functionality
- Claude Code Best Practices - Official guide for ultrathink and thinking budget system
- Simon Willison's Claude Code Analysis - Internal implementation analysis of ultrathink
- Electron Security Guidelines
- OAuth 2.0 Security Best Practices
💡 ultrathink Token Allocation Info: Progressively allocates more thinking resources in the order of "think" (4,000 tokens) < "megathink" (10,000 tokens) < "ultrathink" (31,999 tokens).
Top comments (0)