The only viewpoint I really agree with in this article is the "use it or lose it" mentality. Skills are developed and maintained by practicing them, but if all the author really wants to do is write code, then LLMs are literally an answer to their prayers!

You can enable virtually free test driven development. Write the test names down and let the LLM implement them for you. You save 50% of your time and you get to go to town on implementation and or optimizations.

You can have the LLM take the non-tech-counterparts description of a bug and have it point you at precise lines of code to investigate rather than grepping around a codebase you might not know well.

You can onboard to new languages, frameworks, repositories extremely fast by having a partner (the LLM) explain implementation patterns and approaches on demand! You don't even need to talk to another human being! Get your questions answered in seconds and start coding!

You can rapidly prototype. You can get immediate code reviews. You can rubber duck. You can visualize business/logic flows and code branching to better understand existing implementations. You can even have the LLM write an implementation plan for you then write the code yourself!

If you cant find a way to write more code with LLMs, its either an imagination or skill issue.

> You can enable virtually free test driven development. Write the test names down and let the LLM implement them for you. You save 50% of your time and you get to go to town on implementation and or optimizations.

That's assuming that it writes good tests, and that you don't care to take the time to verify the tests it wrote, no?

I do find LLMs useful for scaffolding this stuff, but yeah, good test writing still seems to require a lot of hand-holding. I don't mind. I'm happy with my tests and they get written faster. Hand-holding and verifying is still faster than how I used to do it, and the LLMs admittedly capture more cases than I did without them. They will try to create test cases that make no sense too, but it's worth having to delete if it means it also comes up with test cases that I didn't.

I feel like we are still using it when cleaning up the code that we often get I guess.

No. There's a difference between writing code, and getting code written. LLMs are the second.

all of this sounds awful

The whole point of my post is that you get to pick and choose what parts this magical software automates for you. Based on your response, it's an imagination issue for you.

I can imagine doing it and I have in fact used it to automate things like tests. This usually leads to me having to rewrite the tests and spending more time on them than I otherwise would have. Or delete tests that test trivial functionality, or add tests for x even when I specifically mentioned it in my prompt.

Being able to imagine something doesn't mean I have to like it.

> or add tests for x even when I specifically mentioned it in my prompt

> Write the test names down and let the LLM implement them for you.

This sort of reinforces the idea I (and I believe others) have that people mostly talk past each other on this topic. It seems like there might be some other difference in understanding and/or practice when it comes to using these tools effectively. This seems to be a common issue to notice once one starts noticing it.

LLM’s can write documentation well, too.

>Reviewing is worse than writing

I think the reason this discussion keeps coming up is that the people who are getting a lot out of these tools are people who are, at best, the software-equivalent of assembly-line workers. If something can be easily understood by passively reading it then it probably isn't complicated or novel and therefore it's not surprising a pseudorandom bullshit generator can do it for you; all it lacks is a unit testing system which can verify that its interpretation of the problem-statement matches the interpretation which would be most obvious to a human and that is evidently not a solved problem thus far.

If the hardest part of your job is understanding code written by other people and even code written by yourself in the distant past, then LLMs are of literal use because the problem they solve was never a significant bottleneck and in fact their "solution" only serves to pump a higher volume of fluid through the neck of the proverbial bottle.

It's the difference between reading somebody's paper in a mathematical journal to understand how they came to the conclusion they are presenting, and merely using the identity they have proven on faith. If all that mattered was to perform some calculation based on their work then its clear which approach will get more work done in less time but if you don't take it for granted that everything in the journal is correct or if you want to be able to further develop ideas based upon their proof then you have to spend a few days or even weeks trying to understand how each step leads to its successor.

It's also why i hate the old adage about not reinventing wheels, it promotes ignorance by asserting that education itself is ignorance.

I’m glad to hear someone say that. I’ve been wrestling for weeks with the idea of reinventing a particular wheel in my profession, for a personal coding project. The problem is that my implementation can’t ever be as complete or as useful as the existing solutions because it’s way too much for one person to accomplish in a reasonable amount of time.

But, I like it, I’ve reinvented many wheels in my work and it’s benefited me greatly. So I will reinvent this particular wheel as well…

We can't uninvent LLMs. They're here already and the best course of action for everyone is to learn to live with them.

That being said I noticed that the more opinionated a language/framework/library is, the worse off one is using LLMs.

I was surprised by this, but then I put a particularly fishy line into GitHub's search box. What I saw were piles upon piles of bad practices and incorrect usages. There's a lot of bad code there and LLMs are learning from it.

If you're working on something where the cost of bugs is high and they're tricky to detect, LLM generated code may not be a winning strategy if you're already a skilled programmer. However, LLMs are great for code review in these circumstances - there is a class of bugs that are hard to spot if you're the author.

As a simple example, accidentally inverting feature flag logic will not cause tests to fail if the new behavior you're guarding does not actually break existing tests. I and very senior developers I know have occasionally made this mistake and the "thinking" models are very good at catching issues like this, especially when prompted with a list of error categories to look for. Writing an LLM prompt for an issue class is much easier than a compiler plugin or static analysis pass, and in many cases works better because it can infer intent from comments and symbol names. False positives on issues can be annoying but aren't risky, and also can be a useful signal that the code is not written in a clear way.

“a new paradigm for software development that you must learn or be left behind” that’s a completely inaccurate statement. Nobody is saying that you will be “left behind”. It certainly is a new paradigm but it doesn’t mean the old way of doing things won’t continue to exist. Just like there are still some problems that require code to be written in C or even assembly. Just like there are hand-made goods. The size of the opportunity is a whole different story.

I disagree - a lot of people with positions of power are unfortunately saying the “will be left behind “ bit

not all of course as there’ll be morons always but a lot of people who are saying “will be left behind” see an amazing tool which in hands of the right people is a great multiplier…

I think you wrong the problem is not LLM , the problem is you .

What I don't understand in all that noise from the LLM critics - they keep talking about how LLMs are so horrendously bad at writing code as if that's the only thing we're trying to use them for. As if they're not even genuine programmers, working on real projects, touching code every day.

Software crafting is so much more than merely writing code. There's a significant amount of reading code that goes into it. Code written by you. Code written by someone else. Someone else's code that you butchered with your edits, your own code butchered by someone else, and everything intertwined in between. Code that can't easily be explained by looking at it - sometimes you have to find relevant PRs, tickets, documentation, related online communication, some loosely-related code sitting someplace else, etc.

LLMs absolutely can help you read code, just as they are very capable of helping someone study a book or an academic paper. Denying that fact simply is ignorance. Of course, LLMs are absolutely capable of leading you in the wrong direction, confusing you, and giving you incorrect facts, even when you're studying text in plain English, just like it's possible to end up at the bottom of a lake when driving a car. Everyone needs to exercise caution and "know what the fuck they're doing" when using a model. But calling LLMs "bullshit generators" and "magic 8 balls" is so stupid. Sure, if you use it to perform bullshit stuff, it will generate nothing but bullshit.

You're free not to. Time will tell who's right

I can’t take this article seriously, and neither should you. Being anti AI/anti LLM is solidly in the Luddite camp; there’s really no more debates to be had. Every serious inquiry shows productivity gains by using ai.

It’s anyone’s prerogative to continue to advocate for the horse and buggy over the automobile, but most people won’t bother to take the discussion seriously.

>Being anti AI/anti LLM is solidly in the Luddite camp; there’s really no more debates to be had. Every serious inquiry shows productivity gains by using ai.

These two sentences appear to be at odds with one another.

The data showed llms are better. This put debate to rest. Now we are post-debate.

What data are you talking about? Why do you value it above the data showing the opposite?

It's superior data because it supports his expectations. His expectations are right because they are based on superior data. Checkmate Luddites.

Meanwhile, you have furnished zero data that supports your claims. Ho hum.

Your initial statement is that you are not open to debate so i don't see what the point would be. Furthermore you defined "serious inquiries" as synonymous with your own preconceived ideas so by definition I cannot refute anything you say using a "serious inquiry". Do not interpret this as some sort of complement or concession but it is not possible to argue against you.

Even putting the sophistry aside your argument is incomplete because you never defined what "productivity" means in this context or how it can be quantified. I would never dispute that a pseudo-random bullshit generator can shit out javascript faster than any human, but that's not necessarily productive.

give me one seriously peer reviewed study please with proper controls

i wait

Go ahead and move the goalposts now... This took about 2 minutes of research to support the conclusions I know to be true. You can waste time as long as you choose in academia attempting to prove any point, while normal people make real contributions using LLMs.

### An Empirical Evaluation of Using Large Language Models for Automated Unit Test Generation We evaluate TESTPILOT using OpenAI’s gpt3.5-turbo LLM on 25 npm packages with a total of 1,684 API functions. The generated tests achieve a median statement coverage of 70.2% and branch coverage of 52.8%. In contrast, the state-of-the feedback-directed JavaScript test generation technique, Nessie, achieves only 51.3% statement coverage and 25.6% branch coverage. - *Link:* [An Empirical Evaluation of Using Large Language Models for Automated Unit Test Generation (arXiv)](https://arxiv.org/abs/2302.06527)

---

### Field Experiment – CodeFuse (12-week deployment) - Productivity (measured by the number of lines of code produced) increased by 55% for the group using the LLM. Approximately one third of this increase was directly attributable to code generated by the LLM. - *Link:* [CodeFuse: Generative AI for Code Productivity in the Workplace (BIS Working Paper 1208)](https://www.bis.org/publ/work1208.htm)

> This took about 2 minutes of research to support the conclusions I know to be true

This is a terrible way to do research!

The point is that the information is readily available, and rather than actually adding to the discussion they chose to crow “source?”. It’s very lame.

“ Productivity (measured by the number of lines of code produced) increased”

The LLM’s better have written more code, they’re a text generation machine!

In what world does this study prove that the LLM actually accomplished anything useful?

Nothing about this is moving goalposts - you and/or the person(s) conducting this study are the ones being misleading!

If you want to measure time to complete a complex task, then measure that. LOC is an intermediate measure. How much more productive is "55% more lines of code"?

I can write a bunch of garbage code really fast with a lot of bugs that doesn't work, or I can write a better program that works properly, slower. Under your framework, the former must be classified as 'better' - but why?

I read the study you reference and there is literally nothing in the study that talks about whether or not tasks were accomplished successfully.

It says: * Junior devs benefited more than senior devs, then presents a disingenuous argument as to why that's the senior devs' fault (more experienced employees are worse than less experienced employees, who knew?!) * 11% of the 55% increase in LOC was attributed directly to LLM output * Makes absolutely no attempt to measure whether or not the extra code was beneficial

Yes, like I said, it’s not hard to provide counterexamples to why more LOC is better, but it’s also missing the forest for the trees to pretend it doesn’t matter at all.

If you are seriously linking "productivity" to "lines of code produced," that says all about your credibility that I need to know.

Do you think LOC and program complexity are not correlated? You are arguing in bad faith.

Neither has anything to do with the effectiveness of a piece of software or the productivity of the people who created it.

"the data"

> Being anti AI/anti LLM is solidly in the Luddite camp; there’s really no more debates to be had. Every serious inquiry shows productivity gains by using ai.

"Guys this debate is so stupid. Every serious inquiry shows productivity gains when we take away all senses, jack workers into the matrix and feed them a steady diet of speed intravenously. This put debate to rest. Now we are post-debate"

Something can increase productivity and still not be good.

You mean like the study that found a 20% productivity drop instead of gain?

It didn't really show that if you break down the data, and its methodology was pretty bad

https://www.fightforthehuman.com/are-developers-slowed-down-...

The Luddites had some great ideas and were driven by a more sophisticated philosophy than people tend to give them credit for. I think their motivations are still applicable and worth considering today.

Then put me solidly in the Luddite camp. I think you should look into the history of the Luddites though. They were not against technology; they were against technology that destroyed jobs.

AI is about destroying working-class jobs so that corporations and the owning class can profit. It's not about writing code or summarizing articles. Those are just things workers can do with it. That's not what it's actually for. Its purpose is to reduce payroll costs for companies by replacing workers.

> They were not against technology; they were against technology that destroyed jobs.

They were not against technology; they were against technology that their destroyed jobs. If we had followed what they wanted, we'd still be in a semi pre industrial artisnal economy, and the worse off for it.

So you didn't read about them.

> In North West England, textile workers lacked these long-standing trade institutions and their letters composed an attempt to achieve recognition as a united body of tradespeople. As such, they were more likely to include petitions for governmental reforms, such as increased minimum wages and the cessation of child labor.

Sounds pretty modern doesn't it? unions, wages, no child-exploitation...

And the government response?

> Mill and factory owners took to shooting protesters and eventually the movement was suppressed by legal and military force, which included execution and penal transportation of accused and convicted Luddites.

you're absolutely correct!