> Nothing because I’m a senior and LLM’s never provide code that pass my sniff test, and it remains a waste of time.

I am constantly surprised how prevalent this attitude is. ChatGPT was only just released in 2022. Is there some expectation that these things won't improve?

> LLM’s never provide code that pass my sniff test

This is ego speaking.

> I am constantly surprised how prevalent this attitude is. ChatGPT was only just released in 2022. Is there some expectation that these things won't improve?

Is there any expectations that things will? Is there more untapped great quality data that LLMs can ingest? Will a larger model perform meaningfully better? Will it solve the pervasive issue of generating plausibly sounding bullshit?

I used LLMs for a while, I found them largely useless for my job. They were helpful for things I don't really need help with, and they were mostly damaging for things I actually needed.

> This is ego speaking.

Or maybe it was an accurate assessment for his use case, and your wishful thinking makes you think it was his ego speaking.

> Is there any expectations that things will?

Seems like an odd question. The answer is obviously yes: There is a very pervasive expectation that LLM's will continue to improve, and it seems odd to suggest otherwise. There is hundreds of billions of dollars being spent on AI training and that number is increasing each year.

> Is there more untapped great quality data that LLMs can ingest?

Why wouldn't there be? AI's are currently trained on the internet but that's obviously not the only source of data.

> Will a larger model perform meaningfully better?

The answer to this, is also yes. It is well established that, all else being equal, a bigger model is better than a smaller model, assuming that the smaller model hasn't already captured all of the available information.

We recently had a few submissions about this topic. Most recently Ilyas talk. Further improvement will be a research type problem. This trend was clear for a while already, but is reaching the mainstream now. The billions of dollar spend goes into scaling existing technology. If it doesn't scale anymore and becomes a resarch problem again, rational companies will not continue to invest in this area (at least without the usual research arrangements).

> There is a very pervasive expectation that LLM's will continue to improve, and it seems odd to suggest otherwise. There is hundreds of billions of dollars being spent on AI training and that number is increasing each year.

It isn't odd at all. In the early 21st century there were expectations of ever, exponentially increasing processing power. This misconception partially gave us the game Crysis, which, if I'm not mistaken, was written with wildly optimistic assumptions about the growing power of computer hardware.

People are horrible at predicting the future of technology (beyond meaninglesslessly or trivially broad generalizations) and even when predictions turn out to be correct, they're often correct for the wrong reasons. If we were better at it, even in the shortest term, where such predictions should be the easiest, we'd all be megamillionaires, because we'd have seen the writing on the wall and invested in Nvidia before the AI craze reached its current fever pitch.

> because we'd have seen the writing on the wall and invested in Nvidia before the AI craze reached its current fever pitch.

I did this when I saw the first stable diffusion AI titties. So far up over 10x.

If I had a nickel for every tech that takes off once porn finds its way to it, I wouldn't be counting in nickels.

What's the logic behind that? Porn has had nothing to do with the current AI boom.

> The answer is obviously yes: There is a very pervasive expectation that LLM's will continue to improve, and it seems odd to suggest otherwise. There is hundreds of billions of dollars being spent on AI training and that number is increasing each year.

That makes an assumption that throwing dollars on AI training is a surefire way to solve the many shortcomings of LLMs. It is a very optimistic assumption.

> Why wouldn't there be? AI's are currently trained on the internet but that's obviously not the only source of data.

"The Internet" basically encompasses all meaningful sources of data available, especially if we are talking specifically about software development. But even beyond that, it is very unclear what other high quality data it would consume that would improve the things.

> The answer to this, is also yes. It is well established that, all else being equal, a bigger model is better than a smaller model, assuming that the smaller model hasn't already captured all of the available information.

I love how you conveniently sidestepped the part where I ask if it would improve the pervasive issue of generating plausibly sounding bullshit.

The assumption that generative AI will improve is as valid as the assumption that it will plateau. It is quite possible that what we are seeing is "as good as it gets", and some major breakthrough, that may or may not happen on our lifetime, is needed.

> That makes an assumption that throwing dollars on AI training is a surefire way to solve the many shortcomings of LLMs. It is a very optimistic assumption.

That's not an assumption that I am personally making. That's what experts in the field believe.

> "The Internet" basically encompasses all meaningful sources of data available, especially if we are talking specifically about software development. But even beyond that, it is very unclear what other high quality data it would consume that would improve the things.

How about, interacting with the world?

> I love how you conveniently sidestepped the part where I ask if it would improve the pervasive issue of generating plausibly sounding bullshit.

I was not trying to "conveniently sidestep". To me, that reads like a more emotional wording of the first question you asked, which is if LLM's are expected to improve. To that question I answered yes.

> The assumption that generative AI will improve is as valid as the assumption that it will plateau.

It is certainly not as valid to say that generative AI will plateau. This is comparable to saying that the odds of winning any bet are 50/50, because you either win or lose. Probabilities are a thing. And the probability that the trend will plateau is lower than not.

> It is quite possible that what we are seeing is "as good as it gets", and some major breakthrough, that may or may not happen on our lifetime, is needed.

It's also possible that dolphins are sentient aliens sent here to watch over us.

> That's not an assumption that I am personally making. That's what experts in the field believe.

People invested in something believe that throwing money at it will make it better? Color me shocked.

"eat meat, says the butcher"

The rest of your answer amount to optimistic assumptions that yes, AI future is rosy, based on nothing but a desire that it will, because of course it will.

It’s not worth arguing with anyone who thinks LLMs are a fad. I just tell them that they’re right and get back to using LLMs myself. I’ll take the edge while I can.

If all of this is true, then I would expect LLMs today to be in a whole different league of LLMs from two years ago. Personally I find them less helpful and worse at programming and creative writing related tasks.

YMMV but count me in the camp that I think there’s better odds that LLMs are at or near their potential vs in their nascent stages.

> This is ego speaking.

No, it really isn't. Repeatedly, the case is that people are trying to pass off GPT's work as good without actually verifying the output. I keep seeing "look at this wonderful script GPT made for me to do X", and it does not pass code review, and is generally extremely low quality.

In one example, a bash script was generated to count number SLoC changed by author; it was extremely convoluted, and after I simplified it, I noticed that the output of the simplified version differed, because the original was omitted changes that were only a single line.

In another example it took several back & forths during a review to ask "where are you getting this code? / why do you think this code works, when nothing in the docs supports that?" and after several back and forths, it was admitted that GPT wrote it. The dev who wrote it would have been far better served RTFM, than a several cycle long review that ended up with most of GPT's hallucinations being stripped from the PR.

Those who think LLM's output is good have not reviewed the output strenuously enough.

> Is there some expectation that these things won't improve?

Because randomized token generation inherently lacks actual reasoning about the behavior of the code. My code generator does not.

I think fundamentally if all you do is glue together popular OSS libraries in well understood way, then yes. You may be replaced. But really you probably could be replaced by a Wordpress plugin at that point.

The moment you have some weird library that 4 people in the world know (which happens more than you’d expect) or hell even something without a lot of OSS code what exactly is an LLM going to do? How is it supposed to predict code that’s not derived from its training set?

My experience thus far is that it starts hallucinating and it’s not really gotten any better at it.

I’ll continue using it to generate sed and awk commands, but I’ve yet to find a way to make my life easier with the “hard bits” I want help with.

> I’ll continue using it to generate sed and awk commands,

The first example I gave was an example of someone using an LLM to generate sed & awk commands, on which it failed spectacularly, on everything from the basics to higher-level stuff. The emitted code even included awk, and the awk was poor quality: e.g., it had to store the git log output & make several passes over it with awk, when in reality, you could just `git log | awk`; it was doing `... | grep | awk` which … if you know awk, really isn't required. The regex it was using to work with the git log output it was parsing with awk was wrong, resulting in the wrong output. Even trivial "sane bash"-isms, it messed up: didn't quote variables that needed to be quotes, didn't take advantage of bashisms even though requiring bash in the shebang, etc.

The task was a simple one, bordering on trivial, and any way you cut it, from "was the code correct?" to "was the code high quality?", it failed.

But it shouldn't be terribly surprising that an LLM would fail at writing decent bash: its input corpus would resemble bash found on the Internet, and IME, most bash out there fails to follow best-practice; the skill level of the authors probably follows a Pareto distribution due to the time & effort required to learn anything. GIGO, but with way more steps involved.

I've other examples, such as involving Kubernetes: Kubernetes is also not in the category of "4 people in the world know": "how do I get the replica number from a pod in a statefulset?" (i.e., the -0, -1, etc., at the end of the pod name) ­— I was told to query,

  .metadata.labels.replicaset-序号

(It's just nonsense; not only does no such label exist for what I want, it certainly doesn't exist with a Chinese name. AFAICT, that label name did not appear on the Internet at the time the LLM generated it, although it does, of course, now.) Again, simple task, wide amount of documentation & examples in the training set, and garbage output.

You ask what the LLM is going to do. It’s going to swallow the entire code base in context and allow any developer to join those 4 people in generating production grade code.

> No, it really isn't

It really is. Either that or you’re not thinking about what you’re saying.

Imagine code passes your rigorous review.

How do you know that it wasn’t from an LLM?

If it’s because you know that you only let good code pass your review and you know that LLMs only generate bad code, think about that a bit.

> Imagine code passes your rigorous review. How do you know that it wasn’t from an LLM?

That's not what I'm saying (and it's a strawman; yes, presumably some LLM code would escape review and I wouldn't know it's from an LLM, though I find that unlikely, given…) — what I'm saying is of LLM generated code that is reviewed, what is the quality & correctness of the reviewed code? And it's resoundingly (easily >90%) crap.

Obviously we can't sample from unknown-authorship … nor am I; I'm sampling problems that I and others run through an LLM, and the output thereof.

The other facet of this point is that I believe a lot of the craze that users using the LLM have is driven by them not looking closely at the output; if you're just deriving code from the LLM, chucking it over the wall, and calling it a day (as was the case from one of the examples in the comment above) — you're perceiving the LLM as being useful, when it fact it is leaving bugs that you're either not attributing to it, someone else is cleaning up (again, that was the case in the above example), etc.

> what I'm saying is of LLM generated code that is reviewed, what is the quality & correctness of the reviewed code? And it's resoundingly (easily >90%) crap.

What makes you so sure that none of the resoundingly non-crap that you have reviewed was not produced by LLM?

It’s like saying you only like homemade cookies not ones from the store. But you may be gleefully chowing down on cookies that you believe are homemade because you like them (so they must be homemade) without knowing they actually came from the store.

> What makes you so sure that none of the resoundingly non-crap that you have reviewed was not produced by LLM?

From the post you're replying to:

> Obviously we can't sample from unknown-authorship … nor am I; I'm sampling problems that I and others run through an LLM, and the output thereof.

Yes, believe it or not I’m able to read.

> I'm sampling problems that I and others run through an LLM

This is not what’s happening unless 100% of the problems they’ve sampled (even outside of this fun little exercise) have been run through an LLM.

They’re pretending like it doesn’t matter that they’re looking at untold numbers of other problems and are not aware whether those are LLM generated or not.

It sounds like that's what's happening. The LLM code that they have reviewed has been, to their standards, subpar.

> The LLM code that they have reviewed has been, to their standards, subpar.

No. The accurate way to say this is:

“The code that they have reviewed that they know came from an LLM has been, to their standards, subpar.”

> Is there some expectation that these things won't improve?

I definitely expect them to improve. But I also think the point at which they can actually replace a senior programmer is pretty much the exact point at which they can replace any knowledge worker, at which point western society (possibly all society) is in way deeper shit than just me being out of a job.

> This is ego speaking.

It definitely isn't. LLMs are useful for coding now, but they can't really do the whole job without help - at least not for anything non-trivial.

Intellisense style systems were a huge feature leap when they gained wider language support and reliability. LLMs are yet another step forward for intellisense and the effort of comprehending the code you're altering. I don't think I will ever benefit from code generation in a serious setting (it's excellent for prototyping) simply due to the fact that it's solving the easy problem (write some code) while creating a larger problem (figure out of the code that was generated is correct).

As another senior developer I won't say it's impossible that I'll ever benefit from code generation but I just think it's a terrible space to try and build a solution - we don't need a solution here - I can already type faster than I can think.

I am keenly interested in seeing if someone can leverage AI for query performance tuning or, within the RDBMS, query planning. That feels like an excellent (if highly specific) domain for an LLM.

> I can already type faster than I can think.

But can you write tickets faster than you can implement them? I certainly can.

> But can you write tickets faster than you can implement them? I certainly can.

Personally, I have a tendency at work to delay creating tickets until after I've already written the implementation.

Why? Because tickets in my employer's system are expected to identify which component needs to be changed, and ideally should have some detail about what needs to be changed. But both of those things depend on the design of the change being implemented.

In my experience, any given feature usually has multiple possible designs, and the only way to know if a design is good is to try implementing it and see how clean or messy it ends up. Of course, I can guess in advance which design will turn out well. I have to guess, or else I wouldn't know which design to try implementing first. But often my first attempt runs into unexpected wrinkles and I retreat and try a different design.

Other people will start with a design and brute-force their way to working code, and (in my judgmental opinion) the code often ends up lower-quality because of it.

Sooner or later, perhaps AI will be able to perform that entire process autonomously, better than I can. In the meantime, though, people often talk about using AI like a 'junior engineer', where you think up a design yourself and then delegate the grunt work to the AI. That approach feels flawed to me, because it disconnects the designer from the implementer.

>>> delay creating tickets until after I've already written the implementation. Why? Because tickets in my employer's system are expected to identify which component needs to be changed,

abso-frigging-lutely

To me this is n example of software being a form Of literacy - creative work. And yet process is designed by software illiterates who think novels can be written by pre-planning all the paragraphs

Depends on the ticket.

If it's "Get us to the moon", it's gonna take me years to write that ticket.

If it was "Make the CTA on the homepage red", it is up for debate whether I needed a ticket at all.

Based on current methods of productivity scoring, I'd try to make 2 tickets for that...

> LLMs are yet another step forward for intellisense

That would be great if the reality wasn't that the suggested LLM slop is actually making it harder to get the much better intellisense suggestions of last year.

> I am keenly interested in seeing if someone can leverage AI for query performance tuning or, within the RDBMS, query planning. That feels like an excellent (if highly specific) domain for an LLM.

Pay the $20 for Claude, copy the table DDL's in along with a query you'd like to tune.

Copy in any similar tuned queries you have and tell it you'd like to tune your query in a similar manner.

Once you've explained what you'd like it to do and provided context hit enter.

I'd be very surprised if having done this you can't find value in what it generates.

I imagine though they might replace 3 out of 4 senior programmers (keep one around to sanity check the AI).

That's the same figuring a lot of business folks had when considering off-shoring in the early 2000s - those companies ended up hiring twice as many senior programmers to sanity check and correct the code they got back. The same story can be heard from companies that fired their expensive seniors to hire twice as many juniors at a quarter the price.

I think that software development is just an extremely poor market segment for these kinds of tools - we've already got mountains of productivity tools that minimize how much time we need to spend doing the silly rote programming stuff - most of software development is problem solving.

Oof, the times I've heard something like that with X tech.

Heh, UML is going to save us! The business people can just write the requirements and the code will write itself! /s

Given the growth-oriented capitalist society we live in in the west, I'm not all that worried about senior and super-senior engineers being fired. I think a much more likely outcome is that if a business does figure out a good way to turn an LLM into a force-multiplier for senior engineers, they're going to use that to grow faster.

There is a large untapped niche too that this could potentially unlock: projects that aren't currently economically viable due to the current cost of development. I've done a few of these on a volunteer basis for non-profits but can't do it all the time due to time/financial constraints. If LLM tech actually makes me 5x more productive on simple stuff (most of these projects are simple) then it could get viable to start knocking those out more often.

> LLM’s never provide code that pass my sniff test

If that statement isn't coming from ego, then where is it coming from? It's provably true that LLM's can generate working code. They've been trained on billions of examples.

Developers seem to focus on the set of cases that LLM's produce code that doesn't work, and use that as evidence that these tools are "useless".

My experience so far has been: if I know what I want well enough to explain it to an LLM then it’s been easier for me to just write the code. Iterating on prompts, reading and understanding the LLM’s code, validating that it works and fixing bugs is still time consuming.

It has been interesting as a rubber duck, exploring a new topic or language, some code golf, but so far not for production code for me.

Okay, but as soon as you need to do the same thing in [programming language you don't know], then it's not easier for you to write the code anymore, even though you understand the problem domain just as well.

Now, understand that most people don't have the same grasp of [your programming language] that you have, so it's probably not easier for them to write it.

I don’t disagree with anything you said and I don’t think anything you said disagrees with my original comment :)

I actually said in my comment that exploring a new language is one area I find LLMs to be interesting.

there's a lot more involved in senior dev work beyond producing code that works.

if the stakeholders knew how to do what they needed to build and how, then they could use LLMs, but translating complex requirements into code is something that these tools are not even close to cracking.

> there's a lot more involved in senior dev work beyond producing code that works.

Completely agree.

What I don't agree with is statements like these:

> LLM’s never provide code that pass my sniff test

To me, these (false) absolutions about chat bot capabilities, are being rehashed so frequently, that it derails every conversation about using LLM's for dev work. You'll find similar statements in nearly every thread about LLM's for coding tasks.

It's provably true that LLM's can produce working code. It's also true, that some increasingly large portion of coding is being offloaded to LLM's.

In my opinion, developers need to grow out of this attitude that they are John Henry and they'll outpace the mechanical drilling machine. It's a tired conversation.

> It's provably true that LLM's can produce working code.

This is correct - but it's also true that LLMs can produce flawed code. To me the cost of telling whether code is correct or flawed is larger than the cost of me just writing correct code. This may be an AuDHD thing but I can better comprehend the correctness of a solution if I'm watching (and doing) the making of that solution than if I'm reading it after the fact.

> It's provably true that LLM's can produce working code.

You've restated this point several times but the reason it's not more convincing to many people is that simply producing code that works is rarely an actual goal on many projects. On larger projects it's much more about producing code that is consistent with the rest of the project, and is easily extensible, and is readable for your teammates, and is easy to debug when something goes wrong, is testable, and so on.

The code working is a necessary condition, but is insufficient to tell if it's a valuable contribution.

The code working is the bare minimum. The code being right for the project and context is the basic expectation. The code being _good_ at solving its intended problem is the desired outcome, which is a combination of tradeoffs between performance, readability, ease of refactoring later, modularity, etc.

LLM's can sometimes provide the bare minimum. And then you have to refactor and massage it all the way to the good bit, but unlike looking up other people's endeavors on something like Stack Overflow, with the LLM's code I have no context why it "thought" that was a good idea. If I ask it, it may parrot something from the relevant training set, or it might be bullshitting completely. The end result? This is _more_ work for a senior dev, not less.

Hence why it has never passed my sniff test. Its code is at best the quality of code even junior developers wouldn't open a PR for yet. Or if they did they'd be asked to explain how and why and quickly learn to not open the code for review before they've properly considered the implications.

Code is a liability, not an asset. It is a necessary evil to create functional software.

Senior devs know this, and factor code down to the minimum necessary.

Junior devs and LLMs think that writing code is the point and will generate lots of it without worrying about things like leverage, levels of abstraction, future extensibility, etc.

LLMs can be prompted to write code that considers these things.

You can write good code or bad code with LLMs.

The code itself, whether good or bad, is a liability. Just like a car is a liability, in a perfect world, you'd teleport yourself to your destination, instead you have to drive. And because of that, roads and gas stations have to be built, you have to take care of the car, etc,.... It's all a huge pain. The code you write, you will have to document, maintain, extend, refactor, relearn, and a bunch of other activities. So yo do your best to only have the bare minimum to take care of. Anything else is just future troubles.

Sure, I don’t dispute any of that. But it's not a given that using LLMs means you’re going to have unnecessary code. They can even help to reduce the amount of code. You just have to be detailed in your prompting about what you do and don’t want, and work through multiple iterations until the result is good.

Of course if you try to one shot something complex with a single line prompt, the result will be bad. This is why humans are still needed and will be for a long time imo.

I'm not sure that's true. A LLM can code because it is trained on existing code.

Empirically, LLMs work best at coding when doing completely "routine" coding tasks: CRUD apps, React components, etc. Because there's lots of examples of that online.

I'm writing a data-driven query compiler and LLM code assistance fails hard, in both blatant and subtle ways. There just isn't enough training data.

Another argument: if a LLM could function like a senior dev, it could learn to program in new programming languages given the language's syntax, docs and API. In practice they cannot. It doesn't matter what you put into the context, LLMs just seem incapable of writing in niche languages.

Which to me says that, at least for now, their capabilities are based more on pattern identification and repetition than they are on reasoning.

Have you tried new languages or niche languages with claude sonnet 3.5? I think if you give it docs with enough examples, it might do ok. Examples are crucial. I’ve seen it do well with CLI flags and arguments when given docs, which is a somewhat similar challenge.

That said, you’re right of course that it will do better when there’s more training data.

As a developer, while I do embrace intellisense, I don't copy/paste code, because I find typing it out is a fast path to reflection and finding issues early. Copilot seems to be no better than mindlessly copy/pasting from StackOverflow.

From what I've seen of Copilots, while they can produce working code, I've not seen that much that it offers beyond the surface level which is fast enough for me to type. I am also deeply perturbed from some interviews I've done for senior candidates recently who are using them and, when asked to disable them for collaborative coding task, completely fall apart because of their dependency over knowledge.

This is not to say I do not see value in AI, LLMs or ML (I very much do). However, I code broadly at the speed of thought, and that's not really something I think will be massively aided by it.

At the same time, I know I am an outlier in my practice relative to lots around me.

While I don't doubt other improvements that may come from LLM in development, the current state of the art feels less like a mechanical drill and more like an electric triangle.

> It's provably true that LLM's can produce working code

ChatGPT, even now in late-2024, still hallucinates standard-library types and methods more-often-than-not whenever I ask it to generate code for me. Granted, I don’t target the most popular platforms (i.e. React/Node/etc; I’m currently in a .NET shop, which is a minority platform now, but ChatGPT’s poor performance is surprising given the overall volume and quality of .NET content and documentation out there.

My perception is that “applications” work is more likely to be automated-away by LLMs/copilots because so much of it is so similar to everyone else’s, so I agree with those who say LLMs are only as good as there are examples of something online, whereas asking ChatGPT to write something for a less-trodden area, like Haskell or even a Windows driver, is frequently a complete waste of time as whatever it generates is far beyond salvaging.

Beyond hallucinations, my other problem lies in the small context window which means I can’t simply provide all the content it needs for context. Once a project grows past hundreds of KB of significant source I honestly don’t know how us humans are meant to get LLMs to work on them. Please educate me.

I’ll declare I have no first-hand experience with GitHub Copilot and other systems because of the poor experiences I had with ChatGPT. As you’re seemingly saying that this is a solved problem now, can you please provide some details on the projects where LLMs worked well for you? (Such as which model/service, project platform/language, the kinds of prompts, etc?). If not, then I’ll remain skeptical.

> still hallucinates standard-library types and methods more-often-than-not whenever I ask it to generate code for me

Not an argument, unsolicited advice: my guess is you are asking it to do too much work at once. Make much smaller changes. Try to ask for as roughly much as you would put into one git commit (per best practices)-- for me that's usually editing a dozen or less lines of code.

> Once a project grows past hundreds of KB of significant source I honestly don’t know how us humans are meant to get LLMs to work on them. Please educate me.

https://github.com/Aider-AI/aider

Edit: The author of aider puts the percentage of the code written by LLMs for each release. It's been 70%+. But some problems are still easier to handle yourself. https://github.com/Aider-AI/aider/releases

Thank you for your response - I've aksed these questions before in other contexts but never had a reply, so pretty-much any online discussion about LLMs feels like I'm surrounded by people role-playing being on LinkedIn.

> It's provably true that LLM's can produce working code

Then why can't I see this magical code that is produced? I mean a real big application with a purpose and multiple dependencies, not yet another ReactJS todo list. I've seen comments like that a hundred times already but not one repository that could be equivalent to what I currently do.

For me the experience of LLM is a bad tool that calls functions that are obsolete or do not exist at all, not very earth-shattering.

> if the stakeholders knew how to do what they needed to build and how, then they could use LLMs, but translating complex requirements into code is something that these tools are not even close to cracking.

They don't have to replace you to reduce headcount. They could increase your workload so where they needed five senior developers, they can do with maybe three. That's like six one way and half a dozen the other way because two developers lost a job, right?

Yeah. Code that works is a fraction of the aim. You also want code that a good junior can read and debug in the midst of a production issue, is robust against new or updated requirements, has at least as good performance as the competitors, and uses appropriate libraries in a sparse manner. You also need to be able to state when a requirement would loosen the conceptual cohesion of the code, and to push back on requirements thdt can already be achieved in just as easy a way.

> It's provably true that LLM's can generate working code.

Yeah for simple examples, especially in web dev. As soon as you step outside those bounds they make mistakes all the time.

As I said, they're still useful because roughly correct but buggy code is often quite helpful when you're programming. But there's zero chance you can just say "write me an driver for the nRF905 using Embassy and embedded-hal" and get something working. Whereas I, a human, can do that.

The question is, how long would it take you to get as far as this chat does when starting from scratch?

https://chatgpt.com/share/6760c3b3-bae8-8009-8744-c25d5602bf...

How confident are you in the correctness of that code?

Because, one way or another, you're still going to need to become fluent enough in the problem domain & the API that you can fully review the implementation and make sure chatgpt hasn't hallucinated in any weird problems. And chatgpt can't really explain its own work, so if anything seems funny, you're going to have to sleuth it out yourself.

And at that point, it's just 339 lines of code, including imports, comments, and misc formatting. How much time have you really saved?

Yeah now actually check the nRF905 documentation. You'll find it has basically made everything up.

> It's provably true that LLM's can generate working code.

What I've seen of them, the good ones mostly produce OK code. Not terrible, usually works.

Although I like them even for that low-ish bar, although I find them to be both a time-saver and a personal motivation assistant, they're still a thing that needs a real domain expert to spot the mistakes they make.

> Developers seem to focus on the set of cases that LLM's produce code that doesn't work, and use that as evidence that these tools are "useless".

I do find it amusing how many humans turned out to be stuck thinking in boolean terms, dismissing the I in AGI, calling them as "useless" because it "can't take my job". Same with the G in AGI, dismissing the breadth of something that speaks 50 languages when humans who speak five or six languages are considered unusually skilled.

Working code some subset of the time, for popular languages. It’s not good at Rust nor at other smaller languages. Tried to ask it for some help with Janet and it was hopelessly wrong, even with prompting to try to get it to correct its mistakes.

Even if it did work, working code is barely half the battle.

I'd say ChatGPT at least is a fair bit better at Python than it is at Scala which seems to match your experience.

> It's provably true that LLM's can generate working code

They produce mostly working code, often with odd design decisions that the bot can't fully justify.

The difficult part of coding is cultivating a mental model of the problem + solution space. When you let an LLM write code for you, your mental model falls behind. You can read the new code closely, internalize it, double-check the docs, and keep your mental model up to date (which takes longer than you think), or you can forge ahead, confident that it all more or less looks right. The second option is easier, faster, and very tempting, and it is the reason why various studies have found that code written with LLM assistance introduces more bugs than code written without.

There are plenty of innovations that have made programming a little bit faster (autocomplete, garbage collection, what-have-you), but none of them were a silver bullet. LLMs aren't either. The essential complexity of the work hasn't changed, and a chat bot can't manage it for you. In my (admittedly limited) experience with code assistants, I've found that the faster you move with an LLM, the more time you have to spend debugging afterwards, and the more difficult that process becomes.

> If that statement isn't coming from ego, then where is it coming from? It's provably true that LLM's can generate working code. They've been trained on billions of examples.

I am pro AI and I'm probably even overvaluing the value AI brings. However, for me, this doesn't work in more "esoteric" programming languages or those with stricter rulesets like Rust. LLMS provide fine JS code, since there's no compiler to satisfy, but CPP without undefined behaviour or compiling Rust code is rare.

There's also no chance of LLMS providing compiling code if you're using a library version with a newer API than the one in the training set.

> LLMs are useful for coding now

*sort of, sometimes, with simple enough problems with sufficiently little context, for code that can be easily tested, and for which sufficient examples exist in the training data.

I mean hey, two years after being promised AGI was literally here, LLMs are almost as useful as traditional static analysis tools!

I guess you could have them generate comments for you based on the code as long as you're happy to proofread and correct them when they're wrong.

Remember when CPUs were obsolete after three years? GPT has shown zero improvement in its ability to generate novel content since it was first released as GPT2 almost ten years ago! I would know because I spent countless hours playing with that model.

Firstly, GPT-2 was released in 2019. Five years is not "almost ten years".

Secondly, LLMs are objectively useful for coding now. That's not the same thing as saying they are replacements for SWEs. They're a tool, like syntax highlighting or real-time compiler error visibility or even context-aware keyword autocompletion.

Some individuals don't find those things useful, and prefer to develop in a plain text editor that does not have those features, and that's fine.

But all of those features, and LLMs are now on that list, are broadly useful in the sense that they generally improve productivity across the industry. They already right now save enormous amounts of developer time, and to ignore that because you are not one of the people whose time is currently being saved, indicates that you may not be keeping up with understanding the technology of your field.

There's an important difference between a tool being useful for generating novel content, and a tool being useful. I can think of a lot of useful tools that are not useful for generating novel content.

> are broadly useful in the sense that they generally improve productivity across the industry. They already right now save enormous amounts of developer time,

But is that actually a true statement. Are there actual studies to back that up?

AI is hyped to the moon right now. It is really difficult to separate the hype from reality. There are ancedotal reports of ai helping with coding, but there are also ancedotal reports that they get things almost right but not quite, which often leads to bugs which wouldn't otherwise happen. I think its unclear if that is a net win for productivity in software engineering. It would be interesting if there was a robust study about it.

> Are there actual studies to back that up?

I am aware of an equal number of studies about the time saved overall by use of LLMs, and time saved overall by use of syntax highlighting.

In fact, here's a study claiming syntax highlighting in IDEs does not help code comprehension: https://link.springer.com/article/10.1007/s10664-017-9579-0

Shall we therefore conclude that syntax highlighting is not useful, that developers who use syntax highlighting are just part of the IDE hype train, and that anecdotal reports of syntax highlighting being helpful are counterbalanced by anecdotal reports of $IDE having incorrect syntax highlighitng on $Esoteric_file_format?

Most of the failures of LLMs with coding that I have seen has been a result of asking too much of the LLM. Writing a hundred context-aware unit tests is something that an LLM is excellent at, and would have taken a developer a long time previously. Asking an LLM to write a novel algorithm to speed up image processing of the output of your electron microscope will go less well.

> Shall we therefore conclude that syntax highlighting is not useful, that developers who use syntax highlighting are just part of the IDE hype train, and that anecdotal reports of syntax highlighting being helpful are counterbalanced by anecdotal reports of $IDE having incorrect syntax highlighitng on $Esoteric_file_format?

Yes. We should conclude that syntax highlighting is not useful in languages that the syntax highlighter does not support. I think basically everyone would agree with this statement.

Similarly an llm that worked 100% of the time and could solve any problem would be pretty useful. (Or at least worked correctly as often as syntax highlighting in situations where it is actually used does)

However that's not the world we live in. Its a reasonable question to ask if llm is good enough yet where the productivity gain outweighs the productivity lost.

Your stance feels somewhat contradictory. A syntax highlighter is not useful in languages it does not support, therefore an LLM must be able to solve any problem to be useful?

The point I was trying to make was, an LLM is as reliably useful as syntax highlighting, for the tasks that coding LLMs are good at today. Which is not a lot, but enough to speed up junior devs. The issues come when people assume they can solve any problem, and try to use them on tasks to which they are not suited. Much like applying syntax highlighting on an unsupported language, this doesn't work.

Like any tool, there's a learning curve. Once someone learns what does and does not work, it's generally an strict productivity boost.

The problem is that there are no tasks that LLMs are reliably good at. I believe that's what OP is getting at.

I fixed a production issue earlier this year that turned out to be a naive infinite loop - it was trying to load all data from a paginated API endpoint, but there was no logic to update the page number being fetched.

There was a test for it. Alas, the test didn't actually cover this scenario.

I mention this because it was committed by a co-worker whose work is historically excellent, but who started using Copilot / ChatGPT. I'm pretty sure it was an LLM-generated function and test, and they were deeply broken.

Mostly they've been working great for this co-worker.

But not reliably.

I understand that, the point I'm making is that reliability is not a requirement for utility. One does not need to be reliable to be reliably useful :)

A very similar example is StackOverflow. If you copy/paste answers verbatim from SO, you will have problems. Some top answers are deeply broken or have obvious bugs. Frequently, SO answers are only related to your question, but do not explicitly answer it.

SO is useful to the industry in the same way LLMs are.

Sure, there is a range. If it works 100% of the time its clearly useful. If it works 0% then it clearly isn't.

LLMs are in the middle. Its unclear which side of the line they are on. Some ancedotes say one thing some say another. That's why studies would be great. Its also why syntax highlighting is a bad comparison since that is not in the greyzone.

exactly. many SWEs currently are fighting this fight of “oh it is not good enough bla bla…” on my team currently (50-ish people) you would not last longer than 3 months if you tried to do your work “manually” like we did before. several have tried, no longer around. I believe SWEs fighting LLMs are doing themselves a huge disservice in that they should be full-on embracing it and trying to figure out how to more effectively use them. just like any other tool, it is as good as the user of the tool :)

> Secondly, LLMs are objectively useful for coding now.

No, they're subjectively useful for coding in the view of some people. I find them useless for coding. If they were objectively useful, it would be impossible for me to find them useless because that is what objectivity means.

I do believe you stopped reading my comment at that quote, because I spent the remainder of my comment making the same distinction you did...

It's useless to your coding, but useful to the industry of coding.

If a LLM (or any other tool) makes so that team of 8 can get the same results in the same time as it used to take a team of 10 to do, then I would count that as "replaced 2 programmers" - even if there's no particular person for which the whole job has been replaced, that's not a meaningful practical difference, replacing a significant fraction of every programmer's job has the same outcomes and impacts as replacing a significant fraction of programmers.

Fav anecdote from ages ago:

When hand-held power tools became a thing, the Hollywood set builder’s union was afraid of this exact same thing - people would be replaced by the tools.

Instead, productions built bigger sets (the ceiling was raised) and smaller productions could get in on things (the floor was lowered).

I always took that to mean “people aren’t going to spend less to do the job - they’ll just do a bigger job.”

It's always played out like this in software, by the way. Famously, animation shops hoped to save money on production by switching over to computer rendered cartoons. What happened instead is that a whole new industry took shape, and brought along with it entire cottage industries of support workers. Server farms required IT, renders required more advanced chips, some kinds of animation required entirely new rendering techniques in the software, etc.

A few hundred animators turned into a few thousand computer animators & their new support crew, in most shops. And new, smaller shops took form! But the shops didn't go away, at least not the ones who changed.

It basically boils down to this: some shops will act with haste and purge their experts in order to replace them with LLMs, and others will adopt the LLMs, bring on the new support staff they need, and find a way to synthesize a new process that involves experts and LLMs.

Shops who've abandoned their experts will immediately begin to stagnate and produce more and more mediocre slop (we're seeing it already!) and the shops who metamorphose into the new model you're speculating at will, meanwhile, create a whole new era of process and production. Right now, you really want to be in that second camp - the synthesizers. Eventually the incumbents will have no choice but to buy up those new players in order to coup their process.

And 3D animation still requires hand animation! Nobody starts with 3D animation, the senior animators are doing storyboards and keyframes which they _then_ use as a guide for 3D animation.

Another anecdote: when mechanical looms became a thing, textile workers were afraid that the new tools would replace them, and they were right.

It solely depends on whether more software being built is being constrained by feasibility/cost or a lack of commercial opportunities.

Software is typically not a cost constrained activity due to its typically higher ROI/scale. Its all about fixed costs and scaling profits mostly. Unfortunately given this my current belief is that on balance AI will destroy many jobs in this industry if it gets to the point where it can do a software job.

Assuming inelastic demand (software demand relative to SWE costs) any cost reductions in inputs (e.g. AI) won't translate to much more demand in software. The same effect that drove SWE prices high and didn't change demand for software all that much (explains the 2010's IMO particularly in places like SV) also works in reverse.

Is there a good reason to assume inelastic demand? In my field —- biomedical research —-I see huge untapped areas in need of much more and better core programming services. Instead we “rely” way too much on grad students (not even junior SWEs) who know a bit of Python.

Depends on the niche (software is broad) but I think as a whole for the large software efforts employing a good chunk of the market - I think so. Two main reasons for thinking this way:

- Software scales; generally it is a function of market size, reach, network effects, etc. Cost is a factor but not the greatest factor. Most software makes profit "at scale" - engineering is a capital fixed cost. This means that software feasibility is generally inelastic to cost or rather - if I make SWE's cheaper/not required to employ it wouldn't change the potential profit vs cost equation much IMV for many different opportunities. Software is limited more by ideas, and potential untapped market opportunities. Yes - it would be much cheaper to build things; but it wouldn't change the feasibility of a lot of project assessments since cost of SWE's at least from what I've seen in assessments isn't the biggest factor. This effect plays out to varying degrees in a lot of capex - as long as the ROI makes sense its worth going ahead especially for larger orgs who have more access to capital. The ROI from scale dwarfs potential cost rises often making it less of a function of end SWE demand. This effect happens in other engineering disciplines as well to varying effects - software just has it in spades until you mix hardware scaling into the mix (e.g GPUs).

- The previous "golden era" where the in-elasticity of software demand w.r.t cost meant salaries just kept rising. Inelasticity can be good for sellers of a commodity if demand increases. More importantly demand didn't really decrease for most companies as SWE salaries kept rising - entry requirements were relaxing generally. The good side of in-elasticity is reversed potentially by AI making it a bad thing.

However small "throwaway" software which does have a "is it worth it/cost factor" will increase under AI most probably. Just don't think it will offset the reduction demanded by capital holders; nor will it be necessarily done by the same people anyway (democratizing software dev) meaning it isn't a job saver.

In your case I would imagine there is a reason why said software doesn't have SWE's coding it now - it isn't feasible given the likely scale it would have (I assume just your team). AI may make it feasible, but that doesn't help the OP in the way it does it - it does so by making it feasible for as you put it junior out of uni not even "SWE" grads. That doesn't help the OP.

Oh my, no. Fabrics and things made from fabrics remain largely produced by human workers.

Those textile workers were afraid machines would replace them, but that didn't happen - the work was sent overseas, to countries with cheaper labor. It was completely tucked away from regulation and domestic scrutiny, and so remains to this day a hotbed of human rights abuses.

The phenomenon you're describing wasn't an industry vanishing due to automation. You're describing a moment where a domestic industry vanished because the cost of overhauling the machinery in domestic production facilities was near to the cost of establishing an entirely new production facility in a cheaper, more easily exploitable location.

I think you're talking about people who sew garments, not people who create textile fabrics. In any case, the 19th century British textile workers we all know I'm talking about really did lose their jobs, and those jobs did not return.

430 million people currently work in textiles[0]; how big was the industry before mechanical looms?

[0] https://www.uniformmarket.com/statistics/global-apparel-indu...

How many worked in America and Western Europe and were paid a living wage in their respective countries, and how many of those 430 million people currently work making textiles in America and Western Europe today, and how many are lower paid positions in poorer countries, under worse living conditions? (Like being locked into the sweatshop, and bathroom breaks being regulated?)

Computers aren't going anywhere, so the whole field of programming will continue to grow, but will there still be FAANG salaries to be had?

i heard the same shit when people were talking about outsourcing to India after the dotcom bubble burst. programmer salaries would cap out at $60k because of international competition.

if you're afraid of salaries shrinking due to LLMs, then i implore you, get out of software development. it'll help me a lot!

That's a different topic entirely.

I think this is THE point.

And that was good. Workers being replaced by tools is good for society, although temporarily disruptive.

This could very well prove to be the case in software engineering, but also could very well not; what is the equivalent of "larger sets" in our domain, and is that something that is even preferable to begin with? Should we build larger codebases just because we _can_? I'd say likely not, while it does make sense to build larger/more elaborate movie sets because they could.

Also, a piece missing from this comparison is a set of people who don't believe the new tool will actually have a measurable impact on their domain. I assume few-to-none could argue that power tools would have no impact on their profession.

> Should we build larger codebases just because we _can_?

The history of software production as a profession (as against computer science) is essentially a series of incremental increases in the size and complexity of systems (and teams) that don't fall apart under their own weight. There isn't much evidence we have approached the limit here, so it's a pretty good bet for at least the medium term.

But focusing on system size is perhaps a red herring. There is an almost unfathomably vast pool of potential software systems (or customization of systems) that aren't realized today because they aren't cost effective...

Have you ever worked on a product in production use without a long backlog of features/improvements/tests/refactors/optimizations desired by users, managers, engineers, and everyone else involved in any way with the project?

The demand for software improvements is effectively inexhaustible. It’s not a zero sum game.

This is a real thing. LLMs are tools, not humans. They truly do bring interesting, bigger problems.

Have people seen some of the recent software being churned out? Hint, it's not all GenAI bubblespit. A lot of it is killer, legitimately good stuff.

This is a good example of what could happen to software development as a whole. In my experience large companies tend to more often buy software rather than make it. Ai could drastically change the "make or buy" decision in favour of make. Because you need less developers to create a perfect tailored solution that directly fits the needs of the company. So "make" becomes affordable and more attractive.

I work for a large european power utility. We are moving away from buying to in-house development. LLMs have nothing to do with it.

The saddle, the stirrup, the horseshoe, the wagon, the plough, and the drawbar all enhanced the productivity of horses and we only ended up employing more of them.

Then the steam engine and internal combustion engine came around and work horses all but disappeared.

There's no economic law that says a new productivity-enhancing programming tool is always a stirrup and never a steam engine.

I think you raise an excellent point, and can use your point to figure out how it could apply in this case.

All the tools that are stirrups were used "by the horse" (you get what I mean); that implies to me that so long as the AI tools are used by the programmers (what we've currently got), they're stirrups.

The steam engines were used by the people "employing the horse" - ala, "people don't buy drills they buy holes" (people don't employ horses, they move stuff) - so that's what to look for to see what's a steam engine.

IMHO, as long as all this is "telling the computer what to do", it's stirrups, because that's what we've been doing. If it becomes something else, then maybe it's a steam engine.

And, to repeat - thank you for this point, it's an excellent one, and provides some good language for talking about it.

Thanks for the warm feedback!

Maybe another interesting case would be secretaries. It used to be very common that even middle management positions at small to medium companies would have personal human secretaries and assistants, but now they're very rare. Maybe some senior executives at large corporations and government agencies still have them, but I have never met one in North America who does.

Below that level it's become the standard that people do their own typing, manage their own appointments and answer their own emails. I think that's mainly because computers made it easy and automated enough that it doesn't take a full time staffer, and computer literacy got widespread enough that anyone could do it themselves without specialized skills.

So if programming got easy enough that you don't need programmers to do the work, then perhaps we could see the profession hollow out. Alternatively we could run out of demand for software but that seems less likely!

(a related article: https://archive.is/cAKmu )

That's actually not accurate. See Jevons paradox, https://en.m.wikipedia.org/wiki/Jevons_paradox. In the short term, LLMs should have the effect of making programmers more productive, which means more customers will end up demanding software that was previously uneconomic to build (this is not theoretical - e.g. I work with some non-profits who would love a comprehensive software solution, they simply can't afford it, or the risk, at present).

yes, this. the backlog of software that needs to be built is fucking enormous.

you know what i'd do if AI made it so i could replace 10 devs with 8? use the 2 newly-freed up developers to work on some of the other 100000 things i need done

I'm casting about for project ideas. What are some things that you think need to be built but haven't?

Every company that builds software has dozens of things they want but can't prioritize because they're too busy building other things.

It's not about a discrete product or project, but continuous improvement upon that which already exists is what makes up most of the volume of "what would happen if we had more people".

A consumer-friendly front end to NOAA/NWS website, and adequate documentation for their APIs would be a nice start. Weather.com, accuweather and wunderground exist, but they're all buggy and choked with ads. If I want to track daily rainfall in my area vs local water reservoir levels vs local water table readings, I can do that, all the information exists but I can't conveniently link it together. The fed has a great website where you can build all sorts of tables and graphs about current and historical economic market data, but environmental/weather data is left out in the cold right now.

some ideas from my own work:

- a good LIMS (Laboratory Information Management System) that incorporates bioinformatics results. LIMS come from a pure lab, benchwork background, and rarely support the inclusion of bioinformatics analyses on samples included in the system. I have yet to see a lab that uses an off-the-shelf LIMS unmodified - they never do what they say they do. (And the amount of labs running on something built on age-old software still in use is... horrific. I know one US lab running some abomination built on Filemaker Pro)

- Software to manage grants. Who is being owed what, what are the milestones, who's looking after this, who are the contact persons, what are the milestones and when to remind, due diligence on potential partners etc. I worked for a grant-giving body and they came up with a weird mix of PowerBI and a pile of Excel sheets and PDFs.

- A thing that lets you catalogue Jupyter notebooks and Rstudio projects. I'm drowning in various projects from various data scientists and there's no nice way to centrally catalogue all those file lumps - 'there was this one function in this one project.... let's grep a bit' can be replaced by a central findable, searchable, taggable repository of data science projects.

> A thing that lets you catalogue Jupyter notebooks and Rstudio projects. I'm drowning in various projects from various data scientists and there's no nice way to centrally catalogue all those file lumps - 'there was this one function in this one project.... let's grep a bit' can be replaced by a central findable, searchable, taggable repository of data science projects.

Oh... oh my. This extends so far beyond data science for me and I am aching for this. I work in this weird intersection of agriculture/high-performance imaging/ML/aerospace. Among my colleagues we've got this huge volume of Excel sheets, Jupyter notebooks, random Python scripts and C++ micro-tools, and more I'm sure. The ones that "officially" became part of a project were assigned document numbers and archived appropriately (although they're still hard to find). The ones that were one-off analyses for all kinds of things are scattered among OneDrive folders, Zip files in OneDrive folders, random Git repos, and some, I'm sure, only exist on certain peoples' laptops.

Ha - I’m on the other side of the grant application process and used an LLM to make a tool to describe the project, track milestones, sub-contractors, generate a costed project plan and all generate the other responses that need to be self-consistent in the grant application process.

Ditto for most academic biomedical research: we desperately need more high quality customized code. Instead we have either nothing or Python/R code written by a grad student or postdoc—code that dies a quick death.

> then I would count that as "replaced 2 programmers"

Well then you can count IDEs, static typing, debuggers, version control etc. as replacing programmers too. But I don't think any of those performance enhancers have really reduced the number of programmers needed.

In fact it's a well known paradox that making a job more efficient can increase the number of people doing that job. It's called the Jevons paradox (thanks ChatGPT - probably wouldn't have been able to find that with Google!)

Making people 20% more efficient is very different to entirely replacing them.

I know it's popular to hate on Google, but a link to the Wikipedia is the first result I get for a Google search of "efficiency paradox".

As a founder, I think that this viewpoint misses the reality of a fixed budget. If I can make my team of 8 as productive as 10 with LLMs then I will. But that doesn’t mean that without LLMs I could afford to hire 2 more engineers. And in fact if LLMs make my startup successful then it could create more jobs in the future.

> I definitely expect them to improve. But I also think the point at which they can actually replace a senior programmer is pretty much the exact point at which they can replace any knowledge worker, at which point western society (possibly all society) is in way deeper shit than just me being out of a job.

Agree with this take. I think the probability that this happens within my next 20 years of work is very low, but are non-zero. I do cultivate skills that are a hedge against this, and if time moves on and the probability of this scenario seems to get larger and larger, I'll work harder on those skills. Things like fixing cars, welding, fabrication, growing potatoes, etc (which I already enjoy as hobbies). As you said, skills that are helpful if shit were to really hit the fan.

I think there are other "knowledge workers" that will get replaced before that point though, and society will go through some sort of upheaval as this happens. My guess is that capital will get even more consolidated, which is sort of unpleasant to think about.

im also expecting this outcome. my thoughts are that once devs are completely replaced by ml then were going to finally have to adapt society to raise the floor because we can no longer outcompete automation. im ready to embrace this, but it seems like there is no plan for mass retirement and were going to need it. if something as complicated as app and system dev is automated, pretty much anything can be.

earnest question because i still consider this a vague, distant future: how did you come up with 20 years?

That's around, give or take a few years, when I plan to retire. Don't care a whole lot what happens after that point :)

What if anti-aging technology is developed and you can live up to 1000 years?

I certainly am not in the 0.5% rich enough to be able to afford such a thing. If it does get developed (it won't in my lifetime), there's absolutely no way in hell it will be accessible to anyone but the ultra rich.

I think if you are either young or bound to retire in the next 5-10 years there's less worry. If you are young you can pivot easier (avoid the industry); if you are old you can just retire with enough wealth behind you.

Its the mid age people 35-45 yr olds that I think will be hit hardest by this if it eventuates. Usually at this point in life there's plenty of commitments (family, mortgage, whatever). The career may end before they are able to retire, but they are either too burdened with things; or ageism sets in making it hard to be adaptable.

I think you can look at any cohort (except for the people already at retirement age) and see a way that they're screwed. I'm 34 and I agree that you're right, but the 22 year old fresh out of college with a CS degree might have just gotten a degree in a field that is going to be turned inside out, in an economy that might be confused as we adapt. It's just too big of a hypothetical change to say who will get the most screwed, imo.

And like the parent poster said - even if you were to avoid the industry, what would you pivot to? Anything else you might go into would be trivial to automate by that point.

I think trades and blue collar work where experience learnt (the moat) is in the physical realm (not math/theory/process but dexerity and hands-on knowledge), where iteration/brute force costs too much money/causes too much risk is the place to be. If I get that building wrong unlike software where I can just "rebuild" it costs a lot of money in the real world and has risk like say "environmental damage". It means rapid iteration and development just doesn't happen which limits the exponential growth of AI in that area compared to the Digital world. Sure - in a lifetime we may have robots, etc but it will be a LOT more expensive to get there, and happen a lot slower and people can adjust. LLM's being 90% right are just not good enough - the cost of failure is too high and accountability in failure needs to occur.

Those industries also more wisely IMO tend to be unionised, own their own business, and so have the incentive to keep their knowledge tight. Even with automation the customer (their business) and the supplier (them and their staff) are the same so the value transfer of AI will make their job easier but they will keep the value. All good things to slow down progress and keep some economic rent for yourself and your family. Slow change is a less stressful life.

The intellectual fields lose in an AI world long term; the strong and the renter class (capital/owners) win. That's what "Intelligence is a commodity" that many AI heads keep saying actually means. This opens up a lot of future dystopian views/risks that probably aren't worth the benefit IMO to the majority of people that aren't in the above classes of people (i.e. most people).

The problem with software in general is that it is quite difficult generally to be a "long term" founder at least in my opinion for most people which means most employment comes from large corps/govt's/etc where the supplier (the SWE) is different than the employer. Most ideas generally don't make it or last only briefly, and the ones that stick around usually benefit from dealing with scale - something generally only larger corps have with their ideas (there are exceptions in new fields, but then they become the next large corp and there isn't enough for everyone to do this).

one side thing i want to point out. There is a lot of talk about llms not being able to replace a senior engineer... The implication being that they can replace juniors. How exactly do you get senior engineers when you've destroyed the entire market for junior engineers, exactly?

This.

When this moment becomes reality - the world economy will change a lot, all jobs and markets will shift.

And there won’t be any way to future proof your skills and they all will be irrelevant.

Right now many like to say “learn how to work with ai, it will be valuable “ . No, it won’t. Because even now it is absolutely easy to work with it, any developer can pick up ai in a week, and it will become easier and easier.

A better time spent is developing evergreen skills.

At my job I review a lot of code, and I write code as well. The only type of developer an LLM’s output comes close to is a fresh junior usually straight out of university in their first real development job, with little practical experience in a professional code-shipping landscape. And the majority of those juniors improve drastically within a few weeks or months, with handholding only at the very start and then less and less guidance. This is because I teach them to reason about their choices and approaches, to question assumptions, and thus they learn quickly that programming rarely has one solution to a problem, and that the context matters so much in determining the way forward.

A human junior developer can learn from this tutoring and rarely regress over time. But the LLM’s all by design cannot and do not rewire their understanding of the problem space over time, nor do they remember examples and lessons from previous iterations to build upon. I have to handhold them forever, and they never learn.

Even when they use significant parts of the existing codebase as their context window they’re still blind to the whole reality and history of the code.

Now just to be clear, I do use LLM’s at my job. Just not to code. I use them to parse documents and assist users with otherwise repetitive manual tasks. I use their strength as language models to convert visual tokens parsed by an OCR to grasp the sentence structure and convert that into text segments which can be used more readily by users. At that they are incredible, even something smaller like llama 7b.

That's a good observation. How would you teach an LLM the processes and conduct in your company? I suppose you'd need to replace code reviews and tutoring with prompt engineering. And hope that the next software update to the LLM won't invalidate your prompts.

It's not very different from documentation, except it's not used for learning but rather immediate application, i.e. it's something you must include with each prompt/interaction (and likely need a way to determine which are the relevant bits to reduce token count, depending on the size of the main prompt.) In fact, this is probably one of the more important aspects of adapting LLMs for real-world use within real team/development settings that people don't do. If you provide clear and comprehensive descriptions of codebase patterns, pitfalls, practices, etc the latest models are good at adhering to them. It sounds difficult and open-ended, as this requires content beyond the scope of typical (or even sensible) internal documentation, but much of this content is captured in internal docs, discussions, tickets, PR comments, and git commit histories, and guess what's pretty great at extracting high-level insights from these types of inputs?

This is at least the third time in my life that we've seen a loudly-heralded purported the-end-of-programming technology. The previous two times both ended up being damp squibs that barely mention footnotes in the history of computing.

Why do we expect that LLMs are going to buck this trend? It's not for accuracy--the previous attempts, when demonstrating their proof-of-concepts, actually reliably worked, whereas with "modern LLMs", virtually every demonstration manages to include "well, okay, the output has a bug here."

I do seem to vaguely remember a time when there was a fair amount of noise proclaiming "visual programming is making dedicated programmers obsolete." I think the implication was that now everybody's boss could just make the software themselves or something.

LLM's as a product feel practically similar, because _even if_ they could write code that worked in large enough quantities to constitute any decently complex application, the person telling them what problem to solve has to understand the problem space since the LLM's can't reason.

Given that neither of those things are true, it's not much different from visual programming tools, practically speaking.

This is a feeling I have too. However, compared to Visual Programming it's perhaps harder to dismiss? Visual programming - its pretty obvious you can't effectively or even at all step through a UML diagram with a debugger to find a problem. The code that gets generated from diagrams, with visual programming, is obviously cr*p. So the illusion doesn't last long. Whereas AI - it kind of looks OK, you can indeed debug it, its not necessarily more complex or worse than the hideously over-complex systems human teams create. Especially if the human team is mismanaged e:g original devs left, some got burnt out and became unproductive, others had to cut corners and make tech debt to hit unrealistic deadlines, other bits get outsourced to another country where the devs themselves are great but perhaps there's a language barrier or simply geographical distance means requirements and domain understanding got lost somewhere in the mix. So, I suppose I sit on the fence, AI-generated code may be terrible but is it worse than what we were making anyway? ;). In the future there are probably going to be companies run by "unwise people" that generate massive amounts of their codebase then find themselves in a hole when no-one working at the company understands the code at all. (whereas in the past perhaps they could hire back a dev they laid off on large contractor rates of pay to save the day). Seems inevitable one day the news will be of some high profile company failure and/or tanking of stock caused by a company basically not knowing what it was doing due to AI generated code.

I wonder how programmers of the time felt when spreadsheets got popular.

We used spreadsheets too, and found them useful, but not very threatening

I use spreadsheets a lot, and often they end up serving as an MVP «prototype» until it’s obvious I need a proper database and custom UI, then build an application for the task instead.

> > LLM’s never provide code that pass my sniff test

> This is ego speaking.

That's been my experience of LLM-generated code that people have submitted to open source projects I work on. It's all been crap. Some of it didn't even compile. Some of it changed comments that were previously correct to say something untrue. I've yet to see a single PR that implemented something useful.

Isn't this a kind of survivor bias? You wouldn't know if you approved (undisclosed) LLM-generated code that was good..

Good LLM-generated code comes from good developers that can provide detailed requests, filter through wrong/misleading/cruft results, and test a final working copy. If your personal bar for PRs is high enough then it won't matter if you use AI or not because you won't contribute shitty results.

I think the problem has become people with no bar for quality submitting PRs that ruin a repo, and then getting mad when it's not merged because ChatGPT reviewed the patch already.

> LLM-generated code that people have submitted to open source projects I work on

Are you sure it was people? Maybe the AI learned how to make PRs, or is learning how to do so by using your project as a test bed.

Terrible software engineers sent you terrible code. A good software engineer will obviously send you good quality code, whether he used AI for that is impossible to tell on your end.

I agree with you tbh, and it also just misses something huge that doesnt get brought up: its not about your sniff test, its about your bosses sniff test. Are you making 300k a year? Thats 300 thousand reasons to replace you for a short term boost in profit, companies love doing that.

I'm in a leadership role and one of the primary parties responsible for hiring. So code passing my sniff test is kind of important.

To bring it back to the question that spawned the ask: One thing to future proof a career as a SWE is to get into business and leadership/management as well as learning how to program. If you're indispensable to the business for other reasons, they'll keep you around.

in that case the conversation is still kind of missing the forest for the trees, yes your career will be safer if you get into management but thats not going to play for everyone. Mathematically, it cant, not every engineer can go be a manager. What Im interested in is the stories of the people who arent going to make it.

ego? LLMs goof on basic math and cant even generate code for many non public things. theyre not useful to me whatsoever

This... for my most important use case (applied numerical algorithms) it is in fact beyond not useful, it is negative value - even for highly available methods’ codes.

Sure, I can ask for it to write (wrong) boilerplate but it is hardly where work ends. It is up to me to spend the time doing careful due diligence at each and every step. I could ask for it to patch each mistake but, again, it relies on a trained, skillful, many times formally educated domain expert on the other end puppeteering the generative copywriter.

For the many cases where computer programming is similar to writing boilerplate, it could indeed be quite useful but I find the long tail of domain expertises will always be outside the reach of data-driven statistical learners.

LLMs aren't supposed to do basic math, but be chat agents. Wolfram Alpha can't do chat.

Math is a major part of programming. In fact programming without math is impossible. And if you go all the way down to bare metal it’s all math. We are shifting bits through incredibly complex abstractions.

No, math is major part of writing good code, but when was the last time you've seen somebody put effort into writing O(n) algorithm? 99% of programming is "import sort from sort; sort.sortThisReallyQuick". Programming is mostly writing code that just compiles and eventually gives correct results (and has bugs). You can do a lot of programming just buy copy-pasting results from stackoverflow.

https://en.wikipedia.org/wiki/Npm_left-pad_incident

https://old.reddit.com/r/web_design/comments/35prfv/designer...

https://www.youtube.com/watch?v=GC-0tCy4P1U

In any real-world application you'll sooner than later run into optimization challenges where if you don't understand the foundational challenges, googling "fastly do the thing" won't help you ;)

Much like asking an LLM to solve a problem for you.

Most optimization you do as a software engineer is about figuring out what you do not need to do, no math involved.

You aren't going around applying novel techniques of numerical linear algebra.

No, math can describe programming, but that's also true of everything. You wouldn't say "Playing basketball without math is impossible" even though it's technically true because you don't need to know or use math to play basketball. You also can do a ton of programming without knowing any math, although you will more than likely need to learn arithmetic to write enterprise code.

Has never been true in my experience, almost all programming can be done without any mathematics. Of course very specific things do require mathematics, but they are uncommon and often solved by specialists.

Btw. I come from a math background and later went into programming.

> ChatGPT was only just released in 2022.

Bitcoin was released in what year? I still cannot use it for payments.

No-code solutions exist since when? And still programmers work...

I dont think all hyped techs are fads. For instance: we use SaaS now instead of installing software locally. This transition took the world by storm.

But those tech that needs lots of ads, and lots of zealots, and make incredible promises: they usually are fads.

> For instance: we use SaaS now instead of installing software locally.

If anything, I feel like this argument works against you. If people are willing to replace locally installed software with shitty web "apps" that barely compare, why do you think they won't be willing to replace good programmers with LLMs doing a bad job simply because it's trendy?

SaaS has generally been better than the local apps it replaced, particularly when you factor in 'portability'.

I love local apps but it's undeniable that developers having to split their attention between platforms lowered quality by a lot. You're probably remembering the exemplars, not the bulk which half-worked and looked bad too

Just look at the job market: how many programmers work in SaaS now compared to 2000?

Cryptocurrency more broadly can be used to send vast amounts of money, anywhere in the world for near-zero fees regardless of sovereignty. And Bitcoin is still faster and cheaper than shipping gold around.

> Is there some expectation that these things won't improve?

Sure. But the expectation is quantitative improvement - qualitative improvement has not happened, and is unlikely to happen without major research breakthroughs.

LLMs are useful. They still need a lot of supervision & hand holding, and they'll continue to for a long while

And no, it's not "ego speaking". It's long experience. There is fundamentally no reason to believe LLMs will take a leap to "works reliably in subtle circumstances, and will elicit requirements as necessary". (Sure, if you think SWE work is typing keys and make some code, any code, appear, then LLM are a threat)

The reason it's so good at "rewrite this C program in Python" is because it was trained on a huge corpus of code at GitHub. There is no such corpus of examples of more abstract commands, thus a limited amount by which it can improve.

> I am constantly surprised how prevalent this attitude is. ChatGPT was only just released in 2022. Is there some expectation that these things won't improve?

I mean, in a way, yeah.

Last 10 years were basically one hype-cycle after another filled with lofty predictions that never quite panned out. Besides the fact that many of these predictions kind of fell short, there's also the perception that progress on these various things kind of ground to a halt once the interest faded.

3D printers are interesting. Sure, they have gotten incrementally better after the hype cycle died out, but otherwise their place in society hasn't changed, nor will it likely ever change. It has its utility for prototyping and as a fun hobbyist machine for making plastic toys, but otherwise I remember people saying that we'd be able to just 3D print whatever we needed rather than relying on factories.

Same story with VR. We've made a lot of progress since the first Oculus came out, but otherwise their role in society hasn't changed much since then. The latest VR headsets are still as useless and still as bad for gaming. The metaverse will probably never happen.

With AI, I don't want to be overly dismissive, but at the same time there's a growing consensus that pre-training scaling laws are plateauing, and AI "reasoning" approaches always seemed kind of goofy to me. I wouldn't be surprised if generative AI reaches a kind of equilibrium where it incrementally improves but improves in a way where it gets continuously better at being a junior developer but never quite matures beyond that. The world's smartest beginner if you will.

Which is still pretty significant mind you, it's just that I'm not sure how much this significance will be felt. It's not like one's skillset needs to adjust that much in order to use Cursor or Claude, especially as they get better over time. Even if it made developers 50% more productive, I feel like the impact of this will be balanced-out to a degree by declining interest in programming as a career (feel like coding bootcamp hype has been dead for a while now), a lack of enough young people to replace those that are aging out, the fact that a significant number of developers are, frankly, bad at their job and gave up trying to learn new things a long time ago, etc etc.

I think it really only matters in the end if we actually manage to achieve AGI, once that happens though it'll probably be the end of work and the economy as we know it, so who cares?

I think the other thing to keep in mind is that the history of programming is filled with attempts to basically replace programmers. Prior to generative AI, I remember a lot of noise over low-code / no-code tools, but they were just the latest chapter in the evolution of low-code / no-code. Kind of surprised that even now in Anno Domini 2024 one can make a living developing small-business websites due to the limitations of the latest batch of website builders.

The funny thing about 3D printers is that they're making a bit of a comeback. The early ones managed to get the capabilities right - you can print some really impressive things on the older Creality printers, but it required fiddling, several hours of building the bloody things, cogged extruders, manual bed leveling and all sorts of technical hurdles. A very motivated techy person will persevere and solve them, and will be rewarded with a very useful machine. The other 99.99% of people won't and will either drop it the moment there's an issue or will hear from others that they require a lot of fiddling and never buy one. If things ever get more complicated than "I see it on a website and I click a few buttons" (incl maintenance) then it's too complicated to gain mass adoption... which is exactly what newer 3D printers are doing - the Bambulabs A1 Mini is £170, prints like a champ, is fairly quiet, requires next to no setup, takes up way less space than the old Enders and needs almost no maintenance. It's almost grandma-proof. Oh, and to further entice your grandma to print, it comes with all sorts of useful knick-knacks that you can start printing immediately after setup. On the hype cycle curve I think 3D printers are almost out of their slump now that we have models that have ironed out the kinks.

But for VR I think we're still closer to the bottom of the curve - Meta and Valve need something to really sell the technology. The gamble for Valve was that it'd be Half Life: Alyx, and for Meta it was portable VR but the former is too techy to set up (and Half Life is already a nerdy IP) while Meta just doesn't have anything that can convince the average person to get a headset (despite me thinking it's a good value just as a Beat Saber machine). But they're getting there - I've convinced a few friends to get a Quest 3S just to practice piano with Virtuoso and I think it's those kinds of apps I hope we see more of that will bring VR out of the slump.

And then LLMs I think their hype cycle is a lot more elevated since even regular people use them extensively now. There will probably be a crash in terms of experimentation with them but I don't see people stopping their usage and I do see them becoming a lot more useful in the long term - how and when is difficult to predict at the top of the hype curve.

Like I said, 3D printers have gotten incrementally better. Buddy of mine makes high-quality prints on one that’s way cheaper than what I owned back in the day.

And yet nothing has really changed because he’s still using it to print dumb tchotchkes like every other hobbyist 10 years ago.

I can foresee them getting better but never getting good enough to where they actually fundamentally change society or live up to past promises

>> > LLM’s never provide code that pass my sniff test

> This is ego speaking.

Consider this, 100% of AI training data is human-generated content.

Generally speaking, we apply the 90/10 rule to human generated content: 90% of (books, movies, tv shows, software applications, products available on Amazon) is not very good. 10% shines.

In software development, I would say it's more like 99 to 1 after working in the industry professionally for over 25 years.

How do I divorce this from my personal ego? It's easy to apply objective criteria:

- Is the intent of code easy to understand?

- Are the "moving pieces" isolated, such that you can change the implementation of one with minimal risk of altering the others by mistake?

- Is the solution in code a simple one relative to alternatives?

The majority of human produced code does not pass the above sniff test. Most of my job, as a Principal on a platform team, is cleaning up other peoples' messes and training them how to make less of a mess in the future.

If the majority of human generated content fails to follow basic engineering practices that are employed in other engineering disciplines (i.e: it never ceases to amaze me how much of an uphill battle it is just to get some SWEs just to break down their work into small, single responsibility, easily testable and reusable "modules") then we can't logically expect any better from LLMs because this is what they're being trained on.

And we are VERY far off from LLMs that can weigh the merits of different approaches within the context of the overall business requirements and choose which one makes the most sense for the problem at hand, as opposed to just "what's the most common answer to this question?"

LLMs today are a type of magic trick. You give it a whole bunch of 1s and 0s so that you can input some new 1s and 0s and it can use some fancy proability maths to predict "based on the previous 1s and 0s, what are the statistically most likely next 1s and 0s to follow from the input?"

That is useful, and the result can be shockingly impressive depending on what you're trying to do. But the limitations are so limited that the prospect of replacing an entire high-skilled profession with that magic trick is kind of a joke.

> That is useful, and the result can be shockingly impressive depending on what you're trying to do. But the limitations are so limited that the prospect of replacing an entire high-skilled profession with that magic trick is kind of a joke.

The possible outcome space is not binary (at least in the near term), i.e. either AI replace devs, or it doesn't.

What I'm getting at is this: There's a pervasive attitude among some developers (generally older developers, in my experience) that LLM's are effectively useless. If we're being objective, that is quite plainly not true.

These conversations tend to start out with something like: "Well _my_ work in particular is so complex that LLM's couldn't possibly assist."

As the conversation grows, the tone gradually changes to admitting: "Yes there are some portions of a codebase where LLM's can be helpful, but they can't do _everything_ that an experienced dev does."

It should not even be controversial to say, that AI will only improve at this task. That's what technology does, over the long run.

Fundamentally, there's ego involved whenever someone says "LLM's have _never_ produced useable code." That statement, is provably false.

Your customers don't care how your code smells, as long as it solves their problem and doesn't cost an arm and a leg.

A ton of huge business full of Sr Principal Architect SCRUM masters are about to get disrupted by 80 line ChatGPT wrappers hacked together by a few kids in their dorm room.

> Your customers don't care how your code smells, as long as it solves their problem and doesn't cost an arm and a leg.

Software is interesting because if you buy a refrigerator, even an inexpensive one, you have certain expectations as to its basic functions. If the compressor were to cut out periodically in unexpected ways, affecting your food safety, you would return it.

But in software customers seem to be conditioned to just accept bugs and poor performance as a fact of life.

You're correct that customers don't care about "code quality", because they don't understand code or how to evaluate it.

But you're assuming that customers don't care about the quality of the product they are paying for, and you're divorcing that quality from the quality of the code as if the code doesn't represent THE implementation of the final product. The hardware matters too, but to assume that code quality doesn't directly affect product quality is to pretend that food quality is not directly impacted by its ingredients.

Code quality does not affect final product quality IMHO.

I worked in companies with terrible code, that deployed on an over-engineered cloud provider using custom containers hacked with a nail and a screwdriver, but the product was excellent. Had bugs here and there, but worked and delivered what needs to be delivered.

SWEs need to realize that code doesn't really matter. For 70 years we are debating the best architecture patterns and yet the biggest fear of every developer is working on legacy code, as it's an unmaintainable piece of ... written by humans.

> Code quality does not affect final product quality IMHO.

What we need, admittedly, is more research and study around this. I know of one study which supports my position, but I'm happy to admit that the data is sparse.

https://arxiv.org/abs/2203.04374

From the abstract:

"By analyzing activity in 30,737 files, we find that low quality code contains 15 times more defects than high quality code."

The parent point isn't that shitty code doesn't have defects but rather that there's usually a big gap between the code (and any defects in that code) and the actual service or product that's being provided.

Most companies have no relation between their code and their products at all - a major food conglomerate will have hundreds or thousands of IT personnel and no direct link between defects in their business process automation code (which is the #1 employment of developers) and the quality of their products.

For companies where the product does have some tech component (e.g. refrigerators mentioned above) again, I'd bet that most of that companies developers don't work on any code that's intended to be in the product, in such a company there simply is far more programming work outside of that product than inside of one. The companies making a software-first product (like startups on hackernews) where a software defect implies a product defect are an exception, not the mainstream.

It doesn't matter.. Until it does.

Having poor quality code makes refactoring for new features harder, it increases the time to ship and means bugs are harder to fix without side effects.

It also means changes have more side effects and are more likely to contain bugs.

For an MVP or a startup just running off seed funding? Go ham with LLMs and get something in front of your customers, but then when more money is available you need to prioritise making that early code better.

Much like science in general, these topics are never -- and can never be -- considered settled. Hence why we still experiment with and iterate on architectural patterns, because reality is ever-changing. The real world from whence we get our input to produce desired output is always changing and evolving, and thus so are the software requirements.

The day there is no need to debate systems architecture anymore is the heat death of the universe. Maybe before that AGI will be debating it for us, but it will be debated.

Code quality absolutely does matter, because when everything is on fire and your service is down and no one is able to fix it customers WILL notice.

I've seen plenty of companies implode because they fired the one guy that knew their shitty codebase.

> Consider this, 100% of AI training data is human-generated content.

Probably doesn't change the conclusion, but this is no longer the case.

I've yet to try Phi-4, but the whole series has synthetic training data; I don't value Phi-3 despite what the benchmarks claim.

They shouldn’t be expected to improve in accuracy because of what they are and how they work. Contrary to what the average HackerNews seems to believe, LLMs don’t “think,” they just predict. And there’s nothing in them that will constrain their token prediction in a way that improves accuracy.

If anything, they may regress due to being trained on lower-quality input.

> Contrary to what the average HackerNews seems to believe, LLMs don’t “think,” they just predict.

Anecdotally, I can't recall ever seeing someone on HackerNews accuse LLM's of thinking. This site is probably one of the most educated corners of the internet on the topic.

> They shouldn’t be expected to improve in accuracy because of what they are and how they work.

> And there’s nothing in them that will constrain their token prediction in a way that improves accuracy.

These are both incorrect. LLM's are already quite better today than they were in 2022.

> I can’t recall ever seeing someone on HackerNews accuse LLMs of thinking.

There are definitely people here who think LLMs are conscious.

https://news.ycombinator.com/item?id=41959163

> Is there some expectation that these things won't improve?

Yes. The current technology is at a dead end. The costs for training and for scaling the network are not sustainable. This has been obvious since 2022 and is related to the way in which OpenAI created their product. There is no path described for moving from the current dead end technology to anything that could remotely be described as "AGI."

> This is ego speaking.

This is ignorance manifest.

LLMs as they currently exist will never yield a true, actually-sentient AI. maybe they will get better in some ways, but it's like asking if a bird will ever fly to the moon. Something else is needed.

A bird can fly to moon if it keeps on improving every month.

it literally cannot though, unless it becomes some other form of life that doesn't need oxygen, that's the whole thing with this analogy, it's ironically suited to the discourse

Ha I didn't even count oxygen in the mix; it could hold its breath maybe? j/k, what's for sure is that I don't see how a biological entity could ever achieve escape velocity from self-powered flight, because, well, physics.

That, or they "keep improving every month" til they become evolved enough to build rockets, at which point the entire point of them being birds becomes moot.

It would need to: * Survive without oxygen * Propel itself without using wings * Store enough energy for the long trip and upkeep of the below * Insulation that can handle the radiation and temperature fluctuations * Have a form of skin that can withstand the pressure change from earth to space and then the moon * Have eyes that don't pop while in space

It would need to become something literally extraterrestrial that has not evolved in the 3.7b+ years prior.

I wouldn't say it's impossible, but if evolution ever got there that creature would be so far removed from a bird that I don't think we'd recognize it :p

no ego but incompetence :)

>This is ego speaking.

Very much so. These things are moving so quickly and agentic systems are already writing complete codebases. Give it a few years. No matter how 1337 you think you are, they are very likely to surpass you in 5-10 years.

> agentic systems are already writing complete codebases

Examples?

Have you ever used LLMs to generate code? It's not good enough yet.

In addition to this, most companies aren't willing to give away all off their proprietary IP and knowledge through 3rd party servers.

It will be awhile before engineering jobs are at risk.

> This is ego speaking.

I suspect you haven't seen code review at a 500+ seat company.

100% and even if they might not "replace" a senior or staff SWE, they can make their job significantly easier which means that instead of requiring 5 Senior or Staff you will only need two.

LLM WILL change the job market dynamics in the coming years. Engineers have been vastly overpaid over the last 10 years. There is no reason to not see a reversal to the mean here. Getting a 500k offer from a FAANG because you studied leetcode for a couple weeks is not going to fly anymore.

“which means that instead of requiring 5 Senior or Staff you will only need two”

What company ever feels they have “enough” engineers? There’s always a massive backlog of work to do. So unless you are just maintaining some frozen legacy system, why would you cut your team size down rather than doubling or tripling your output for the same cost? Especially considering all your competitors have a similar productivity boost available. If your reaction is to cut the team rather than make your product better at a much faster rate (or build more products), you will likely be outcompeted by others willing to make that investment.

LLMs are great for simple, common, boring things.

As soon as you have something less common, it will give you widely incorrect garbage that does not make any sense. Even worse, it APPEARS correct, but it won’t work or will do something else completely.

And I use 4o and o1 every day. Mostly for boilerplate and boring stuff.

I have colleagues that submit ChatGPT generated code and I’ll immediately recognize it because it is just very bad. The colleague would have tested it, so the code does work, but it is always bad, weird or otherwise unusual. Functional, but not nice.

ChatGPT can give very complicated solutions to things that can be solved with a one-liner.

> This is ego speaking.

It absolutely isn't. I have yet to find an area where LLM-generated code solves the kinds of problems I work on more reliably, effectively, of efficiently than I do.

I'm also not interested in spending my mental energy on code reviews for an uncomphrehending token-prediction golem, let alone finding or fixing bugs in the code it blindly generates. That's a waste of my time and a special kind of personal hell.

Comments like these make me wonder whether we live in the same worlds.

I'm a cursor user e.g. and Tab completion is by far the most powerful auto complete I've ever used.

There's scenarios where you can do some major refactors by simply asking (extract this table to its own component while using best react practices to avoid double renders) and it does so istantly. Refactor the tests for it? Again. Semi instant. Meanwhile monocole wielding "senior" is proudly copy pasting, creating files and fixing indentation as I move to the next task.

I don't expect LLMs to do the hard work, but to speed me up.

And people ignoring LLMs are simply slower and less productive.

It's a speed multiplier right now, not a substitute.

If you complain that you don't like the code, you're not understanding the tools nor you can use them, end of story.

Sounds like you’re working in react. The models are orders of magnitude worse at less common frameworks and/or languages. React is so boilerplate-heavy that it’s almost a perfect match for LLMs. That said, every large react codebase I’ve worked in inevitably became really complex and had a ton of little quirks and tweaks to deal with unexpected re-renders and such. I avoid the FE when I can these days, but I’d be fairly surprised if LLMs generated anything other than typical performance-footgun-heavy react

Not in my experience, claude seems great at writing idiomatic and performant react. You can even highlight code and ask it to spot performance issues and it will tell you where you can improve rendering efficiency etc.

That's interesting. I haven't tried it, and my day job moved on from React some time ago. Most of what I do these days is Rust, which all the models I've tried are pretty miserable at.

A bunch of people with hurt egos responding in this thread; a pleasure to read.

Even since ChatGPT 3.5 AI coding has been astoundingly good. Like you, I'm totally baffled by developers who say it's not. And I'm not just unskilled and unable to judge. I have 35yrs experience! I've been shocked and impressed from day one, how good AI is. I've even seen Github Copilot do thing that almost resemble mind-reading insofar as predicting what I'm about to type next. It predicts some things it should NOT be able to predict unless it's seeing into the future or into parallel universes or something! And I'm only half joking when I speculate that!

This just shows that time spent is not the same as wisdom.

Even ChatGPT 3.5 had "wisdom", so you're definitely wrong.

Yeah I feel like this is just the beginning.

I'm in my 40s with a pretty interesting background and I feel like maybe I'll make it to retirement. There are still mainframe programmers after all. Maintaining legacy stuff will still have a place.

But I think we'll be the last generation where programmers will be this prevalent and the job market will severely contract. No/low code solutions backed by llms are going to eat away at a lot of what we do, and for traditional programming the tooling we use is going to improve rapidly and greatly reduce the number of developers needed.

> Is there some expectation that these things won't improve?

Most of the noise I hear about LLMs is about expectations that things will improve. It's always like that: people extrapolate and get money from VCs for that.

The thing is: nobody can know. So when someone extrapolates and says it's likely to happen as they predict, they shouldn't be surprised to get answers that say "I don't have the same beliefs".

when people's entire livehoods are threatened, you're going to see some defensive reactions.

That’s short term thinking in my opinion. LLMs will not replace developers by writing better code: it’s the systems we work on that will start disappearing.

Every SaaS, marketplace is at risk of extinction, superseded by AI agents communicating ad-hoc. Management and business software replaced by custom, one-off programs built by AI. The era of large teams painstakingly building specialized software for niche use cases will end. Consequently we’ll have millions of unemployed developers, except for the ones maintaining the top level orchestration for all of this.

> most of the actual systems we work on will simply start disappearing.

What systems do you think are going to start disappearing? I'm unclear how LLMs are contributing to systems becoming redundant.

Not parent poster, but I imagine it will be a bit like the horror stories of companies (ab)using spreadsheets in lieu of a proper program or database: They will use an LLM to get half-working stuff "for free" and consider it a bargain, especially if the detectable failures can be spot-fixed by an intern doing data-entry.

I think we'll see it first in internal reporting tools, where the stakeholder tries to explain something very specific they want to see (logical or not) and when it's visibly wrong they can work around it privately.

> Not parent poster, but I imagine it will be a bit like the horror stories of companies (ab)using spreadsheets in lieu of a proper program or database: They will use an LLM to get half-working stuff "for free" and consider it a bargain, especially if the detectable failures can be spot-fixed by an intern doing data-entry.

When I read things like this I really wonder if half of the people on HackerNews have ever held a job in software development (or a job at all to be fair).

None of what you describe is even remotely close to reality.

Stuff that half works gets you fully fired by the client.

If you can't even believe that kludgy-shit exists out there in the world, then it sounds like you've led a sheltered existence climbing within a very large engineering department of a well-funded company.

Do you perhaps have any friends at companies which hired overseas contractors? Or system-admins working at smaller companies or nonprofits? They're more-likely to have fun stories. I myself remember a university department with a master all_students.xls file on a shared drive (with way too many columns and macros in it) that had to be periodically restored from snapshots every time it got corrupted...

Are you sure you read the post you’re quoting correctly? They’re talking about companies that don’t have custom software at all, and cobble together half-working buggy spreadsheets and call the problem solved. Then the developers (either FT or contract) have to come in and build the tool that kills the spreadsheeet, once it gets too unwieldy.

I have seen the above story play out literally dozens of times in my career.

I think a lot of CRUD apps will disappear. A lot of the infrastructure may also be done by AI instead of some dude writing tons of YAML code.

The infrastructure is not a 'some dude writing tons of YAML code'.

CRUD apps should already be disappearing. You should be using a framework that auto-generates the boilerplate stuff.

> I think a lot of CRUD apps will disappear

How does that make any sense? How is AI, and especially GenAI, something that is by definition fallible, better in ANY way than current frameworks that allow you to write CRUD applications deterministically with basically one line of code per endpoint (if that)?

Recovering enterprise SaaS PM here. I don't necessarily know that a lot of enterprise SaaS will disappear, but I do think that a lot of the companies that build it will go out of business as their customers start to build more of their internal systems with LLMs vs. buy from an existing vendor. This is probably more true at the SMB level for now than actual enterprise, both for technical and internal politics reasons, but I expect it to spread.

As a direct example from myself, I now acquire and run small e-commerce brands. When I decided to move my inventory management from Google Sheets into an actual application, I looked at vendors but ultimately just decided to build my own. My coding skills are pretty minimal, but sufficient that I was able to produce what I needed with the help of LLMs. It has the advantages of being cheaper than buying and also purpose-built to my needs.

So yeah, basically the tl;dr is that for internal tools, I believe that LLMs giving non-developers sufficient coding skills will shift the build vs. buy calculus squarely in the direction of build, with the logical follow-on effects to companies trying to sell internal tools software.

Long-time enterprise SaaS PM here, and sorry, this does not make any sense. The SMB segment is likely to be the least exposed to AI, and software, and the concept of DIY software through AI.

As you visualize whole swaths of human workers getting automated away, also visualize the nitty gritty of day-to-day work with AI. If it gets something wrong, it will say "I apologize" until you, dear user, are blue in the face. If an actual person tried to do the same, the blueness would instead be on their, not your, face. Therein lies the value of a human worker. The big question, I think, is going to be: is that value commensurate to what we're making on our paycheck right now?

> If it gets something wrong, it will say "I apologize" until you, dear user, are blue in the face. If an actual person tried to do the same, the blueness would instead be on their, not your, face. Therein lies the value of a human worker.

The value of a human worker is in a more meaningful apology? I think the relevant question here is who's going to make more mistakes, not who's going to be responsible when they happen. A good human is better than AI today, but that's not going to last long.

> go out of business as their customers start to build more of their internal systems with LLMs vs. buy from an existing vendor.

there is going to be so much money to make as a consultant fixing these setups, I can't wait!

There is absolutely going to be a golden window of opportunity in which a person who understands LLMs can sell zero-effort, custom-crafted software to SMBs at the most insane margins of any business ever.

For trivial setups this might work, but for anything sufficiently complex that actually hits on real complexity in the domain, it's hard to see any LLM doing an adequate job. Especially if the person driving it doesn't know what they don't know about the domain.

> For trivial setups this might work, but for anything sufficiently complex that actually hits on real complexity in the domain, it's hard to see any LLM doing an adequate job.

I mostly agree with this for now, but obviously LLMs will continue to improve and be able to handle greater and greater complexity without issue.

> Especially if the person driving it doesn't know what they don't know about the domain.

Sure, but if the person driving it doesn't know what they're doing, they're also likely to do a poor job buying a solution (getting something that doesn't have all the features they need, selecting something needlessly complex, overpaying, etc.). Whether you're building or buying a piece of enterprise software, you want the person doing so to have plenty of domain expertise.

Amazing to see this comment downvoted. You're spot on, and I even think the feasible use cases will quickly move from internal tools to real line of business software. People are in denial or really have no idea what's coming.

you do realize that these so called "one-off" AI programs would need to be maintained? Most people paying for Saas are paying for the support/maintenance rather than features, which AI can't handle. No one will want to replace any Saas they depend on with a poorly generated variant that they want to maintain

Most people don’t want cloud hosted subscription software, we do it that way because VCs love vendor lock in and recurring revenue.

Old school desktop software takes very little maintenance. Once you get rid of user tracking, AB testing, monitoring, CICD pipelines, microservices, SOC, multi tenant distributed databases, network calls and all the other crap things get pretty simple.

There was a vulnerability of 7-zip found in Nov, 2024.

Yes, 7-zip.

https://cert.europa.eu/publications/security-advisories/2024...

1. If everyone is running custom written software that's not shared with anyone else if will be really hard to find vulnerabilities in them

2. I'm sure LLMs are already way better at detecting vulnerabilities than the average engineer. (when asked to do so explicitly)

Nah, you only write it and it runs by itself forever in the AI cloud.

Sometimes I wonder if people saying this stuff have actually worked in development at all.

Thinking of it in terms of code is why the idea sounds ridiculous. AI won't make you a Django app and deploy to the cloud (though you can also do that), systems will be built based on pipelines and automation, integrations, just-in-time UI or conversational interfaces. Similar to the no-code platforms of today.

You can go further: Which business will bet its entire existence, let alone finances, to an "AI" (Companies are literally writing "don't rely on X LLM outputs as medical, legal, financial, or other professional advice"?

"Nothing because I’m a senior and LLM’s never provide code that pass my sniff test, and it remains a waste of time"

That's why the question is future proof. Models get better with time, not worse.

Models don’t get better just by time passing. The specific reasons for why they’ve been getting better don’t necessarily look like they’ll extend indefinitely into the future.

If the last-mile problems of things like autonomous vehicles have been anything to go by, it seems the last mile problems of entrusting your entire business operations to complete black box software, or software written by a novices talking to complete black box, will be infinitely worse.

There's plenty of low-code, no-code solutions around, and yet still lots of software. The slice of the pie will change, but it's very hard to see it being eliminated entirely.

Ultimately it's going to come down to "do I feel like I can trust this?" and with little to no way to be certain you can completely trust it, that's going to be a harder and harder sell as risk increases with the size, complexity, and value of the business processes being managed.

Even if seniors still do the last mile, that’s a significant reduction from the full commute they were paid for previously. Are you saying seniors should concede this?

No, I think there's cases in which if you can't do the last mile, you aren't entrusted to do the first either.

It's astounding that basically every response you give is just "it can't happen to me". The actual answer to the OP's question for you is a resounding: "nothing".

More or less. I'm just going to enjoy the ride of what becomes of the industry until I either retire or just go do something else with my life.

I already had my panic moment about this like 2 years ago and have calmed down since then. I feel a lot more at peace than I did when I was thinking AGI was right around the corner and trying to plan for a future where no matter what course of action I took to learn new skills to outpace the AI I was already too late with my pivot because the AI would also become capable at doing whatever I was deciding to switch to on a shorter timeline than It would take me to become proficient in it.

If you at all imagine a world where the need for human software engineers legit goes away, then there isn't likely much for you to do in that world anyway. Maybe except become a plumber.

I don't think AGI is this magic silver bullet Silicon Valley thinks it is. I think, like everything in engineering, it's a trade-off, and I think it comes with a very unpalatable caveat. How do you learn once you've run out of data? By making mistakes. End of the day I think it's in the same boat as us, only at least we can be held accountable.

Compilers weren't trusted in the early days either.

LLMs are not the right tool for the job, so even if some marginal bits can be improved, it fundamentally cannot "get better".

The job of a software engineer is to first understand the real needs of the customer/user, which requires a level of knowledge and understanding of the real world that LLMs simply don't have and will never do because that is simply not what it does.

The second part of a software engineer's job is to translate those needs into a functional program. Here the issue is that natural languages are simply not precise enough for the kind of logic that is involved. This is why we invented programming languages rather than use plain English. And since the interface of LLMs is by definition human (natural) languages, it fundamentally will always have the same flaws.

Any precise enough interface for this second part of the job will by definition just be some higher level programming language, which not only involves an expert of the tool anyway, but also is unrealistic given the amount of efforts that we already collectively invest into getting more productive languages and frameworks to replace ourselves.

> Models get better with time, not worse

A decade (almost?) ago, people were saying "look at how self-driving cars improved in the last 2 years: in 3-5 years we won't need to learn how to drive anymore". And yet...

Hard to believe anyone is getting contacted more now than in 2020. But I agree with the general sentiment. I'll do nothing and if I get replaced then I get replaced and switch to woodworking or something. But if LLMs do not pan out then I'll be ahead of all the people who wasted their time with that.

The sanest comment here.

> But I think that’s generations away at best.

I'm not sure whether you mean human generations or LLM generations, but I think it's the latter. In that case, I agree with you, but also that doesn't seem to put you particularly far off from OP, who didn't provide specific timelines but also seems to be indicating that the elimination of most engineers is still a little ways away. Since we're seeing a new generation of LLMs every 1-2 years, would you agree that in ~10 years at the outside, AI will be able to do the things that would cause you to gladly retire?

I mean human generations because to do system architecture, design and development well you need something that can at least match an average human brain in reasoning, logic and learning plasticity.

I don’t think that’s impossible but I think we’re quite a few human generations away from that. And scaling LLM’s is not the solution to that problem; an LLM is just a small but important part of it.

I'd be cautious as describing anything in tech as human generations away because we're only about a single human generation into a lot of this industry existing.

I understand the hesitancy to do so, but the thing is, what's changed with computers since the inception of the technology is speed and size. The fundamentals are still the same. Programming today is a lot more convenient than programming via punch cards, but it's a matter of abstractions + scale + speed. Given this I'm pretty confident when I say that, but obviously not 100%.

+1 to this sentiment for now, I give them a try every 6 months or so to see how they advance. And for pure code generation, for my workflow, I don't find them very useful yet. For parsing large sets of documentation though, not bad. They haven't creeped their way into my usual research loop just yet, but I could see that becoming a thing.

I do hear some of my junior colleagues use them now and again, and gain some value there. And if llm's can help get people up to speed faster that'd be a good thing. Assuming we continue to make the effort to understand the output.

But yeah, agree, I raise my eyebrow from time to time, but I don't see anything jaw dropping yet. Right now they just feel like surrogate googler's.

> If there’s ever a day where there’s an AI that can do these things, then I’ll gladly retire. But I think that’s generations away at best.

People really believe it will be generations before an AI will approach human level coding abilities? I don't know how a person could seriously consider that likely given the pace of progress in the field. This seems like burying your head in the sand. Even the whole package of translating high level ideas into robust deployed systems seems possible to solve within a decade.

I believe there will still be jobs for technical people even when AI is good at coding. And I think they will be enjoyable and extremely productive. But they will be different.

I've heard similar statements about human translation - and look where the translators are now

This is a fascinating comment, because it shows such a mis-reading of the history and point of technology (on a tech forum). Technological progress always leads to loss of skilled labor like your own, usually resulting in lower quality (but higher profits and often lower prices). Of COURSE an LLM won't be able to do work as well as you, just as industrial textile manufacturing could not, and still does not, produce the quality of work of 19th century cottage industry weavers; that was in fact one of their main complaints.

As an aside, at the top of the front page right now is a sprawling essay titled "Why is it so hard to buy things that work well?"...

This is a take that shows a completely lack of understanding on what software engineering is actually about.

The truth is somewhere in the middle. Do you remember the early 2000s boom of web developers that built custom websites for clients ranging from e-commerce sites to pizza restaurants? Those folks have found new work as the pressure from one-size fits all CMS providers (like Squarespace) and much stronger frameworks for simple front-ends (like node) have squeezed that market down to just businesses that actually need complex custom solutions and reduced the number of people required to maintain those.

It's likely we'll see LLMs used to build a lot of the cheap stuff that previously existed as arcane excel macros (I've already seen less technical folks use it to analyze spreadsheets) but there will remain hard problems that developers are needed to solve.

Comparing an LLM to an industrial textile machine is laughable, because one is consistent and reliable while the other is not.

It's laughable only if you think that the only reasonable metric is "consistent and reliable".

The parent says "it typically doesn't matter that the product is worse if it's cheap enough". And that seems valid to me: the average quality of software today seems to be worse than 10 years ago. We do worse but cheaper.

> And that seems valid to me: the average quality of software today seems to be worse than 10 years ago.

You don't remember Windows Vista? Windows ME?

I think you have that view because of survivor's bias. Only the good old software is still around today. There was plenty of garbage that barely worked being shipped 10 years ago.

Let's think about this: smartphones are orders of magnitude faster today than they were 10 years ago, and yet websites load slower on average.

isn't "delve" a classic tell of gpt-generated output? i'm pretty sure simianparrot is just trolling us. :-)

The question isn't about what you'll do when you're replaced by an LLM, it's what you're doing to future proof your job. There is a difference. The risk to hedge against is the productivity boost brought by LLMs resulting in a drop in the needs for new software engineers. This will put pressure on jobs (simply don't need as many as we used to so we're cutting 15%) AND wages (more engineers looking for fewer jobs with a larger part of their utility being commoditized).

Regardless of how sharp you keep yourself you're still at subject to the macro environment.

I'm future proofing my job by ensuring I remain someone whose brain is tuned to solving complex problems, and to do that most effectively I find ways to keep being engaged in both the fundamentals of programming (as already mentioned) and the higher-level aspects: Teaching others (which in turn teaches me new things) and being in leadership roles where I can make real architectural choices in terms of what hardware to run our software on.

I'm far more worried about mental degradation due to any number of circumstances -- unlucky genetics, infections, what have you. But "future proofing" myself against some of that has the same answer: Remain curious, remain mentally ambidextrous, and don't let other people (or objects) think for me.

My brain is my greatest asset both for my job and my private life. So I do what I can to keep it in good shape, which incidentally also means replacing me with a parrot is unlikely to be a good decision.

Nobody who's been replaced by a parrot thought they were going to get replaced by a parrot.

Where's your espoused intellectual curiosity and mental ambidextrousness when it comes to LLMs? It seems like your mind is pretty firmly made up that they're of no worry to you.

In another comment I briefly mention one use case I have been implementing with LLM's: https://news.ycombinator.com/item?id=42434886

I'm being vague with the details because this is one of the features in our product that's a big advantage over competitors.

To get to that point I experimented with and prototyped a lot using LLM's; I did a deep dive into how they work from the ground up. I understand the tech and its strengths. But likewise the weaknesses -- or perhaps more apt, the use cases which are more "magic show" than actually useful.

I never dismissed LLM's as useless, but I am as confident as I can possibly be that LLM's on their own cannot and will not put programmers out of jobs. They're a great tool, but they're not what many people seem to be fooled into believing that they are; they are not "intelligent" nor "agents".

Maybe it'll be a bit difficult for juniors to get entry level jobs for a short while due to a misunderstanding of the tech and all the hype, but that'll equalize pretty quickly once reality sets in.

Are you though? Until the AI-augmented developer provides better code at lower cost, I'm not seeing it. Senior developers aren't paid well because they can write code very fast, it's because they can make good decision and deliver projects that not only work, but can be maintained and built upon for years to come.

I know a few people who have been primarily programming for 10 years but are not seniors. 5 of them (probably 10 or more, but let's not overdo it), with AI, cannot replace one senior developer unless you make that senior do super basic tasks.

So your argument is:

There is some tech that is getting progressively better.

I am high on the linear scale

Therefore I don't worry about it cathing up to me ever

And this is the top voted argument.

> is getting progressively better

Is it still getting better? My understanding is that we're already training them on all of the publicly available code in existence, and we're running in to scaling walls with bigger models.

So you think that was it? Amazing comforting thoughts here

Considering the entire purpose of the original post is asking people what they're doing, why do you have such a problem with the top voted argument? If the top voted argument was in favour of this tech taking jobs, would you feel better?

The arrogance of comments like this is amazing.

I think it's an interesting psychological phenomenon similar to virtue signalling. Here you are signalling to the programmer in-group how good of a programmer you are. The more dismissive you are the better you look. Anyone worried about it reveals themself as a bad coder.

It's a luxury belief, and the better LLMs get the better you look by dismissing them.

This is spot on.

It's essentially like saying "What I do in particular, is much too difficult for an AI to ever replicate." It is always in part, humble bragging.

I think some developers like to pretend that they are exclusively solving problems that have never been solved before. Which sure, the LLM architecture in particular might never be better than a person for the novel class of problem.

But the reality is, an extremely high percentage of all problems (and by reduction, the lines of code that build that solution) are not novel. I would guesstimate that less than 1 out of 10,000 developers are solving truly novel problems with any regularity. And those folks tend to work at places like Google Brain.

That's relevant because LLM's can likely scale forever in terms of solving the already solved.

How is it humble bragging when there isn't "humble" part?

Fair point

> I would guesstimate that less than 1 out of 10,000 developers are solving truly novel problems with any regularity. And those folks tend to work at places like Google Brain.

Looks like the virtue signalling is done on both sides of the AI fence.

Not sure how you equate that statement with virtue signaling.

This is just a natural consequence of the ever growing repository of solved problems.

For example, consider that sorting of lists is agreed upon as a solved problem. Sure you could re-discover quick sort on your own, but that's not novel.

"The arrogance of comments like this is amazing."

Defending AI with passion is nonsensical, at least ironic.

My perspective is that if you are unable to find ways to improve your own workflows, productivity, output quality, or any other meaningful metric using the current SOTA LLM models, you should consider the possibility that it is a personal failure at least as much as you consider the possibility that it is a failure of the models.

A more tangible pitfall I see people falling into is testing LLM code generation using something like ChatGPT and not considering more involved usage of LLMs via interfaces more suited for software development. The best results I've managed to realize on our codebase have not been with ChatGPT or IDEs like Cursor, but a series of processes that iterate over our full codebase multiple times to extract various levels of resuable insights, like general development patterns, error handling patterns, RBAC-related patterns, extracting example tasks for common types of tasks based on git commit histories (i.e. adding a new API endpoint related to XYZ), common bugs or failure patterns (again by looking through git commit histories), which create a sort of library of higher-level context and reusable concepts. Feeding this into o1, and having a pre-defined "call graph" of prompts to validate the output, fix identified issues, consider past errors in similar types of commits and past executions, etc has produced some very good results for us so far. I've also found much more success with ad-hoc questions after writing a small static analyzer to trace imports, variable references->declarations, etc, to isolate the portions of the codebase to use for context rather than RAG-based searching that a lot of LLM-centric development tools seem to use. It's also worth mentioning that performance quality seems to be very much influenced by language; I thankfully primarily work with Python codebases, though I've had success using it against (smaller) Rust codebases as well.

Sometimes if it's as much work to setup and keep the tech running compared to writing it, it can be worth thinking about the tradeoffs.

A person with experience knowing how to push LLMs to output the perfect little function or utility to solve a problem, and collect enough of them to get somewhere is the interesting piece.

This sounds nice, but it also sounds like a ton of work to set up we don't have time for. Local models that don't require us to send our codebase to Microsoft or OpenAI would be something I'm sure we'd be willing to try out.

I'd love it if more companies were actually considering real engineering needs to provide products in this space. Until then, I have yet to see any compelling evidence that the current chatbot models can consistently produce anything useful for my particular work other than the occasional SQL query.

> CPU-only custom 2D pixel blitter engine I wrote to make 2D games in styles practically impossible with modern GPU-based texture rendering engines

I’m curious what’s so special about that blitting?

BTW, pixel shaders in D3D11 can receive screen-space pixel coordinates in SV_Position semantic. The pixel shader can cast .xy slice of that value from float2 to int2 (truncating towards 0), offset the int2 vector to be relative to the top-left of the sprite, then pass the integers into Texture2D.Load method.

Unlike the more commonly used Texture2D.Sample, Texture2D.Load method delivers a single texel as stored in the texture i.e. no filtering, sampling or interpolations. The texel is identified by integer coordinates, as opposed to UV floats for the Sample method.

Agree with this. SWE don't need to do anything because LLMs will just make expert engineers more productive. More detail on my arguments here: https://rakkhi.substack.com/p/economics-of-large-language-mo...

For those less confident:

U.S. (and German) automakers were absolutely sure that the Japanese would never be able to touch them. Then Koreans. Now Chinese. Now there are tariffs and more coming to save jobs.

Betting against AI (or increasing automation, really) is a bet against not against robots, but against human ingenuity. Humans are the ones making progress, and we can work with toothpicks as levers. LLM's are our current building blocks, and people are doing crazy things with them.

I've got almost 30 years experience but I'm a bit rusty in e.g. web. But I've used LLM's to build maybe 10 apps that I had no business building, from one-off kids games to learn math, to building a soccer team generator that uses Google's OR tools to optimise across various axes, to spinning up four different test apps with Replit's agent to try multiple approaches to a task I'm working on. All the while skilling up in React and friends.

I don't really have time for those side-quests but LLM's make them possible. Easy, even. The amount of time and energy I'd need pre-LLM's to do this makes this a million miles away from "a waste of time".

And even if LLM's get no better, we're good at finding the parts that work well and using that as leverage. I'm using it to build and check datasets, because it's really good at extraction. I can throw a human in the loop, but in a startup setting this is 80/20 and that's enough. When I need enterprise level code, I brainstorm 10 approaches with it and then take the reins. How is this not valuable?

As a senior-ish programmer who struggled a lot with algorithmic thinking in college, it's really awe-inspiring.

Truly hit the nail on the head there. We HAD no business with these side-quests, but now? They're all ripe for the taking, really.

One hundred per cent this.

LLM pair programming is unbelievably fun, satisfying, and productive. Why type out the code when you can instead watch it being typed while thinking of and typing out/speaking the next thing you want.

For those who enjoy typing, you could try to get a job dictating letters for lawyers, but something tells me that’s on the way out too.

Yeah I had my fair share of pride around typing super fast back in college, but the algorithms were super annoying to think through.

Nowadays I get wayyy more of a kick typing the most efficient Lego prompts in Claude.

What do you prefer to use for LLM pair programming?

Copilot and aider-chat

Claude and pasting code back and forth for simple things. But I’d like to try Claude with a few MCP servers so it can directly modify a repo.

But lately Cursor. It’s just so effortless.

Claude 70%. ChatGPT o1 for anything that needs more iterations, Cursor for local autocomplete, tested Gemini for concepts and it seemed solid. Replit when I want it to generate everything, from setting up a DB etc for any quick projects. But it’s a bit annoying and drives into a ditch a lot.

I honestly have to keep a tight rein on them all, so I usually ask for concepts first with no code, and need to iterate or start again a few times to get what I need. Get clear instructions, then generate. Drag in context, tight reins on changes I want. Make minor changes rather than wholesale.

Tricks I use. “Do you have any questions?” And “tell me what you want to do first.” Trigger it into the right latent space first, get the right neurons firing. Also “how else could I do this”. It’ll sometimes choose bad algo’s so you need to know your DSA, and it loves to overcomplicate. Tight reins :)

Claude’s personality is great. Just wants to help.

All work best on common languages and libraries. Edge cases or new versions get them confused. But you can paste in a new api and it’ll code against that perfectly.

I also use the API’s a lot, from cheap to pricy depending on task. Lots of data extraction, classifying. I got a (pricier model) data cleaner working on other data generated by a cheaper model, asking it to check eg 20 rows in each batch for consistency. Did a great job.

I've never found "LLM pair-programming" to be fun. I enjoy engaging my brain and coding on its own. Co-pilot and it's suggestions after a point become distracting. I'm sure there's are several use cases, but for me it's a tool that sometimes gets in the way (I usually turn off suggestions).

My experience is it's been unbelievably fun until I actually try to run what it writes and/or add some non-trivial functionality. At that point it becomes unbelievably un-fun and frustrating as the LLM insists on producing code that doesn't give the outputs it says it does.

quantum computers still can’t factor any number larger than 21

"Other people were wrong about something else so that invalidates your argument"

Why are half the replies like this?

The cognitive dissonance of seemingly educated people defending the LLMs when it comes to writing code is my top mystery for the entirety of 2024.

Call me if you find a good reason. I still have not.

In my opinion people that harp on about how LLMs have been game changer for them are the people that put themselves as never actually having built anything sophisticated enough that a team of engineers can work and extend on for years.

This back and forth is so tiring.

I have built web services used by many Fortune 100 companies, built and maintained and operated them for many years.

But I'm not doing that anymore. Now I'm working on my own, building lots of prototypes and proof-of-concepts. For that I've founding LLMs to be extremely helpful and time-saving. Who the hell cares if it's not maintainable for years? I'll likely be throwing it out anyway. The point is not to build a maintainable system, it's to see if the system is worth maintaining at all.

Are there software engineers who will not find LLMs helpful? Absolutely. Are there software engineers who will find LLMs extremely helpful? Absolutely.

Both can exist at the same time.

I agree with you and I don't think OP disagrees either. The point if contention is the inevitable and immediate death of programming as a profession.

Surely nobody has that binary a view?

What are the likely impacts over the next 1, 5, 10, 20 years. People getting into development now have the most incredible technology to help them skill up, but also more risk than we had in decades past. There's a continuum of impact and it's not 0 or 100%, and it's not immediate.

What I consider inevitable: humans will keep trying to automate anything that looks repeatable. As long as there is a good chance of financial gain from adding automation, we'll try it. Coding is now potentially at risk of increasing automation, with wildcards on "how much" and "what will the impact be". I'm extremely happy to have nuanced discussions, but I balk at both extremes of "LLMs can scale to hard AGI, give up now" and "we're safe forever". We need shorthand for our assumptions and beliefs so we can discuss differences on the finer points without fixating on obviously incorrect straw men. (The latter aimed at the general tone of these discussions, not your comment.)

And I'll keep telling you that I never said I'm safe forever.

And I never said both can't exist at the same time. Are you certain you are not the one fighting straw men and are tiring yourself with the imagined extreme dichotomy?

My issue is with people claiming LLMs are undoubtedly going to remove programming as a profession. LLMs work fine for one-off code -- when they don't make mistakes even there, that is. They don't work for a lot of other areas, like code you have to iterate on multiple times because the outer world and the business requirements keep changing.

Works for you? Good! Use it, get more productive, you'll only get applause for me. But my work does not involve one-off code and for me LLMs are not impressive because I had to rewrite their code (and to eye-ball it for bugs) multiple times.

"Right tool for the job" and all.

Yep, as cynical and demeaning that must sound to them, I am arriving at the same conclusion.

My last project made millions for the bank I was working at within the first 2 years and is now a case study at one of our extremely large vendors who you have definitely heard of. I conceptualised it, designed it, wrote the most important code. My boss said my contribution would last decades. You persist with making statements about people in the discussion, when you know nothing about their context aside from one opinion on one issue. Focus on the argument not the people.

You're the one who claimed that I'm arrogant and pulled that out of thin air. Take your own advice.

I also have no idea what your comment here had to do with LLMs, will you elaborate?

This is like a school yard. Go do some work.

Indeed, your blaming of me being arrogant is like a school yard indeed. You started it, you got called out, and are now acting superior. I owe you no grace if you started off the way you did in the other sub-thread.

Go away, I don't want you in my replies. Let me discuss with people who actually address the argument and not looking to paint me as... something.

All the programming for the Apollo Program took less then a year and Microsoft Teams is decades in development obviously they are better than NASA programmers.

the programming for the NASA program is very simple; the logistics of the mission, which has nothing to do with programming, is what was complex

You're essentially saying "the programming to do basic arithmetic and physics took only a year" as if that's remotely impressive compared to the complexity of something like Microsoft Teams. Simultaneous editing of a document by itself is more complicated than anything an Apollo program had to do

I want to not like this comment, but I think you are right! There's a reason people like to say your watch has more compute power than the computers it took to put man on the moon.

"Game changer" maybe.

But what you'll probably find is that people that are skilled communicators are currently getting a decent productivity boost from LLMs, and I suspect that the difference between many that are bullish vs bearish is quite likely coming down to ability to structure and communicate thoughts effectively.

Personally, I've found AI to be a large productivity boost - especially once I've put certain patterns and structure into code. It's then like hitting the N2O button on the keyboard.

Sure, there are people making toy apps using LLMs that are going to quickly become a unmaintainable mess, but don't be too quick to assume that LLMs aren't already making an impact within production systems. I know from experience that they are.

> I suspect that the difference between many that are bullish vs bearish is quite likely coming down to ability to structure and communicate thoughts effectively.

Strange perspective. I found LLMs lacking in less popular programming languages, for example. It's mostly down to statistics.

I agree that being able to communicate well with an LLM gives you more results. It's a productivity enabler of sorts. It is not a game changer however.

> don't be too quick to assume that LLMs aren't already making an impact within production systems. I know from experience that they are.

OK, I am open to proof. But people are just saying it and leaving the claims hanging.

but that’s thing, right? it is not “seemingly” there are A LOT of highly educated people here telling you LLMs are doing amazing shit for them - perhaps a wise response should be “lemme go back and see whether it can also become part of my own toolbox…”

I have spent 24 years coding without LLMs, cannot fathom now spending more than a day without it…

I have tried them a few times but they were only good at generating a few snippets.

If you have scrutable and interesting examples, I am willing to look them up and try to apply them to my work.

Which needs does it fulfil that you weren't able to fulfil yourself? (Advance prediction: these are needs that would be fulfilled better by improvements to conventional tooling.)

The short answer is they're trying to sell it.

Agreed, but I can't imagine that everybody here on HN that's defending LLMs so... misguidedly and obviously ignoring observable reality... are financially interested in LLMs' success, can they?

It's a message board frequented by extremely tech-involved people. I'd expect the vast majority of people here to have some financial interest in LLMs - big-tech equity, direct employment, AI startup, AI influencer, or whatever.

Yeah, very likely. It's the new gold rush, and they are commanding wages that make me drool (and also make me want to howl in pain and agony and envy but hey, let's not mention the obvious, shall we?).

I always forget the name of that law but... it's hard to make somebody understand something if their salary depends on them not understanding it.

Conflict of interest perhaps

Yep. Still makes me wonder if they are not seeing the truth but just refusing to admit it.

It’s a line by Upton Sinclair: “It is difficult to get a man to understand something, when his salary depends on his not understanding it.”

For similar reasons, I can confidently say that your disliking of LLMs is sour grapes.

I could take you seriously if you didn't make elementary English mistakes. Also think what you like, makes zero difference to me.

Orrrrr more simpler than imagining a vast conspiracy is that your observations just don't match theirs. If you're writing, say, C# with some esoteric libraries using CoPilot, it's easy to see it as glorified auto-complete that hallucinates to the point of being unusable because there's not enough training data. If you're using Claude with Aider to write a webpage using NextJS, you'll see it as a revolution in programming because of how much of that is on stack overflow. The other side of it is just how much the code needs to work, vs has to look good. If you're used to engineering the most beautifully organized code before shipping once, vs shipped some gross hacks you're ashamed of shipping, and the absolute quality of the code is secondary to it working and passing tests, then the generated code having an extra variable or crap that doesn't get used isn't as big an indightment of LLM-assisted programming that you believe it to be.

Why do you think your observable reality is the only one, and the correct one at that? Looking at your mindset, as well as the objections to the contrary (and their belief that they're correct), the truth is likely somewhere in-between the two extremes.

Where did I imply conspiracy? People have been known to turn a blind eye to criticism towards stuff they like ever since... forever.

The funny thing about the rest of your comment is that I'm in full agreement with you but somehow you decided that I'm an extremist. I'm not. I'm simply tired of people who make zero effort to prove their hypothesis and just call me arrogant or old / stuck in my ways, again with zero demonstration how LLMs "revolutionize" programming _exactly_.

And you have made more effort in that direction than most people I discussed this with, by the way. Thanks for that.

You said you couldn't imagine a conspiracy and I was responding to that. As far as zero demonstration, simonw has a bunch of detailed examples at:https://simonwillison.net/tags/ai-assisted-programming/ or maybe https://simonwillison.net/tags/claude-artifacts/, but the proof is in the pudding, as they say, so setting aside some time and $20 to install Aider and get it working w/ Claude, and then building a web app is the best way to experience either the second coming, or an overhyped let down. (or somewhere in the middle.)

Still, I don't think it's a hypothesis that most are operating under, but a lived experience that either it works for them or it does not. Just the other day I used ChatGPT to write me a program to split a file into chunks along a delimiter. Something I could absolutely do, in at least a half-dozen languages, but writing that program myself would have distracted me from the actual task at hand, so I had the LLM do it. It's a trivial script, but the point is I didn't have to break my concentration on the other task to get that done. Again, I absolutely could have done it myself, but that would have been a total distraction. https://chatgpt.com/share/67655615-cc44-8009-88c3-5a241d083a...

On a side project I'm working on, I said "now add a button to reset the camera view" (literally, aider can take voice input). we're not quite at the scene from star trek where scottie talks into the mac to try and make transparnet aluminum, but we're not that far off! The LLM went and added the button, wired it into a function call that called into the rendering engine and reset the view. Again, I very much could have done that myself, but it would have taken me longer just to flip through the files involved and type out the same thing. It's not just the time saved, which, I didn't have a stopwatch and a screen recorder, but apart from the time, it's not having to drop my thinking into that frame of reference, so I can think more deeply about the other problems to be solved. Sort of why ceo isn't an IC and why IC's aren't supposed to manage.

Detractors will point out that it must be a toy program, and that it won't work on a million line code base, and maybe it won't, but there's just so much that LLMs can do, as they exist now, that it's not hyperbole to say it's redefined programming, for those specific use cases. But where that use case is "build a web app", I don't know about you, but I use a lot of web apps these days.

These are the kind of the informed takes that I love. Thank you.

> Detractors will point out that it must be a toy program, and that it won't work on a million line code base, and maybe it won't

You might call me a detractor. I think of myself as being informed and feeling the need to point out where do LLMs end and programmers begin because apparently even on an educated forum like HN people shill and exaggerate all the time. That was the reason for most of my comments in this thread.

I’m financially interested in Anthropic being successfull since it means their prices are more likely to go down, or for their models to get (even) better.

Honestly, if you don’t think it works for you, that’s fine with me. I just feel the dismissive attitude is weird since it’s so incredibly useful to me.

Why is it weird, exactly? I don't write throwaway projects so the mostly one-off nature of LLM code generation is not useful to me. And I'm not the only one either.

If you can give examples of incredible usefulness then that can advance the discussion. Otherwise it's just us trying to out-shout each other, and I'm not interested in that.

Given they're a VC backed company rushing to claim market share and apparently selling well below cost, it's not clear that that will be the case. Compare the ride share companies for one case where prices went up once they were successful.

And it’s the short wrong answer. I get absolutely zero benefit if you or anyone else uses it. This is not for you or I, it’s for young people who don’t know what to do. I’m a person who uses a few LLM’s, and I do so because I see the risks and want to participate rather than have change imposed on me.

OK, do that. Seems like a case of FOMO to me but it might very well turn out that you're right and I'm wrong.

However, that's absolutely not clear today.

Genuine question: how hard have you tried to find a good reason?

Obviously not very hard. And looking at the blatant and unproven claims on HN gave me the view that the proponents are not interested in giving proof; they simply want to silence anyone who disagrees LLMs are useful for programming.

Because they don’t have an actual argument.

Because what is shared is overconfidence in the face of a system that has humble beginnings but many people trying to improve it. People have a natural bias against massive changes, and assume the status quo is fixed.

I’m open to all possibilities. There might be a near term blocker to improvement. There might be an impending architectural change that achieves AGI. Strong opinions for one or the other with no extremely robust proof are a mistake.

In other words, you have built exactly zero commercial-grade applications that us the working programmers work on building every day.

LLMs are good for playing with stuff, yes, and that has been implied by your parent commenter as well I think. But when you have to scale the work, then the code has to be easy to read, easy to extend, easy to test, have extensive test coverage, have proper dependency injection / be easy to mock the 3rd party dependencies, be easy to configure so it can be deployed in every cloud provider (i.e. by using env vars and config files for modifying its behavior)... and even more important traits.

LLMs don't write code like that. Many people have tried with many prompts. It's mostly good for just generating stuff once and maybe do little modifications while convincingly arguing the code has no bugs (and it has).

You seem to confuse one-off projects that have zero to little need for maintenance for actual commercial programming, perhaps?

Your analogy with the automakers seems puzzlingly irrelevant to the discussion at hand, and very far from transferable to it. Also I am 100% convinced nobody is going to protect the programmers; business people trying to replace one guy like myself with 3 Indians has been a reality for 10 years at this point, and amusingly they keep failing and never learning their lesson. /off-topic

Like your parent commenter, if LLMs get on my level, I'd be _happy_ to retire. I don't have a super vested interest in commercial programming, in fact I became as good at it in the last several years because I started hating it and wanted to get all my tasks done with minimal time expended; so I am quite confident in my assessment that LLMs are barely at the level of a diligent but not very good junior dev at the moment, and have been for the last at least 6 months.

Your take is rather romantic.

"In other words, you have built exactly zero commercial-grade applications that us the working programmers work on building every day."

The majority of programmers getting paid a good salary are implementing other people's ideas. You're getting paid to be some PMs chatGPT

You’re completely missing the point. The point being made isn’t about “are we implementing someone else’s idea”. It’s about the complexity and trade-offs and tough calls we have to make in a production system.

I never said we are working on new ideas only -- that's impossible.

I even gave several examples of the traits that a commercial code must have and that LLMs fail to generate such code. Not sure why you ignored that.

> LLMs fail to generate such code

As another oldster, yes, yes absolutely.

But the deeper question is: can this change? They can't do the job now, will they be able to in the future?

My understanding of what LLM's do/how they work suggests a strong "no". I'm not confident about my confidence, however.

I am sure it can change. Ultimately programming we be completely lost; we are going to hand-wave and command computers inside us or inside the walls of our houses. This absolutely will happen.

But my issue is with people that claim we are either at that point, or very nearly it.

...No, we are not. We are not even 10% there. I am certain LLMs will be a crucial part of such a general AI one day but it's quite funny how people mistake the brain's frontal lobe with the entire brain. :)

Plenty of jobs for coming by to read the logs across 6 systems when the LLM applications break and can't fix themselves.

Yep, quite correct.

I am even fixing one small app currently that the business owner generated with ChatGPT. So this entire discussion here is doubly amusing for me.

Just like we were fixing last year the PowerApps-generated apps (or any other low/no code app) the citizens developers slapped together.

The question is how those jobs will pay. That seems like something that might not be able to demand a living wage.

If everyone prompts code. Less people will actually know what they're doing?

That's the part many LLM proponents don't get it or hand-wave away. For now LLMs can produce okay one-off / throwaway code by having been fed with StackOverflow and Reddit. What happens 5 years down the road when half the programmers are actually prompters?

I'll stick to my "old-school" programming. I seem to have a very wealthy near-retirement period in front of me. I'll make gobs of money just by not having forgotten how to do programming.

Really? Excellent debugging is something I associate with higher-paid engineers.

If it can't demand a living wage then senior programmers will not be doing it, leading to this software remaining defective. What _that_ will lead to we have no idea because we don't know what kind of software.

> You're getting paid to be some PMs chatGPT

yes but one that actually works

> LLMs are good for playing with stuff, yes, and that has been implied by your parent commenter as well I think. But when you have to scale the work, then the code has to be easy to read, easy to extend, easy to test, have extensive test coverage, have proper dependency injection / be easy to mock the 3rd party dependencies, be easy to configure so it can be deployed in every cloud provider (i.e. by using env vars and config files for modifying its behavior)... and even more important traits.

I'm totally conflicted on the future of computing careers considering LLM impact, but I've worked at a few places and on more than a few projects where few/none of these are met, and I know I'm far from the only one.

I'd wager a large portion of jobs are like this. Majority of roles aren't working on some well-groomed Google project.

Most places aren't writing exquisite examples of a canonically "well-authored" codebase; they're gluing together enterprise CRUD slop to transform data and put it in some other database.

LLMs are often quite good at that. It's impossible to ignore that reality.

LLM’s are good at things a lot of people do, because a lot of people do them, and there’s tons of examples.

It’s the very definition of a self-fulfilling prophecy.

Yes. LLMs are great at generating Python code but not so great at generating APL code.

Good to the power of one by infinity.

Fixed that for you.

If there is one job I don't want to do, it's being responsible for a big heap of enterprise CRUD slop generated and glued together by LLMs. If they can write it, they should learn to maintain it too!

Insightful.

Whadja say, sama and backers?

IOW: maintain your own dog food, etc.

Absolutely. I agree with your take. It's just that I prefer to work in places where products are iterated on and not made once, tweaked twice, and then thrown out. There LLMs are for the moment not very interesting because you have to correct like 50% of the code they generate, ultimately wasting more time and brain energy than writing the thing yourself in the first place.

And wasting more money too, of highly paid devs.

A wake-up call for the bean counters.

I wish. But many of them only get as far as "this tool will replace your expensive programmer". Thinking stops there for them.

Lets replace them.

The analogy is that Japanese cars were initially utterly uncompetitive, and the arrogance of those who benefited from the status quo meant they were unable to adapt when change came. Humans improved those cars, humans are currently improving models and their use. Cheap toys move up the food chain. Find the direction of change and align yourself with it.

> people trying to replace one guy like myself with 3 Indians has been a reality for 10 years at this point, and amusingly they keep failing and never learning their lesson.

Good good, so you're the software equivalent of a 1990's era German auto engineer who currently has no equal, and maybe your career can finish quietly without any impact whatsoever. There are a lot of people on HN who are not you, and could use some real world advice on what to do as the world changes around them.

If you've read "crossing the chasm", in at least that view of the world there are different phases to innovation, with different roles. Innovators, early adopters, early majority, late majority, laggards. Each has a different motivation and requirement for robustness. The laggards won't be caught dead using your new thing until IBM gives it to them running on an AS400. Your job might be equivalent to that, where your skills are rare enough that you'll be fine for a while. However, we're past the "innovators" phase at this point and a lot of startups are tearing business models apart right now, and they are moving along that innovation curve. They may not get to you, but everyone is not you.

The choices for a developer include: "I'm safe", "I'm going to get so good that I'll be safe", "I'm going to leverage AI and be better", and "I'm out". Their decisions should not be based on your unique perspective, but on the changing landscape and how likely it is to affect them.

Good sense-check on where things are in the startup universe: https://youtu.be/z0wt2pe_LZM

I can't find it now, but there's at least one company that is doing enterprise-scale refactoring with LLM's, AST's, rules etc. Obviously it won't handle all edge cases, but...that's not your grandad's Cursor.

Might be this one, but don't recognise the name: https://www.linkedin.com/pulse/multi-repo-ai-assisted-refact...

You are assuming I am arrogant because I don't view the current LLMs as good coders. That's a faulty assumption so your argument starts with a logical mistake.

Also I never said that I "have no equal". I am saying that the death of my career has been predicted for no less than 10 years now and it still has not happened, and I see no signs of it happening; LLMs produce terrible code very often.

This gives me the right to be skeptical from where I am standing. And a bit snarky about it, too.

I asked for a measurable proof, not for your annoyed accusations that I am arrogant.

You are not making an argument. You are doing an ad hominem attack that weakens any other argument you may be making. Still, let's see some of them.

---

RE: choices, my choice has been made long time ago and it's this one: "I will become quite good so as to be mostly safe. If 'AI' displaces me then I'll be happy to work something else until my retirement". Nothing more, nothing less.

RE: "startup universe", that's a very skewed perspective. 99.99999% of all USA startups mean absolutely nothing in the grand scheme of things out there, they are but a tiny bubble in one country in a big planet. Trends change, sometimes drastically and quickly so. What a bunch of guys in comfy positions think about their bubble bears zero relevance to what's actually going on.

> I can't find it now, but there's at least one company that is doing enterprise-scale refactoring with LLM's, AST's, rules etc.

If you find it, let me know. That I would view as an interesting proof and a worthy discussion to have on it after.

"You seem to confuse"

"Your analogy with the automakers seems puzzlingly irrelevant"

"Your take is rather romantic."

That's pretty charged language focused on the person not the argument, so if you're surprised why I'm annoyed, start there.

Meta has one: https://arxiv.org/abs/2410.08806

Another, edited in above: https://www.linkedin.com/pulse/multi-repo-ai-assisted-refact...

Another: https://codescene.com/product/ai-coding

However, I still don't recognise the names. The one I saw had no pricing but had worked with some big names.

Edit: WAIT found the one I was thinking of: https://www.youtube.com/watch?v=Ve-akpov78Q - company is https://about.grit.io

In an enterprise setting, I'm the one hitting the brakes on using LLM's. There are huge risks to attaching them to e.g. customer-facing outputs. In a startup setting, full speed ahead. Match the opinion to the needs, keep two opposing thoughts in mind, etc.

Thanks for the links, I'll check them out.

Too bad the Grit.io guy doesn’t use his considerable resources to learn how to enunciate clearly.

Or build an AI agent to transform his speech into something more understandable.

> If you find it, let me know. That I would view as an interesting proof and a worthy discussion to have on it after.

https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/tra...

To be honest, I have no idea how well it works, but you can’t get much bigger than AWS in this regard.

Thanks. I'll absolutely check this out.

Very defensive.

I love it anyhow. Sure, it generates shit code, but if you ask it it’ll gladly tell you all the ways it can be improved. And then actually do so.

It’s not perfect. I spent a few hours yesterday pulling it’s massive blobby component apart by hand. But on the plus side, I didn’t have to write the whole thing. Just do a bunch of copy paste operations.

I kinda like having a junior dev to do all the typing for me, and to give me feedback when I can’t think of a good way to proceed.

If an LLM can give you feedback on a way to proceed it sounds more like you might be the junior? :P

LLMs seems to be ok'ish at solving trivial boilerplate stuff. 20 attempts deep I have not yet seen it able to even remotely solve anything I have been stuck enough on to have to sit down and think hard.

> If an LLM can give you feedback on a way to proceed it sounds more like you might be the junior? :P

More like it has no grey matter to get in the way of thinking of alternatives. It doesn’t get fixated, or at least, not on the same things as humans. It also doesn’t get tired, which is great when doing morning or late night work and you need a reality check.

Deciding which option is the best one is still a human thing, though I find that those often align too.

Curious: what kind of problem domain to you work on? I use LLMs every day on pretty hard problems and they are always net positive. But I imagine they’re not well trained on material related to your work if you don’t find them useful.

What kind of problem domain do you work on?

> I spent a few hours yesterday pulling it’s massive blobby component apart by hand. But on the plus side, I didn’t have to write the whole thing.

The question, really, is: are you confident that this was better than actually writing the whole thing yourself? Not only in terms of how long it took this one time, but also in terms of how much you learned while doing it.

You accumulate experience when you write code, which is an investment. It makes you better for later. Now if the LLM makes you slightly faster in the short term, but prevents you from acquiring experience, then I would say that it's not a good deal, is it?

Those are the right questions indeed, thank you for being one of the commenters who looks past the niche need of "I want to generate this and move along".

I tried LLMs several times, even started using my phone's timers, and found out that just writing the code I need by hand is quicker and easier on my brain. Proof-reading and looking for correctness in something already written is more brain-intensive.

Asking questions and thinking critically about the answers is how I learn. The information is better structured with LLMs.

Everyone isn't "generating and moving on". There's still a review and iteration part of the process. That's where the learning happens.

I would not mind having a junior type out the code, or so I thought for a while. But in the case of those of us who do deep work it simply turned out that proof-reading and correcting the generated code is more difficult than writing it out in the first place.

What in my comment did you find defensive, btw? I am curious on how does it look from the outside for people that are not exactly of my mind. Not making promises I'll change, but still curious.

> LLMs are barely at the level of a diligent but not very good junior dev at the moment, and have been for the last at least 6 months.

> Your take is rather romantic.

I’m not sure you’re aware what you’ve written here. The contrast physically hurts.

Apparently I'm not. Elaborate?

Current generation LLMs have been in development for approximately as long as it takes for a college to ingest a high schooler and pump out a non-horrible junior software developer. The pace of progress slowed down, but if we get further 50% improvement in 200% time it’s still you who is being the romantic, not the op.

I honestly don't follow your angle at all. Mind telling me your complete takeaway? You are kind of throwing just bits and pieces at me and I followed too many sub-threads to keep full context.

I don't see where I was romantic either.

Not the OP, but I imagine it has to do with the "LLMs will improve over time" trope. You said "and have been for the last at least 6 months" and it's confusing what you meant or what you expected should have happened in the past 6 months.

I am simply qualifying my claims with the fact that they might not be super up to date is all.

And my comments here mostly stem from annoyance that people claim that we already have this super game-changing AI that will remove programmers. And I still say: no, we don't have it. It works for some things. _Some_. Maybe 10% of the whole thing, if we are being generous.

> But when you have to scale the work, then the code has to be easy to read, easy to extend, easy to test, have extensive test coverage, have proper dependency injection / be easy to mock the 3rd party dependencies, be easy to configure so it can be deployed in every cloud provider

the code doesn't have to be anything like that, it only has to do one thing and one thing only: ship

But in a world of subscription based services, it has to ship more than once. And as soon as that's a requirement, all of the above applies, and the LLM model breaks down.

If and only if it's a one-off. I already addressed this in my comment that you are replying to, and you and several others happily ignored it. Really no idea why.

i'm sorry, both you and /u/NorthTheRock have a dev first mindset. Or a google-work-of-art codebase mindset. Or a bespoke little dev boutique mindset. Something like that. For the vast, vast majority of software devs it doesn't work that way. The way it works is: a PM says: we need this out ASAP, then we need this feature, this bug, hurry up, close your tickets, no, a clean codebase and unit tests are not needed, just get this out, the client is complaining.

And so it goes. I'm happy you guys work in places where you can take your time to design beautiful work of arts, I really am. Again, that's not the experience for everyone else, who are toiling in the fields out there, chased by large packs of rabid tickets.

I am aware that the way I work is not the only one, of course, but I am also not so sure about your "vast, vast majority" thing.

You can call it dev-first mindset, I call it a sustainable work mindset. I want the people I work for to be happy with my output. Not everything is velocity. I worked in high-velocity companies and ultimately got tired and left. It's not for me.

And it's not about code being beautiful or other artsy snobby stuff like that. It's about it being maintainable really.

And no I am not given much of a time, I simply refused to work in places where I am not given any time is all. I am a foot solider in the trenches just like you, I just don't participate in the suicidal charges. :)

Thank you for saying this; I commented something similar.

The HN commentariat seems to be comprised of FAANGers and related aspirants; a small part of the overall software market.

The "quality" companies doing high-skilled, bespoke work are a distinct minority.

A huge portion of work for programmers IS Java CRUD, React abominations, some C# thing that runs disgusting queries from an old SQL Server, etc etc.

Those privileged enough to work exclusively at those companies have no idea what the largest portion of the market looks like.

LLMs ARE a "threat" to this kind of work, for all the obvious reasons.

Are they more of a threat than all the no code, spreadsheets, bi tools, and salesforce?

We've watched common baselines be abstracted away and tons of value be opened up to creation from non engineers by reducing the complexity and risk of development and maintenance.

I think this is awesome and it hasn't seemed to eliminate any engineering jobs or roles - lots of crud stuff or easy to think about stuff or non critical stuff is now created that wasn't before and that seems to create much more general understanding of and need for software, not reduce it.

Regardless of tools available I think of software engineering as "thinking systematically" and being able to model, understand, and extend complex ideas in robust ways. This seems improved and empowered by ai coding options, not undermined, so far.

If we reach a level of ai that can take partially thought out goals and reason out the underlying "how it should work"/"what that implies", create that, and be able to extend that (or replace it wholesale without mistakes) then yeah, people who can ONLY code wont have much earning potential (but what job still will in that scenario?).

It seems like current ai might help generate code more quickly (fantastic). Much better ai might help me stay at a higher level when I'm implementing these systems (really fantastic if it's at least quite good), and much much better ai might let me just run the entire business myself and free me up to "debug" at the highest level, which is deciding what business/product needs to exist in the first place and figuring out how to get paid for it.

I'm a pretty severe ai doubter but you can see from my writing above that I think if it DOES manage to be good I think that would be good for us actually, not bad.

I don't know what to believe, long or short term; I'm just speculating based on what I perceive to be a majority of software job opportunities and hypothetical immediate impacts.

My basic conclusion is "they seem quite good (enough) at what appears to be a large portion of 'Dev' jobs" and I can't ignore the possibility of this having a material impact on opportunities.

At this point I'm agnostic on the future of GenAI impacts in any given area. I just no longer have solid ground upon which to have an opinion.

"But when you have to scale the work, then the code has to be easy to read, easy to extend, easy to test, have extensive test coverage, have proper dependency injection / be easy to mock the 3rd party dependencies, be easy to configure so it can be deployed in every cloud provider (i.e. by using env vars and config files for modifying its behavior).."

Interestingly I do not find that the stuff you mentioned are the things that LLLMs are bad at. It can generate easy to read code. It can document its code extensively. It can write tests. It can use dependency injection especially if you ask it to. What I noticed where I am currently am much better than an LLM is that I can still have a very nuanced very complicated problem space in my head and create a solution based on that. The LLM currently cannot solve a problem which is so nuanced and complicated that even I cannot fully describe and work partially from insincts. It is the 'engineering taste' or 'engineering instincts' and our ability to absorb complicated nuanced design problems in our head that separates experienced developers from LLMs.

Unless LLMs get significantly better and just replace humans in every task, I predict that LLMs effect on industry will be that much less developers will be needed but those who will be needed will be relatively 'well paid' as it will be harder to become a professional software developer. (more experience and engineering talent will be needed to work professionally).

If you say so then OK, I am not going to claim you are imagining it. But some proof would be nice.

I have quickly given up on experimenting with LLMs because they turned out to be net negative for my work -- proof-reading code is slower than writing it.

But if you have good examples then I'll check them out. I am open to the possibility that LLMs are getting better at iterating on code. I'd welcome it. It's just that I haven't seen it yet and I am not going to go out of my way to re-vet several LLMs for the... 4th time it would be, I think.

I think you're talking about the differencing between coding and writing systems, which means you're talking teams, not individuals.

Rarely, systems can be initiated by individuals, but the vast, vast majority are built and maintained by teams.

Those teams get smaller with LLMs, and it might even lead to a kind of stasis, where there are no new leads with deep experience, so we maintain the old systems.

That's actually fine by big iron, selling data, compute, resilience, and now intelligence. It's a way to avoid new entrants with cheaper programming models (cough J2EE).

So, if you're really serious about dragging in "commercial-grade", it's only fair to incorporate the development and business context.

I have not seen any proof so far that LLMs can enable teams. I and one other former colleague had to fix subtly broken LLM code several times, leading to the "author" being reprimanded that he's wasting three people's time.

Obviously anecdata, sure, it's just that LLMs for now seem mostly suited for throwaway code / one-off projects. If there's systemic proof for the contrary I'd be happy to check it out.

> LLMs don't write code like that

As someone who has been doing this since the mid 80's in all kinds of enterprise environments, I am finding that the latest generation are getting rather good at code like that, on par with mid-senior level in that way. They are also very capable of discussing architecture approaches with an encyclopaedic knowledge, although humans contribute meaningfully by drawing connections and analogies, and are needed to lead the conversation and make decisions.

What LLM's are still weak at is holding a very large context for an extended period (which is why you can see failures in the areas you mentioned if not properly handled e.g. explicitly discussed, often as separate passes). Humans are better at compressing that information and retaining it over a period. LLM's are also more eager and less defensive coders. That means they need to be kept on a tight leash and drip fed single changes which get backed out each time they fail - so very bright junior in that way. For example, I'm sometimes finding that they are too eager to refactor as they go and spit out env vars to make it more production like, when the task in hand is to get basic and simple first pass working code for later refinement.

I'm highly bullish on their capabilities as a force multiplier, but highly bearish on them becoming self-driving (for anything complex at least).

> I'm highly bullish on their capabilities as a force multiplier, but highly bearish on them becoming self-driving (for anything complex at least).

Very well summed and this is my exact stance, it's just that I am not seeing much of the "force multiplier" thing just yet. Happy to be proven wrong, but last time I checked (August 2024) I didn't get almost anything. Might be related to the fact that I don't do throwaway code, and I need to iterate on it.

Sonnet 3.5 v2 was released in October. Most people just use this. First and only one that can do passable front end as well.

Thank you, I'll check it out.

Do not know how you are using them? It speeded up my development around 8-10x, things i wouldnt have done earlier i'm doing now, e let it do by the AI; writing boilerplate etc. Just great!

8-10x?! That's quite weird if you ask me.

I just used Claude recently. Helped me with an obscure library and with the hell that is JWT + OAuth through the big vendors. Definitely saved me a few hours and I am grateful, but those cases are rare.

I developed things which i would have never started without AI because i could see upfront that there would be a lot of mundane/exhausting tasks

Amusingly, lately I did something similar, though I still believe my manual code is better in Elixir. :)

I'm open to LLMs being a productivity enabler. Recently I started occasionally using them for that as well -- sparingly. I more prefer to use them for taking shortcuts when I work with libraries whose docs are lacking.

...But I did get annoyed at the "programming as a profession is soon dead!" people. I do agree with most other takes on LLMs, however.

Recently used Cursor/Claude sonnet to port ~30k lines of EOL Livescript/Hyperscript to Typescript/JSX in less than 2 weeks. That would have took at least several months otherwise. Definitively a force multiplier, for this kind of repetitional work.

Shame that you can't probably open-source this, that would have been a hugely impressive case study.

And yeah, out of all the LLMs, it seems that Claude is the best when it comes to programming.

That sounds like they need a Unix plug-in pipe approach creating small modules that do one thing well handing their result without caring where it goes to the next not caring where it came from module while the mother Llm overseas only all the Blackbox connection pipes with the complex end result as a collateral divine conception.

now there was someone that I could call king

> business people trying to replace one guy like myself with 3 Indians has been a reality for 10 years at this point, and amusingly they keep failing and never learning their lesson. /off-topic

What is the "lesson" that business people fail to learn? That Indians are worse developers than "someone like yourself"?

(I don't mean to bump on this, but it is pretty offensive as currently written.)

1. The Indians were given as an example of absolutely terrible outsourcing agencies' dev employees. Call it racist or offensive if you like, to me it's statistical observation and I will offer no excuses that my brain is working properly and is seeing patterns. I have also met amazingly good Indian devs for what it's worth but most have been, yes, terrible. There's a link between very low-quality outsourcing agencies and Indian devs. I did not produce or fabricate this reality, it's just there.

2. The lesson business people fail to learn is that there's a minimum payment for programmers to get your stuff done, below which the quality drops sharply and that they should not attempt their cost-saving "strategy" because it ends up costing them much more than just paying me to do it. And I am _not_ commanding SV wages btw; $100k a year is something I only saw twice in my long career. So it's double funny how these "businessmen" are trying to be shrewd and pay even less, only to end up paying 5x my wage to a team that specializes in salvaging nearly-failed projects. I'll always find it amusing.

not OP, but not necessarily. the general reason is not that indians are worse developers per se. in my opinion it's more about the business structure. the "replacement indian" is usually not a coworker at the same company, but an employee at an outsourcing company.

the outsourcing company's goal is not to ship a good product, but to make the most money from you. so while the "indian developer" might theoretically be able to deliver a better product than you, they wont be incentivized to do so.

in practice, there are also many other factors that play into this - which might arguably play a bigger role like communication barriers, indian career paths (i.e. dev is only a stepstone on the way to manager), employee churn at cheap & terrible outsourcing companies, etc.

Did you think computers and ARPANET came out for commercial-grade applications and not "good for playing with stuff" ?

Of course they came from playing. But did you have people claiming we have a general AI while basic programming building blocks were still on the operating table?

Then what was dot com bubble?

This is quite an absurd, racist and naive take.

"Commercial grade applications" doesn't mean much in an industry where ~50% of projects fail. It's been said before that the average organisation cannot solve a solved problem. On top of this there's a lot of bizarre claims about what software _should_ be. All the dependency injection and TDD and scrum and all the kings horses don't mean anything when we are nothing more than a prompt away from a working reference implementation.

Anyone designing a project to be "deployed in every cloud provider" has wasted a huge amount of time and money, and has likely never run ops for such an application. Even then, knowing the trivia and platform specific quirks required for each platform are exactly where LLMs shine.

Your comments about "business people" trying to replace you with multiple Indian people shows your level of personal and professional development, and you're exactly the kind of personality that should be replaced by an LLM subscription.

And yet, zero proof again.

Getting so worked up doesn't seem objective so it's difficult to take your comment seriously.

The main takeaway is that llms can't code to a professional level yet. But with improvement they probably will. It doesn't even have to be LLMs the coding part of our job will eventually be automated to a much larger degree than it is.

Anything might happen in the future. My issue is with people claiming we're already in this future, and their only proof is "I generated this one-off NextJS application with LLMs".

Cool for you but a lot of us actually iterate on our work.

Or not. The point is that we don't know.

We're gonna get mini-milled.

People with the attitude that real programmers are producing the high level product are going to get eaten slowly, from below, in the most embarrassing way possible.

Embarrassing because they'll actually be right. LLMs aren't making the high quality products, it's true.

But the low quality CRUD websites (think restaurant menus) will get swallowed by LLMs. You no longer need a guy to code up a model, run a migration, and throw it on AWS. You also don't need a guy to make the art.

Advances in LLMs will feed on the money made from sweeping up all these crap jobs, which will legitimately vanish. That guy who can barely glue together a couple of pages, he is indeed finished.

But the money will make better LLMs. They will swallow up the field from below.

>But the low quality CRUD websites (think restaurant menus) will get swallowed by LLMs. You no longer need a guy to code up a model, run a migration, and throw it on AWS. You also don't need a guy to make the art.

just like you don't need webmasters, if you remember that term. IF you are just writing CRUD apps, then yeah - you're screwed.

If you're a junior, or want to get into the field? same, you're totally screwed.

LLMs are great at soft tasks, or producing code that has been written thousand of times - boilerplate, CRUD stuff, straightforward scripts - but the usual problems aren't limited by typing speed, nor amount of boilerplate but by thinking and evaluating solutions and tradeoffs from business perspective.

Also I'll be brutally honest - by the time the LLMs catch up to my generation's capabilities, we'll be already retired, and that's where the real crisis will start.

No juniors, no capable people, most seniors and principal engineers are retired - and quite probably LLMs won't be able to fully replace them.

> But the low quality CRUD websites (think restaurant menus) will get swallowed by LLMs. You no longer need a guy to code up a model, run a migration, and throw it on AWS. You also don't need a guy to make the art.

To be fair those were eaten long ago by Wordpress and site builders.

And even Facebook. I think the last time bespoke restaurant menu websites were a viable business was around 2010.

Have you personally tried? I have a business doing exactly that and have three restaurants paying between $300-400/month for a restaurant website -- and we don't even integrate directly with their POS / menu providers (Heartland).

That doesn't agree with my area at all. Most restaurants have menus or an app or both. Some have a basic website with phone number and link to an app. There seems to be some kind of app template many restaurants use which you can order from too.

> I think the last time bespoke restaurant menu websites

> There seems to be some kind of app template many restaurants use which you can order from too.

I think you agree with the comment you are replying to, but glossed over the word bespoke. IME as a customer in a HCOL area a lot of restaurants use a white-label platform for their digital menu. They don't have the need or expertise to maintain a functional bespoke solution, and the white-label platform lends familiarity and trust to both payment and navigation.

Yeah, and it's always in the future, right? ;)

I don't disagree btw. Stuff that is very easy to automate will absolutely be swallowed by LLMs or any other tool that's the iteration #13718 of people trying to automate boring stuff, or stuff they don't want to pay full programmer wages for. That much I am very much convinced of as well.

But there are many other, rather nebulous shall we call them, claims, that I take issue with. Like "programming is soon going to be dead". I mean OK, they might believe it, but arguing it on HN is just funny.

Who checks to see if the LLM swallowed it or not?

Arguably you never really needed a SWE for those use cases, SWEs are for bespoke systems with specific constraints or esoteric platforms.

"That guy who can barely glue together a couple of pages" was never going to provide much value as a developer, the lunches you describe were already eaten: LLMs are just the latest branding for selling solutions to those "crap jobs".

I don't think they will vanish at all.

A modern CRUD website (any software can be reduced to CRUD for that matter) is not trivially implemented and far beyond what current LLM can output. I think they will hit a wall before they will ever be able to do that. Also, configuration and infrastructure management is a large part of such a project and far out of scope as well.

People build some useful tools for LLM to enable them to do anything besides outputting text and images. But it is quite laborious to really empower them to do anything still.

LLM can indeed empower technical people. For example those working in automation can generate little Python or JavaScript scripts to push bits around, provided the endpoints have well known interfaces. That is indeed helpful, but the code still always needs manual review.

Work for amateur web developers will likely change, but they certainly won't be out of work anytime soon. Although the most important factor is that most websites aren't really amateur land anymore, LLM or not.

>> LLMs aren't making the high quality products,

And who cares exactly? The only real criteria is whether the product is good _enough_ to bring in profit. And rightly so if you ask me.

Also, far too many products build by human _experts_ are low quality. So, in a way we're more than ready for the LLM-quality products.

There are some very narrow minded, snarky people here,

“doesn’t pass my sniff test”

okay Einstein, you do you

Surely, you actually mean those who extrapolate from a few niche tasks to "OMG the programmers are toast"?

Fixed it for you. ;)

Sorry I don’t mean to be snarky :) I think there is a happy middle ground between

“AI can’t do anything, it sucks!”

and

“AI is AGI and can do everything and your career is done for”

I teeter along the spectrum, and use with caution while learning new topics without expertise.

But I’ve been very surprised by LLMs in some areas (UI design - something I struggle with - I’ve had awesome results!)

My most impressive use case for an LLM so far (Claude 3.5 Sonnet) has been to iterate on a pseudo-3D ASCII renderer in the terminal using C and ncurses, where with the help of an LLM I was able to prototype this, and render an ascii “forest” of 32 highly detailed ascii trees (based off a single ascii tree template), with lighting and 3 axis tree placement, where you can move the “camera” towards and away from the forest.

As you move closer trees scale up, and move towards you, and overlapping trees don’t “blend” into one ascii object - we came up with a clever boundary highlighting solution.

Probably my favourite thing I’ve ever coded, will post to HN soon

I absolutely agree that it's a spectrum. I don't deny the usefulness of some LLMs (and I have used Claude 3.5 lately with great success -- it helped me iterate on some very annoying code with very niche library that I would have needed days to properly decipher myself). I got annoyed by the grandiose claims though so likely got a bit worked up.

And indeed:

> “AI is AGI and can do everything and your career is done for”

...this is the thing I want to stop seeing people even imply it's happening. An LLM helped you? Cool, it helped me as well. Stop claiming that programming is done for. It's VERY far from that.

> LLMs don't write code like that. Many people have tried with many prompts. It's mostly good for just generating stuff once and maybe do little modifications while convincingly arguing the code has no bugs (and it has).

You have to make them write code like that. I TDD by telling the LLM what I want a test for, verify it is red, then ask it to implement. I ask it to write another test for an edge case that isn’t covered, and it will.

Not for 100% of the code, but for production code for sure. And it certainly speeds me up. Especially in dreadful refactoring where I just need to flip from one data structure to another, where my IDE can’t help much.

This is no different from creating a to-do app with an LLM and proclaiming all developers are up for replacement. Demos are not what makes LLMs good, let alone useful.

> 've got almost 30 years experience but I'm a bit rusty in e.g. web. But I've used LLM's to build maybe 10 apps that I had no business building, from one-off kids games to learn math,

Yea i built bunch of apps when RoR blog demo came out like 2 decades ago. So what?

LLMs are not necessarily a waste of time like you mention, as their application isn't limited to generating algorithms like you're used to.

When you consider LLMs to be building blocks in bigger, more complex systems, their potential increases dramatically. That's where mid/senior engineers would chip in and add value to a company, in my point of view. There's also different infrastructure paradigms involved that have to be considered carefully, so DevOps is potentially necessary for years to come.

I see a lot of ego in this comment, and I think this is actually a good example of how to NOT safeguard yourself against LLMs. This kind of skepticism is the most toxic to yourself. Dismiss them as novelty for the masses, as bullshit tech, keep doing your same old things and discard any applications. Textbook footgun.

> When you consider LLMs to be building blocks in bigger, more complex systems, their potential increases dramatically.

Do you have any examples of where/how that would work? It has seemed for me like lot of the hype is "they'll be good" with no further explanation.

I pull messy data from a remote source (think OCR-ed invoices for example), and need to clean it up. Every day I get around 1k new rows. The way in which it's messed up changes frequently, and while I don't care about it being 100% correct, any piece of code (relying on rules, regex, heuristics and other such stuff) would break in a couple of weeks. This means I need at least a part time developer on my team, costing me a couple of thousands per month.

Or I can pass each row through an LLM and get structured clean output out for a couple of dollars per month. Sure, it doesn't work 100%, but I don't need that, and neither could the human-written code do it.

Effectively, LLM resulted in one less develper hired on our team.

It resulted in one less developer, but you're still using that tool, right? Didn't a human (you) point the LLM at this problem and think this through?

That fired developer now has the toolset to become a CEO much, much easier than pre-LLM era. You didn't really make him obsolete. You made him redundant. I'm not saying he's gonna become a CEO, but trudging through programming problems is much easier for him as a whole.

Redundancies happen all the time and they don't end career types. Companies get bought, traded, and merged. Whenever this happens the redundant folk get the axe. They follow on and get re-recruited into another comfy tech job. That's it really.

Human or LLM the trick with messy inputs from scanned sources is having robust sanity combs that look for obvious fubar's and a means by which end data users can review the asserted values and the original raw image sources (and flag for review | alteration).

At least in my past experience with volumes of transcribed data for applications that are picky about accuracy.

I do! I posted this a while down below but I guess the way the algorithm here works it got super deprioritized. Full repost:

I can chip in from my tech consulting job where we ship a few GenAI projects to several AWS clients via Amazon Bedrock. I'm senior level but most people here are pretty much insulated.

I think whoever commented once here about more complex problems being tackled, (and the nature of these problems becoming broader) is right on the money. Newer patterns around LLM-based applications are emerging and having seen them first hand, they seem like a slightly different paradigm shift in programming. But they are still, at heart, programming questions.

A practical example: company sees GenAI chatbot, wants one of their own, based on their in-house knowledge base.

Right then and there there is a whole slew of new business needs with necessary human input to make it work that ensues.

- Is training your own LLM needed? See a Data Engineer/Data engineering team.

- If going with a ready-made solution, which LLM to use instead? Engineer. Any level.

- Infrastructure around the LLM of choice. Get DevOps folk in here. Cost assessment is real and LLMs are pricey. You have to be on top of your game to estimate stuff here.

- Guard rails, output validation. Engineers.

- Hooking up to whatever app front-end the company has. Engineers come to the rescue again.

All these have valid needs for engineers, architects/staff/senior what have you — programmers. At the end of the day, these problems devolve into the same ol' https://programming-motherfucker.com

And I'm OK with that so far.

Could you give an example of an AI capability that would change your mind on this, even slightly? "Sniff test" is rather subjective, and job replacement rarely happens with machines doing something better on the exact same axis of performance as humans. E.g., cars wouldn't have passed the coachman's "sniff test". Or to use a current topic - fast food self-order touchscreens don't pass the customer service people sniff test.

> never provide code that pass my sniff test

Unfortunately it won't be your sniff test that matters. It's going to be an early founder that realizes they don't need to make that extra seed round hire, or the resource limited director that decides they can forgo that one head count and still deliver the product on time, or the in house team that realizes they no longer need a dedicated front end dev because, for their purposes, AI is good enough.

Personally, the team I lead is able to ship much faster with AI assistants than without, which means in practice we can out compete much larger teams in the same space.

Sure their are things that AI will always struggle with, but those things aren't merely "senior" in nature, they're much closer to the niche expert type of problems. Engineers working on generally cutting edge work will likely be in demand and hard to replace, but many others will very likely be impacted by AI from multiple directions.

"Personally, the team I lead is able to ship much faster with AI assistants than without, which means in practice we can out compete much larger teams in the same space."

So, you're giving away your company's IP to AI firms, does your CEO understand this?

Appreciate the snark, but yes my CEO and I did have a good chat about that. My team's work is 100% open source, so if anyone wants to borrow that code I'm more than happy to share! (obviously not from a pseudonymous account, but I don't mind the API sniffing).

But there's plenty of fantastic open models now and you can increasingly run this stuff locally so you don't have to send that IP to AI firms if you don't want to.

IP is a legal construct not a technical one. If it's protected by law it's protected by law.

This is satire, right? The completely off-topic mentioning of your graphics programming skills, the overconfidence, the phrase "delve into"... Let me guess: The prompt was "Write a typical HN response to this post"

This made me chuckle. But at the same time a bit uneasy because this could mean my own way of expressing myself online might've been impacted by reading too much AI drivel whilst trying to find signal in the noisy internet landscape...

The off-topic mentioning of graphics programming was because I tend to type as I think, then make corrections, and as I re-read it now the paragraph isn't great. The intent was to give an example of how I keep myself sharp, and challenging what many consider "settled" knowledge, where graphics programming happens to be my most recent example.

For what it's worth, English isn't my native language, and you'll have to take my word for it that no chat bots were used in generating any of the responses I've made in this thread. The fact that people are already uncertain about who's a human and who's not is worrisome.

I'm certain that humans are picking up AI dialect. Very hard to prove though and will become harder.

Either that or it's this simple: AI dialect is already the amalgamation of the most popular internet dialects for its training set. I used to read a lot of Reddit years ago now. It's more likely my dialect is influenced by that in subtle ways when typing online in English, and AI is parroting this for obvious reasons.

Yeah.. generations. I really hope that it doesn’t end like the New York Times article saying that human flight was at best hundred of years away a few weeks before the Wright brothers flight..

Completely agree. The other day I was trying to find something in the Shopify API docs (an API I'm not familar with), and I decided to try their chat bot assistant thingy. I thought, well, if an LLM is good at something, it's probably at finding information in a very narrow field like this. However, it kept telling me things that were plain wrong, I could compare it to the docs next to it easily. Would have been faster just reading the docs.

> I thought, well, if an LLM is good at something, it's probably at finding information in a very narrow field like this.

I feel like of all the things in this thread, this one is on them. It absolutely is something that LLMs are good at. They have the sample size, examples and docs, all the things. LLMs are particularly good at speaking "their" language, the most surprising thing is that they can do so much more beyond that next token reckoning.

So, yeah, I'm a bit surprised that a shop like Shopify is so sloppy, but absolutely I think they should be able to provide you an LLM to answer your questions. Particularly given some of the Shopify alumni I've interviewed.

That said, some marketing person might have just oversold the capabilities of an LLM that answers most of their core customer questions, rather than one that knows much at all about their API integrations.

Another perspective is: Given that Shopify should have the capabilities to be good at this and their AI assistant is still sucking ass, it's not possible to make a better product with the current technology.

Maybe it's right 99% of the time and works well for many of their developers. But this is exactly the point. I just can't trust a system that sometimes gives me the wrong answer.

Another post where I get to tell a skeptic that they’re failing at using these products.

There will be human programmers in the future as well, they just won’t be ones who can’t use LLMs.

I'd challenge the assertion that LLMs never pass whatever a "sniff test" is to you. The code they produce is looking more and more like working production code.

This is denial. LLMs already write code at a senior level. Couple that with solid tests and a human code reviewer and we’re already at 5x the story points per sprint at the startup I work at.

I'm sure that startup is a great indication of things to come. Bound for long term growth.

It’s solid, efficient, bug free code. What else matters?

Yap yap yap. Keep living in denial mate.

I'm not living in denial, I think LLMs are extremely useful and have huge potential. But people that are all "omg my startup did this and we reduced our devs by 150% so it must be the end-all tech!" are just as insufferable as the "nope the tech is bad and won't do anything at all" crowd.

And before you mention, the hyperbole is for effect, not as an exact representation.

Seems like nobody noticed the "delve" part, which is a very dark irony here.

"delve"

hmmmmm

I have been an AI denier for the past 2 years. I genuinely wanted to try it out but the experience I got from Copilot in early 2023 was just terrible. I have been using ChatGPT for some programming questions for all that time, but it was making mistakes and lack of editor integration did not seem like it would make me more productive.

Thanks to this thread I have signed up again for Copilot and I am blown away. I think this easily makes me 2x productive when doing implementation work. It does not make silly mistakes anymore and it's just faster to have it write a block of code than doing it myself.

And the experience is more of an augmentation than replacement. I don't have to let it run wild. I'm using it locally and refactor its output if needed to match my code quality standards.

I am as much concerned (job market) as I am excited (what I will be able to build myself).

head meet sand lol

source: been coding for 15+ years and using LLMs for past year.

Tell me more about this 2D pixel blitter engine