this post was submitted on 09 Aug 2025

40 points (100.0% liked)

technology

24063 readers

257 users here now

On the road to fully automated luxury gay space communism.

Spreading Linux propaganda since 2020

Rules:

1. Obviously abide by the sitewide code of conduct. Bigotry will be met with an immediate ban
2. This community is about technology. Offtopic is permitted as long as it is kept in the comment sections
3. Although this is not /c/libre, FOSS related posting is tolerated, and even welcome in the case of effort posts
4. We believe technology should be liberating. As such, avoid promoting proprietary and/or bourgeois technology
5. Explanatory posts to correct the potential mistakes a comrade made in a post of their own are allowed, as long as they remain respectful
6. No crypto (Bitcoin, NFT, etc.) speculation, unless it is purely informative and not too cringe
7. Absolutely no tech bro shit. If you have a good opinion of Silicon Valley billionaires please manifest yourself so we can ban you.

founded 5 years ago

MODERATORS

context@hexbear.net

SexUnderSocialism@hexbear.net

gaycomputeruser@hexbear.net

Wakmrow@hexbear.net

The current state of LLM-driven development (blog.tolki.dev)

submitted 2 months ago by yogthos@lemmygrad.ml to c/technology@hexbear.net

15 comments fedilink hide all child comments

all 21 comments

sorted by: hot top controversial new old

[+] semioticbreakdown@hexbear.net 31 points 2 months ago* (last edited 1 month ago) (2 children)

[deleted]

[–] yogthos@lemmygrad.ml 15 points 2 months ago (1 children)

I expect that we'll see tooling and languages adapt overtime and we'll be developing code differently.

For example, programming languages might start shifting in the direction of contracts. You specify the signature for the function and the agents figures out how to meet the spec. You could also specify parameters like computational complexity and memory usage. It would be akin to genetic algorithm approach where the agent could converge on a solution over time.

If that’s the direction things will be moving in, then current skills could be akin to being able to write assembly by hand. Useful in some niche situations, but not necessary vast majority of the time.

The way code is structured will likely shift towards small composable components. As long as the code meets the spec, it doesn't necessarily matter what quality of the functions is internally. You can treat them as black boxes as long as they’re doing what’s expected. This is how we work with libraries right now. Nobody audits all the code in a library they include, you just look at the signatures and call the API level functions.

Incidentally, I’m noticing that functional style seems to work really well with LLMs. Having an assembly line of pure functions naturally breaks up a problem into small building blocks that you can reason about in isolation. It’s kind of like putting Lego blocks together. The advantage over approaches like microservies here is that you don’t have to deal with the complexity of orchestration and communication between the services.

[+] semioticbreakdown@hexbear.net 22 points 2 months ago* (last edited 1 month ago) (2 children)

[deleted]

[–] MizuTama@hexbear.net 16 points 2 months ago (1 children)

At every level of abstraction, someone did due diligence to ensure that the processes that they wrote worked

We know very different programmers lol

[–] yogthos@lemmygrad.ml 11 points 2 months ago (1 children)

I mean there's plenty of shit code written by humans, and many libraries are of very poor quality. This is especially true in languages like Js. The assertion that somebody used diligence at every level is not true. Even when we do code reviews we often miss really basic things. And the way we get around that is by creating test harnesses, using tools like type systems and linters. We don't just trust that the code works because a human wrote it and looked at it.

Whether someone made it or not is not really that important if you have a formal contract. You specify what the inputs and outputs are, and as long as the code meets the contract you know what it's doing. That's basically been the whole promise with static typing. Whether a human writes this code or a model doesn't really matter.

Also worth noting that people used these exact types of arguments when programming languages started being used. People claimed that you had to write assembly by hand so you know what the code is doing, and that you can't trust the compiler, and so on. Then these arguments were made regarding GC saying that you have to manage memory by hand and that GC is too unpredictable, and etc. We've already been here many times before.

If programmers no longer produce anything really new, because they no longer understand how to, it would just be feeding back into itself, creating output based on LLM output.

This isn't what I suggested at all. What I said that the programmer would focus on the specification and understanding what the code is doing semantically. The LLM handles the implementation details of the code with the human focusing on what the code is doing while the LLM focuses on how it does it.

[+] semioticbreakdown@hexbear.net 23 points 2 months ago* (last edited 1 month ago) (1 children)

[deleted]

[–] yogthos@lemmygrad.ml 4 points 2 months ago (1 children)

Again, you use exact same tools and processes to evaluate software whether it's written by a human or a model. The reality is that people make mistakes all the time, people write code that's as bad as any LLM. We have developed practices to evaluate code and to catch problems. You're acting as if human written code doesn't already have all these same problems that we deal with on daily basis.

Yes, every programming abstraction comes with trade offs. Yet, it's pretty clear that most people prefer the trade offs that allow them to write code that's more declarative. That said, using approaches like genetic algorithms coupled with agents could actually allow automating a lot of optimization that we don't bother doing because it's currently too tedious.

but the how is relevant to the what, and intimately tied to the learning process of good programming as a praxis.

It's relevant because the key skill is being able to understand the problem and then understand how to represent it formally. This is the skill that's needed whether you have agents fill in the blanks or you do it yourself. There's a reason why you do a lot of math work and algorithms on paper in university (or at least I did back in my program). The focus was on understanding how algorithms work conceptually and writing pseudo code. The specific language used to implement the code was never the focus.

What you're talking about is a specific set of skills degrading because they're becoming automated. This is no different from people losing skills like writing assembly by hand because the compiler can do it now.

There's always a moral panic every time new technology emerges that automates something that displaces a lot of skills people invested a lot of time into. And the sky never comes crashing down. We end up making some trade offs, we settle on practices that work, and the world moves on.

[+] semioticbreakdown@hexbear.net 9 points 2 months ago* (last edited 1 month ago) (1 children)

[deleted]

[–] yogthos@lemmygrad.ml 2 points 2 months ago

I don't see how that follows. You appear to be conflating the skill of learning the specific syntax of a language with the skill of designing algorithms and writing contracts. These are two separate things. A developer will simply do work that's more akin to what a mathematician or a physicist does.

LLMs don't allow the programmer to bypass every stage of the learning process in both an academic and professional capacity. That's simply a false statement. You cannot create quality software with the current generation of LLMs without understanding how to structure code, how algorithms work, and so on. These are absolutely necessary skills to use these tools effectively, and they will continue to be needed.

Its proliferation is already having significant and serious effects, so no I don’t think it’s a moral panic.

Again, this was said many times before when development became easier. What's really happening is that the barrier is being lowered, and a lot more people are now able to produce code, many of whom simply would've been shut out of this field before.

I think LLM technology itself is fundamentally flawed and I think believing formal methods and genetic algorithms will prevent its issues in real-world applications is a recipe for a disaster, or at least, even crappier software than most of what we get today.

I see no basis for this assertion myself, but I guess we'll just wait and see.

Maybe history will prove me wrong, but I see zero reason to trust LLMs in basically any capacity.

Nobody is suggesting trusting LLMs here. In fact, I've repeatedly pointed out that trust shouldn't be part of the equation with any kind of code whether it's written by a human or a machine. We have proven techniques for verifying that the code does what was intended, and that's how we write professional software.

Theres going to be another AI winter and revolution before AI programming technology is used for anything but sludgeware and vibe coded apps that leak all their userdata.

Even if this technology stopped improving today, which there is very reason to expect, it is already a huge quality of life improvement for software development. There are plenty of legitimate real world use cases for this tech already, and it's not going away.

[–] aanes_appreciator@hexbear.net 2 points 2 months ago (1 children)

do we think it could be self-resolving? vibe coders and cheats cant get last the PoC stage of an app, so they'll get into jobs and perform like shit and leave, or profs will just make the tasks harder or more novel to limit the abilities of AI.

Sorts like how Photoshop made it easy for anyone to get the basics of graphic design down but the actual fundamentals are harder to replicate from an hour's worth of fiddling with your edit of trans gritty getting top surgery

[–] CommunistCuddlefish@hexbear.net 29 points 2 months ago (1 children)

In addition to churning out unreliable low quality code, this sounds like it takes any of the fun out of programming.

And,

Using LLMs did make me a worse software developer, as I didn’t spend as much time reading docs and thinking as before. There’s a reason why most managers suck at writing code.

LLM agents often add unnecessary complexity in their implementations of features, they create a lot of code duplication, and make you a worse developer.

Every time I tried using an LLM for core features of applications I develop at work, the implementations were questionable and I spent at least as much time rewriting the code than I would have spent writing it from scratch.

Regarding frontend, agents really struggled at making good, maintainable, DRY software. All models used magic numbers everywhere even when asked not to, keyboard interaction was poorly implemented, and some widgets took 5+ prompts to get right.

It can be helpful or useful in limited cases but it also needs to go.

[–] aanes_appreciator@hexbear.net 4 points 2 months ago (1 children)

If you wanna churn out loads of poor quality code with an AI agent, awesome. Remember, though: so can your manager, your product owner, or your boss.

What use are you if you produce the same slop as them but with a salary and workers rights (if any)?

The developers who will survive the AI slop age will be the ones who write high quality code with strong fundamentals within architecture. You will have a unique value above the AI that otherwise spaffs out code no one understands.

The ones who won't survive are the ones who think they've found a hack to do their job in 2 hours before logging off, because everyone knows about it. You're not some kid who followed the "automate the boring stuff with python" anymore, you're one of billions who all know you can type a prompt and get something that sorta looks correct.

[–] CommunistCuddlefish@hexbear.net 1 points 2 months ago

Good take

[–] tricerotops@hexbear.net 6 points 2 months ago* (last edited 2 months ago) (2 children)

I don't think this is a very good or useful article because it is clearly someone who went into this "experiment" with a negative perspective on the whole thing and didn't try very hard to make it work. Vibe coding as it stands today is, at best, a coin flip as to whether you can make something coherent and the chances of success rapidly diminish if the project can't fit into about 50% of the context window. There are things you can do, and probably these things will be incorporated into tools in the future, that will improve your chances of achieving a good outcome. But I disagree with the author's first statement that using LLMs in a coding workflow is trivial, because it is not. And the fact that they had a bad time proves that it is not. My perspective as someone who has a couple of decades of coding under their belt is that this technology can actually work but it's a lot harder than anybody gives it credit for and there's a major risk that LLMs are too unprofitable to continue to exist as tools in a few years.

I agree though with their last point - "don't feel pressured to use these" - for sure. I think that is a healthy approach. Nobody knows how to use them properly yet so you won't lose anything by sitting on the sidelines. And in fact, like I said, it's completely possible that none of this will even be a thing in 5 years because it's just too goddamn expensive.

[–] Le_Wokisme@hexbear.net 9 points 2 months ago (1 children)

I agree though with their last point - "don't feel pressured to use these" - for sure. I think that is a healthy approach. Nobody knows how to use them properly yet so you won't lose anything by sitting on the sidelines. And in fact, like I said, it's completely possible that none of this will even be a thing in 5 years because it's just too goddamn expensive.

that's fine for indies but i have friends at [redacted] and [redacted] and the have management on their asses to be using the shitty "ai" tools even though it literally is worse and takes longer.

[–] tricerotops@hexbear.net 4 points 2 months ago (1 children)

Then their management doesn't really understand what's going on. In that case either they can decide to learn to use them a little better or they can set up two of them to have a conversation in the background all day every day to fudge the stats.

[–] Le_Wokisme@hexbear.net 9 points 2 months ago

Then their management doesn't really understand what's going on

many such cases

[–] yogthos@lemmygrad.ml 7 points 2 months ago

I thought it was overall a fairly sober take. I agree that becoming effective at using these tools actually does take some time. People often try them with an existing bias that these tools won't work well, and then when they don't see these tools working magic they claim it as evidence that they don't work. Yet, like with any tool, you have to take the time to develop intuition for cases it works well in, when it gets into trouble, how to prompt it, etc.