The hyperbolic time chamber, also known as the “room of spirit and time”, is a dimension in the Dragon Ball Universe where time is compressed such that a full year can be spent in the room while just a day passes in the external world. The Dragon Ball characters occasionally use it for intensive training to level up before a big boss fight.
Last year I goofed around with the idea of hyperbolic time chamber projects, those for which loads of free time weren’t enough to get started, but basically required that time stood still1 and all my worries and obligations just vanished away; projects that I’d like to work on, in theory, but in practice would take a full disruption of time and space for me to gather the will to carry them out.
I’ve been thinking again about this concept, in relation to AI. I started using newer models at work, and I must admit that they are indeed getting less dumb at autonomous task execution; I have no reason to doubt the serious engineers who report successes in throwing increasingly ambitious projects at LLM agents. If the trend continues, it’s fair to say that these tools will enable a kind of time compression: we’ll still need to put in the design and spec effort, but tasks that would otherwise take weeks or months could be carried out in mere hours of background work. Could Claude be my hyperbolic time chamber?
So I went back and re-read my post from last year and saw the project examples I listed: a Game Boy emulator, a search engine, a little OS. All standard programs an agent should be able to tackle, with plenty of context and reference implementations already baked into its training data. But then, why would I bother? All of those projects were about training and knowledge acquisition, they were about leveling up. These projects, which were almost all execution, would be killed by delegation. No one needs a new Game Boy emulator (at least not the one I could provide): all the joy was in the ride.
∗ ∗ ∗
A recent piece, Grief and the AI Split, made me ask myself what exactly it is that I like about building software. In the divide presented by the author, I’m more on the make-it-go than the craft-lover side, but I’m still torn: I don’t care for code in the abstract, unattached from whatever thing I’m building, but experience taught me that simplicity—which is not totally different from elegance and beauty—is the best way to make things happen. I’m one to take ugly shortcuts to get something to show up on screen yet the same person who spends inordinate amounts of time adding comments, renaming variables, and shuffling functions around for readability.
So I think there’s less of a split and more of a set of different hats one gets to wear, each providing its own form of creative pleasure. There’s joy in hand crafting things no one needs, even if left unfinished; joy in designing an artifact and seeing it materialized, even if its implementation is largely delegated; and also joy in using good software, programs that feel right, that do precisely the thing we want them to do—perhaps because we built them ourselves.
There are other projects I frequently think about, besides my hyperbolic time chamber ones. Projects where I want the thing done, as a user, regardless of the process. I want a book trading webapp, a TUI music album player, a golang port of my RSS reader, a small-web alternative to goodreads. These are not time chamber projects, not akin to Goku’s intensive training to level up, but more like those lazy-ass skill uploads Neo gets in The Matrix. All done, no effort. I will call these my ‘I know kung-fu’ projects.