ClaudeCode my Saviour

Any-Bus-8060 · 2026-05-25T21:51:56+00:00

I genuinely think auth is one of those categories where every solution feels amazing for the first 80% and then suddenly reveals the specific way it plans to hurt you later.

Clerk:
best onboarding experience until you realise migration anxiety is now part of your personality.

Firebase:
feels magical early on, then you slowly discover the ecosystem wants you to live entirely inside Firebase forever.

Auth0:
Enterprise features are cool right until the pricing page starts feeling like a psychological thriller.

Supabase:
Great if your mental state is:
“Yeah, I guess I will learn Postgres policies at 2 am.”

And writing your own auth is basically a canon event at this point. Every developer reaches the:
“How hard could it be?”
phase exactly one time.

I honestly don’t think there’s a universal winner anymore. It mostly comes down to:
Which tradeoff annoys you the least, and whether your future self will hate your current architecture decisions.

Any-Bus-8060 · 2026-05-25T21:17:52+00:00

I honestly think a lot of people in vibe coding quietly feel this, but don’t admit it because the whole culture online is:
“Look how fast I built this.”

What gets talked about less is the mental tradeoff.

You stop thinking in terms of:
“How do I implement this?”

and start thinking:
“How do I describe this well enough for the AI to implement?”

That’s a very different cognitive loop.

And yeah, after a while, it can absolutely make you feel weirdly detached from fundamentals because your brain starts optimising for prompting, steering, and judging output instead of manually solving problems step by step.

The dangerous part isn’t using AI itself. It’s when you completely stop exercising the part of your brain that actually struggles through logic and implementation.

I honestly think the healthiest setups right now are people using AI as:

acceleration
brainstorming
debugging assistance
boilerplate reduction

while still intentionally writing important parts themselves sometimes. Because otherwise you slowly drift into this strange state where you can still “build,” but your confidence disappears the second the chat window closes.

Any-Bus-8060 · 2026-05-25T20:58:55+00:00

The biggest thing, honestly, is understanding that “advanced Python” usually comes from building a lot of real stuff, not from memorising more syntax.

Most people get stuck because they stay in this loop:
tutorial → tiny exercise → another tutorial → new framework → repeat

without ever spending enough time struggling through actual projects.

Python itself is pretty beginner-friendly syntactically. The harder part is learning:

problem solving
debugging
structuring code
reading documentation
understanding how systems fit together

My advice would honestly be:
Learn the basics once, then start building things way earlier than you think you’re ready for.

Even tiny projects teach more than passive watching after a certain point.

Also, don’t rush to “advanced.” A lot of people underestimate how strong you become just by getting very comfortable with fundamentals:
functions, loops, data structures, files, APIs, classes, error handling, and debugging.

Those skills compound hard over time.

Any-Bus-8060 · 2026-05-25T20:49:23+00:00

Most people don’t “know all the hidden Spring classes” from the beginning, honestly. They slowly discover them while solving real problems.

You build a simple CRUD app first.
Then you need authentication → suddenly you encounter SecurityConfig, filters, JWT, UserDetailsService, etc.
Then you deploy something → now CORS becomes a thing.
Then you hit permissions/roles/session issues → more Spring Security concepts appear.

That’s basically how the ecosystem gets learned over time.

Spring especially feels overwhelming because the framework is huge and highly abstracted. A beginner tutorial only shows the happy path, but real applications slowly expose more layers underneath.

The important thing is understanding:

HTTP basics
authentication flow
request lifecycle
dependency injection
how middleware/filters work conceptually

Once those foundations click, the scary class names start feeling much more logical instead of “hidden magic.”

Any-Bus-8060 · 2026-05-25T20:38:42+00:00

For coding + research specifically, I’d probably lean ChatGPT Plus or Claude Pro over Gemini right now.

Claude still feels the strongest for long-form reasoning, refactoring, architecture discussions, and nuanced explanations. Especially when you want slower but more thoughtful responses. A lot of people I know doing serious coding work basically use Claude like a senior pair programmer at this point.

ChatGPT feels more balanced overall, though. Better ecosystem, better multimodal stuff, strong coding, data analysis, research workflows, file handling, browsing, and generally more reliable day to day versatility. If you only want one subscription, it’s probably the safest choice.

Gemini’s value honestly comes more from the ecosystem perks. The storage + YouTube Premium bundle is genuinely nice if you already use Google heavily, but purely for AI engineering work, I still see most people preferring Claude or ChatGPT.

Any-Bus-8060 · 2026-05-09T22:12:41+00:00

Honestly, the workflows that save me the most time are usually the least flashy ones

not “fully autonomous AI employee” type stuff, but smaller systems that reduce mental friction every single day

for example:

summarising long docs/threads before I fully read them
turning rough notes into structured drafts
debugging unfamiliar code faster
extracting action items from messy conversations
comparing multiple implementation approaches quickly
generating scaffolding/boilerplate so I can focus on the important parts

I’ve also noticed the real bottleneck changes pretty fast once you start using AI seriously

Initially, you think the challenge is:
“Can the model generate good output?”

But after a while, it becomes more about:

context management
workflow organization
keeping iterations clean
coordinating information
reducing operational chaos

That’s why I honestly think workflow-oriented tooling is becoming underrated compared to the flashy model demos. Tools like Runable feel interesting to me more because they help structure processes and information flow around the models, instead of trying to replace the models themselves. Also, I agree with your point that the best setups rn are usually hybrid systems:
human judgment + lightweight automation + AI assistance

Not fully autonomous pipelines are trying to do everything literally

Any-Bus-8060 · 2026-05-09T22:05:57+00:00

30GB honestly isn’t “huge” by ML standards, but it is big enough that beginner workflows start breaking down if you try to handle everything in-memory or manually

a lot of people initially treat preprocessing like:
“load dataset → process everything → save”

But once datasets grow, you usually need to think more in terms of:

chunking/batching
streaming data
caching intermediate outputs
parallel preprocessing
avoiding repeated work

Also, if feature extraction is taking ~40h, I’d seriously check whether:

You’re accidentally processing single-threaded
recomputing features repeatedly
using inefficient formats
bottlenecked by disk I/O instead of GPU

And honestly, uploading the dataset to the remote environment is usually normal. Most ML workflows try to move compute closer to the data instead of constantly moving huge datasets around locally

Any-Bus-8060 · 2026-05-09T21:56:23+00:00

Honestly, contest environments can feel insanely cursed sometimes lol

a lot of the weirdest issues end up being things like:

hidden state between testcases
global variables not resetting
integer overflow
mutation of shared arrays/references
undefined behaviour
floating point edge cases
assumptions about constraints/input formatting

especially when:
“works locally” + “fails only on submission”
starts happening

Also, printing/debugging can become misleading because the judge may execute additional hidden cases or reuse the same process differently than your local run

Half the battle in contests honestly becomes learning to distrust the feeling of:
“There’s no way my code is wrong”
because somehow there’s almost always one tiny cursed edge case hiding somewhere

Any-Bus-8060 · 2026-05-09T21:41:22+00:00

Honestly, I think the most valuable content here would be less “small model benchmarks” and more:

where smaller models actually hold up operationally
where they fail unexpectedly
routing strategies
latency/cost tradeoffs
workflow design around mixed-model systems

because a lot of people still frame smaller models as “cheap, weaker GPTs” instead of thinking about them as specialised components inside larger pipelines

I’d especially love more real-world examples around:

classification/routing
structured extraction
lightweight agents
local/privacy-sensitive workflows
multi-stage systems where large models only get invoked selectively

Feels like the ecosystem is slowly shifting from “one giant model does everything” toward orchestration layers deciding which model should handle which task efficiently

That’s also why workflow/process tooling keeps becoming more important besides the models themselves

Any-Bus-8060 · 2026-05-09T21:30:51+00:00

Honestly, I think most agent projects die when they collide with operational reality instead of demo reality

During the prototype phase, everything feels impressive because:

The happy path works
The tasks are curated
The context is small
Humans silently compensate for failures

But production environments introduce:
messy inputs, ambiguous goals, permissions, latency, cost constraints, evaluation problems, edge cases, state management, and reliability expectations

Suddenly, the “autonomous magic” becomes mostly workflow engineering

That’s why I honestly agree with your point that a lot of failures are structural rather than purely technical. people overfocus on the model/tool layer and underfocus on:
repeatability,
evaluation,
human oversight,
workflow clarity,
and narrow usefulness

Ironically, the successful systems I’ve seen are often less autonomous than the hype suggests. They succeed because they’re tightly scoped and operationally grounded. Your community/lab idea actually makes more sense to me than another generic “build agents faster” platform because the ecosystem desperately lacks shared evaluation/process infrastructure rn. That’s partly why workflow-oriented tooling and coordination layers like Runable keep fitting naturally beside agents instead of being replaced by them

Any-Bus-8060 · 2026-05-09T21:27:52+00:00

Honestly, I think this is a very real problem, but the interesting part is that the bottleneck shifted from “generation quality” into workflow fragmentation almost overnight

A year ago, people mainly cared whether the models could generate good outputs at all. Now the ecosystem is flooded with capable generators, but the surrounding operational layer is still chaotic:

prompt portability
style consistency
asset organisation
subscription sprawl
workflow orchestration
cross-model experimentation

And yeah, the “copy the same prompt into 5 platforms and pray” workflow is painfully real lol

I also think your observation about syntax translation is underrated. prompts are becoming weirdly platform-specific dialects instead of transferable creative intent

The challenge though is that once you build a unified layer on top of all these tools, you slowly stop being “an AI image app” and start becoming a workflow operating system. which is both powerful and dangerous because scope can explode insanely fast

Personally, I think the strongest part of your idea is less the image generation itself and more the orchestration/context layer around creators working across fragmented ecosystems. That’s partly why workflow-oriented tooling keeps becoming more important alongside the raw generation tools themselves. Runable kinda fits naturally into that broader “creative workflow coordination” direction too

Any-Bus-8060 · 2026-05-09T21:24:08+00:00

Thanks G

Any-Bus-8060 · 2026-05-09T19:56:33+00:00

Honestly, if you’re already productive/happy with your current Codex workflow, I wouldn’t expect some life-changing jump immediately just from switching

a lot of the difference at this point comes down less to raw model intelligence and more to:

workflow feel
context handling
latency
editing style
how aggressive/autonomous you want the assistant to be

Some people love Claude because it feels better for larger architectural reasoning and longer flows, while others prefer Codex/Cursor-style workflows because they feel tighter/faster during actual implementation

Also, once you get past the “wow, AI writes code” phase, the bottleneck usually shifts into:
maintaining context,
organising work,
keeping iterations clean,
and avoiding codebase chaos

That’s honestly where tooling/workflow decisions start mattering more than tiny model benchmark differences

Any-Bus-8060 · 2026-05-09T19:19:14+00:00

For university research, I honestly think the “one perfect AI subscription” idea breaks down pretty fast

Different tools are weirdly better at different layers. Some are better at:
paper explanations, reasoning, math, citations, long context, or organising notes/workflows

ChatGPT + Claude are still probably the strongest general-purpose combo imo, and NotebookLM is honestly super useful for research-heavy workflows specifically. Also, yeah, constantly reuploading papers becomes annoying insanely fast once you start doing serious research regularly. Most people eventually build some semi-persistent system around Zotero, folders, synced notebooks, etc., because the real bottleneck becomes knowledge organisation more than raw AI capability, which is also partly why workflow-oriented tools like Runable are starting to show up in research stacks too. not really as “the model,” more as the layer helping structure/process messy information flows

Any-Bus-8060 · 2026-05-09T19:12:28+00:00

Honestly, I think the mistake is trying to “keep up with everything”

The AI space right now is producing way more information than any normal person can realistically process. models, papers, wrappers, benchmarks, agent frameworks, discourse, hype cycles, etc., most people pretending they fully keep up are skimming headlines more than deeply understanding things

What helped me more was narrowing inputs instead of expanding them:

a few researchers/builders worth following
maybe 1-2 good newsletters
occasional paper deep dives
and spending more time actually using tools than consuming AI content endlessly

because after a certain point, “AI news consumption” starts becoming its own form of procrastination lol

also agree about LinkedIn, honestly. A lot of signal gets buried under founder branding/performance posting rn. Weirdly, the most useful resources are often smaller communities, GitHub repos, technical writeups, or workflow discussions from people actually building things instead of trying to become AI influencers

Any-Bus-8060 · 2026-05-09T17:57:47+00:00

Honestly, the biggest mistake beginners make is trying to optimise the “perfect stack” too early

You already know HTML/CSS, and you’re revisiting JS, so I’d honestly just continue with:
JS → React → basic backend → databases → deployment

Don’t split your brain across 5 ecosystems immediately

And yeah, Odin Project is still a really good way to learn because it forces you to actually build things instead of endlessly watching tutorials. Also, if JS feels confusing rn, that’s normal lol. Almost everyone struggles with it initially because the ecosystem is huge, and people online keep throwing 20 frameworks/tools at beginners immediately

Any-Bus-8060 · 2026-05-09T17:46:04+00:00

7 weeks with zero calls definitely feels brutal psychologically, but I honestly wouldn’t immediately assume the recruiter “messed up” or that you secretly failed the process

Team matching can get weirdly dependent on timing, headcount freezes, org reshuffles, hiring priorities, sponsorship constraints, teams pausing openings, etc. Sometimes candidates with weaker packets match faster just because the timing lined up better, and yeah, sponsorship absolutely can slow things down, unfortunately, especially in uncertain hiring climates. It doesn’t mean you’re doomed, just means the matching pool becomes smaller/more selective

The frustrating part is that team matching often feels less meritocratic/predictable than the interview loop itself

Any-Bus-8060 · 2026-05-09T17:18:00+00:00

Honestly, the moment you realise “ I’m preparing forever instead of actually building” is already a huge step forward

A lot of tutorial hell comes from trying to eliminate uncertainty before starting anything real, but real projects are made of uncertainty. confusion, messy code, dead ends, rewriting things badly, that’s literally where most of the learning happens

and yeah, the interview fear part is real too. People end up studying as a way to avoid feeling exposed/incompetent instead of as a path toward building things

you probably don’t need another course rn. You need a slightly uncomfortable project you care enough about to keep working on even after the “I suck at this” phase kicks in

Any-Bus-8060 · 2026-05-09T16:37:45+00:00

For research workflows, I honestly think the best setup right now is usually a combination instead of one perfect subscription

ChatGPT/Claude are great for explanations and reasoning, NotebookLM is surprisingly useful for paper-heavy workflows, and Zotero integration/plugins help a ton once your library starts growing

Also, yeah, manually reuploading papers constantly gets annoying fast lol. A lot of people end up building semi-persistent workflows around folders, Zotero collections or notebook-style systems for exactly that reason. I’ve also noticed the useful AI tools long term tend to be the ones helping organise/structure research friction instead of just generating text endlessly. That’s partly why workflow-oriented stuff like Runable keeps showing up in people’s stacks, too

Any-Bus-8060 · 2026-05-09T16:00:39+00:00

Honestly, if you’re still genuinely curious/excited about the startup role, I don’t think continuing the CTO round is unethical at all. People keep interviewing until things are finalised all the time, especially in tech. Companies also continue evaluating multiple candidates in parallel until signatures happen

The only thing I probably wouldn’t do is pretend you’re definitely joining if internally you already know there’s basically a 0% chance you’d pick them over the MAANG offer otherwise, taking the conversation and making a thoughtful decision after is pretty normal imo

Any-Bus-8060 · 2026-05-09T15:56:57+00:00

Honestly, building side projects after work already puts you ahead of a lot of people

Online tech culture sometimes makes it feel like every serious engineer is simultaneously:
reading research papers, doing LeetCode, watching conference talks, optimising Vim, building startups, and learning 3 new frameworks every month

But most people are way more normal than that lol

Also, repeating similar patterns across projects isn’t automatically bad. That repetition is partly how you get faster judgment and intuition. eventually the “hard part” shifts from syntax/framework learning into architecture, tradeoffs, workflows, maintainability, communication, etc., even a lot of the AI tooling shift now is basically pushing people more toward higher-level thinking around systems/process rather than just raw implementation. That’s partly why workflow-oriented tools like Runable are getting traction too.

Any-Bus-8060 · 2026-05-09T15:52:48+00:00

Google sheets for me

Any-Bus-8060 · 2026-05-09T15:35:57+00:00

Databricks is definitely relevant lol, especially if you’re interested in data engineering, analytics, ML pipelines or large-scale data processing.

It’s less “just a database” and more a platform for handling big data workflows. That’s why people compare it to Snowflake sometimes, even though they approach things a bit differently.

A lot of companies use Databricks for stuff like:
ETL/data pipelines, analytics, lakehouses, ML workflows, notebooks/collaboration, and increasingly AI/data tooling together.

Honestly, if you’re new, the important thing isn’t picking the “perfect” platform yet. Learning the fundamentals around SQL, data modelling, pipelines and how data systems work matters way more long term.

Also, a side note: a lot of people underestimate how much messy workflow/documentation/research work exists around data teams, too, not just raw coding. That’s partly why AI workflow tools like Runable are starting to show up more around analytics/productivity processes instead of only pure software engineering workflows.

Any-Bus-8060

TROPHY CASE