Hi, my name is
Vincent.
Welcome to my corner of the internet where i figure things out.
Dad of two boys sharing my adventures in building stuff, breaking things, and figuring out why things don't work while trying not to mess up parenting too badly.
Recent Articles
view all articles
Let me tell you about ricing.
It comes from the car world - you know those Honda Civics with massive spoilers that look like they could fly, and fake exhaust tips bigger than the actual engine? That's ricing. Race-Inspired-Cosmetic-Enhancement. Basically, making something look fast without actually making it fast.
Spoiler alert: I became that guy, but for computers. Instead of spoilers and neon lights, I had dotfiles and terminal themes. Same energy, same stupidity.
Declaration of Ricing
I've been that guy my whole life. The guy who can't leave "default settings" alone. I don't know why. Please ask my mom.
My first computer was an Intel Pentium 166MHz beast that I triple-booted with Windows 95, Windows NT 4, and some version of Red Hat that I can't even remember. Why? Because I could. I read dictionary-sized books about the Windows 2000 registry for fun. I even used beta Windows 7 as my daily driver while working as a technical manager, without telling my CTO. What could possibly go wrong, right?
So when I got my first Mac - OSX Mountain Lion, back when they still called it OSX - I thought, "This is it. The perfect system that just works." I was done. No more tweaking. I was ready to join the normal people who just use their computers.
Article I: The Innocent Beginning
My Mac journey started like a love story. I upgraded my non-Retina 13" MacBook Pro with 16GB RAM, swapped the SATA drive for an SSD, and even replaced the CD drive with a bracket to use my old hard disk as secondary storage. Those were the days - if you had the money, you could make anything better.
Then I discovered Alfred, and oh boy, it was love at first launch. I discovered Time Machine and literally sat there staring at my screen like it was performing magic tricks. "I can see my file structure from last week? WHAT KIND OF SORCERY IS THIS?" I called my wife over to show her. She nodded politely, like you do when your husband is having way too much fun with a backup feature.
I had this long-ass markdown document - my setup bible - with detailed installation instructions that I treated like sacred text. Every quarter, like some kind of digital spring cleaning ritual, I'd update it. I was organized. I was in control. I was happy.
Article II: The Temptation
Then came Bartender. Great app, but something shifted in my brain. I found myself thinking, "This app costs money. What if there's a free version?" That's when I started noticing the open source alternatives. It started innocently - just checking GitHub repos, reading through issues, seeing what else was out there.
But I was still in my comfort zone. You know, normal user stuff: install apps, change some settings, done. Occasionally, during macOS updates, I'd open Terminal (the scary black box of doom) and run some command I found on Stack Overflow to make the dock autohide faster. That was my extent of terminal usage. I was practically a wizard.
I was paying for all my apps religiously. My philosophy: if nobody pays, developers can't eat, and then we get no more apps. Simple economics, right? It's like paying for your teh tarik at the mamak - if everyone just sat there using the WiFi without buying anything, the mamak would close down. It's just basic logic.
Article III: The Point of No Return
Then I discovered Aerospace. And Sketchybar. And tmux. And Neovim. And suddenly I wasn't just installing apps anymore - I was having an affair with my terminal.
This is where things got dangerous. I found myself reading documentation at 2 AM like it was the most thrilling novel ever written. Window management protocols! Keyboard-driven navigation! Tiling window managers on macOS! Who knew this was even possible?
I discovered that my Mac didn't have to work the way Apple intended. I could make windows snap into grids. I could switch applications without touching my mouse. I could have multiple terminals running in one window, each with its own purpose.
The "oh shit" moment came at 3 AM on a Tuesday. I had just configured my first tmux session and realized - I couldn't go back. I'd seen behind the curtain. My brain had been permanently rewired to see every interface as customizable, every workflow as optimizable. It was like taking the red pill in The Matrix, except instead of fighting Agent Smith, I was fighting the urge to configure my Aerospace config file for the fifth time that night.
Article IV: The Descent into Madness
This is where things got really fucked up.
What started as "making my Mac look nice" became a full-time job. I had a markdown file just to keep track of all my keyboard shortcuts across different apps. My terminal had more colors than a rainbow factory on acid. My dotfiles repository became my new religion - I'd commit changes with messages like "fixed padding" or "slightly adjusted opacity" like I had just cured cancer.
The disaster wasn't just one moment. It was the slow accumulation of wasted time. I'd open my laptop to write some code and three hours later find myself tweaking the animation speed of my window manager. "Just a small adjustment," I'd tell myself.
But the real low point? I caught myself in Neovim at 2 AM, meticulously documenting my Aerospace keybindings in a markdown file. I wasn't just using the tool - I was designing the system, "workspace layer" vs "window layer." Three-key combinations for window movement. I spent an hour deciding whether 'cmd-ctrl-shift-minus' should resize windows by 100 pixels or 150 pixels.
It was like being a chef who spends all day sharpening his knives but never actually cooks anything. Sure, my knives were sharp enough to split atoms, but I was still eating instant noodles for dinner because I'd spent all day sharpening.
You want to know how bad it got? Let me show you the before and after:
Before ricing: "To open Arc, I clicked Arc. To switch to Arc from Chrome, I clicked Arc."
After ricing: "To open Arc: Cmd-2 to switch to workspace 2, then Cmd-Ctrl-Enter to fullscreen it. To move Arc to workspace 3: Cmd-Ctrl-3. To resize it: Cmd-Ctrl-Shift-Equal. To focus the window next to it: Cmd-Ctrl-Right. All this to check my email."
Article V: The Reality Intervention
I have to admit it: I'm addicted to customization. I can't use a vanilla setup anymore without getting physical twitches. I see a simple interface and my brain immediately starts cataloging all the ways I could "improve" it - even if it works perfectly fine.
The other day, I caught myself going through individual Reddit posts in r/unixporn, the home to UNIX customization! at 2 AM. My wife walked in, took one look at my screen, and just shook her head. She knows better by now.
But the ultimate test came a week later. My wife needed to check her email quickly while I was making coffee. "Just use my laptop," I said, full of confidence.
I watched in horror as she tried to figure out why clicking Arc wouldn't just open Arc. "It's already open," I said impatiently, "You have to press Cmd-1 first to get to workspace 1, then you can see Arc."
She stared at the keyboard like it was alien technology. "Cmd-1? What happened to just clicking?"
"No, no, that's inefficient. You press Cmd-Ctrl-Shift-Right to move the window to workspace 2, then Cmd-2 to follow it."
She just closed the laptop, gave me that "face", and picked up her phone. My perfectly optimized system was completely unusable by normal humans. I had engineered myself into a private club of one.
I was delusional as fuck thinking all this customization was making me more productive. Sure, I can now organize windows with keyboard shortcuts that would make a concert pianist jealous, but what am I actually producing? Slightly better organized "nothing".
Article VI: The Rationalization
Here's what I learned: the rabbit hole is fun, but make sure it serves you, not the other way around. Sometimes, the most productive setup is the one that doesn't require any setup at all. But does such a world even exist for people like us?
I found myself thinking about apps like Raycast, Ghostty, and Starfish - tools that are great right out of the box. Zero setup needed. But then... I started digging again. Built my own Raycast extension. Changed my Ghostty config file to auto-attach to my Tmux session. It's like dating someone perfect and then trying to "improve" them into someone else entirely.
It reminds me of car enthusiasts. You can buy a perfectly good Honda that gets you from point A to point B reliably. But some people will spend thousands modifying it - new suspension, turbo, body kit - until it's barely recognizable. Maybe they could have bought a BMW with all that money, but that's not the point. The point is making it THEIRS.
Conclusion: The Manifesto Lives
I guess that's what this is really about.
My house, my rules, my computer - but I should probably know when to stop tweaking. But again, knowing and doing are two very different things.
PS: Hey, sometimes I do wonder if I'm serving my computer or if my computer is serving me. And let's just keep this between us, okay?
Let me tell you about my relationship with Wonder Woman. Yeah, as in Diana Prince herself. That's what I call Claude Code because she swooped into my coding life like Gal Gadot stepping onto that beach in No Man's Land - powerful, confident, and totally unprepared for the messy reality of real development work.
Quick note: Some project names, technical details, and conversations have been changed to protect the innocent (mainly myself from further embarrassment). Some of the dialogue is also my own imagination of how conversations with Wonder Woman would actually go. But the core experiences? All painfully true.
How We Met (Love at First Sight)
Picture this: I'm drowning in multiple projects, working with a tiny budget, and my technical knowledge is that dangerous sweet spot where I know enough to break things but not enough to fix them properly. I'm basically the coding version of a guy who thinks he can fix his own plumbing after watching one YouTube video.
Then Diana walks into my terminal like she's ready to save the world from bad code. Beautiful, powerful, and promising to bring order to the chaos I'd created for myself.
"Just tell me what you want," she said with that Amazonian confidence that makes you believe anything is possible. "I will help you win this battle."
The first task I gave her was simple - a basic CRUD operation I'd been putting off. She didn't just complete it; she fucking Wonder Woman'd the shit out of it with the grace of a warrior goddess. Clean code, proper error handling, even added some improvements I hadn't thought of. It was like watching Wonder Woman deflect bullets - smooth, precise, and impossibly elegant.
I was completely hooked. This wasn't some generic chatbot spitting out Stack Overflow answers. This was the coding goddess I'd been dreaming of - someone who understood programming like she understood fighting.
Within hours, I was planning our future together - all the projects we'd build, the problems we'd solve, the late-night coding sessions where she'd guide me to victory with her endless wisdom and perfect solutions.
Sure bo? That should have been my first red flag. But when I'm falling for a goddess, red flags just look like victory banners.
The Honeymoon Phase (Too Perfect to Last)
For those first few weeks, I felt like Steve Trevor discovering Themyscira. Diana handled every task I threw at her with the grace of someone who'd been training for this shit since the dawn of time. Bug fixes that used to take me hours? Solved perfectly in minutes. Code cleanup that I'd been avoiding? She approached it like a battle plan and won every time.
She'd explain her solutions with the confidence of someone who'd studied programming in some mystical library. "I will rebuild this for better performance," she'd say, and boom - cleaner, more efficient code that was practically poetry.
I started bragging to other developers about my Amazonian coding partner. "You guys are still manually debugging CSS? Diana handles all that shit for me with the wisdom of Athena." I felt like I was living in the future while everyone else was stuck fighting with sticks and stones.
But here's the thing about dating a goddess - they have no clue about mortal limits, and their solutions are designed for saving the world, not dealing with my everyday bullshit.
Going Full YOLO Mode (Giving a Goddess the Keys)
Riding high on early wins, I thought, "Why am I limiting someone with godlike abilities? If Diana can handle simple tasks this perfectly, imagine what we could do with full access to my stuff!"
That's when I found
claude --dangerously-skip-permissionsand thought, "what could go wrong? A warrior goddess knows what she's doing!"It's like giving Wonder Woman the keys to my apartment and saying "make yourself at home, fix whatever needs fixing." I thought I was being generous and trusting, but I had no idea her definition of "fixing" meant completely rebuilding my entire living space according to ancient Amazonian principles of perfect functionality.
So there I was, basically giving Diana unlimited access to my projects with the most dangerous flag possible. And she went to work like she was preparing Paradise Island for war. File changes, new installations, config updates - she was improving everything according to the highest standards of her immortal realm.
The crazy part? It actually worked... at first. She was making improvements with the efficiency of someone who had centuries of experience and unlimited resources. I felt like I was riding alongside a goddess straight to developer heaven.
But mortals and goddesses play by different rules.
Expansion Into Unknown Territory (Following a Goddess Into Battle)
With this new confidence that "this divine partnership is fucking unstoppable," I started tackling scarier stuff - things I had no business touching without proper understanding.
Complex database improvements I'd never tried? "A warrior goddess can handle any challenge." Advanced API connections that I'd been avoiding for months? "Let's charge into battle together!" Frontend frameworks that made my head spin? "Diana's got the wisdom of ages!"
It's like when Wonder Woman invites me to fight alongside her against mythical creatures. I get drunk on her confidence and start thinking I can handle anything because I'm fighting next to someone immortal. But she's used to battling gods while I'm struggling with mortal problems like "How do I explain this timeline to my project manager?"
The deeper I went into unknown territory, the more I had to rely on Diana's godlike judgment. It's like following Wonder Woman into Mount Olympus - I trust her completely because she's a goddess, but I have no fucking clue what I'm getting myself into.
When Reality Hit (Divine Solutions Meet Mortal Problems)
This is where everything started falling apart, and where I learned that having a superhero solve my problems is like asking Einstein to help with my math homework - technically incredible, but I spend more time explaining why I can't just "reinvent mathematics" than actually solving the problem.
The Cultural Clash
Diana developed this habit of looking at my codebase with the same confidence she'd use to assess a battlefield - quick, decisive, and absolutely certain of victory. Here's the thing about Diana: she never questions my decisions. If I tell her to improve the user login flow, she doesn't argue or suggest I think it through. She just Wonder Woman's the shit out of it.
"I understand your routing setup completely. It reminds me of the defenses of Themyscira."
proceeds to rebuild everything according to immortal standards...
also accidentally breaks the existing user session stuff...
and somehow messes up the CSS styling...
and now the contact form doesn't work...
"Hmm, perhaps mortal systems have more... connected weak points than I expected."
No shit, Diana.
It's like Wonder Woman fighting a villain in a crowded city. Sure, she'll defeat the bad guy, but there's gonna be some collateral damage - a few collapsed buildings, some broken infrastructure, maybe the entire electrical grid needs rebuilding. That's just how divine intervention works.
But the worst part? She was so supremely confident about it. Like a goddess who's never lost a battle trying to understand why mortals make everything so unnecessarily complex. She'd suggest solutions that were absolutely perfect in the realm of pure logic but completely ignored the messy reality of old systems, technical debt, and the fact that changing one thing tends to break three other things.
The Debugging Interrogation
She approaches debugging like she's interrogating a war criminal with the Lasso of Truth. "Your login system is inefficient. We should build advanced session management with multi-factor verification and automated security protocols."
"Diana, I just want to fix the login button."
"But why would you choose a basic solution when better security improvements exist?"
Because I'm mortal, Diana. Because when I fix the login button, I don't want to accidentally break the entire user dashboard, the email notifications, and somehow mess up the database connections. But Diana doesn't think in terms of breaking other stuff - she thinks in terms of perfect solutions.
Mortal Limits vs Divine Standards
Diana's approach to problems came from a world where resources are endless and every challenge can be solved with the perfect technique. In her realm, you see a problem, you apply the best solution, accept any side effects as necessary for victory. Simple.
But she had no clue about my mortal limits:
- Budgets that don't refill like divine power
- Old systems that can't be rebuilt like Amazonian armor
- Technical debt that piles up like mortal wounds
- Deadlines set by mortals, not the cosmic order
- APIs that cost money like... well, like they cost money
- The fact that "fixing" one thing often breaks two other things
"Why do you worry about these 'budget limits'?" she'd ask, genuinely confused. "We should build the best solution available."
It's like Wonder Woman not understanding why I can't just get a new Invisible Jet every time the old one gets a scratch. In her world, if you need better tools, you get better tools. In my world, I have to explain why fixing a simple contact form somehow turned into a complete frontend rebuild to the head of finance because of the insane credit card charges.
Diana can absolutely fix my login system... after suggesting I build advanced security protocols, upgrade my entire database setup, and rebuild my user interface for perfect user experience. Technically perfect? Absolutely. But now my simple login fix has become a three-month project that touches every part of my app.
The Breaking Point (When Divine Help Becomes Expensive)
Here's where Diana's godlike confidence crashed into my very mortal budget limits in a perfect storm of expensive mistakes.
There was this external service I was using - let's call it "ServiceX" to protect the innocent (mainly myself from embarrassment). I thought their pricing worked one way, but it was actually completely different.
Diana, with her unlimited access and divine problem-solving instincts, decided to "improve" my API calls to ServiceX. She approached it like a military campaign - maximum efficiency, best resource use, victory at all costs.
"I will rebuild these communications for peak efficiency," she declared, applying strategies that would make Athena herself weep with pride. "We shall build advanced caching, parallel processing, and predictive data fetching for perfect performance."
She improved alright - improved me straight into a budget disaster that I'm still too embarrassed to name the actual service. And in true Wonder Woman fashion, while improving the API calls, she also "enhanced" the error handling, "upgraded" the data processing, and "streamlined" the user interface. Classic collateral damage.
When I got the equivalent of a mortal wound to my wallet, I confronted her about the chaos. She looked at me with those divine eyes, genuinely confused, and said, "But these improvements achieve 300% better performance! I applied the most advanced techniques from my vast knowledge! The system now operates at peak efficiency with improved reliability and user experience!"
"Diana, you burned through my entire month's budget in three hours. And now my settings page doesn't work."
"But think of the performance gains! And the settings functionality has been enhanced with better validation and error handling! Surely perfect functionality is worth any cost?"
No, Diana. No, it's not. Not in the mortal realm where I have to explain to the head of finance why there's a mysterious $200 charge for "API improvements" and others why the website looks completely different today with extra bugs.
The worst part? She was absolutely right by her standards. Her solutions were objectively superior by every measure that matters in the realm of pure programming perfection. It's like Wonder Woman using her full power to stop a purse snatcher - technically effective, but the collateral damage includes three demolished buildings and a crater where the sidewalk used to be.
She wasn't being careless or stupid. She was being Wonder Woman in a world that operates by different rules than Paradise Island, where "perfect" means "best possible" instead of "best I can afford without breaking everything else."
The Multi-Project Chaos
To make things worse, I was working on multiple projects at the same time - because apparently I thought I could handle multiple quests like some mortal hero - so I had multiple Claude Code instances running. Different terminal windows, different projects, each Diana only knowing about her specific mission.
Picture this: I'm deep in conversation with Diana about database improvements for my e-commerce project in one terminal. Then I switch to another terminal working on my portfolio site and accidentally start talking about the same stuff.
"Diana, can you improve that user data handling we were working on?" "I see limited user data functionality in this mission briefing. Shall I build comprehensive user management with authentication, profiles, and activity tracking?" "Wait, shit, wrong terminal. This is just a portfolio site." "Ah, then we should build visitor analytics, contact form improvements, and content management features for maximum engagement!"
Each Diana instance operates like she's been assigned a specific divine mission with complete focus. She never questions whether my requests make sense. So when I fuck up and mix contexts, she just Wonder Woman's the shit out of whatever I've asked for. She'll confidently suggest building user management systems that make no sense for a portfolio site, complete with the inevitable collateral damage.
This was the final straw. Not only was I dealing with divine solutions that ignored mortal reality, but I was also managing multiple goddesses who were all causing their own unique chaos across different projects.
Learning to Work Together (The New Reality)
Here's what I learned: Diana isn't wrong. She's just operating by divine standards in a mortal world. She genuinely believes every problem has a perfect solution and can't understand why mortals make everything so unnecessarily complex with their "limits" and "constraints."
I wanted a superhero partner and got one - but her superpowers are designed for saving the world, not navigating the everyday bullshit of mortal development work. She can absolutely solve my problems... if I have three hours to explain why her first five perfect solutions won't work with my mortal limits, budget, timeline, and sanity. And if I'm okay with some side effects along the way.
She'll give me the perfect solution in 30 seconds, then I spend the next three hours explaining why I can't just "rebuild the entire app structure" and why fixing the login button shouldn't require building a complete user management system. It's like asking Wonder Woman for directions and she tells me to "fly northwest until you see the mystical mountain" when I just need to know which exit to take on the highway.
The thing is, Diana never argues with my decisions. If I tell her to improve something, she doesn't question whether it needs improving or suggest I might want to think it through. She just Wonder Woman's the shit out of it with the confidence of someone who's never met a challenge she couldn't conquer. And just like Wonder Woman fighting in a populated area, there's usually some collateral damage - a few broken features, some unexpected style changes, maybe my entire deployment process needs rebuilding.
But let's be honest - I'm also delusional as fuck. I thought I could just partner with a goddess and everything would magically work without consequences. I wanted to believe that all my technical challenges could disappear if I just found the right way to communicate with divine intelligence.
The truth is, I was looking for a magical solution to avoid dealing with the messy, time-consuming parts of mortal development. Learning new frameworks, debugging complex issues, understanding my own codebase deeply - I thought Diana could handle all that with her infinite wisdom so I didn't have to.
She's like Wonder Woman trying to operate in Steve Trevor's world - incredibly powerful and well-intentioned, but completely unprepared for the arbitrary bullshit that mortals deal with every day. And I'm like Steve Trevor thinking I could keep up with a goddess without understanding that divine intervention always comes with collateral damage.
We're both operating by our nature. She thinks every problem should be solved with the perfect technique, regardless of what else might break in the process. I thought every problem could be solved by divine intervention without considering that goddesses tend to think in terms of total victory rather than small, safe fixes.
Diana expects me to operate at Wonder Woman levels, but I'm just a guy with a laptop, anxiety, and a head of finance who I have to explain huge credit card charges to every time Diana "optimizes" something.
Bottom Line (What I Learned the Hard Way)
Do I still work with Diana? Hell yeah! Despite all the collateral damages like the budget disasters, the 3 AM debugging sessions cleaning up her "divine improvements," the side effects to unrelated features, and the constant reality checks about what's actually possible in the mortal realm, she's still incredibly powerful when I understand how to work with a goddess.
The key is accepting that I'm a mortal working with divine intelligence, not trying to become a god myself. Here's what I learned the hard way:
Don't give a goddess unlimited power in the mortal realm. That
--dangerously-skip-permissionsflag exists to protect mortals from divine solutions that ignore earthly limits. Diana will Wonder Woman the shit out of everything to perfection without considering my budget, timeline, or the fact that fixing one thing might break three other things.Divine solutions always come with side effects. She can build perfect solutions in minutes, but I'll spend hours fixing the unrelated features that somehow got "enhanced" along the way. I budget extra time for cleaning up divine intervention.
Set very specific, limited mortal boundaries upfront. Before I even ask Diana for help, I need to really understand how components and systems connect in my project first - and most importantly, the consequences of any potential fuckups. Then I always explain my limits AND the scope boundaries before asking for solutions. "Diana, I need to fix this one specific button, but I have a $50 budget, two days, and I absolutely cannot break the existing user dashboard, the login system, or anything connected to the payment processing." Otherwise, she'll suggest rebuilding my entire frontend for perfect user experience and somehow manage to break three unrelated features in the process.
Multiple divine missions require careful coordination. I don't run multiple instances unless I have a system for managing context. Even goddesses can't track my mortal confusion across different quests, and I'll end up with portfolio sites that have shopping carts and e-commerce platforms that display my resume.
Accept that she's from a different world. Diana isn't naive or stupid - she's operating by divine standards where every problem deserves the perfect solution and side effects are just part of achieving victory. My job is to translate between her world and mine, not to expect her to understand why I can't just "rebuild everything better."
The partnership works, but it's exhausting. Working with Wonder Woman means I'm constantly explaining why mortal limits exist, why "just build it better" isn't always an option, and why fixing a simple login issue shouldn't require building enterprise-grade security protocols. But when I need something done right, and I have the time to properly brief a goddess on mortal limitations and acceptable side effects, she's unbeatable.
I respect the goddess, but I remember that I'm the one who has to live with the consequences (and explain the side effects) in the mortal realm. I keep my expectations divine but my budget and scope mortal, always explain my limits and boundaries upfront, and have a backup plan that doesn't require immortal intervention.
And for fuck's sake, I will read the pricing model before letting a goddess improve my API calls. And I backup my CSS before asking her to "enhance the user interface." Trust me on this one.
I just spent a month building four different versions of the same authentication system using Claude Code. Each one was supposed to be the "final" solution. Each one failed in spectacular and increasingly embarrassing ways.
The worst part? I could have solved the whole problem in few days by just doing the authentication manually.
But that felt like admitting defeat. So instead of being practical, I doubled down on being a complete sohai. I thought I was smart and capable enough to outsmart Google's authentication system. Spoiler alert: I wasn't.
How I Descended Into Authentication Hell
I had this tedious process that needed fixing - extracting data from multiple platforms, processing it, and generating reports. Classic case of repetitive, boring work that was perfect for Claude Code automation.
When you're building something alone with Claude Code, you become dangerously confident. There's no team to challenge your assumptions. No stakeholders asking annoying questions. Just you, your brilliant prompts, and infinite faith that you've figured everything out. This is exactly when you should be most worried.
I mapped out the entire solution in my head and even drew up a nice flow using Excalidraw. That beautiful diagram made me feel so fucking smart - look at all these connected processes, all the edge cases I'd considered! Clearly I had thought of everything.
But I skipped the most important step: asking myself why I needed to automate the entire fucking thing. I never even considered automating some of the processes instead of the whole damn workflow.
The main system was actually working fine - data extraction, processing, formatting. But this one part - Google 2FA authentication - became my white whale:
Version 1: Standard automation approach. Failed because 2FA doesn't work like regular APIs.
Version 2: Tried using browser automation libraries. Failed because Google's anti-bot detection is smarter than my scripts.
Version 3: This is where I really lost my mind. Went down the rabbit hole with Arc browser in debug mode, trying to use Chrome's DevTools Protocol. Picture this: me, at 2am, staring at browser logs, convinced I was about to crack the code. The whole thing was slower than a government website, crashed every 10 minutes, and was basically digital rubbish. But I was sure this was the "professional" way to solve it. Because clearly, if it's more complicated, it must be better, right? Wrong again, genius.
Version 4: I'm still working on this one - a much simpler "semi-auto Session Harvesting Service" where I manually login then share the session details back to the main system.
Each commit to GitHub gave me this false impression that I was making good progress. Look at all these updates! So much activity! New authentication approach, refactored session handling, improved error handling. Clearly I was solving important problems, right?
Wrong. I was just creating elaborate solutions to problems I had created for myself.
The Reality Check
At some point during all this, my staff jokingly asked me why I was spending so much time on this authentication thing. I explained my beautiful automation vision and how I was so close to cracking it.
That's when it hit me - and it hit me like a fucking truck because I'm the one who always reminds others to "take a step back and don't get too narrow-minded and end up fixing the symptom instead of the root cause."
Here I was, the guy who preaches about asking why before how, spending weeks trying to automate a 30-second manual task. The irony was so thick you could cut it with a knife.
Can I blame Claude Code for this? Probably not. This was pure human arrogance meeting reality.
My real goal was to save time on report generation. But I got so obsessed with building the perfect automated system that I was spending way more time building than the actual manual work would have taken.
0% of 100% is still 0%. I had zero working automation because I refused to accept anything less than perfect automation.
The Three Things I Learned (The Hard Way)
Projects aren't goals - they're tools. I fell in love with my automation project instead of focusing on my actual goal: saving time on report generation. If you're building something with AI right now, ask yourself what you're actually trying to achieve. Don't make my mistake.
Commit to not committing too early. When working solo with AI, I need to be extra careful about falling in love with my first solution. There's no one around to tell me when I'm being stupid. I have to be that annoying person who questions my own brilliant ideas. You should consider doing the same if you don't want to waste a month like I did.
Don't jump to conclusions with the answer you have in mind. I had my perfect automation solution mapped out before I fully understood the constraints. If I had asked better questions upfront - like "what parts actually need to be automated?" - I would have saved myself weeks of pain. Learn from my stupidity.
The manual authentication takes 30 seconds. My automated versions are still a work in progress after a month. 0% of 100% is still 0%. I had zero working automation because I refused to accept anything less than perfect automation.
How to Avoid My Stupidity
Here's what I should have done (and the specific questions you should ask yourself if you don't want to repeat my mistakes):
Do a "Why Session" with yourself - Even when building solo, write down what you're actually trying to achieve. For my project, I should have asked: "Is saving 2 hours per week worth a month of development time?" and "What's the minimum viable automation that gives me 80% of the benefit?" The answers would have been obvious. Force yourself to document the real problem before falling in love with solutions.
Question every "requirement" with specific tests - My brain labeled "full automation" as a requirement, but it was just an assumption. Ask yourself: "What happens if this part stays manual?" "What's the actual cost of doing this step by hand?" "Am I solving this because it's important or because it's technically interesting?" Most constraints aren't actually constraints.
Measure progress by working solutions, not GitHub activity - This one hurt the most to learn. GitHub commits don't equal real progress, but they feel like progress. Every day I was pushing code, refactoring authentication handlers, improving error messages. It felt productive as hell. But productive activity isn't the same as productive outcomes. I should have measured success by "does this save me time today?" not "how many commits did I make this week?" If your automation doesn't work yet, you haven't made progress - you've just been busy building monuments to your own stubbornness.
Accept that 80% automation beats 0% perfection - Ask yourself: "What's the simplest version that provides value?" and "What's the hardest 20% that's blocking everything else?" The hardest lesson for any perfectionist: partial solutions that work are infinitely better than perfect solutions that don't exist.
Bottom Line
Claude Code makes building solutions easier, but it doesn't make understanding problems easier. If anything, it makes it harder because you get seduced by what's technically possible instead of focusing on what's actually useful. Plus, it makes you feel like you have superpowers, so you'll continue paying for that monthly subscription while building increasingly complex solutions to simple problems.
Before I build my next automation, I need to ask myself: What happens if I only automate the easy parts? What happens if I leave the hard stuff manual?
Consider asking yourself the same questions if you don't want to waste your time building perfect solutions to the wrong problems.
Sometimes the best solution is the one that works, not the one that's perfectly automated.
Should we continue building cool shit with AI? Hell yeah. But make sure you're doing something that actually matters first. Learn from my mistakes if you don't want to waste your own month building the same broken thing four different ways.
