HackerTube: HN's Twenty Years of Video Picks, Built in Two Hours

Opening Dialogue

Shiwen: Two days ago, Andrej Karpathy created a site called HackerTube on Hacker News, claiming it was a clone of YouTube, with data sourced from videos recommended by Hacker News from 2007 to 2026. Most notably, he said the entire site was developed in just two hours using Claude Code’s Opus 5.5. Don’t pay attention to the time frame—is this approach worth discussing?

Yongliang: It’s worth discussing, and there are two aspects. One is the engineering implementation: building a functional product in two hours using an agent. The other is the product philosophy: replacing YouTube’s algorithmic recommendations with Hacker News’ collective aesthetic over these twenty years. But don’t get too excited about either aspect. The two hours were because the site was small, and the 503 server was already available.

Q1: How were those two hours spent?

Shiwen: What was the specific process?

Yongliang: Karpathy’s request to Claude Code was simply: “Let’s write our own YouTube clone based on whatever videos have been recommended on Hacker News.” He chose Opus 5.5 Medium effort mode. Opus first downloaded all comments from Hacker News, filtered out those containing YouTube links, then ran a Sonnet workflow to remove irrelevant content, finally producing about 40,000 comment posts corresponding to 6,454 YouTube videos, categorized under 150 topics. The front end had a YouTube-style UI with 50% thumbnail images, ForYou recommendations for users without accounts, local session storage in the browser, and keyboard shortcuts. The rest involved domain names, VPS, security加固, and optimization.

Shiwen: What does Medium effort mean?

Yongliang: It refers to the work intensity level in Claude Code. Medium effort means the agent explores and iterates autonomously within a certain number of steps, without the need for users to confirm every sentence. This saves effort compared to full manual processing, but Karpathy still needs to intervene at critical moments to make decisions and verify results.

Shiwen: So, it wasn’t him who actually wrote the code?

Yongliang: No. As he said in his blog: “I don’t actually do anything resembling traditional engineering anymore… I only talk to Claude and let it do everything.” He no longer touches traditional coding or running terminals. He did three things himself: obtaining a Google Cloud API key to check video metadata, setting up a VPS, and buying a domain name. In his words, “I do these tasks in my spare time while working with Claude, and it feels like teamwork.”

Shiwen: There’s a trust issue here. Doesn’t he check the diff?

Yongliang: This question hits the mark. Karpathy’s approach has shifted from “looking at diffs” to “observing behavior.” He relies on Claude Code’s complete trace, exported full-site data, and actual performance after launch. Whether the code looks beautiful or not doesn’t matter anymore; the acceptance criteria have changed to whether the site can function, recommendations are relevant, and user interactions are smooth. Establishing this trust chain depends on the transparency and reproducibility of the agent.

Q2: Why do HN’s recommendations outperform YouTube’s?

Shiwen: Karpathy criticizes YouTube as “an enshittified wall of slop,” with exaggerated thumbnails and homogenized content. Can HN’s recommendations solve this problem? Yongliang: This is an experiment to replace algorithmic feeding with community curation. HN’s recommendations come from reviews users have written seriously over the past twenty years, backed by a group of people who are willing to read long texts and delve into deep content. It doesn’t win by recommending more popular topics; instead, it uses “having been discussed on HN” as a quality threshold. Shiwen: Does it have any problems? Yongliang: Yes. First, the scale: 6,454 videos are insignificant compared to YouTube’s volume. Second, timeliness: HN recommendations naturally have delays, and many popular topics can only get in after discussions start. Third, taste bias: HN mainly features technical, scientific, and entrepreneurial content, while entertainment and lifestyle content rarely gets in. It won’t replace YouTube; it will become a curated channel for a specific audience. Shiwen: From the perspective of self-media creators, what insights does this community curation offer for content distribution? Yongliang: Current content distribution is becoming increasingly homogenized. Platform algorithms push people to content that easily evokes emotions to maximize dwell time. HN’s model offers a counterpath: using community trust and long-term discussions to filter content, rather than click-through rates and completion rates. For creators, this means that depth and long-term value may be revalued, provided you can enter such communities or become such curators. For self-media creators, curatorial skills and audience trust are more valuable than simple traffic techniques. Shiwen: What about the 50% thumbnail design? Yongliang: This is a key detail to reduce the sense of slop. YouTube’s thumbnails become more exaggerated to attract clicks, with more exaggerated expressions being better. HackerTube halved the thumbnail size, reducing visual impact and allowing users to focus on titles and community discussions. This restraint itself is a product stance: not driven by click-through rates, but by content itself. Shiwen: Will it be quickly replaced by AI search? Yongliang: The problem with AI search is similar to platform algorithms, which provide results based on statistical relevance, lacking the context and judgment from community discussions. HackerTube’s core is curation; retrieval is just its most superficial function. As long as people still need reliable filters, this community curation will have a place.

Q3: What lies behind its two-hour launch?

Shiwen: Is this speed really enviable?

Yongliang: It’s possible to be envious, but you need to clearly understand the cost structure. It can be done in two hours because the entire product is very simple: no account system, no backend recommendation engine, data is calculated offline, the front end uses YouTube embedding, and the recommendation logic consists of static lists plus local sessions. The occurrence of 503 errors indicates that a site built by an agent overnight and one capable of stable service for large amounts of traffic differ significantly in terms of operation, capacity planning, caching, and error handling.

Shiwen: Where did you see this detail about 503?

Yongliang: Someone mentioned in the HN comment section of HackerBooks, “HackerTube is 404ing and 503ing, so it might not last a day.” This is normal; when a hack on a Saturday morning is accessed by thousands of people at the same time, 503 errors are almost inevitable. It doesn’t mean Karpathy’s abilities are poor; rather, “building a site overnight with an agent” and “operational services” are two different things.

Shiwen: So it’s not production-level?

Yongliang: Given its current state, it’s more like a well-packaged demo. Karpathy himself said it was “a hack on a Saturday morning.” This isn’t a negative; it reminds us that the agent has minimized the cost from idea to prototype, but the distance from a prototype to reliable service hasn’t shortened. His ability to export all site data is interesting; saying “give your agent a chance to build its own version” means that reproducibility has also been taken into account.

Shiwen: What’s the value of such a demo?

Yongliang: The value lies in lowering the threshold for trial and error. In the past, you might need to recruit a team and schedule two weeks to verify an idea; now, one person can launch a usable product in just one morning and see how it performs in the community. If it gets good feedback, then true engineering efforts can be invested; if it’s average, the cost is just one morning. This ability to quickly test is more important than the number “two hours to launch.”

Q4: Why did HackerBooks and HackerTok appear within a day?

Shiwen: After HackerTube went live, HackerBooks appeared the next day, and some people also shared HackerTok in the HN comment section, saying they created it using Claude after seeing Karpathy. What do you think?

Yongliang: This is a typical example of the chain reaction that occurs after “the cost of implementing an idea reaches zero.” When building a site only requires one sentence and two hours, what was once a scarce resource becomes “topic selection and taste.” HN’s twenty-year comment data is public property, and anyone can use it for secondary curation. HackerBooks even makes the data CSV files available for download, more open than HackerTube.

Shiwen: What about the specific data?

Yongliang: As of November 2nd morning, HackerTube’s original posts on HN had over 2200 likes and 534 comments; HackerBooks followed closely with 846 likes and 168 comments. HackerTok currently only has one comment with self-reporting, no independent verification. This popularity shows that there is strong consensus among people about “recreating a content platform using community data.”

Shiwen: Is following this trend meaningful?

Yongliang: Yes, there is also a bubble. The significance lies in showing that now one can验证 a concept at very low cost; the bubble is that if everyone just changes the shell without new curatorial logic or community trust, aesthetic fatigue will soon occur. The value of HackerTube lies in its 20-year data accumulation behind it. If followers don’t have similar data assets, they are just building an empty shell.

Shiwen: So do these derivative sites add value to HackerTube or dilute it?

Yongliang: In the short term, they add value because they expand the narrative from “one person’s two hours” to “the emergence of a new paradigm.” In the long term, it depends on whether HackerTube can continuously maintain its data and community. If it only stays at the demo stage, and HackerBooks or HackerTok perform better in terms of data and openness, then first-mover advantage isn’t much of an advantage.

Q5: What lessons can it teach ordinary creators and developers?

Shiwen: The last question, what lessons does this teach us who deal with content and code every day?

Yongliang: For creators, it reminds us that AI search and recommendation are becoming increasingly homogeneous, and community trust and curatorial taste will become new barriers. YouTube’s algorithm works for the median user but not for specific groups. Future distribution may not be a single platform, but countless small, credible curatorial layers.

Shiwen: What about developers?

Yongliang: Developers need to re-evaluate their workflows. Karpathy now doesn’t write code or run terminals, only talks with Claude. For most people, it’s too early to completely copy him, but abilities like “requirement description, acceptance criteria, and boundary judgment” will become increasingly important. You need to clearly state what to do, what not to do, what counts as good, and what counts as bad.

Shiwen: Does that mean we don’t need to learn programming in the future?

Yongliang: No. Programming has changed from “handwriting every line” to “designing processes, verifying results, and handling exceptions.” The real challenge isn’t making AI write code, but knowing whether the code is correct, can it be launched, and how to roll back if problems occur. These judgments still need to be made by humans.

Shiwen: For teams wanting to try this working style, what advice would you give?

Yongliang: Don’t start with “I also want to build a site in two hours.” Start with your real pain points, create a minimum viable version in a weekend, and then invite real users to use it. The key is to clearly define acceptance criteria: feature scope, performance baseline, and rollback plans for errors. Also, don’t treat agents as black boxes; keep key data, critical decisions, and configurations in your own hands. Finally, be prepared for 503 errors, because the code written by agents will likely fail during initial deployment.

Shiwen: For managers of small and medium-sized technical teams, what does this mean?

Yongliang: It means redefining performance and roles. In the past, we looked at an engineer based on how beautifully they wrote code and how quickly they fixed bugs; in the future, we’ll see whether they can break down business problems into processes that agents can execute, design acceptance criteria, and maintain manual approval at key points. New roles like workflow designer and agent reviewer will emerge, and evaluations will no longer be based on code output, but on process stability, reproducibility, and error rollback capabilities.

Shiwen: What should individual developers practice most now?

Yongliang: The ability to turn vague ideas into clear acceptance criteria. Can you explain in three sentences what this function does, what it doesn’t do, what counts as good, and what counts as bad? This capability used to be called product sense; now it’s a basic skill for working with agents. The sooner you start practicing, the faster you’ll see compound returns.

Shiwen: So what’s your overall judgment?

Yongliang: HackerTube demonstrates that people with ideas can now share them at extremely low cost. What’s truly scarce now is not just the speed of coding, but the ability to choose topics, have taste, build community trust, and turn prototypes into reliable services. Most people should focus on testing a few ideas they truly care about while costs remain low. After all, only those who can explain their value in two minutes are worthy of talking about two-hour implementations. This skill pays off every day of practice, and this window won’t always be open.

---

Signature: Yongliang