Hacker News new | past | comments | ask | show | jobs | submit
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.

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.

loading story #42440431
loading story #42440387
loading story #42449500
loading story #42442462
loading story #42442428
loading story #42440716
> 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.

loading story #42440248
loading story #42438878
loading story #42440739
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.

loading story #42440342
loading story #42439750
loading story #42440765
"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

loading story #42439472
loading story #42437664
loading story #42437656
> 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).

loading story #42440919
loading story #42442016
"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).

loading story #42440829
> 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

loading story #42439287
loading story #42440584
> 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.)

loading story #42440817
loading story #42440369
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...

loading story #42437809
> 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.

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.

loading story #42440951
> 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.

loading story #42440603
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.
loading story #42440594
loading story #42440327
Did you think computers and ARPANET came out for commercial-grade applications and not "good for playing with stuff" ?
loading story #42440620
There are some very narrow minded, snarky people here,

“doesn’t pass my sniff test”

okay Einstein, you do you

loading story #42448691
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.

loading story #42440641