Yeah, that is situation 2 mentioned above. A Chomsky Grammar is also a generator. So it can generate valid inputs, and then turn them into valid outputs -- and it can do the first part stochastically/randomly.
So, take a look at my previous comment (I am sibling, not parent). The pencil pushers are still being manufactured by the educational system itself, but they major in Business now, not Social Sciences or Education. This is due to government policy from 1980s incentivizing the creation of more business entities (they each need accountants, and managers, and so on), which caused a few generations of people to go down that route. The tragedy here is that these generations have internalized the idea that the practical and profitable is more valuable than the aesthetic and beautiful. Instead of cultivating human beings that can contemplate and appreciate, we are cultivating human beings that can analyze and optimize (this is fine, but it is possible to have too many of them, which creates a competitive dynamic that _everyone_ has to participate in, that _nobody_ can opt out of, and that most people (80% or more) -- even very capable and strategic people -- are likely to lose).
What I am saying is that the paper pushers are allocated elsewhere, they are more miserable and shallow minded now, and they have a corrosive long-term effect on society and culture, even though they contribute positively to economic growth. In way, it is trans-generational debt with extra steps.
And, in case anyone needed proof, this is reflected in the US degree-completion-data, when measured as a percentage (https://galacticbeyond.com/two-percent-programmer/plots/over...), and when measured as a derivative of percentage (https://galacticbeyond.com/two-percent-programmer/plots/deri...). That green top-line, is business-majors, and those two lines that declined from top to average are social-sciences and education (all data from 1970 to 2011). In 1970 1 in 10 graduates were in business, 1 in 5 were in education and in social sciences. By 2011, 1 in 5 (or 2 in 10) were in business, and 1 in 10 were in social sciences and 1 in 20 were in education. Healthcare went from 3 in 100 to 1 in 10.
> and we got “Greed is Good” Geckos running things since
This phrase is the opposite of an exaggeration. It sounds like it should not be true, but it really, really is. To be fair though, if you told me in 2015 what the headlines for the 2020s would look like, I would assume you are some kind of satirist or comedian.
As someone who does a lot of genetic programming (like, old-school, without AI/LLMs, etc), I can confirm that the fitness function is very difficult to get right, especially if you are trying to evolve programs that have "adversarial fitness" -- you'd need to maintain a hall-of-fame, and that just makes the runs take _much_ longer, because, chances are, your fitness function is the bottle-neck.
So, it is very hands-off, but also very expensive, and it is never clear if optimizing the fitness function is worth it, because the fitness function itself may be insufficiently or incorrectly specified.
However, I do think that people should try, even with just a whiteboard or a notebook, to design a fitness-function, for their problem, as if they were going to try to evolve it, because (1) it forces them to explicate their correctness constraints, and (2) they may discover that the program that they are trying to write _is equivalent_ to the fitness function.
I'll give you an example for point 2. Many years ago, I had to parse a gnarly language, and I chose to do it via Chomsky Grammars (that automatically build a tree based on the grammar-spec). Chomsky Grammars are cool, in that they are basically just a state-machine, but they are incredibly difficult to debug: when they work, they might work incorrectly (malformed tree), and when they fail, they give no reason for failure (because even with a trace, you are trying to figure out which backtrack should not have happened). So, out of desperation, I started to consider using genetic programming to just evolve a correct Chomsky Grammar. It became clear that there are only 2 possible fitness functions (1) a function that tests a hand-picked input against a hand-crafted tree-output (which is vulnerable to over-fitting), and (2) a function that is not (well, is much less) vulnerable to over-fitting, but is effectively a pre-existing, correct grammar that can produce those trees.
If you are in situation 2, then the genetic programming is not necessary, unless you are trying to create an optimized (or obfuscated) parser, and even then the optimization may be overfit to the test-inputs (even if they are generated test-inputs from the grammar itself). If you are in situation 1, then you are better off re-evaluating your approach (I abandoned the Chomsky Grammar notation, and invented one that is much easier to understand and debug, without losing any of the expressiveness -- it also happens to be slower, but fast-and-broken is worthless compared to not-so-fast-and-works-fine).
One place where genetic programming has been consistently awesome, is in parameter-search style problems (e.g. your genome is a long list of floats, representing weights and/or anti-weights, and you need to find out which weights give you more fitness (or less error)). I hear good things about variable-neighborhood-search, but have yet to try it.
Disclaimer: I have never applied nor worked at oxide, but nevertheless have a bit of an odd thought.
Having looked at the process (RFD 3 and original post on dtrace.org), and contextualizing it with the oversubscribed-problem (which was mentioned somewhere else in this thread), I cannot help but think that there is a kind of solution that can help both the applicants and oxide and (yes) the industry as a whole.
The kinds of materials that the RFD asks for, seems like it would make for very interesting reading, regardless of whether it is read by a hiring-manager or a computer nerd. So why not, instead of (or in addition to) writing 11 pages, and sending them to the inbox of someone who (even without the additional responsibility of sorting thousands of applications in order hire-ability) is already extremely busy (this is, after all, a very demanding job), you publish them on your webpage?
In addition to taking some of the pressure off the oxide hiring-pipeline, you also get more exposure to people, who may work at organizations that would benefit from such a pipeline, but cannot afford to burn the political capital to replace the old pipeline. In a way, people who would appreciate your materials would, over some amount of time (and time should not be an issue, because it seems like it takes (at least sometimes) a long time for oxide to respond anyway), find them and possibly reach out.
I am basically a nobody, but if people started publishing things in the format of an oxide application, I would _totally_ read them. I am not saying I would necessarily _like_ them, but I would certainly read them[1]. Also, if disclosure is an issue, people can be published pseudonymously.
[1]: If for no other reason, than to see the multitude funny ways in which other people are wrong ;)
You might be surprised just how durable the effects of 40-year-old decisions are. You can actually see changes to the very degree completion-rates, when partitioned by field of study. Particularly, education and physics fields (as classified by NCES), have absolutely cratered from the mid 70s to the mid 80s, while business fields became dominant. And if you need data, I actually published an entire (and entirely too long) essay, analyzing the NCES data from 1970 to 2011 (a sequel post for 2011 to present is planned), yesterday[0][1]. Healthcare tends to boom and bust[2] in cycles, and those cycles are _inversely_ correlated with engineering, informatics (the most elegant term for what we call "computer and information sciences"), and business.
[2]: In both the economic sense, and in the completion-rate sense, because those two things are correlated. And they have been correlated since the 1980s, because a lot of the healthcare industry became de-regulated and more profitable as a result, since at least 1978 (when hospitals were de-forbidden from making profits).
You, and the HN users, `lojban`, `klingon`, `ido`, `brithenig`, `solresol`, `babm`, and `tokipona`, may want to start a club. Amusingly, nobody seems to have registered the `esperanto`, `volapuk`, `interslavic`, `balaibalan`, and `dothraki` usernames.
An alternative to a capped income, would be that every income gets "inflated" by as much as needed until it reaches parity with big-tech incomes, which would require a kind of transnational union, but would have the effect of reversing the direction of extraction. Also, printing that money to inflate the income, would also cause asset-inflation, which also benefits people who own a life-changing amount of capital/assets. But _if_ you could cap asset-prices, then the inflation strategy might work. Note that I have not modeled this particular scenario yet.
Each of those employees is a liability, for various reasons, not just financial. Even if their salaries were completely subsidized by the state, there are many problems that come from having a very large number of employees. Firstly, there is more coordination overhead, and that is not great. Secondly, people are very political and very envious, and that has a corrosive effect on, well everything. Thirdly, people are (justifiably) afraid of getting laid off, which results in decisions that are sub-optimal or even illogical. Fourthly, people tend to only spend a few years at companies before moving on (for a pay-increase), which disincentivizes companies to hire more, and it incentivizes companies/management (and even employees) to engage in a kind of performative conformity designed to signal replace-ability (this effectively means that many companies are going to choose to do whatever everyone else is doing, instead of the unusual thing that will likely work better -- think of it as cargo-cult entrepreneurship/management/engineering). Fifthly, those engineers that leave take with them the knowledge and technology that they built up at a different employer and launder[1] it to their next employer. Sixthly, larger teams tend to produce more code per feature, and tend not to abstract/compress aggressively (which requires actually having a holistic understanding of the product), which means that team-sizes are likely to keep growing until the company's revenues stop growing. Put differently, enshittification and sloppification naturally emerge from the dynamics of how the majority of the industry works, and LLMs have simply automated it[2].
The solution may be to modify the incentives. Maybe federally cap all salaries to 90k or so, to filter out the serial job-hoppers and con-artists, and to also prevent poaching and "nerd-hoarding"[3]. Has the additional benefit of forcing rents and property prices to go down, and stops gentrification in its tracks (I mean I would expect this to be partially true, though it might force people to instead seek massive loans to compensate -- which should also be capped by salary to prevent it). And since we are already talking about federal limits, maybe a federal guarantee that covers healthcare and housing would further improve things.
[1]: This depends on context. If the IP is already open source, then there is no laundering. But I know people who have been building the same software system for the last 3 employers, and they do it (ostensibly) from scratch each time (but in fact they are permuting/improving the old version -- which does not actually belong to them -- and are over-reporting how much time they spent working on it). My point here is not that employees are ruthless rogues, but rather that the incentives are set up in a way that encourages the rapid dilution of the value of IP (it is effectively non-exclusive, which makes industrial espionage _unnecessary_), and discourages any kind of mutual responsibility between employer and employee (in a different knowledge-work field, I hear from a friend, seniors give juniors only minimal training because they do not expect to have to deal with them in two years -- and this was true since at least 2017, and has only gotten more true since 2020).
[2]: With or without LLMs, the biggest winners of this dynamic are the quasi-monopolies (or, more precisely oligopolies and duopolies), like MSFT, GOOG, META, etc. Everyone else will lose, and if they happen to win, they will get acquired (not for the tech, which is probably slop anyway and cannot run at hyperscales, but for the clients/customers/users -- why else would MSFT buy LinkedIn and GitHub, why else would startup incubators like YC be such a huge success (I doubt YC would have been possible in the 70s or 80s)). Software is awesome, and I love it, but the software _industry_ has always been an operation designed to extract money and data from the populace, using deceptive and predatory practices (see: Uber, Theranos, Celsius, Alameda for outright fraud, and Oracle for mere deception and plunder).
[3]: Sorry, could not think of a better term. The idea is basically the corporate equivalent of nerd-sniping, but instead of sniping by offering interesting problems/puzzles, you snipe by offering large paychecks and golden handcuffs.
I have been saying things to this effect for a few years now, and have literally been laughed at. I feel like that guy that suggested that doctors should wash their hands before operating on patients -- they laughed at him too, before they put him in an asylum. What's going to happen, is that everyone who realizes that these policies are a mistake, is going to quietly retcon their own role in that mistake, while scapegoating everyone that they don't like.
Also, would bet money that the derived data from the meeting-summarizers is being sold to hedge-funds, to give them a bit of an edge.
No, that would be a strict improvement. The AI note-takers can easily "mishear" or "misreport" non-existent illegal and unethical things. It also seems to easily mess up numbers (which is big problem, because a lot of decisions hinge on precise numbers -- imagine inflating an inventory by an order of magnitude, and then imagine having to pay a tariff on something that never existed).
I have a friend who works at a large-ish company that imports and manufactures things (in one of the clerical/quantitative professions). A few years back, they had the IT department go on a kind of "inquisition", wherein they forced employees to disable the summarization function that came with MS Teams, and threatened to fire them if they did not. The resistance to this demand was surprising -- most people are clueless about the cost of their own convenience. Worst of all, people would zone out of meetings, because the AI was producing summaries, which they would then never read.
The effect of the technology was that it made meetings infinitely more expensive, because the supposed benefit of meetings was nullified by complacency, _and_ it made the meetings a liability (incorrectly summarized meetings, that could be used in the discovery process, sure, but could also be sold by MSFT as a kind of market-research-data to competitors in the space).
Nothing illegal has to happen in these meetings at all, for this tech to cause an infinity of problems for the corporation. Every employee that uses these is effectively an unwitting spy. And if that is the case, then the meetings might as well be recorded and uploaded to YouTube (or whatever people watch these days)[1].
[1]: Maybe this is the future. Which I am okay with, but only if the entire planet has to do it, and the penalties for not doing it are irrecoverably severe.
Could not help but notice that this project has no explicit policy on whether AI contributions are allowed or not (i.e. nothing analogous to https://ziglang.org/code-of-conduct/).
This is interesting. I have always preferred to make my personal projects single-file (or at least few-massive-file)[1]. I noticed that teams in general, strongly dislike this style of programming (even before LLM-coding-assistants, as far back as 2020).
[1]: It makes navigation and iteration much faster, and obviates the need to use indexers. It also forces you to only put _orthogonal_ programs in external files (I recently had to write a kind of quasi-SAT-solver, and that was code that was complex enough to require its own "namespace", and it was also something that was reusable across projects). One thing I noticed, maybe in 2025, is that LLMs struggled to navigate large single-file programs, but were quite good at navigating multi-file programs. It is interesting that they (according to my 2025 experience and the quote you give) prefer to _write_ code in ways that make it difficult for them to _read_ code.
> What will it mean when I can no longer tell the difference?
It just means that you will have to evaluate prose on its own merits (aesthetic, logical, etc).
The main problem with LLM-assisted writing is that effort-to-write is now much lower than effort-to-read -- the LLM-prose-style is simply an imperfection that can sometimes help the reader bail on a piece (and there might be false-positives).
Most people are already biased against reading long pieces, and seem to skim them more often than not. These people are _probably_ a little worse off than before, but they are not paying full-price for being hoodwinked. The people who end up paying full-price are probably going to become more sophisticated in how they choose what to read. I can't tell if this will be good/bad for publishers and/or advertisers.
There is a universe out there, where most of the world is reading Solaris man pages, instead of Linux man pages. Whatever your thoughts on the Solaris OS, I think it is fair to say that no operating system has ever matched the quality of its man pages.
Interestingly, I also converged on the "reverse dictionary" usage of LLMs, in around 2024[1], mostly to indulge in (human) language-learning.
An excerpt from the post below:
```
It is a phenomenal reverse dictionary (i.e. which English words mean "of a specific but unspecified character, quality, or degree"). It not only works for English, but also for Esperanto (i.e. which Esperanto words mean "of a specific but unspecified character, quality, or degree"), as well as my own obscure native language. This is a huge time-saver when learning languages (normal dictionaries won't cut it, and bi-lingual dictionaries are limited, if they are available at all). Even if you are just using a language you are fluent in, a reverse-dictionary-prompt can help you find words and usages, and can also help you find "dark spots" in the language's lexicon.
```
I don't know how to tell you this, but people have been writing custom software for personal use for decades. I've been doing it since at least 2009! I find it hard to believe that there is a demographic of people that were yearning to write code, but simply could not because they lacked LLMs. Is it the price? Are people simply too cheap to buy books? Or have they simply "forgotten" how to patiently and thoughtfully read them? Or has the quality of tutorials/documentation of languages/libraries/framework online decayed in the last decade? Or is it really that people have struggled to type characters of code into their text editors[1]?
Basically, I am prepared to accept that there is a friction that LLMs lubricate away, but what is the source of the friction, and why am I (and a bunch of other colleagues) not feeling that friction daily in our practice?
[1]: And if so, where did we programmers and computer scientists go wrong? Were subroutines and macros not sufficient for automating all of that excess typing? Were Emacs and Vim simply not saving enough keystrokes? Did people forget how to touch-type?
Just to emphasize my point, China is not being deprived of chip _designs_ (via export bans of ASML-made lithography equipment), but rather of the actual physical machines that rearrange the atoms.
People (well, American people (disclosure, I am an American)), used to be scared/worried that Silicon Valley will eventually move to Bangalore or Shenzhen, because of wage-discrepancies, and so on -- and it is not a totally unreasonable concern, considering that the _Silicon_ part of Silicon Valley has been slowly relocated to Taipei, Seoul, Tokyo, and a few others. At this point, maybe we should start pushing that the _rest_ of Silicon Valley gets relocated somewhere else, too.
It's a breeding ground for Edisons and Morgans, not Teslas. It is profoundly depressing that SV is doing everything it can (knowingly or unknowingly, not sure which is worse) to get the entire planet to stop taking it seriously and to shun it.
I feel like LLMs[1] are going to cause a kind of "divorce" between those who love making software and those who love selling software. It was difficult for these two groups to communicate and coordinate before, and now it is _excruciating_. What little mutual tolerance and slack there was, is practically gone.
Open source was always[2] a fragile arrangement based on the kind of trust that involves looking at things through one's fingers (turning a blind eye may be more idiomatic in English), and we are at the point where you just have to either shut your eyes, or otherwise stop pretending that the situation can be salvaged at all.
Just a thought I had: some people think that LLM-shaming is declasse, and maybe it is, but I think that perhaps we _should_ LLM-shame, until the AI-companies train their LLMs to actually give attribution, if nothing else (I mean if it can memorize entire blocks of code, why can't it memorize where it saw that code? Would this not, potentially, _improve_ the attribution-situation, to levels better than even the pre-LLM era? Oh right, because plagiarism might actually be the product).
[1]: Not blaming the tech itself, but rather the people who choose to use it recklessly, and an industry that is based almost entirely on getting mega-corporations to buy startups that, against the odds, have acquired a decent number of happy-ish customers, that can now be relentlessly locked-in and up-sold to.
webpage: https://galacticbeyond.com
github: github.com/galactic-beyond
github-legacy: github.com/nickziv