Backend recommendations:

I'm much less confident about this.

1. If you want a working backend with minimal effort, because actually the React part was the fun thing
   1. Firebase (Firestore) :
      1. This gives you, sort of, an autogenerated backend, if only you describe the structure of your database. I'd mainly recommend this if you're not interested in writing a backend but you still want things to work as if you built an amazing backend.
      2. The main disadvantage is it will be different from what many databases look like.
         1. You could skip the "subscribe for changes" feature and only use the "read" feature and it will be a bit more realistic, but I don't actually recommend that.
2. If you want to write backend in a way that will push you towards best practices, using a technology that is very popular (and specifically documented well for beginners)
   1. Django
   2. A big disadvantage is you'd need to learn some pyhton, and you might be reading this because you already built a fun React project and you want to get it done without learning lots of new tech
   3. DB:
      1. Postgres is the default normal DB for most use cases. SQLite might be easier for local development (on your laptop), and is missing some features that you'll almost surely not notice, so please don't care about them until a concrete problem comes up.

Things that automatically override this advice:

1. If you're picking technologies for your startup or something then remember this wasn't written for you.
2. If you have a senior developer who will mentor you if you work on some different technology that they know well, then probably go with them.

Tech stack recommendations:

Many people who want to build a side project want to build a website that does something, or an "app" that does something (and could just be a website that can be opened on a smartphone).

So I want to add recommendations to save some searching:

1. React. You can learn react from their official tutorial, or from an online course. Don't forget to also learn any prerequisites they mention (but you don't need to invent your own prerequisites)
   1. If you want a React competitor, like Vue, that's also ok (assuming you're more excited about it).
      1. Choices I don't think are legit: JQuery, vanilla javascript.
         1. I can elaborate.
         2. (If someone sent you to "learn the basics" then I probably disagree with them. Yes it has value, but it's not the most effective path to a first job with mentorship nor to getting far in 5 years. There are other times to learn these things which are not "before your first job")
2. For graphics (making your website nice)
   1. If you don't care about graphics, you can skip all that (including css)
   2. If you don't want to put effort into graphics but you want your website to look nice anyway, you can use Material UI or Bootstrap. They have ready components like a pretty button or a pretty checkbox, you just import them and only do minimal customization like "hey checkbox, you're disabled by default".
   3. If you think making a pretty website is really cool and is obviously the exciting thing to do: you can learn css, and perhaps Tailwind. This isn't a path I took myself and I don't know it well. Just remember - it's a higher priority to get a first project done even if bad and ugly. But as part of "looking for things that excite you to learn more", graphics might be one of them
3. Deploying (having a url that you can send to your friends, or put on your CV)
   1. Firebase Hosting
      1. There are many fun ways to deploy websites, including React, I'm specifically recommending Firebase because you might want to use it to solve other problems too (which I might write about).
4. Backend
   1. If you mainly wanted to make a website-that-does-something, I'd start with that before getting into backend. Once you reach this point on a real project, check if you actually want to continue here. The main important thing is that you work on something that excites you, so you have my official permission to leave your project "not perfect", without a backend (even if it needs one), if you think that part will be less fun.
   2. Main things a backend will give you (written here so you can check if this seems exciting or meh)
      1. User login
      2. Communication between users (for example if it's anything like a chat)
      3. Saving information that will still exist if you open the website in a new browser (for example, if you have a TODO list, you probably want to see the list both in your phone and in your computer)
   3. ((I might continue in a sub-comment))

My frank opinion is that the solution to not advancing capabilities is keeping the results private, and especially not sharing them with frontier labs.

((

making sure I'm not missing our crux completely: Do you agree:

1. AI has a non negligable chance of being an existential problem
2. Labs advancing capabilities are the main thing causing that

))

I also think that a lot of work that is branded as safety (for example, that is developed in a team called the safety-team or alignment-team) could reasonably be considered to be advancing "capabilities" (as the topic is often divided).

My main point is that I recommend checking the specific project you'd work on, and not only what it's branded as, if you think advancing AI capabilities could be dangerous (which I do think).

Zvi on the 80k podcast:

Zvi Mowshowitz: This is a place I feel very, very strongly that the 80,000 Hours guidelines are very wrong. So my advice, if you want to improve the situation on the chance that we all die for existential risk concerns, is that you absolutely can go to a lab that you have evaluated as doing legitimate safety work, that will not effectively end up as capabilities work, in a role of doing that work. That is a very reasonable thing to be doing.

I think that “I am going to take a job at specifically OpenAI or DeepMind for the purposes of building career capital or having a positive influence on their safety outlook, while directly building the exact thing that we very much do not want to be built, or we want to be built as slowly as possible because it is the thing causing the existential risk” is very clearly the thing to not do. There are all of the things in the world you could be doing. There is a very, very narrow — hundreds of people, maybe low thousands of people — who are directly working to advance the frontiers of AI capabilities in the ways that are actively dangerous. Do not be one of those people. Those people are doing a bad thing. I do not like that they are doing this thing.

And it doesn’t mean they’re bad people. They have different models of the world, presumably, and they have a reason to think this is a good thing. But if you share anything like my model of the importance of existential risk and the dangers that AI poses as an existential risk, and how bad it would be if this was developed relatively quickly, I think this position is just indefensible and insane, and that it reflects a systematic error that we need to snap out of. If you need to get experience working with AI, there are indeed plenty of places where you can work with AI in ways that are not pushing this frontier forward.

The transcript is from the 80k website. The episode is also linked to in the post. It also continues to Rob replying that the 80k view is "it's complicated" and Zvi replying to that.

Something like "noticing we are surprised". Also I think it would be nice to have prediction markets for studies in general and EA seem like early adopters (?)

I don't know why this was so downvoted/Xed 

:/

Hey :)

Looking at some of the engineering projects (which is closest to my field) :

• API Development: Create a RESTful API using Flask or FastAPI to serve the summarization models.
• Caching: Implement a caching mechanism to store and quickly retrieve summaries for previously seen papers.
• Asynchronous Processing: Use message queues (e.g., Celery) for handling long-running summarization tasks.
• Containerization: Dockerize the application for easy deployment and scaling.
• Monitoring and Logging: Implement proper logging and monitoring to track system performance and errors.

I'm guessing Claude 3.5 Sonnet could do these things, probably using 1 prompt for each (or perhaps even all at once).

Consider trying, if you didn't yet. You might not need any humans for this. Or if you already did then oops and never mind!

Thanks for saving the world!

If you ever run another of these, I recommend opening a prediction market first for what your results are going to be :) 

cc @Nathan Young 

Any idea if these capabilities were made public or, for example, only used for private METR evals?