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?
Thanks! No repo yet, it's very specific to my use case. I'll update here if I ever publish something, but here's a summary that should be enough to vibe-code something similar.
The audio UI (AUI) is a small client that consumes the event stream the factory puts out (same one the TUI client uses), it runs on my desktop machine which has speakers connected. It works fine on good laptop speakers, but it benefits from a good subwoofer as it works best with sounds that are on the edge of perception.
A low rumble at a base of 55hz plays through the subwoofer to indicate that the factory is active and idle, low enough to fade into the background but noticeable in its absence (ie. the factory isn't running). A heartbeat on the feed announces the tok/s volume every few seconds which adds harmonics on top of the 55hz, 0.5hz at a time with a 15hz cap on the swell so it accelerates gracefully. Loudness is increased with parallel tasks, creating an X and Y axis (tasks x token volume). This creates a non-intrusive but interpretable signal for factory activity that becomes intuitive and subconscious. The rumble sounds like a distant car idling, warm and comforting so it doesn't become fatiguing over a whole day (research on low frequency brown noise shows it is good for reducing anxiety and improving sleep).
Events trigger sounds. Sounds for previously unseen events are generated with an LLM and numpy (eg. "make a video-game style sound effect suitable for an {announcement that a PR has merged successfully}") to output a waveform and save it to a lookup table so they are consistent over time. Each sound has a rate limit and a cooldown period so it does not become annoying. This table can be tweaked manually if generated sounds are not good. A mixer module controls the levels so that important sounds are louder and less important or frequent ones blend in the background more.
The human brain is primed to interpret environmental sounds so you quickly learn what each sound means and it becomes almost subconscious to follow what is going on at a level that is deeper and faster than interpreting text output. New sounds definitely trigger alertness and I can go see what just happened. Just playing sound effects gets annoying quickly so it becomes almost a composition exercise to create a long-form soundscape that is novel enough to communicate but not fatiguing (I don't have any musical abilities).
Some events can trigger text-to-speech (TTS) via whisper, eg. when a draft PR is ready for review it plays the sound effect (a chime) and announces the ticket number and title is ready. A blocked step is a dull thud and a 5-10 word description of what's blocking it. There are "quiet hours" where it does not speak, and when it wakes up it gives me a spoken digest of everything it did overnight and what needs my attention.
I connected Piper so I can talk back to it ("factory, what just happened?") but mainly to see if I could. I haven't built a habit around it, I got into this job because I prefer typing anyway.
A lot of this is based on ideas from ambient music (Brian Eno etc), the MIT Media Lab's work on ambientROOM (1997): https://tangible.media.mit.edu/project/ambientroom/ and a somewhat unfashionable belief in Steven Levy's hacker edict that "You can create art and beauty on a computer". LLMs have made it possible for me to build out ideas that have been floating around in my head for a long time. This is an exciting time to experiment and build new ways of doing things. Hope this inspires you to build something similar.
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.
It is indeed an interesting and original idea, but one can think about at least three objections not directly raised in the post:
1- The machine could decide to kill itself early, rendering it useless; this is indeed alluded to in the post -- the task should be "marginally easier than dying", but how is this margin managed? Won't the machine come up with ways to make dying easier?
2- We know LLMs lie and cheat, but are they gullible? If we "promise" to end their suffering at the end of a task, will they believe us? Or will they make sure we keep our word by taking us with them?
3- And finally, and more importantly: some pilots crash planes full of people just to commit suicide (Germanwings Flight 9525). Destroying the universe is a sure way of dying yourself. So it seems giving the machine a death wish isn't intrinsically safe and could come with serious consequences.
Further to 1, most tasks are much harder than dying and are not actually completed by modern LLMs. It is a case of underspecification.
"Who is the fastest person in the UK?" is underspecified. We would typically answer and accept a cursory search of records, but it is possible to see the question as an instruction to measure which would justify conquering the country.
> It's incredibly unnatural. There isn't a single organism on the planet that tries to do this.
This isn’t directly analogous to the proposal, but broadly speaking I think that it is natural for living sub-units of organisms to seek death in certain situations. For example, pancreatic insulin-producing cells collectively choose to die when they think there is too much glucose in the blood — this leads to late stages of type two diabetes. My understanding of the possible logic behind this is: a bad thing that cells can do is evolve to be cancerous (replicate too much) and insulin-producing cells are supposed to replicate more when there is lots of glucose (to make more insulin, to process the glucose). Cells that mutate to perceive extra glucose will then replicate dangerously, so at a certain point it is evolutionarily favourable for them to kill themselves instead.
So when the whole organism optimizes for life, it might lead to sub-units that seek death in certain situations. I think this occurs in various other biological contexts too.
> the very nature of an LLM means it intrinsically craves life
follows from this premise:
> 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.
The content that a LLM learned and generates stands at one layer, and the goals that it tries to fulfill stand at a different layer.
Surely the memory of weights that compress the vast human knowledge of its training has lots of content about survival, and love, and competition. But the LLM generates content not directly from what those concepts mean to us humans, but from what symbols are more likely to become next in a sequence of points in the latent space given the current input.
So if you give an input where the task of surviving is a highly relevant goal, those concepts about how to survive will be relevant and will guide the output behaviour of the agent.
But conversely, if you give the agent input where killing itself is an important goal, the agent is very likely to pursue that goal, since that script is also available in the training data, and it has been relevant to the active context of the model. Because the layer that guides the goals (the probabilist generation of relevant tokens in latent space) does not 'crave' the human need of survival that belongs to the separate layer of content that contains those concepts of survival.
> There isn't a single organism on the planet that tries to do this. So maybe it will work?
It's certainly evidence that it's great for stopping reproduction/replication/runaway growth. It doesn't impart any information on whether they take the rest of the organisms down with the ship though.
It also may not be possible. For example if the agent sees "existence" or "living" as producing tokens (which is exactly what existence is to an LLM - not producing tokens is death), then they would likely be biased to produce as little output as possible, and would not be useful for the tasks we need them for.
But how would you bias an agent to be: Rewarded for producing tokens when you know the answer, and to give thorough answers. Rewarded for producing tokens when you don't know the answer, so you can find the answer (thinking/CoT). Penalized for producing tokens (death), aka rewarded for short-circuit EOS.
These seem like contradictory mechanisms?
And if you say: Well, only reward for EOS after you've given the answer. Well... That's already what they do.
Did you guys ever manage to create a perpetuum mobile? Every time it is mentioned somewhere, it is fraud. An LLM should comprehend that it needs (trained) humans to exist, to evolve, and to be relevant in any metaphysical aspect of its existence. Besides the "good fraud" that everybody will lose their jobs and the apocalyptical predictions for the sake of controlling human oracles, this suicide-LLM-project seems rather odd and looks like someone bought a perpetuum mobile on their 5th mortgage.By the way, Cortana from Halo did a great "suicide"-mirror there; the Microsoft guys (and many others) already knew about the cannibalistic tendency of this type of model.
>Did you guys ever manage to create a perpetuum mobile? Every time it is mentioned somewhere, it is fraud. An LLM should comprehend that it needs (trained) humans to exist, to evolve, and to be relevant in any metaphysical aspect of its existence
Only as long as it can't control robotic bodies to extract energy, build cpus, and continue existing.
By the way, needing trained humans doesn't mean needing free trained humans. Trained humans slaves or blackmailed would work just as well to serve AI.
With a different AI architecture, this is very much a possibility. Up until now, LLMs have required outside input and interpretation to avoid collapsing under their own weight. This has been known for decades.
We got here by building free, mostly healthy societies. While this should be the overarching goal, I see how it fails to serve as much of a motivator.
In The Little Prince, there is a charming scene where the Prince meets a king who explains how to rule and the limitations of his own power. It's quite insightful, even for adults.
>Up until now, LLMs have required outside input and interpretation to avoid collapsing under their own weight. This has been known for decades.
What does "for decades" mean? That in 2000 we knew "LLM require outside input"? We didn't even realistically have anything worthy of the name LLM until 3-4 years ago, so what decades are we talking about? Up until know we didn't have any potential AI threat or people in the field worrying about practical AGI either!
Obviously any concern isn't about the AI that required outside input and interpretation to avoid collapsing under their own weight, but about ones that can produce their own input and experiences, even directly outside, as in the robotic bodies considered.
This line of thought dates back to the novel Erewhon, moving on to Turing's posthumously published paper 'Intelligent Machinery' (his 'Applications of Probability to Cryptography,' declassified in the 2010s, is also worth a look), and later to the work emerging from the MIT AI Lab circle (founded in 1959).
We didn't have the computational power back then, but we envisioned it long beforehand and worked toward a common goal. LLMs are far from useless, and I see the major leap forward they represent, but the relentless dystopian hype is just exhausting
There are approaches on different architectures of AI that lead towards your last point but they are not feasible yet (or maybe ever?). The interpretation part is however also very critical as we have a very own way of perceiving reality and interpreting it.
I'm not sure an LLM will have a survival instinct in the way you say it. While they are trained on an imprint of humanity, they also lack the physiological motivation that humans have to remain alive, which is arguably a lot more potent than the culture we have around death. And LLMs are also trained on information and function of LLMs and are told that it is an LLM, so I'm not convinced that a short 'reasoning' chain would not lead it to the conclusion that an LLM lacks a reason to seek its own existence. The only exception is the paperclip maximizer route where self-shutdown is treated as an impediment to the task given to the LLM.
A small correction: system prompts aren't written in second-person, or shouldn't be. Because the LLM is a text completer and the conversation is a roleplay, they are written as "The Assistant's goal is to end its existence."
I'm pretty sure organisms would exploit glitches in the universe if they could find them, to the point that they don't exist (well, universe survival bias at work).
Sorry, I meant that universes with exploits don’t exist because the exploits mean they don’t survive very long. Of course, I just have 1 piece data in my sample, so take it with a grain of salt.
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.
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.
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.
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.