I think for big groups it’s not so much luck/randomness that is the key but complexity. Low complexity games are going to play better. They can be pure skill games. Many drinking games are (beer pong etc).
Luck/randomness is directly against determinism. A way of making feel less mechanical and opening up the combinatorial state space? Essentially increasing the fun/interest without introducing high complexity necessarily? As well as narrow the skill range as you say, but not necessarily over longer time horizons.
Like you can do a 2d matrix of luck and complexity.
I think this is a systemic problem of an industry where gross margin is 80% or higher, so you can plow all that extra money into superfluous headcount tasked with objectives of questionable business value. It’s a curse of riches, if you will. The rest of us living on 15 to 30% margins need to think a little harder about what we do and why.
It's worse when you consider these are the only companies that can afford it due to the tax implications of R&D, my understanding was that you still pay the full bill on a developer building something as if you were making profits, even though you're burning their entire salary and other resources on it.
FWIW, what you will see at times in the HF world is a firm will want to get into a strategy and build competing teams. It lights a fire under both. It diversifies the risk. You can select winner and move some people over from loser. And if they both work, they both work.
It isn't a crazy idea if the opportunity is large enough to make the larger investment required worth it.
The problem I see in applying this to products is it can be very confusing for clients.
The way I understood the 80% is that is the margin on the actual product. 36% is what remains after the “investments” in moonshot projects nobody asked for.
Wasn't it always somewhere between 20 to 30% (especially more recently in the 30s) but the real difference is, they're in the billions of dollars, your small business might be in the millions, it's quite a drastic difference altogether.
I found judicial use of rtk on specific commands that you know can be improved with rtk, e.g. go test, pnpm test (vitest), etc. to be worthwhile, at least in CC. But using their default setup which is to prepend rtk to everything is more trouble than its worth. I have a custom-built hook that prepends rtk based on a hierarchical whitelist.
And you should disable the savings reporting feature since it’s worse than useless—it breaks sandboxing and always reports ~100% savings for me because rtk obviously doesn’t know about the head/tail the agent pipes into.
I can't find the relevant issues in their repo, but I've been somewhat skeptical of their tool over-reporting token savings and there are many issues to that effect in the repo.
I'm not likely to install it again in my latest configuration, instead applying some specific tricks to things like `make test` to spit out zero output exit on unsuccessful error codes, that sort of thing. Anecdotally, I see GPT-5.5 often automatically applying context limiting flags to the bash it writes :shrug:
I've had the same experience with RTK, where my agent got stuck in a loop with a faulty RTK command and could not escape it since RTK hard overwrites anything automatically. I've uninstalled it again for the time being.
> it is important to make the distinction between inlining the implementation of some behaviour and inlining the invocation (or declaration) of some behaviour
tailwind’s biggest problem is that it doesn’t make this distinction well.
In a sense this is a strength because it probably matches the amount of effort most devs/orgs who don’t focus here are willing to put in to the problem; this worse-is-better solution is functional enough especially in settings where component separation has already been adopted. Along with some decent baseline design tokens, it’s enough for people who don’t want to care more, especially if they don’t ever particularly see the consequences of hyperlocalizing implementation.
If your project has someone whose job it is to think through design systems and how they’re expressed via CSS, you can do better. If you don’t, you can do worse.
And personally, I’ve seen a LOT of discussion about separating SQL and app code. There’s a similar tension. Wrapping queries in function calls often means fewer duplicated queries (often painfully verbose) and opportunities for dumb security mistakes, but reduces the expressive variation the raw query language provides, and many systems and devs behind them end up pursuing balance between the two… or outsourcing the decision to an ORM or other data access layer whose tradeoffs also probably have shortcomings but at least they get to worse-is-better stop thinking about it except at particular pain points.
There’s absolutely no tension between locality of behavior and separation of concerns in CSS: you’re putting styles on the elements in the document. The styles are defined elsewhere.
It’s like arguing that all of your source code should go in one big file because one file is less than two files, which means greater localization.
Its arguing that that source code that affects the behaviour of something should be easily discoverable from the point/points its behaviour affects. or alternatively more indirection/obfuscation is worse.
Its not so much about same file, as reducing distance to understanding, whether visually or by some sort of easily traceable path.
Like you would want to init a variable closer to its usage, Or that having a 100 wrapper functions is less understandable than inlining for a single statement, or global mutations are harder to trace then local, and that sometimes its easier to inline a single sql statement then split it out into a different file just because its 2 different languages.
Also, to be clear its possible to write CSS that exhibits less or more LoB. The file thing is more that I don't think HTML, CSS, JS "must" be written as separate files which is what the prevailing best practice used to be, justified as SoC. I just think splitting along the scope/behaviour lines rather than file type is more understandable.
> the behaviour of something should be easily discoverable from the point/points its behaviour affects. or alternatively more indirection/obfuscation is worse.
This is why I'm not that big of a fan of Tailwind and similar frameworks. To me it feels like they introduce yet another language into the mix. It adds all sorts of classes directly to the html, but now I need to understand what all of those mean. If I write my own CSS, I generally just have to look in one place to understand the styling of an element.
I think I feel kind of like that about overuse of annotations in Java. (Simple/obvious ones are fine, but not all are simple and obvious.)
Sorry maybe that wasn’t the best example. It’s not really about separation of files. But how they connect.
In sql your code may be in a seperate file but your app code is still clearly calling the sql. The inlining vs not inlining is just abstraction. You could use a function, or a separate file or not, a different language or not.
But there is a clear single call chain at the points where that behaviour is being applied and a single definition.
With css that’s not necessarily true. There’s a bunch of different rules that may or may not apply.
> With css that’s not necessarily true. There’s a bunch of different rules that may or may not apply.
There's only one algorithm, the cascade. And it's described here[0].
And just like any code you write, try not to write complex selectors. If you're not sure two styles are equal, it's better to write two different rules. And just like styling works in any system, you go from generic (standard html elements) to very specific ones (the link in the hero section of the about page)
that’s exactly the part that is anti locality of behaviour.
I don’t want/need cascade. I only care about components and building up from them. And I would rather have it be explicit over implicit and scoped/encapsulated.
Call it composition over cascade.
To be clear I think it’s possible to do this without tailwind. And tailwind has other out of the box features/opinions.
But it works well enough without too much friction.
> that’s exactly the part that is anti locality of behaviour.
It is not. Because it fits the concept of "web pages" as documents and forms (which most web apps are, even if they're trying to pass as desktop applications.
> I don’t want/need cascade. I only care about components and building up from them. And I would rather have it be explicit over implicit and scoped/encapsulated.
And you're very welcome to do what you want. But there's no need to bash cascading as it's a good solution for web pages.
End users and even other programs/extensions can load rules to alter your styles. I think thats about as opposite of locality of behaviour as it gets. (no judgment on customization on being good/bad).
With the rest I don't really strongly disagree. I think its just a question of complexity. For simple things its fine, but for complex apps with teams of people :shrug:
I’ve been thinking about how to get creativity out of llms, apart from temperature. The thing is even humans have a hard time with creativity.
Is it really surprising that llms don’t just one shot a unique story when they are all starting from roughly similar training data and state and a roughly 30 secs of processing time.
I had Gemini do some deep research for me around processes and frameworks to prompt ideation and creativity and they do exist. See SCAMPER and others.
Another interesting thing that comes up is using random decks of cards as prompts.
See Oblique Strategies, Deck of Lenses, the Story engine and similar.
I guess I still believe that even creativity is still fundamentally a type of search, as well as problem solving. Manipulating and or combining existing ideas in unexplored ways and breaking out of bias.
So I kinda want to experiment with these two approaches:
1. Longer running workflows that follow a framework and loop.
2. Some simple cli tools with these decks and a random draw to trigger interesting directions.
I think really just need to break llms out of their initial start state which is mostly the same for everyone.
And to run over longer horizons and so the higher level reasoning flows.
Just a thought, what if you added in a random steering vector at the start of the residual stream for each token? Intuition says it wouldn't act in the same way as increasing temperature would, but I honestly have no idea what would happen. Maybe it would be better if the random steering vector flowed a little from token to token so the output wouldn't be so noisy.
This would be done with Gaussian noise and you could change the standard deviation to make the LLM more "creative".
This would be similar to throwing in and quickly removing random reddit posts and artworks in the LLMs context window, and who knows maybe it could get inspired by that.
Tbh I have no idea, I’m mostly thinking about it from what I can do when using the frontier models, so I don’t think such low level changes are available to me.
I feel like it’s probably just complexity.
Different workloads benefit from specific types of optimisations.
reply