Oxide Computer's public Requests for Discussion, internal design and policy documents on engineering, hiring, Rust, and LLM use.
Commenters praise Oxide's RFD culture as a rigorous written engineering process and cite the RFD on LLMs as writers.
I continue to resonate with the Oxide take when I hear this kind of sentiment expressed about AI prose
"... LLM-generated prose undermines a social contract of sorts: absent LLMs, it is presumed that of the reader and the writer, it is the writer that has undertaken the greater intellectual exertion. (That is, it is more work to write than to read!) For the reader, this is important: should they struggle with an idea, they can reasonably assume that the writer themselves understands it — and it is the least a reader can do to labor to make sense of it.
If, however, prose is LLM-generated, this social contract becomes ripped up: a reader cannot assume that the writer understands their ideas because they might not so much have read the product of the LLM that they tasked to write it. If one is lucky, these are LLM hallucinations: obviously wrong and quickly discarded. If one is unlucky, however, it will be a kind of LLM-induced cognitive dissonance: a puzzle in which pieces don’t fit because there is in fact no puzzle at all. This can leave a reader frustrated: why should they spend more time reading prose than the writer spent writing it?"
https://rfd.shared.oxide.computer/rfd/0576#_llms_as_writers
"Using LLMs at Oxide" [0], as seen on the HN frontpage yesterday, had a bit to say about LLMs as writers
> LLM-generated prose undermines a social contract of sorts: absent LLMs, it is presumed that of the reader and the writer, it is the writer that has undertaken the greater intellectual exertion. (That is, it is more work to write than to read!) For the reader, this is important: should they struggle with an idea, they can reasonably assume that the writer themselves understands it — and it is the least a reader can do to labor to make sense of it.
> If, however, prose is LLM-generated, this social contract becomes ripped up: a reader cannot assume that the writer understands their ideas because they might not so much have read the product of the LLM that they tasked to write it. If one is lucky, these are LLM hallucinations: obviously wrong and quickly discarded. If one is unlucky, however, it will be a kind of LLM-induced cognitive dissonance: a puzzle in which pieces don’t fit because there is in fact no puzzle at all. This can leave a reader frustrated: why should they spend more time reading prose than the writer spent writing it?
[0] https://rfd.shared.oxide.computer/rfd/0576
I think the Oxide computer LLM guidelines are wise on this front:
> Finally, LLM-generated prose undermines a social contract of sorts: absent LLMs, it is presumed that of the reader and the writer, it is the writer that has undertaken the greater intellectual exertion. (That is, it is more work to write than to read!) For the reader, this is important: should they struggle with an idea, they can reasonably assume that the writer themselves understands it — and it is the least a reader can do to labor to make sense of it.
https://rfd.shared.oxide.computer/rfd/0576#_llms_as_writers
The heavy use of LLMs in writing makes people rightfully distrustful that they should put the time in to try to read what's written there.
Using LLMs for coding is different in many ways from writing, because the proof is more there in the pudding - you can run it, you can test it, etc. But the writing _is_ the writing, and the only way to know it's correct is to put in the work.
That doesn't mean you didn't put in the work! But I think it's why people are distrustful and have a bit of an allergic reaction to LLM-generated writing.
> Took them 3 months before a "we're not interested" email was sent. No reasons, either.
Yeh this is really really tough. They have an excellent RFD that explains the hiring process and it contains a section on this here: https://rfd.shared.oxide.computer/rfd/0003#_rejection_of_non_interviewed_candidates
I ported their Hubris kernel to RISC-V and ARMv6 before applying for a role to work on it, so thought I had reasonably strong materials, but got rejected.
I fully understand and empathise with their reasons for not providing feedback, but it does mean you're left not knowing whether you were a hair's breadth away from getting in but were behind a better candidate and it would be worth trying again in the future, or rejected for other reasons that no improvement in materials will make up for. As a fully signed-up member of imposter syndrome club I'll obviously lean towards the latter ;)
A few years ago I worked for a tech company that had many senior ex-Googlers engineers, with 30+ years of experience in SWE, and they were able to imbue into our team a culture of engineers writing and reading Design docs.
There was even a design doc for design docs. This CAN help, but one of the problems that happened as the company grew in size and age, was that there was a plethora of design docs, and no real summary.
So we supplemented the documents with recurring presentations to new engineers, who could get a glimpse of the design decisions, without being overwhelmed with design doc reading.
Oxide (Bryan Cantrill's computer company) does something similar with their RFDs (Requests for Discussion), but publicly. Their "design doc for design docs" is RFD 1, and you can read it here: https://rfd.shared.oxide.computer/rfd/0001
Also, if you haven’t read the linked Oxide RFD#3 [1], I recommend doing so. It has shaped much of our hiring process.
> But how does one assess candidates for such positions? This is an age-old question without a formulaic answer: designing, building, selling, and supporting computing systems is itself too varied to admit a single archetype.
> In terms of evaluation mechanism: using in-person interviewing alone can be highly unreliable and can select predominantly for surface aspects of a candidate’s personality. While we advocate (and indeed, insist upon) interviews, they should come relatively late in the process; as much assessment as possible should be done by allowing the candidate to show themselves as they truly work: on their own, via their creations.
[1] https://rfd.shared.oxide.computer/rfd/3