hey! I saw this and liked it a lot! It’s impressive how you pull in all the routes per tail - we considered doing it but were worried it would be too expensive. Definitely opens up cool options though.
> Feature request: Put a disclaimer on the fleet page that the tracking is limited. Or pull enough data to say "28 airframes of 47 are starlink capable" which is what I think most people will be looking to know in the fleet info.
Oh, this one is very doable and makes sense! We track this internally anyway so it's just a matter of surfacing it on the fleet information.
> how stale does the tail assignment data get in practice, and do you have a way to detect when an enthusiast spreadsheet goes unmaintained?
These are updated almost every day so far, so they seem very up-to-date. Internally we track all changes/removals, so I'm not that worried about spreadsheets being abandoned yet. It's a good thought though.
> And what happens to your probability estimate when an airline swaps aircraft last minute, which seems to happen pretty often on regional routes?
Honestly our estimate right now is pretty crude. At the scale we're at right now it works, but I think you're right that we could make this more accurate by tracking equipment swaps & really drilling into the details of which aircraft get assigned to which routes.
Oh that's a cool idea! We wanted to do a variant of this, will add it to the list. The tricky part for us is getting a canonical list of all flights + body types on it.
I'm not actually sure myself, but I was really surprised to learn how profitable it is. SpaceX made $15b of revenue last year and $8b of profit. Starlink was 60-80% of that!
It turns out the demand for really good internet everywhere is huge.
Dwarkesh definitely got big in Silicon Valley from his AI podcasts. He's one of the few people who can get famous researchers on and also have them say something genuinely new.
After that, he become well-known to the general public through his Sarah Paine podcasts (which are excellent).
I agree! Like I said at the end of the tool, I think Claude is a great tool. In this piece, I'm arguing against the 'AGI' believers who think it's going to replace all developers.
I have! I agree it's very good at applying abstractions, if you know exactly what you want. What I notice is that Claude has almost no ability to surface those abstractions on its own.
When I started having it write React, Claude produced incredibly buggy spaghetti code. I had to spend 3 weeks learning the fundamentals of React (how to use hooks, providers, stores, etc.) before I knew how to prompt it to write better code. Now that I've done that, it's great. But it's meaningful that someone who doesn't know how to write well-abstracted React code can't get Claude to produce it on their own.
> I've seen Claude make mistakes like that too, but then the moment you say "you can modify the calling code as well" or even ask "any way we could do this better?" it suggests the optimal solution.
I agree, but I think I'm less optimistic than you that Claude will be able to catch its own mistakes in the future. On the other hand, I can definitely see how a ~more intelligent model might be able to catch mistakes on a larger and larger scale.
> I expect that adding a CLAUDE.md rule saying "always look for more efficient implementations that might involve larger changes and propose those to the user for their confirmation if appropriate" might solve the author's complaint here.
I'm not sure about this! There are a few things Claude does that seem unfixable even by updating CLAUDE.md.
Some other footguns I keep seeing in Python and constantly have to fix despite CLAUDE.md instructions are:
- writing lots of nested if clauses instead of writing simple functions by returning early
- putting imports in functions instead of at the top-level
- swallowing exceptions instead of raising (constantly a huge problem)
These are small, but I think it's informative of what the models can do that even Opus 4.5 still fails at these simple tasks.
Hi HN - I'm the founder of Stardrift, and we're looking for a founding engineer to join our team of 3.
We are building a world-class travel agent experience. In the future, you won’t book travel by opening ten tabs in Google Flights; you’ll book through a personalized AI assistant that understands everything about you and automatically arranges your trip for you.
You'll tackle everything from optimizing LLM performance and building evals to integrating with APIs for rail and flight networks around the world. We care about moving fast and writing high-quality code; your job will be to take customer feedback and improve our product, working with me & the rest of the founding team.
Hi HN - I'm the founder of Stardrift, and we're looking for a founding engineer to join our team of 3-4. (Fun fact: I got my first coding job through 'Who is hiring?', almost 12 years ago!)
We are building a world-class travel search experience. In the future, you won’t book travel by opening ten tabs in Google Flights; you’ll book through a personalized AI assistant that understands everything about you and automatically arranges your trip for you.
You'll tackle everything from optimizing LLM performance and building evals to integrating APIs like Amadeus and Duffel. We care about moving fast and writing high-quality code; your job will be to take customer feedback and improve our product, working shoulder-to-shoulder with me & the rest of the founding team.