Mastodawn

Arne Brasseur 3d ago

It's clear that AI assisted coding is dividing developers (welcome to the culture wars!). I've seen a few blog posts now that talk about how some people just "love the craft", "delight in making something just right, like knitting", etc, as opposed to people who just "want to make it work". As if that explains the divide.

How about this, some people resent the notion of being a babysitter to a stochastic token machine, hastening their own cognitive decline. Some people resent paying rent to a handful of US companies, all coming directly out of the TESCREAL human extinction cult, to be able to write software. Some people resent the "worse is better" steady decline of software quality over the past two decades, now supercharged. Some people resent that the hegemonic computing ecosystem is entirely shaped by the logic of venture capital. Some people hate that the digital commons is walled off and sold back to us. Oh and I guess some people also don't like the thought of making coding several orders of magnitude more energy intensive during a climate emergency.

But sure, no, it's really because we mourn the loss of our hobby.

Hans Hübner 3d ago

@plexus In the end, software engineering is about creating solutions to problems other people have. The solutions are not a byproduct, but the primary purpose. To the majority of users, the inner workings and the creation process of software is opaque. The qualities that software exposes on the outside are largely independent of its inner workings.

This means that for most people in the software industry, adapting to the new tooling that makes the creation process more efficient is 1/

Cassandrich 3d ago

@hanshuebner @plexus Did you ever read the toot you replied to before arguing with standard AI propaganda points? 🙄

Hans Hübner 3d ago

@dalias @plexus I'm just a software developer. What I write comes from my personal experience writing software with Claude Code. Do you have any experience you can share? What are your credentials?

Matt Campbell 3d ago

@hanshuebner You are replying to Rich Felker, primary developer of the musl C library for Linux, a shining example of software at a low layer of the stack developed with meticulous attention to quality. True, quality that business people probably don't appreciate, but if software at all layers were developed with this attention to quality, I think users would feel the difference.

@dalias @plexus

Hans Hübner 3d ago

@matt @dalias @plexus Is the reality not that not all software is developed with meticulous attention to quality? In my experience, most software is primarily written with the intent to solve a problem. The engineering challenge is to make it maintainable as requirements evolve. Success is when the software fulfills its purpose.

I love writing beautiful code, but don't expect anyone to pay me for it - not only because beauty is in the eye of the beholder, but also because users don't care.

Cassandrich 3d ago

@hanshuebner @matt @plexus Software written without any concern that it's doing the wrong thing does not "solve any problem" except "how to line venture capitalists' pockets".

Unless it's just being written for fun and not actual deployment to real-world applications, software is responsible for people's safety.

It controls deadly machines like cars and airplanes.It's used to design buildings and bridges. It guards people's communications against abusive partners, stalkers, governments. It controls people's money. It controls who gets need-based benefits. It decides whether people will be wrongly accused of embezzlement and driven to suicide.

Hans Hübner 3d ago

@dalias @matt @plexus In my experience as a software developer, there is no difference between a program written by a human and one written by an LLM. Both can be bad or dangerous, or good, or right. It is just that LLMs are faster at cranking out code.

Matt Campbell 3d ago

@hanshuebner @dalias (Dropping the original author as they already warned you that they're in no mood for your arguments.)

IMO, code is not something to be cranked out en masse. Every detail matters; as such, we should write every line deliberately, with care, as the clearest, most direct expression of our understanding of how to solve the problem, certainly clearer and more precise than a natural-language prompt.

Hans Hübner 3d ago

@matt @dalias "Our understanding" is often incomplete, leading to code that is just a reflection of the process of understanding the task at hand. Code often suffers from that in that the person working on it learned faster than they could or would refactor. The resulting reality is that code, by and large, is messy.

Not everyone is working the same way, but it is certainly true that not everyone is a genius. Thus, bad, human code prevails.

Cassandrich 3d ago

@hanshuebner @matt "Capitalism is already producing bad things so we should just accelerate that" 🙄

Hans Hübner 3d ago

@dalias @matt I live in capitalism as a software developer. I don't get to choose what tools I use, I'm getting paid to do the work. I can change my profession, or I can pick up what I need to know in order to sustain myself. This is me personally.

Then: LLMs create code that is comparable to human written code in that frame of reference. There is better code, but there is also much worse.

Finally: LLMs create shitty prose, shitty images and shitty music. I hate all of that.

Matt Campbell 3d ago

@hanshuebner @dalias If LLMs create shitty prose, images, and music, why is code the exception? Simply because that's the area that we work in and we're afraid of losing our jobs? (I admit I'm not immune to that fear.)

Hans Hübner 3d ago

@matt @dalias Code is different because it has a function that is beyond human reception.

Matt Campbell 3d ago

@hanshuebner @dalias The details still matter though. The same lack of attention to detail that makes LLM prose, images, and music shitty, will come back to bite us, or the people affected by our work, sooner or later, in the form of defects. So I'd rather give each detail the attention it deserves, by writing the code myself, than roll the dice and find out later that some detail in that mass of LLM-extruded code was wrong -- possibly subtly wrong, in a way that's easy to miss in review.

Hans Hübner 3d ago

@matt @dalias You are absolutely right, but here's the thing: Code review also does not prevent subtle bugs from creeping into the code base when humans wrote the code. Review is just one of the tools that ensure software quality.

This is to say that code written by LLMs and humans suffer from similar issues, require similar care and review and can fail in similar ways. There is more LLM code, though, and there are new challenges because scaling with LLMs works differently than with humans.

Matt Campbell 3d ago

@hanshuebner @dalias Isn't it obvious, though, that the risks are higher when you have an LLM generate code statistically from a natural-language prompt, as opposed to writing the code and paying attention to every detail yourself?

Hans Hübner 3d ago

@matt @dalias Statistically, you will have more bugs because you have more software. But also, you can easily create tests, refactor and make executable requirements.

Making good software with LLM support is hard work and takes time. If you look at the stuff that people make with three prompts and then post to LinkedIn, you know what I mean.

A good program requires attention to detail, no matter what the tool does for you.

Matt Campbell 3d ago

@hanshuebner @dalias So then why do it with an LLM as opposed to the hard work of writing the code directly? Is it just to appease capital's irrational demands?

Hans Hübner 3d ago

@matt @dalias You use an LLM because it makes the code writing part take radically less time.

Matt Campbell 3d ago

@hanshuebner @dalias But then you have to spend time putting guardrails in place (e.g. comprehensive tests) to make sure the LLM doesn't do something wrong; using an LLM is rolling the dice, after all. Now, if you believe that one should always put maximal guardrails in place anyway even for human-written code, then I suppose the faster code generation could still be a net gain. But I'm not sure there's one correct answer to how much one should invest in guardrails (tests, types, lints, etc.).

Hans Hübner 3d ago

@matt @dalias In my own anecdotal and personal experience, LLM code gets enough things right to be competitive, but that experience is just a couple of months old. I can say, though, that the systems I created with LLM help very much fulfilled a real purpose, did not break randomly and are maintainable with LLM help.

@hanshuebner @matt @dalias
Would you highlight this map: written by LLM -> maintaned with LLM [tooling] ?
Or, you will maintain such artifact manually?
Also, can another LLM be used for maintenance?

Hans Hübner 2d ago

@mikalai If I create an application program that mostly fulfills end-user requirements, I am less concerned with the inner workings and more with steering the architecture in the right direction. When working on systems that are maintained by humans, I put more emphasis on controlling source level structure.

I rarely see the need to write code myself recently. I still do it for fun, sometimes.

1/

@mikalai LLM coding agents can work on any code base, no matter it was created by the same or a different LLM or by humans.

Someone made the point that they don't want to try LLM assisted coding because they fear that their judgement would be influenced by the experience. I can certainly say that this was the case for me. When I first used an LLM to write me a special purpose, non-trivial tool that I needed and it took just a few minutes to complete, it impressed me thoroughly.

2/2

@hanshuebner
I "can" write in any language. But, in practice, are you bound to initial LLM, thus, vendor, if this wasn't local tooling?

Hans Hübner 1d ago

@mikalai No, not at all. The LLM based tools use their "world knowledge" and agent rules to examine your code base and generate new code based on that and your prompts. It does not matter how the code was initially created.

The fundamental limitation is the context window of the LLM - It cannot just include all of your code, so it needs to find the relevant declarations, schema definitions etc. The tooling is responsible for keeping enough information in the context so it can keep going.