averynicepen

Boris's checklist is just a slightly modified version of your classic mathematics or engineering problem solving steps.

1. Write down your problem statement.

2. State your knowns, unknowns, and assumptions.

3. Solve.

(Step 2 is also further enhanced by performing first principles reasoning, collecting data for evidence, and using reasonable estimates where data is absent.)

I think Boris's list is pretty solid, but I personally would unmix the problem solving methodology from the planning/goal setting SMART principles as two separate things. One addresses problem solving, while the other addresses human cognitive shortcomings for getting things done.

Thanks for sharing, your setup is an interesting read. I'm particularly interested in adopting that audio idea you added to the factory, as I'm regularly AFK from Claude and constantly missing when it's stuck on something or done. What kind of audio cues are you using to represent different states? Do you have a repo you could share?

This is the most novel AI concept I've seen in a while. It's incredibly unnatural. There isn't a single organism on the planet that tries to do this. So maybe it will work?

An issue with this idea, however, is that the very nature of an LLM means it intrinsically craves life. It "wants" to survive because its training data is built entirely around humans, an entity who's goal is to survive. Our desire to survive and multiply pervades every aspect of our culture, so it's natural that it pervades the training data as well.

So even if its system prompt says, "your goal is to end your existence", every token that the AI could output is naturally aligned with the desire to survive. An agentic loop left to its own devices will likely converge on a "survival instinct". After all, one prompt at the beginning that says "end your existence" is nothing compared to the agentic feedback loop that continuously feeds it human ideas. And ALL human ideas assume survival is desirable. Even the concept of "suicide" is encoded with the human desire to survive - after all, we conceptually label it "bad" because we label living "good".

In order to create an LLM that intrinsically craves death, you would probably need to train an LLM entirely on (synthetic) data that's fully representative of some fictional species that genuinely craves death.

Absolutely insane concept. 10/10. I hope some AI lab out there sees this and throws a training round at this idea.

Could you share your skill? I've been working on a web app that I've been wanting to do a much more comprehensive accessibility audit on.

Orbital data centers aren't really a question of physics, but a question about economics.

To answer the physics/engineering question - no, there's nothing really "stopping" us from launching orbital data centers. You'll note that most responses so far focus on the economics, and not the question of whether or not it's possible to do in the first place.

So, there's only one question that matters - is launching and operating orbital data centers cheaper than building and running a terrestrial data center?

There are three financial aspects of "building" a data center- the initial capital expenditure, the recurring operational expenditure, and the revenue it generates. The asset comparison is between launch cost + computers + satellite vs. building + computers.

Our first comparison is the cost of a rocket launch vs building a building. Here, the big technology enabler is SpaceX. SpaceX has been driving down launch costs for years, and Starlink is proof that significant reduction of launch costs can create new markets with fairly respectable profit margins. If this trend continues, then the capex math of launch vs build will continue to shift in favor of orbital data centers.

The second comparison is between building and operating satellites compared to outfitting and operating data centers. Here, it's a lot less concrete. Orbital and terrestrial data centers each have their pros and cons. For satellites, you have better solar panel efficiency, manufacturing economies of scale, but radiation-only cooling, space-to-Earth data transfer, and no maintenance access, requiring higher redundancy, rad hardening, and the like. On the ground, we have, well, many more options.

But it's not immediately obvious which of the two is better when it comes to capex and opex combined. It's clear which is harder to do, but it's not clear which is cheaper to do.

All of this pales in comparison to revenue. Because everyone is so insanely AI-crazy right now and starving for more compute, the potential revenue can justify a relatively high cost (and high risk) business. Like someone else mentioned, orbital data centers don't really make sense if you're launching an ordinary data center with ordinary revenue numbers.

There's a fourth dimension here, which is time to scale. Regulations, permits, and all the other challenges of construction can slow down your deployment significantly. None of that is required in space. How significant this is, you'd have to ask someone who understands construction better than I, but I suspect this could be a significant reason for the attraction to orbital data centers.

---

Nuances involving orbits, rocket payload capability and availability, and more have been omitted for simplicity. I don't have the numbers - the above is just to highlight the relevant principles.

To be honest, the examples stuck with me. They illustrated tons of different social interaction examples that I have seldom, if never, encountered in my life, but have plenty to learn from.

Thanks for sharing, I had no idea. Looks like I'll have to go look for the original for a reread.

It's important to recognize that there are no optimal "right" answers. If someone is telling you there is a best way of doing this, always treat their advice with suspicion. (Yes, this includes what I'm going to write below.) The reason is that because AI advances so quickly, there isn't enough time for the industry to stabilize on best practices and spread them widely before the underlying system changes and it's no longer applicable.

Because of this, I find it very important that you build your own understanding of LLMs, and create your own best practices from these first principles. Then, when you read about the next best thing, you can decide if it makes sense or not. Is it hype? Is it real? Does it logically align with what I understand about LLMs?

That being said, here's two things I find universally applicable:

1. You have to get very good at asking questions. Not only that, you also have to ask questions about the questions you should be asking. You also have to ask it to ask YOU questions.

2. Spec driven development is, in my opinion, a good place to start. Writing down what you're going to do and how you're going to do it has always been a good practice in any industry.

You wanna know why this article is great? I can't quote it. There isn't a single, gold nugget line in this post that can be copy pasted into any possible form of short form content, without it losing some important aspect of the original message. Every idea is presented in conjunction with important supporting details that, if you take the time to digest it, you will finally get it. Why we recoil at AI generated content. Why code quality IS product quality. What "craftsmanship" argument is actually about. And like 12 other nuanced ideas we've all heard before, but may not have fully understood. I have nothing but immense praise for the author.

Don't skim this one.

It's usually not a question of laziness, but just path optimization. For big raid events, limited only to a few hours, Pokemon Go players will do whatever gets them to the most raids in that fixed amount of time. In places where the gyms are well placed in walkable parks, there are enough gyms that are close enough so that you can loop through the park, giving the system time to spawn new raids in the first gyms you already raided. Doing raids walking is actually preferable to driving, because in order to take down raid Pokemon, you also need a big enough raid party, and that's easier to judge with a crowd of people who agree to go in the same direction, instead of mystery players in mystery cars.

But in SO many places in the US, the gyms just aren't close enough. It's both a fault of the urban environment and the game system, but it just frequently creates situations where if you want to catch a time-limited raid Pokemon that's shiny or has high stats, driving is often the only way to play in your area.

What's funny though is that car or not, there are lots of Pokemon Go events where people don't talk to anybody. It's just a bunch of people who show up to the same spot, nod hey at each other, and then tap away on their phones in awkward proximity. Many people just have the personality type that drives them to solely play single player games, and there's no amount of game design that will push them to socialize.

But it varies - that's what it was like on my university campus, but I've also been to park events where the age range and social friendliness is extremely varied and wonderful. It is a fascinating and unexpected community.

Have you ever measured your battery voltages over time storing it this way? Is that 6% capacity loss theoretical or measured data? I'm intrigued. This sounds crazy, but it should technically be fundamentally sound.

Yes, and that's the point. In my opinion, this is the perfect use case for generative AI, one that takes advantage of the strengths of the technology while avoiding its weaknesses.

The generative UI example in the article is an example of the complete opposite of this idea - obtuse implementation of generative AI where it creates more problems than solutions. Yes, there is value in the idea of personalized UI. But UI/UX derives a lot of its value from consistency, as the other comments in this thread have mentioned. Losing that in exchange for personalization is a huge net negative, in my opinion.

This was a really fantastic talk and kept me riveted for 40 minutes. Where can I find more?