are you advocating for not having code reviews...? Just straight force push to main?

▲ AdieuToLogic 5 days ago | parent | next [-]

> are you advocating for not having code reviews...? Just straight force push to main?

No, not at all.

What I was speaking about was if the person to whom I replied is not a s/w engineer, then perhaps a better contribution to their project would be to define requirements in the form of RSpec specifications (since Ruby is in use) and allow the engineering team to satisfy them as they determine appropriate.

I have seen product/project managers attempt to "contribute" to a development effort much like what was described. Usually there is a power dynamic such that engineers cannot overtly tell the manager(s), "you define the 'what' and we will define the 'how'." Instead, something like the PR flow described is grudgingly accepted and then worked around.

▲ marcus_holmes 4 days ago | parent [-]

I'm the person you replied to. I've been developing software for >30 years now. In this case I have domain knowledge, architecture knowledge, experience with the type of systems we're building, but not the language (it's an odd situation). I'm using an LLM to avoid the weeks/months of getting up to speed with Ruby myself, and it appears to be working.

To address your comments about PRs: without the LLM I would be submitting shitty PRs with lots of basic Ruby mistakes. With the LLM I am submitting PRs that are on a par with everyone else's PRs (Ruby has many ways of doing the same thing, so most suggested changes to my PRs are the usual "or you could do it this way and that might be more elegant" discussions). It's not that the rest of the team are picking up my slack, it's actually better this way.

I was a bit sceptical when I started, and like you I assumed that I would end up having to learn Ruby, but in fact it's working well.

▲ AdieuToLogic 3 days ago | parent [-]

> I'm the person you replied to. I've been developing software for >30 years now.

As a s/w engineer with 30+ years of experience, I assume you agree that in order to become proficient in a programming language one must go through the process of learning its syntax and idioms. Yet when you say:

  I'm using an LLM to avoid the weeks/months of getting up
  to speed with Ruby myself, and it appears to be working.

This contradicts my understanding of what you originally stated:

  ... I don't need to learn Ruby to write acceptable-level code [0]

  [0] acceptable-level as defined by the rest of the team

Regarding:

  To address your comments about PRs: without the LLM I
  would be submitting shitty PRs with lots of basic Ruby
  mistakes.

IMHO, this is how s/w engineers learn quickest assuming an environment which supports an open learning process. There are no shortcuts to achieving understanding.

Maybe we just have very different opinions on the learning process and/or maybe I lack the context required to understand your situation. In any event, best of luck in your endeavours.

EDIT:

For some reason I cannot reply to your reply to this message in order to share this resource:

  Why’s (Poignant) Guide to Ruby[0]

I found it a very entertaining read and one of the best language tutorials I have ever found. Hopefully you find it as useful as well.

0 - https://poignant.guide/book/chapter-1.html

▲ marcus_holmes 3 days ago | parent [-]

Thanks, yeah, it's interesting. We're not through the whole project, so it may still mess up ;) But so far so good.

I think the key point here is that I'm not trying to learn Ruby. We're trying to get a single project done in Ruby. I'm the best person to do the project, Ruby is the best language to do it in, but I don't know Ruby.

If I was trying to learn Ruby, this is not the way I'd do it, and I'd go up the learning curve as normal, writing all those shitty PRs and making all the mistakes as normal. As you say, there are no shortcuts to achieving understanding.

	▲	AdieuToLogic 3 days ago \| parent [-]
		And the plot thickens... :-) Now I can reply to your message (can't say why I couldn't before, so moving on). Below is the added content in the event you were unaware of the previous message edit. In addition are three other resource links which may be beneficial to your project. The last one, nokogiri[3], is least likely to be applicable in general but is simply too cool to omit. `Why’s (Poignant) Guide to Ruby[0]` I found it a very entertaining read and one of the best language tutorials I have ever found. Hopefully you find it as useful as well. 0 - https://poignant.guide/book/chapter-1.html 1 - https://www.rubyguides.com/2018/07/rspec-tutorial/ 2 - https://github.com/cucumber/cucumber-ruby 3 - https://nokogiri.org/

▲ cyphar 5 days ago | parent | prev [-]

Code reviews (especially internal ones) generally assume that the person writing the original code has an idea of what they are doing and are designed to catch mistakes that humans might make. Just because they probably work to improve codebases with human submissions doesn't mean that they are good enough filter for LLM-generated code that the submitter doesn't sufficiently understand and has submitted without their own review. Same goes for CI and testing.

This reminds of some of the comments made by reviewers during the infamous Schön scientific fraud case. The scientific review process is designed to catch mistakes and honest flaws in research. It is not designed to catch fraud, and the evidence shows that it is bad at it.

Another applicable example would be the bad patches fiasco with the Linux kernel. (And there is going to be a session at the upcoming maintainers' summit about LLM-generated kernel patches.)