Ask HN: SWEs how do you future-proof your career in light of LLMs?

>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.

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.

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".

>> 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.

Who checks to see if the LLM swallowed it or not?

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.

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!

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.

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.

> 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?

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.

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.

> You're getting paid to be some PMs chatGPT

yes but one that actually works

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.

> 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.

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

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.

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.

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.

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.

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.

Apparently I'm not. Elaborate?

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.

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?

Surely, you actually mean those who extrapolate from a few niche tasks to "OMG the programmers are toast"?

Fixed it for you. ;)

And yet, zero proof again.

Getting so worked up doesn't seem objective so it's difficult to take your comment seriously.

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.

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.

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.

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…

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

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

> 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 can already type faster than I can think.

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

> 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.

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.”

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).

> 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.

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.

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?

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?

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.

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.

> 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.

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.

> 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.

> 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.

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.

> 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.

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.

> 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-序号

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.

> 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.

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?

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.

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.

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.

> 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.

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.

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.

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

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

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

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.

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.

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

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

> 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

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

> 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.

> 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.

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)?

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?

> 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!

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.

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.

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.

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

Yes, 7-zip.

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

> 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.

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.

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.

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.

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%.

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.

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.

Fair point

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.

"AI didn’t replace me, AI accelerated me or improved me with feedback about my work"

This really sums up how I feel about AI at the moment. It's like having a partner who has broad knowledge about anything that you can ask any stupid questions to. If you don't want to do a small boring task you can hand it off to them. It lets you focus on the important stuff, not "whats the option in this library called to do this thing that I can describe but don't know the exact name for?".

If you aren't taking advantage of that, then yes, you are probably going to be replaced. It's like when version control became popular in the 00s, where some people and companies still held out in their old way of doing things, copying and pasting folders or whatever other nasty workflows the had, because $reasons... where the only real reason was that they didn't want to adapt to the new paradigm.

I would not hire someone who eschews LLMs as a tool. That does not mean I would accept someone mindlessly shoving its code through review, as it is a tool, not a wholesale solution.

That ship seems to have sailed at the same time boxed software went extinct.

How many companies still have dedicated QA orgs with skilled engineers? How many SaaS solutions have flat out broken features? Why is SRE now a critical function? How often do mobile apps ship updates? How many games ship with a day zero patch?

The industries that still have reliable software are because there are regulatory or profit advantages to reliability -- and that's not true for the majority of software.