171–180 of 699 posts
> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. It's even worse than that: non -junior devs are doing it as well.
[Edit] man, people dont get /s unless its explicit
Whole article seems very much all llm generated Edit: I'm an idiot ignore me.
If we are accepting LLM generated code, we should accept LLM generated content as long as it is "proof read" :)
Earlier quoted context omitted.
Code review is an unfunded mandate. It is something the company demands while not really doing anything make sure people get rewarded for doing it.
> while not really doing anything make sure people get rewarded for doing it. I don’t know about you, but I get paychecks twice a month for doing things included in my job description.
Now we have nightly builds that nobody checks the result of and we’re finding out about bugs weeks later. Big company btw
Earlier quoted context omitted.
[flagged]
This sounds like the exact kind of profound pseudo-enlightenment that one gets from psychedelics. Of course, it's all electrons in the end. Trying to create a secure, reliable and scalable system that enables many people to work on one code base, share their code around with others and at the end of the day coordinate this dance of electrons across multiple computers, that's where all of these 'useless' layers of abs…
I know exactly what those layers of abstraction are used for. Why so many? Jobs making layers of abstraction.
But all of them are dev friendly means of modeling memory states for the CPU to watch and transform just so. They can all be compressed into a generic and generalized set of mathematical functions ridding ourselves of the various parser rules to manage each bespoke syntax inherent to each DSL, layers of framework.
Earlier quoted context omitted.
Code review is an unfunded mandate. It is something the company demands while not really doing anything make sure people get rewarded for doing it.
> while not really doing anything make sure people get rewarded for doing it. I don’t know about you, but I get paychecks twice a month for doing things included in my job description.
> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. It's even worse than that: non -junior devs are doing it as well.
In the company I’m at this is beginning to happen. PM’s want to “prototype” new features and expect the engineers to finish up the work. With the expectation that it ‘just needs some polishing’. What would be your recommendation on how to handle this constructively? Flat out rejecting LLM as a prototyping tool is not an option.
Perhaps off-topic, but: "Testing doesn't show the absence of errors, it shows the presence of errors" Willison says we need to submit code we have proven to work but then argues for empirical testing, not actual correctness proofs.
That's not something I've seen or been able to achieve in most of my professional work.
> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. It's even worse than that: non -junior devs are doing it as well.
>It's even worse than that: non-junior devs are doing it as well. This might be unpopular, but that is seeming more like an opportunity if we want to continue allowing AI to generate code. One of the annoying things engineers have to deal with is stopping whatever they're doing and doing a review. Obviously this gets worse if more total code is being produced. We could eliminate that interruption by having someone do…
I would have thought that reviewing PRs and doing it well is in the job description. You latter mention "someone" a few times - who that someone might be?
"Slow the f*ck down." - Oliver Reichenstein [1] This only happens because the software industry has fallen into the Religion of Speed . I see it constantly: justified corner-cutting, rushing shit out the door, and always loading up another feature/project/whatever with absolutely zero self-awareness. AI is just an amplifier for bad behavior that was already causing chaos. What's not being said here but should be: dis…
Earlier quoted context omitted.
100%. There's no difference at all in my mind between an AI-assisted PR and a regular PR: in both cases they should include proof that the change works and that the author has put the work in to test it.
At the last company I worked at (Large popular tech company) it took an act of the CTO to get engineers to simply attach a JIRA Ticket to the PR they were working on so we could track it for tax purposes. The Devs went in kicking and screaming. As an SRE it seemed like for SDEs, writing a description of the change, explaining the problem the code is solving, testing methodology, etc is harder than actually coding. Ir…
One can also point QA or consultants to a ticket for documentation purposes or timeline details.