Live data from Hacker News

Using LLMs at Oxide

rfd.shared.oxide.computer

121–130 of 284 posts

Re: Using LLMs at Oxide

#121
post #50

Find it interesting that the section about LLM’s tells when using it for writing is absolutely littered with emdashes

There was a comment recently by HN's most enthusiastic LLM cheerleader, Simon Willison, that I stopped reading almost immediately (before seeing who posted it), because it exuded the slop stench of an LLM: https://news.ycombinator.com/item?id=46011877 However, I was surprised to see that when someone (not me) accused him of using an LLM to write his comment, he flatly denied it: https://news.ycombinator.com/item?id=4…

> if you spend too much time interacting with LLMs, you eventually resemble one

Pretty much. I think people who care about reducing their children's exposure to screen time should probably take care to do the same for themselves wrt LLMs.

Re: Using LLMs at Oxide

#122

The guide is generally very well thought, but I see an issue in this part: It sets the rule that things must be actually read when there’s a social expectation (code interviews for example) but otherwise… remarks that use of LLMs to assist comprehension has little downside. I find two problems with this: - there is incoherence there. If LLMs are flawless in reading and summarization, there is no difference with readi…

> It sets the rule that things must be actually read when there’s a social expectation (code interviews for example) but otherwise… remarks that use of LLMs to assist comprehension has little downside.

I think you got this backwards, because I don't think the RFD said that at all. The point was about a social expectation for writing, not for reading.

Re: Using LLMs at Oxide

#123
post #30

Earlier quoted context omitted.

To be fair, LLMs usually use em-dashes correctly, whereas I think this document misuses them more often than not. For example: > This can be extraordinarily powerful for summarizing documents — or of answering more specific questions of a large document like a datasheet or specification. That dash shouldn't be there. That's not a parenthetical clause, that's an element in a list separated by "or." You can just remove…

LLMs also generally don't put spaces around em dashes — but a lot of human writers do.

I think you're thinking of british-style "en-dashes" – which is often used for something that could have been separated by brackets but do have a space either side – rather than "em" dashes. They can also be used in a similar place as a colon – that is to separate two parts of a single sentence.

British users regularly use that sort of construct with "-" hyphens, simply because they're pretty much the same and a whole lot easier to type on a keyboard.

Re: Using LLMs at Oxide

#124
post #102

Strange to see no mention of potential copyright violations found in LLM-generated code (e.g. LLMs reproducing code from Github verbatim without respecting the license). I would think that would be a pretty important consideration for any software development company, especially one that produces so much free software.

Has anything like this worked its way through the courts yet?

Re: Using LLMs at Oxide

#125

A measured, comprehensive, and sensible take. Not surprising from Bryan. This was a nice line: > it’s just embarrassing — it’s as if the writer is walking around with their intellectual fly open. I think Oxide didn't include this in the RFD because they exclusively hire senior engineers, but in an organization that contains junior engineers I'd add something specific to help junior engineers understand how they shoul…

I remember in the very first class I ever took on Web Design the teacher spent an entire semester teaching "first principles" of HTML, CSS and JavaScript by writing it in Notepad. It was only then did she introduce us to the glory that was Adobe Dreamweaver, which (obviously) increased our productivity tenfold.

I love how people speak about Dreamweaver in the past, while Adobe keeps getting money for it,

https://developer.adobe.com/dreamweaver/

And yes, as you can imagine for the kind of comments I do regarding high level productive tooling and languages, I was a big Dreamwever fan back in the 2000's.

Re: Using LLMs at Oxide

#126

Earlier quoted context omitted.

DreamWeaver absolutely destroyed the code with all kinds of tags and unnecessary stuff. Especially if you used the visual editor. It was fun for brainstorming but plain notepad with clean understandable code was far far better (and with the browser compatibility issues the only option if you were going to production).

After 25 or so years doing this, I think there are two kinds of developers: craftsmen and practical “does it get the job done” types. I’m the former. The latter seem to be what makes the world go round.

I think there's more dimensions that also matter a bunch:

  * a bad craftsman will get pedantic about the wrong things (e.g. SOLID/DRY as dogma) and will create architectures that will make development velocity plummet ("clever" code, deep inheritance chains, "magic" code with lots of reflection etc.)
  * a bad practician will not care about long term maintainability either, or even correctness enough not to introduce a bunch of bad bugs or slop, even worse when they're subtle enough to ship but mess up your schema or something
So you can have both good and bad outcomes with either, just for slightly different reasons (caring about the wrong stuff vs not caring).

I think the sweet spot is to strive for code that is easy to read and understand, easy to change, and easy to eventually replace or throw out. Obviously performant enough but yadda yadda premature optimization, depends on the domain and so on...

Re: Using LLMs at Oxide

#127
post #44

A measured, comprehensive, and sensible take. Not surprising from Bryan. This was a nice line: > it’s just embarrassing — it’s as if the writer is walking around with their intellectual fly open. I think Oxide didn't include this in the RFD because they exclusively hire senior engineers, but in an organization that contains junior engineers I'd add something specific to help junior engineers understand how they shoul…

> That junior engineer possibly hasn't programmed without the tantalizing, even desperately tempting option to be assisted by an LLM. This gives me somewhat of a knee jerk reaction. When I started programming professionally in the 90s, the internet came of age and I remember being told "in my days, we had books and we remembered things" which of course is hilarious because today you can't possibly retain ALL the know…

Ah, but lets do leetcode on the whiteboard as interview, for an re-balancing a red-black tree, regardless of how long those people have been in the industry and the job position they are actually applying for.

Re: Using LLMs at Oxide

#128
post #102

Strange to see no mention of potential copyright violations found in LLM-generated code (e.g. LLMs reproducing code from Github verbatim without respecting the license). I would think that would be a pretty important consideration for any software development company, especially one that produces so much free software.

Is there current generation LLMs do this? I suppose I mean "do this any more than human developers do".

A very recent example: https://github.com/ocaml/ocaml/pull/14369

Re: Using LLMs at Oxide

#129

As usual with Oxide's RFDs, I found myself vigorously head-nodding while reading. Somewhat rarely, I found a part that I found myself disagreeing with: > Unlike prose, however (which really should be handed in a polished form to an LLM to maximize the LLM’s efficacy), LLMs can be quite effective writing code de novo. Don't the same arguments against using LLMs to write one's prose also apply to code? Was this structu…

try Opus 4.5, you'll be surprised. It might be true for past versions of LLMs, but they advanced a lot.

Re: Using LLMs at Oxide

#130

Cantrill jumps on every bandwagon. When he assisted in cancelling a Node developer (not a native English speaker) over pronouns he was following the Zeitgeist, now "Broadly speaking, LLM use is encouraged at Oxide." He is a long way from Sun.

For those interested, here's a take from Bryan after that incident https://bcantrill.dtrace.org/2013/11/30/the-power-of-a-prono...

The change: https://github.com/joyent/libuv/pull/1015/files

> Sorry, not interested in trivial changes like that.

- bnoordhuis

As a not native English speaker, I think the change itself is okay (women will also occasionally use computers), but saying you're not interested in merging it is kinda cringe, for a lack of a better term - do you not realize that people will take issue with this and you're turning a trivial change into a messy discussion? Stop being a nerd and merge the damn changeset, it won't break anything either, read the room. Admittedly, I also view the people arguing in the thread to be similarly cringe, purely on the basis that if someone is uninterested/opposed to stuff like this, you are exceedingly unlikely to be able to make them care.

Feels the same as how allowlist/denylist reads more cleanly, as well as main for a branch name uses a very common word as well - as long as updating your CI config isn't too much work. To show a bit of empathy the other way as well, maybe people get tired of too many changes like that (e.g. if most of the stuff you review is just people poking the docs by rewording stuff to be able to say that they contributed to project X). Or maybe people love to take principled stances and to argue idk

> ...it’s not the use of the gendered pronoun that’s at issue (that’s just sloppy), but rather the insistence that pronouns should in fact be gendered.

Yeah, odd thing to get so fixated on when the they/them version is more accurate in this circumstance. While I don't cause drama when I see gendered ones (again, most people here have English as a second language), I wouldn't argue with someone a bunch if they wanted to correct the docs or whatever.

Post reply on HN