This is just the rationalist-empiricist[0] tension, from philosophy. Most empiricists (usually people who are _not_ from continental European cultures), take a position that knowledge and creativity come from observation and imitation, while rationalists believe that knowledge and creativity can be endogenous to the mind.
One could say that, stereotypically and cartoonishly, empiricists believe that invention is a false concept, and a synonym for discovery, while rationalists would oppose this view.
That catch is, if you look at the etymology of words "invention" and "discovery", you will find that they both share the _same_ root: _Ars Inveniendi_.
A natural question arises: does this mean that people from a millennium ago did not have a dyad equivalent to our invention-discovery dyad? And the answer, surprisingly, is _no_. Even a millennium ago, the empiricists and rationalists were going at it. If _Ars Inveniendi_ is art of discovery/invention, then its counterpart is _Ars Demonstrandi_ (the art of demonstration/proof).
So, how do these differ? Is one just observing/creating and the other just math and language-games?
In general, Ars Demonstrandi is about writing down axioms, and then expanding those axioms recursively (similar to rewrite rules in any formal system), until you get to some end-state, or, if there is none, a novel or surprising state. I, personally, call this source-to-sink thinking.
Ars Inveniendi is about taking conclusions (often using observations from the physical world) and trying to figure out what axioms can lead to those conclusions. I, (again) personally, call this sink-to-source thinking.
Put differently, Ars Inveniendi can help one discover starting points for Ars Demonstrandi.
If you read the dialectics (e.g. Plato and friends), you'll find that most of them are just a mutual recursion between Ars Inveniendi and Ars Demonstrandi.
I believe (again, I am not a philosopher, and this is just my intuition), that the thing that we call "creativity" and "invention" _emerges_ from the recursive loop[1]. A favorite example: Esperanto (the conlang). It is a language, which is remarkably elegant and consistent and (in my opinion) beautiful, because it _is_ derived from first principles, which were themselves derived from the various languages spoken in Europe (not all of which are Indo-European -- the agglutinative features have more in common with Finno-Ugric and Turkic languages). There is something about it, that makes it _qualitatively_ different (and thus holistically novel) from all other languages (and I speak, fluently, _two_ national languages, that are very different from each other, so I can attest to the difference personally).
My guess, is that people will not accept that AI/LLMs are creative or inventive, until they can produce an original[2] (non-plagiarized) artifact that feels the way Esperanto feels.
[0]: By Rationalist, I do not mean the "Bay Area Rationalists", who are, in fact, empiricists.
[1]: I am unsure if the loop requires only one human, at least two humans, or if it can be fully automated.
[2]: Note that Centos are poems made completely out of line-numbers (e.g. fragments from the Iliad, or the bible, etc). Every line is borrowed, yet some of them are considered beautiful and original works of art. Similarly, Labatut and Burroughs and Perec, write using a technique called _the cut-up method_, where they take books, magazines, and newspapers, and superimpose page-fragments, and use that as an inspiration -- they are all considered artists, and good ones. It is unclear to me why LLMs (which seem to be built on the cut-up method, and have cut-ups of all of human knowledge) cannot match these artists. What's missing?
I mean, my point is that we would all be better off without any of the KPIs, and stack-ranking, and so on, in large part because they are not reliable metrics, and making them reliable is itself a difficult problem to solve. You need engineers that seek to understand your business, your problem, and are willing to use that understanding and their experience of building software, to solve those problems in as permanent and correct a way as possible.
The reason this is so difficult to manifest, is that only about 2% to 4.6% of the college-educated population are software engineers at any given point, which means that 95% of all the people that we interact with, have no clue what we are talking about, and do not understand why they cannot have more, more, more, now, now, now. For comparison at least 20% of people have a degree in business. And most of those, in non-concrete roles seem to be cargo-culting their way through a career.
Unreliable software is also expensive. Rather, building reliable software is incompatible with a management policy that rewards and punishes people based on KPIs (basically leading indicators). The concept of KPIs is fine, but they should (a) be actual indicators of progress, and (b) be kept secret from employees (so that we can avoid or mitigate Goodhart's Law). Both of those things are difficult, because you need a rigorous statistical model of what correlates, and you need to keep that model a secret, while also changing the KPIs periodically, to prevent employees from intuitively overfitting. That whole process would be very expensive (and if it would not, why is nobody doing it).
Furthermore, software that is reliable, is also software that is done (in the sense that AVL Trees, and ZFS, and DTrace, and ZSTD, and slab allocators are done -- they are very close to perfect, and require minimal changes, related to compilers and kernels and computer architectures). A team that builds reliable software, is a team that cannot be "managed". What exactly is there to manage?
The argument is not just "theft", and to the extent that "theft" is a part of it, it is not the most important part, not by large margin. The reason that "theft" is not a solid argument, is because people creating open-source often distribute it for free themselves. Piracy is not the issue.
The issue is that all attributions get stripped away by the LLM (even in cases where it is trivial to avoid). For example, as a test, I asked DeepSeek to tell me how one can do an exact substring-boolean-test in Common Lisp, and it gave me code that was, character for character, _identical_ to the code that appears in Seibel's Common Lisp Book. It clearly memorized the code. It stands to reason, that it could have also memorized where it saw it, and been trained to tell the user that the code was from that book (which is NOT in the public domain, despite being free to read on the internet)[0].
To give you an analogy, nobody has a problem with someone downloading and distributing the public domain works of Leo Tolstoy or Charles Dickens or Jane Austen or Karl Marx, etc. But to remove their names from those works, and placing your (or someone else's) name on them instead, is plainly malicious behavior. Such behavior needs to shunned.
LLMs (I believe) _can_ be trained to not plagiarize. They do not have to be original, nor to use public domain training-data, they just have to give attribution (which, as far as I can tell, requires little more than a corpus and a stack of similarity-measures).
I suspect that they are not trained this way, because fully automated plagiarism creates an ambiguous situation, where a copyleft license (like GPL or EUPL etc) can be unknowingly violated, and there is hardly any trace of the violation. Plagiarism is the product.
[0]: Such attribution can only make LLMs _more_ useful and _more_ widely and confidently integrated into workflows. The lack of such attributions, risks diluting the value of open source projects, as (1) a high-signal indicator of skill and achievement, and (2) a way to ensure the provenance and quality of the code (both very important, if you are considering to build a business on top of one or more such projects). Just look at all those repos that claim to have "made" Minecraft-like game or Unix-like OS, when all they did was have an LLM plagiarize the code for them. This is a kind of, at best, spam and, at worst, fraud.
With the exception of _one_ company that I worked at, pretty much every[0] company was a struggle between engineering and management. Engineering wants to get the software correct, and management wants to fire-hose features into the market. Most of the time (so more than half, at least), management tends to have a compulsion to mindlessly imitate what other companies/competitors are doing, usually without prioritization (so even if feature-parity is a good idea, usually management will want to prioritize whatever the newest feature is, and to put existing work on the back-burner). It very frequently feels like management is making strategic decisions after snorting a long line of social-media-psychosis and TED talks. It is remarkable that investors have any faith in such founders/entrepreneurs at all.
[0]: Various people I know do not even have the luxury of that one good company. Also, it -- unbelievably -- sounds much worse at other companies.
Owners and developers. I've been thinking about this a lot lately. Years ago, maybe in the late 2000s, when startups were becoming culturally significant, and "Tech" became an "Industry", two books were written and published: Founders at Work by Livingston, and Coders at Work by Seibel. I read both, and recall the Founders-book being a bit of a slog -- I only read it once[0]. The Coders-book, I have been re-reading it for more than a decade. I am sure there are many people who would express the _opposite_ sentiment.
The existence of _two_ books, published by the same publisher, within a few years of each other, is a kind of tacit acknowledgement, that there are two categories of people (Owners/Founders and Developers/Coders), that have a kind of symbiotic relationship with each other. That relationship has always been a relationship of convenience and gain, not resonance and understanding and appreciation.
It is, in a way, similar to globalization: nations will support it, only to the extent that it can make them (or their elites) wealthier, and not because they actually care about peace, or the magnificent diversity of human culture and creativity.
Just as the globalized economy is fraying, so is the symbiotic relationship between Founders and Coders. I think it started with the pandemic, which caused (without pointing any fingers) a tension between Founders and Coders, and has been accelerated by LLMs. In some sense, the tactics that were use by Tech companies to wow and win customers outside of Tech, are now being used by Tech companies on other Tech companies. And those tactics involve making grand promises to people who have knowledge-gaps, and are otherwise easily impressed.
I did not realize that there even was a symbiotic relationship, until I analyzed US degree-completion-rates for 1970 to 2011[1][2]. I suppose it should have been obvious, but these things are difficult to perceive from the inside (even if you've been working in the industry for an entire decade). The big problem is that the symbiosis is asymmetrical: founders get the money, and pay the coders, and are able to fire and replace coders at will, while coders can do none of this to the founders. This may have been fine, in an era where layoffs were rare, and getting a replacement job was less uncertain. But I suspect that the contest we are going to see in the next few years is: can Founders out-code Coders, or can Coders out-found Founders. Note that the Viaweb story (the archetypal startup-story for HN), is a story of Coders out-founding Founders (the equivalent of the late 90s era, did not found companies so much as administer small parts of them).
[0]: This is not a criticism of the author/interviewer, nor the interviewees -- the subject matter simply did not intersect enough with my own obsessions and fixations. I wish it did. It feels like I have some kind of color blindness, when it comes to "founder-y" things.
[2]: If you do not want to read all of that, here is a TLDR. The percentage of informatics-degree-completions never drops below 2% (which confirms an informal observation Knuth has made many times -- see his 3 or 4 oral histories and his interview in Coders at Work). The percentage of informatics-degree-completions rises and falls with business-degree-completions (the symbiosis is visible here). It never exceeds 4.5%, and such doublings coincide with bubbles (the dot-com bubble, and the 1980s AI-bubble -- there is a history section that helps narrate these numbers). Most intriguingly, informatics-degree-completions are _perfectly inversely correlated_ with healthcare-degree-completions -- their first-derivatives are nearly perfect mirror images. Also, the majority of graduates are business-graduates (accounting, administration, etc -- economics belongs to social-sciences instead of business), and their numbers have doubled since 1970, at the expense of social sciences and education (I suspect that this has had an impact on our (both global and American) culture akin to the impact that climate-change has had on our planet, but I have no data to put behind that suspicion, yet).
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.
webpage: https://galacticbeyond.com
github: github.com/galactic-beyond
github-legacy: github.com/nickziv