3,732 karma · joined December 3, 2012
Our PMs don't like making things opt-in.
-> Your users don't like making things opt-out. Low usage metrics is a UX problem. Activating it without informed consent gives you bloated metrics anyway.
i have no doubt, but this has nothing to do with the MVP being vibe coded or not - this has something to do with the (technical)experience of the founder + other personality traits
A startup founder uses AI to create an MVP
to
They secure funding based on the demo
to
They find themselves unable to move beyond that initial prototype
I have trouble believing tech investors throwing money towards a founder that shows a vibe coded product without anything else. The product might be vibe coded, BUT the founder show some traction or discovered a new market or something besides a demo. It does not really matter how a founder did the MVP, they did not create google. They just showed, through the MVP, something to investors. What happens next, after money, i doubt it's vibe coded.
-> it's not marketing you suck at, it's building for someone else that you do
>However, as a techy, I can't seem to build useful things, or things that generate money.
-> build something for someone else, don't think about revenue. Even if you build for 1 person, something will click when you see they're using what you build and only then you will figure it out.
Think of it like this:
-> do you have someone close that calls you when they have a problem where you're the expert in(something computer i'm guessing) - if yes, do the same thing, but build something after you understood their pain, iterate until they cannot live without your solution(big/small whatever it is) - don't let them design their solution - you're the solution designer, you need to understand their pain.
> Models with stronger coding abilities (Claude 3.5-Sonnet, GPT-4o) achieved higher Production Scores and completed more lab tasks. Claude outperformed others with a PS of 293,206 and 28 milestones, progressing beyond early-game resource extraction.
The guy can explain how to rewire your brain in 30 seconds, but somehow his podcast episodes are longer than The Godfather trilogy. Seriously, I tried listening to one, and by the time it was over, I had a PhD in neurobiology and a full-grown beard.
And let’s talk about the Huberman fanboys—walking around like sleep-deprived cyborgs because they refuse to drink coffee after noon and think breathing techniques are a substitute for therapy. You’ll catch them in the gym whispering “tuberculosis” breathing while doing cold plunges and wondering why no one wants to hang out with them.
But in all seriousness, Dr. Huberman is brilliant, and if I ever need a 47-step protocol for blinking optimally, I know exactly where to go.
What really gets me is the whole leadership vibe. If Linus had just clearly said, “Alright, Rust is in, but only in these specific parts and under these conditions,” a lot of this back-and-forth and social media shouting would’ve been avoided. Instead, we’ve got a bunch of maintainers arguing about process and even threatening to use social media to shame people, which just adds more fuel to the fire.
At the end of the day, it’s not as simple as “Rust or no Rust.” Some parts of the kernel might really benefit from Rust’s safety, while other parts might be fine sticking to C. The real challenge is figuring out how to integrate Rust without turning everything into a maintenance nightmare. We’re all aiming for a better, more robust kernel here, but if we keep getting bogged down in personal drama and endless debates about process, nobody wins. Maybe it’s time to take a deep breath, set some clear rules, and move on instead of letting all this online drama derail progress.