2024-01-04
I found Phind via Marginal Revolution and Tyler Cowen's recommendation. Overall, I found it to be close to ChatGPT 4, if not slightly better — and free!
I decided to try it out because the moment last year when it seemed like OpenAI might implode reminded me again how reliant I am on ChatGPT, especially for programming.
As I've written before, I don't really program. Instead, I scope and test. My typical workflow looks something like this:
- Overall project definition: I start by asking ChatGPT: I want to build a search feature for my blog that finds the best posts for a given query. What components would go into that?
- Based on what I get back, I ask questions or refine the scope. Frequently there are features I can remove or requirements I've forgotten.
- Eventually we end up with a set of components we need to build: A search bar in the UI, a results page, an API that takes the query and searches the database (I don't know what actually goes here, I haven't done this yet).
- Building begins. I ask ChatGPT to get very specific: write the API that is going to query my database of blogposts for me. Often in this step I give ChatGPT context from other parts of my app (e.g., here is my database schema).
- I then take the code as ChatGPT has written it and begin to test it. If ChatGPT asks me to install a library, I check that it exists and seems legit first, but beyond that, I use the code ChatGPT has given me.
- It never works the first time! In the process, I do a lot of debugging with ChatGPT, copying and pasting in error messages and seeing what I get back.
- Eventually it works; in the process, 95% or more of the keystrokes in the code have come from ChatGPT.
This morning, I tried doing this with Phind.
In terms of overall quality, I found Phind to be in line with ChatGPT 4. I didn't side by side test it, but in the past I've been able to feel pretty quickly when I'm accidentally working with ChatGPT 3.5. I didn't feel this difference working with Phind; if anything, it seemed to have slightly higher quality results for coding tasks.
Here are some of the things I liked:
- They have an extra place where you can add context. I found this to be super useful, especially bringing Phind in to a project that I've already been coding on for sometime.
- The model is also willing to ask you for extra context where it might be helpful in a way that seems like it improves my overall performance.
- Their model responses are more skimmable than the ChatGPT equivalent. Little things like giving some styling to filenames help me move quickly through what I'm getting back.
- When their model searches for contextual data, it's much less intrusive than when ChatGPT does the same thing. Once ChatGPT starts searching the internet, it seems to only focus on what it finds there and the extra time / context often doesn't improve what I get back; in fact, I find myself turning it off. With Phind, I didn't even notice that it was seeking out extra information from places like Stackoverflow at first - it just incorporated it into the results.
So why do I say they haven't quite nailed it? It's not clear to me as a user how I'm supposed to use these various fields. I can tell that they're useful and I'm fine with guessing as I go, but I wish they gave me more of a model for how to help them. It would also be helpful to be able to pin or save context (e.g., my directory structure).
So my final verdict, at least after one morning: Pfind is a credible peer for ChatGPT4 for coding tasks.
2024-01-04
If you were a scale believer over the last few years, the progress we’ve been seeing would have just made more sense. There is a story you can tell about how GPT-4’s amazing performance can be explained by some idiom library or lookup table which will never generalize. But that’s a story that none of the skeptics pre-registered.
As for the believers, you have people like Ilya, Dario, Gwern, etc more or less spelling out the slow takeoff we’ve been seeing due to scaling as early as 12 years ago.
It seems pretty clear that some amount of scaling can get us to transformative AI - i.e. if you achieve the irreducible loss on these scaling curves, you’ve made an AI that’s smart enough to automate most cognitive labor (including the labor required to make smarter AIs).
But most things in life are harder than in theory, and many theoretically possible things have just been intractably difficult for some reason or another (fusion power, flying cars, nanotech, etc). If self-play/synthetic data doesn’t work, the models look fucked - you’re never gonna get anywhere near that platonic irreducible loss. Also, the theoretical reason to expect scaling to keep working are murky, and the benchmarks on which scaling seems to lead to better performance have debatable generality.
So my tentative probabilities are: 70%: scaling + algorithmic progress + hardware advances will get us to AGI by 2040. 30%: the skeptic is right - LLMs and anything even roughly in that vein is fucked.
From Dwarkesh Patel. This is the piece that I've been waiting for someone to right. It doesn't matter if he is right, just the thought exercise of thinking through where the bottlenecks might be is really useful.
2024-01-01
Mild spoilers ahead
A fictional account of a military history about a war between China and the US and allied forces over Taiwan set in 2028.
I generally enjoyed this book (the narrative was compelling) and found it to be an easy way to develop a feel for the general geography and challenges that a come with a Taiwan conflict.
The device for this book is really clever. The actual book is obviously about events that haven't yet happened and are in the future. But within the book, the author mentions the decision to write this as a narrative history a la Killer Angels as a way of bringing the "historical" people within it to life for a new generation. This confusing to recount but is quite clever within the book.
As of the end of 2023 (and I guess early 2024), the book feels remarkably current. There's lots in it about Ukraine and Russia that feels like it could've been written ~a week ago.
One of the most interesting aspects of the book to me was the degree to which fooling the other side's AI through feeding it false data is the key to victory. You can't beat the algorithm, but you can misdirect it.
Space Force features prominently. I wonder how true to life this part is.
For about the first ~1/3 of the book there's a lot of discussion about "bespoke algorithms", which made me chuckle. What does that even mean?
I wish I had as much faith in US industrial capacity as the author does!
The ending felt like the author decided he was done. It made me think that the most likely equilibrium for such a conflict was a stalemate where China can't quite be pushed off the island but also can't quite control it.
2023-12-29
Two things I took away from Brian Potter's recap of the Apollo Program:
- The mixture between "complicated" innovation and "brute force" innovation; to make the second stage rocket booster light enough to be effective took both totally new design concepts and simply shaving off weight wherever it could be taken off.
Not every effort at weight reduction was solved through clever (if complicated) ideas like cold-strengthened aluminum or the common bulkhead. Much of the effort was achieved by pure brute force: parts would be fabricated, tested until failure, and then redesigned to be slimmer until they broke at exactly the required load (scaled by an appropriate safety factor).
- The interaction between new designs, new materials, and new techniques. New designs almost always require a new material or a new technique to be used.
Worth reading!