> I do love getting into the details of code, but I don't mind having an LLM handle boilerplate.
My usual thought is that boilerplate tells me, by existing, where the system is most flawed.
I do like the idea of having a tool that quickly patches the problem while also forcing me to think about its presence.
> There isn't a binary between having an LLM generate all the code and writing it all myself. I still do most of the design work because LLMs often make questionable design decisions.
One workflow that makes sense to me is to have the LLM commit on a branch; fix simple issues instead of trying to make it work (with all the worry of context poisoning); refactor on the same branch; merge; and then repeat for the next feature — starting more or less from scratch except for the agent config (CLAUDE.md etc.). Does that sound about right? Maybe you do something less formal?
> Sometimes I simply want a program to solve a purpose (outcome-focused) over a project to work on (craft-focused). Sometimes I need a small program in order to focus on the larger project, and being able to delegate that work has made it more enjoyable.
> deep / fast / craft-and-decomposition-loving vs black box / outcome-only
As a (self-reported) craft-and-decomposition lover, I wouldn't call the process "fast".
Certainly it's much faster than if I were trying to take the same approach without the same skills; and certainly I could slow it down with over-engineering. (And "deep" absolutely fits.) But the people I've known that I'd characterize as strongly "outcome-only", were certainly capable of sustaining some pretty high delta-LoC per day.
> Singapore does the whole "race based quotas for everything"
By American constructions of race, almost everyone in Singapore is of the same race.
Even going by genetically objective ethnicity, almost three quarters of people in Singapore are Han Chinese. It's not remotely comparable to the American situation.
> and they have by many metrics, the best standard of living in the entire world.
As self-reported by people from cultures that happen to share common values. They rate higher on HDI than the US, sure; but so does the UAE, and Slovenia is almost as high. They're unusually wealthy per capita, but so is Ireland (capitalist shell games). And there are a lot of things the average American probably wouldn't like about that society, e.g. the strict rules against littering and the threat of https://en.wikipedia.org/wiki/Caning_in_Singapore .
> It depends, there were a lot of studies that showed prejudice and bias in the meritocratic process.
A meritocratic process by definition is not prejudiced or biased. There were studies that claimed to show processes to not actually be meritocratic. In my experience, these findings either haven't reproduced or don't appropriately account for confounders; and if they held up they would be pointing at things that are already illegal (and irrational).
> It's similar to when black athletes weren't allowed in sports. We thought we had a meritocratic process
What? How do you come to the conclusion that "we" thought any such thing? The term (https://en.wikipedia.org/wiki/Meritocracy) was coined in the 50s for socialist criticism invoking satire. The discourse had nothing to do with race and was about disputing how merit is measured, not about supposed prejudices (except perhaps class privilege). Nor did coaches, managers etc. imagine any inferiority on the part of black athletes in regards to physical prowess. Segregation was to keep the peace; see e.g. https://en.wikipedia.org/wiki/Baseball_color_line :
> Before the 1860s Civil War, black players participated in the highest levels of baseball.[2] During the war, baseball rose to prominence as a way to bring soldiers from various regions of the country together. In the aftermath of the war, baseball became a tool for national reconciliation; due to the racial issues involved in the war, baseball's unifying potential was mainly pursued among white Americans.[3]
Anyway,
> You wouldn't know if it works or not unless you give it at least one if not two generations to take effect.
This time lapse isn't required for a moral judgment, however.
> Equity doesn't mean give those that suck a boost. It means give those that weren't given the environment to develop their full potential a chance at it, they may end up being even better than the alternative.
An employer, or a college admissions officer, cannot provide what was missing from someone's "environment" during the formative years, and should not be expected to try; nor ought they shoulder the risk of anyone's "full potential" being absent. Everyone might as well hire randomly from the general population at that point.
Historically, institutions were widely believed to be selecting the best available candidates within the accepted social boundaries of the time. They did not call it meritocracy, but it was assumed.
AA advocacy exposed cracks in systems that claimed to be merit based and pushed reforms like anonymization and structured evaluation, which made selection more merit based, not less.
Merit is noisy and ties are unavoidable. When candidates are effectively equal, a tie breaker is required. The old default was incumbency and other status quo dynamics that favored the existing cohort. Random selection among equals would be defensible. Favoring candidates from groups historically denied opportunity is another possible tie breaker. You can disagree with that choice, but it is coherent to see it as pro merit rather than anti merit.
And that's just my point, some proponents of AA were arguing for better merit based systems, not all, but a lot did.
> Part of speech is quite easily the hardest dimension
Many English words can be used as two (or all three) of noun/verb/adjective. Including, er, "set".
> The share result is really clever. I guess maybe that answers my questions actually, it's designed around a playtime that's more like a daily puzzle game.
That's table stakes for this kind of game now. I think the main way people learned about Wordle must have been from their friends spamming their results on Discord/Twitter/etc.
Haha, well yes - I've put quite a number of these games out myself. I was a little surprised I didn't realize at the start that it was going to be this type of game, probably because of SET being a PVP game I've played tons of (well, you can play it solo but I haven't) so I wasn't really seeing this as a daily puzzle game at first.
But anyway, some of these games do a better job with their share result than others, often depending on if it's tacked on at the end or if the game is designed with it in mind. I was commenting that I liked this specific share result.
> So like why doesn't the person iterate with the AI until they understand the bug (and then ultimately discover it doesn't exist)? Like have any of this bug reports actually paid out? It seems like quickly people should just give up from a lack of rewards.
This sounds a bit like expecting the people who followed a "make your own drop-shipping company" tutorial to try using the products they're shipping to understand that they suck.
> To make sure that the size checks cannot be separated from the copy itself we introduced a string copy replacement function the other day that takes the target buffer, target size, source buffer and source string length as arguments and only if the copy can be made and the null terminator also fits there, the operation is done.
... And if the copy can't be made, apparently the destination is truncated as long as there's space (i.e., a null terminator is written at element 0). And it returns void.
I'm really not sold on that being the best way to handle the case where copying is impossible. I'd think that's an error case that should be signaled with a non-zero return, leaving the destination buffer alone. Sure, that's not supposed to happen (hence the DEBUGASSERT macro), but still. It might even be easier to design around that possibility rather than making it the caller's responsibility to check first.
> This is something I generally believe, but I think it's particularly important for things like languages and runtimes: the idea of installing things "on" the OS or the system needs to die.
Python has been trying to kill it for years; or at least, the Linux distros have been seeking Python's help in killing it on Linux for years. https://peps.python.org/pep-0668/ is the latest piece of this.
I feel like this principle could be codified as "the system is not a workspace."
The use of the system as a workspace goes back to when computers were either very small and always personal only to one user, or when they were very big and administrated by dedicated system administrators who were the only ones with permission to install things. Both these conditions are obsolete.
But the system is not a workspace acts like resources are free. Everything that’s wrong with a modern computer being slower than one from 30 years ago at running user applications has its roots in this kind of thing. It’s more obvious on mobile devices but desktops still suffer. Android needs more RAM and had worse power utilization until a lot was done to move toward native compiled code and background process control. Meanwhile Electron apps think it’s okay to run multiple copies of Javascript environments like working RAM is free and performance isn’t hurt.
My usual thought is that boilerplate tells me, by existing, where the system is most flawed.
I do like the idea of having a tool that quickly patches the problem while also forcing me to think about its presence.
> There isn't a binary between having an LLM generate all the code and writing it all myself. I still do most of the design work because LLMs often make questionable design decisions.
One workflow that makes sense to me is to have the LLM commit on a branch; fix simple issues instead of trying to make it work (with all the worry of context poisoning); refactor on the same branch; merge; and then repeat for the next feature — starting more or less from scratch except for the agent config (CLAUDE.md etc.). Does that sound about right? Maybe you do something less formal?
> Sometimes I simply want a program to solve a purpose (outcome-focused) over a project to work on (craft-focused). Sometimes I need a small program in order to focus on the larger project, and being able to delegate that work has made it more enjoyable.
Yeah, that sounds about right.
reply