My prophecy is that in 3 years we'll see a complete reversal of this. Using GenAI to code will be the default and we'll see policies that put limits on human/artisan development. Possibly even projects that outright ban non-LLM development.

▲

Viliam1234 3 days ago | parent | next [-]

Why would companies accept AI generated code, it they can generate their own (and review the prompt)?

It's like predicting that when compilers become more popular, accepting binary contributions will become the default.

	▲	rpdillon 2 days ago \| parent [-]
		LLMs are non-deterministic, and compilers are (mostly) deterministic. A good PR with AI is a like a series of dice rolls that you need to get right to get high-quality output. Folks asking for prompts are basically saying "hand me the dice, I'll do all the dice rolls." To which my response is "Why?"

▲

ACCount37 3 days ago | parent | prev | next [-]

At this point, I wouldn't be too surprised if LLMs just get better at "write understandable, maintainable code" than most developers are.

For now, LLMs are still bad at it, but they're already at "competitive with humans" tier of bad. I expect them to get better.

▲

abc42 2 days ago | parent | next [-]

They will get better, and they (the best coding models) are already better than 90% of human developers, even when you don't factor in their much faster speed.

▲

Sindisil 3 days ago | parent | prev | next [-]

You might well end up being right, but if you are, I believe it'll be because "most developers" will have become worse at programming, not because GenAI has become massively better.

▲

realusername 3 days ago | parent | prev [-]

I don't think they ever will on the "maintainable" part until their absolutely atrocious memory gets improved at least tenfold. (and no, the tricks we deployed until now aren't enough)

They already are better than most humans at writing code for sure but even the best SOTA model is worse than your average intern at memorization.

▲

ACCount37 3 days ago | parent [-]

That's the entire point of the "maintainable" part: someone with no "memory" of what was written where and why should be able to walk into the codebase, understand how it works, and be able to make a sensible change to it without setting things on fire.

Someone with "memory" should be able to do the same faster, but having that memory should not be a requirement.

Whether that "someone" is a freshly onboarded mid-level SWE or a mid-tier coding LLM is largely irrelevant.

▲

realusername 3 days ago | parent [-]

Depends what you mean by your comment then, if you want to say that you can direct LLMs to write maintainable code yes sure you can through very strict guardrails, if they can do it themselves, no they can't and need help because of their bad memory.

▲

ACCount37 3 days ago | parent [-]

Why would "memory" be relevant to that? I honestly don't see it be much more relevant to "write maintainable code" than it is to "play chess".

▲

realusername 3 days ago | parent [-]

Have you even onboarded somebody at work? There's a big difference between the newcomer and the dev who's been there for 5 years, even at the same seniority level on paper.

And that difference is in the memory. The LLM can work during 5 years on the codebase and still will be as good as a newcomer.

You can somewhat partially compensate for this bad memory by writing tons of guardrails and tons of extra LLM focused documentation, but it doesn't do everything.

Essentially, it's like talking to somebody who has a permanent memory damage.

	▲	ACCount37 3 days ago \| parent [-]
		That's how it works for humans. And, sure, LLMs are severely human-adjacent. But they aren't human. An LLM can just re-ingest the entire codebase every time it wants to make a change - open it up, find the relevant parts, derive how a well structured, maintainable change should look like from them, then make that change. The way a compiler can just re-ingest the entire codebase every time it wants to make a binary. The intermediates are a cache - a resource optimization, not an outcome optimization. Is it wasteful not to have a cache? Maybe. Can you get away with not having it? Yes. And, the more maintainable a codebase is, the easier it is for an LLM to "re-ingest" it from scratch. Or for a human to get onboarded. There's some overlap there.

▲

kdavis 3 days ago | parent | prev | next [-]

I don't know the timeline, but I generally agree.

I think history agrees too, i.e. machine code > assembly language > high-level programming language > prompts.

	▲	encyclopedism 3 days ago \| parent [-]
		A more reasonable extension is: machine code > assembly language > high-level programming language > what ever works for business i.e. prompts/ai/LLM If it works for business then increasingly that's all that will count. Clean code, static vs dynamic any the other principles or debates will give way as long as AI produces results. The economic ends justify the means.

▲

htltzp 3 days ago | parent | prev [-]

Yes, I'm sure that insecure slop projects like Artifactory will ban human contributions.

	▲	wannabe44 2 days ago \| parent [-]
		I would be interested to hear the lore.