jkkramer

I did do it again, and spent time figuring out how to do it even more.

The cool thing though is that I could have chosen to do something else, too. I’m not at a loss for fulfilling, productive things to do. AI won’t change that.

Just yesterday I noticed I was mentally EXHAUSTED after building out a feature with Claude Code.

I actually had to think really, really hard to keep up with the idiot savant as it cranked out code.

Correctness was extremely important for this feature. Claude would consistently make subtle mistakes, and I needed to catch them to keep things from going off the rails. I could have done it myself, but it would have taken MUCH longer.

I essentially compressed a week’s worth of work into a few hours, and my brain paid the price.

So yeah. You can use AI to replace your thinking, or you can use it to push yourself to your max potential.

As a fellow parent and hater of YouTube Kids, I've thought about building a replacement.

What holds me back is knowing that -- if this was an iPad app, for example -- I'd be at the mercy of both Google AND Apple. It's a minefield of sensitive topics:

- Kids & privacy

- Content moderation

- Intellectual property

- Third-party UGC

Way too risky.

Great little product! Seems like this could actually make good money with the right marketing.

Are you doing anything special to leverage TikTok or Instagram Reels? I notice you had a few sample posts. I'd go hard on that if you're not already: post yourself, hire micro influencers, etc.

A rule of thumb I sometimes use to assess products, including ones I've built:

Looking back at the last year, are you (or your users) happy with the time spent using the product? Do you/they regret it?

Juicing short-term engagement can be effective for startups, but it isn't everything, and doesn't necessarily lead to lasting value.

Everyone seems to be missing the obvious reason they want you to view Wrapped in the app: because they want you to share it to your stories on Instagram, Snapchat, etc, which you cannot do on the web.

When Wrapped came out a few days ago, virtually every person I follow on IG had shared their Spotify Wrapped. It's phenomenal marketing.

I would call its style unorthodox rather than nonhuman. It still plays common josekis (standard opening sequences) but often chooses uncommon variations. Its mid game is full of startling moves backed by VERY good reading. There's definitely still discernible strategy that us mortals can learn from.

If I recall correctly, the version that beat Lee Sedol was trained on amateur games plus self-play. My guess would be that this new version relies more heavily on pro games.

One technique that can be useful is imposing domain-specific restrictions, then passing responsibility down the chain.

For example, most people only have a handful of recent conversations; can you get away with ignoring distant-past conversations when it comes to read/unread marking? If so, you could send recent normalized data to the frontend and let it derive the unread state client-side. React has some nice tools for efficiently deriving state from server-sent data.

This isn't always the best solution, but it's something to consider.

It's my experience with their web-oriented and JavaScript projects. They definitely put out lots of high quality open source work in other domains.

It's interesting to contrast how Google and Facebook both approach open source for the web.

Google tends to release code and promote it without really using it much internally first. Documentation is prolific but confusingly organized and often fragmented among several versions simultaneously (cough, Google Analytics).

Facebook, on the other hand, actually seems to use their code before releasing and promoting it. Look at how they handled GraphQL: spec and reference implementation released a year ago, clearly labeled as a "Technology Preview". A lot of design work went into it before that, informed by the problems of internal product teams. Only a few days ago was it promoted as ready for production. The spec hardly changed it the last year. Documentation is good, and they work with the community to improve DX.

Why the difference? Hard to say, but my feeling is that there's a more direct link between Facebook's product-driven open source work and their bottom line. There are other startups constantly nipping at their heels, so they need to be on their game product-wise. Better code -> better products -> profits.

Google is largely impervious in the search and ad space, which is their cash cow. It almost doesn't matter how good or bad their other products are. The company is not at risk. Their open source work reflects that.

It looked like a risky dependency, simple as that. Despite the HN title, the point of the article was not to talk about React Router.

EDIT: Additionally, I'm not saying React Router is bad per se, just that it's not fully baked. I'm glad to see people working on the problem. I look forward to leveraging the fruits of their labor in the future (in fact, I already do - I use the history library on which RR is built).

You're not wrong. But it feels worse in JS. In both cases lib authors would do well to set proper expectations - if your lib is half baked, be up front about it.