[jbeninger]

I've been through a few cycles of using LLMs and my current usage does scratch the itch. It doesn't feel like I've lost anything. The trick is I'm still programming. I name classes and functions. I define the directory structure. I define the algorithms. By the time I'm prompting an LLM I'm describing how the code will look and it becomes a supercharged autocomplete.

When I go overboard and just tell it "now I want a form that does X", it ends up frustrating, low-quality, and takes as long to fix as if I'd just done it myself.

YMMV, but from what I've seen all the "ai made my whole app" hype isn't trustworthy and is written by people who don't actually know what problems have been introduced until it's too late. Traditional coding practices still reign supreme. We just have a free pair of extra eyes.

[akdev1l]

I also use AI to give me small examples and snippets, this way it works okay for me

However this still takes away from me in the sense that working with people who are using AI to output garbage frustrates me and still negatively impacts the whole craft for me

[saghm]

Having bad coworkers who write sloppy code isn't a new problem, and it's always been a social problem rather than a technical one. There was probably a lot less garbage code back when it all only ran on mainframes because fewer people having access meant that only the best would get the chance, but I still think that opening that up has been a net benefit for the craft as a whole.

[akdev1l]

Before there was some understanding that at least they wrote and understood their own garbage code

Now it is not true. Someone can spend a few minutes generating a non-sense change and push for review. I will have to spend a non-trivial amount of time to even know it’s non-sense.

This problem is already impacting projects like curl who just recently closed their bug bounty because of low-effort AI generated PRs

[saghm]

> Before there was some understanding that at least they wrote and understood their own garbage code

> Now it is not true. Someone can spend a few minutes generating a non-sense change and push for review. I will have to spend a non-trivial amount of time to even know it’s non-sense.

The problem sounds basically the same to me honestly. If someone submits code that I can't understand and asks me to review it, the onus on them to explain it. In the previous case, maybe they could, but if they can't now, the review is blocked on them figuring out how to deal with that. If that's not what's happening, it sounds more like an process or organizational problem that wouldn't be possible to fix with the presence or absence of tooling.

> This problem is already impacting projects like curl who just recently closed their bug bounty because of low-effort AI generated PRs

External contributions are a bit of a different problem IMO. I'd argue that open source maintainers have never had any obligation to accept or review external PRs though. Low effort PRs can be closed immediately with no explanation, and that's fine. It's also totally possible and acceptable to limit PRs to only people explicitly listed as contributors. I've even seen projects hosted on their own git infrastructure that don't allow signing up through the web UI so that you can only view everything in the browser (and of course clone the repo, which already isn't something that requires credentials for public git servers).

I guess my overall point is that the changes are more social than technical, and that this isn't the first time that there was a large social shift in how development worked (and likely won't be the last one either). I think viewing it through the lens of "before good, after bad" is reductive because of how it implies that the current changes are so large that everything else beforehand was similar enough to gloss over what had been changing over time already. I'm not convinced that the differences in how programming was achieved socially and technically between 43 years ago (when the author says they started programming) and the dawn of LLM coding assistants were obviously smaller than the new changes that having AI coding tools have introduced, but that isn't reflected by the level of cynicism in most of these discussions.

[akdev1l]

You can’t really claim any PR is “low-effort” without actually reading and digesting the thing

Yes in the past you could check “oh this doesn’t have back trace or any steps to reproduce, close with won’t fix”

Now you cannot do that, the “low-effort” could be a 500+ lines code change with accompanying documentation and a 300 lines in prose describing the “problem” alongside with “backtraces” showing the issue

Except, the fix is non-sense but you have to read 500+ lines too know that. The documentation doesn’t match the changes but you have to read it to know that. The backtraces literally contain made up functions but once again you need to look closely to verify.

And if the thing isn’t immediately obvious to be AI generated then you’ll end up asking questions which will get forwarded to some AI and end up playing broken telephone.

All of this literally happened to curl in different issues.

[abustamam]

I see comments like this a lot. In fact, I've run into it in my own side projects that I work on by myself -- what is this slop and how do i fix it? I only have myself to blame.

I can't speak to open source orgs like curl, but at least at the office, the company should invest time in educating engineers on how to use AI in a way that doesn't waste everyone's time. It could be introducing domain-specific skills, rules that ensure TDD is followed, ADRs are generated, work logs, etc.

I found that when I started implementing workflows like this, slop was less and if anyone wanted to know "why did we do it like X" then we can point to the ADR and show what assumptions were made. If an assumption was fundamentally wrong, we can tell the agent to fix the assumption and fix the issue (and of course leave a paper trail).

Engineers who waste other engineers' time reviewing slop PRs should just be fired. AI is no excuse to start producing bad code. The engineer should still be responsible for the code they ship.

[saghm]

> Engineers who waste other engineers' time reviewing slop PRs should just be fired. AI is no excuse to start producing bad code. The engineer should still be responsible for the code they ship.

Yeah, this is the unfortunate truth about what's going on here in my opinion. The underlying problem is that some workplaces just have bad culture or processes that don't do enough to prevent (or even actively encourage) being a bad teammate. AI isn't going to solve that, but it's also not really the cause, and at the end of the day, you're going to have problem at a place like that regardless of whether AI is being used or not.

[abustamam]

Agreed! I think AI just accelerates existing processes. If existing processes suck, then you'll just get sucky code faster.

[jbeninger]

Hah. I don't work with (coding) people, so thankfully I don't have that problem

[cstever]

Serious question: so what then is the value of using an LLM? Just autocomplete? So you can use natural language? I'm seriously asking. My experience has been frustrating. Had the whole thing designed, the LLM gave me diagrams and code samples, had to tell it 3 times to go ahead and write the files, had to convince it that the files didn't exist so it would actually write them. Then when I went to run it, errors ... in the build file ... the one place there should not have been errors. And it couldn't fix those.

[saghm]

The value is pretty similar to autocomplete in that sometimes it's more efficient than manually typing everything out. Sometimes the time it takes try select the right thing the complete would take longer to type manually, and you do it that way instead, and sometimes what you want isn't even going to be something you can autocomplete at all so you do it manually because of that.

Like autocomplete, it's going to work best if you already know what the end state should be and are just using it as a quicker way of getting there. If you don't already know what you're trying to complete, you might get lucky by just tabbing through to see if you find the right result, or you might spend a bunch of time only to find out that what you wanted isn't coming up for what you've typed/prompted and you're back to needing to figure out how to proceed.

[jbeninger]

I mean, it's not actually autocomplete. But it serves the same role. I know approximately what I want to type, maybe some of the details like argument-order are a bit foggy. When I see the code I recognize it as my own and don't have too much trouble reading it.

But I use LLMs one level higher than autocomplete, at the level of an entire file. My prompts tend to look like "We need a new class to store user pets. Base it on the `person` class but remove Job and add Species. For now, Species is an enum of CAT,DOG,FISH, but we'll probably turn that into a separate table later. Validate the name is just a single word, and indicate that constraint when rendering it. Read Person.js, CODE_CONVENTIONS.md, and DATA_STRUCTURES.md before starting. When complete, read REFACTOR.md"

With the inclusion of code examples and conventions, the agent produces something pretty close to what I'd write myself, particularly when dealing with boilerplate Data or UI structures. Things that share common structure or design philosophy, but not common enough to refactor meaningfully.

I still have to read it through and understand it as if I'd written it myself, but the LLM saves a lot of typing and acts as a second pair of eyes. Codex currently is very defensive. I have to remove some unnecessary guardrails, but it will protect against rare issues I might not have noticed on my first pass.