Hacker Newsnew | past | comments | ask | show | jobs | submit | vtemian's commentslogin

Git was designed for humans.

Commits, branches, and the entire model works really well for human-to-human collaboration, but it starts to be too much for agent-to-human interactions.

Sharing the entire session, in a human, readble way, offering a rich experiences to other humans to understand, is way better then having git annotations.

That's why we built https://github.com/wunderlabs-dev/claudebin.com. A free and open-source Claude Code session sharing tool, which allows other humans to better understand decisions.

Those sessions can be shared in PR https://github.com/vtemian/blog.vtemian.com/pull/21, embedded https://blog.vtemian.com/post/vibe-infer/ or just shared with other humans.


why was this post removed? it was #1


> For me, the joy of programming is understanding a problem in full depth, so that when considering a change, I can follow the ripples through the connected components of the system.

100%. The fun is in understanding, creating, exaplaining. Is not in typing, boilerplating, fixing missing imports, and API mismatch etc.


This nails what vibe coding actually is. The model handles execution, but intent and taste stay human. That’s where the real leverage is.


PING google.com (172.217.17.142): 56 data bytes

Request timeout for icmp_seq 0

Request timeout for icmp_seq 1

Request timeout for icmp_seq 2


I'm still searching for successful vibe coding examples.

Each time I tried it, with custom rules, git, and all the best practices I found, it went amazingly well initially, and garbage afterward.

Using the same technique, after a while, it generates a lot more shitty code than helpful.

> So, it’s shit and you’ll spend a long time fixing it.

It just takes more time overall to make it functional. Fixing, debugging and improving vibed code takes more mental resources and time than just writing it from scratch.

Also, there's the flow aspect. Each time you let it "vibe", you're losing the flow state that is important while creating and thinking about complex work.


>I'm still searching for successful vibe coding examples.

I'm wondering what this means.

Kind of by definition, you wouldn't be able to tell "successful vibe coding" from "successful coding", right? Unless someone announces it. And a quick look at the comments here, or any other thread with about AI & coding, would immediately tell you is a bad idea to announce.

There's a few things you just don't say on HN, because you'll be piled-on immediately: don't criticize Kagi, don't hint at being pro-cryptocurrency, don't announce you "vibe coded" something even if it's extremely successful, etc.

(The immediate downvotes on this is actually hilarious, and proves the point)


What's the actual magnitude of this outage? Is there a way to estimate how many machines were down?


Serverless all the way. There are a lot of good options out there, with AWS being quite flexible.

The onboarding for other developers is also painless. I've recently experiment with AWS Amplify and even if is not quite there yet, is pretty close.

Lambda, cloudfunctions, https://supabase.com/, https://hasura.io/, AWS Amplify, https://aws.amazon.com/serverless/.

For frontend, I would go with either React or Vue, both with a huge community and already a lot of builtin solutions. I would 100% start with a design system, maybe material UI.

Nothing fancy, low maintenance and painless onboarding/development experience.


Yeah...we know, but there is a plan of rewriting / refactoring some parts and we hope to port as much as we can from Python 2 to 3 by the end of this summer.

Thanks for reminding us ^_^


The whole "Python 2 only" thing feels pretty 2012.


I accidentally upvoted your comment which is annoying as I think your attitude stinks. This is a useful project, what language it was or wasn't written in should be irrelevant. You'd already pointed out that it disappointed you, a pointless comment but fair enough, then you went on to rub it in further - was there a need for that? No.


Yes, it can be scary, but usually this is the safest strategy. You can implement your own strategy and use it very easily (https://github.com/PressLabs/gitfs/tree/master/gitfs/merges).

Also, you can see how conflicts are solved, directly in the implementation (https://github.com/PressLabs/gitfs/blob/master/gitfs/merges/...).

Do you want to know something more specific?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: