Live data from Hacker News

Firing programmers for AI is a mistake

defragzone.substack.com

311–320 of 886 posts

Re: Firing programmers for AI is a mistake

#311
post #243

Earlier quoted context omitted.

I do feel with the rise of "reasoning" class of models, it's not hard to believe that code quality will improve over time.

The thing is: how much 0.2x, 2x, 5x, 50x?

Who knows? It just needs to be better than the average engineer.

Re: Firing programmers for AI is a mistake

#312

Earlier quoted context omitted.

I actually know a professional translator and while a year ago he was full of worry, he now is much more relaxed about it. It turns out that like art, many people just want a human doing the translation. There is a strong romantic element to it, and it seems humans just have a strong natural inclination to only want other humans facilitating communication.

How do they know that a human is doing the translation? What's to stop someone from just c&ping the text into an LLM, giving it a quick proofread, then sending it back to the client and saying "I translated this"? Sounds like easy money, maybe I should get into the translation business.

I mean, they don't, but I can assure you there are far more profitable ways to be deceptive than being a faux translator haha

Re: Firing programmers for AI is a mistake

#313
post #266

Earlier quoted context omitted.

Did you have to do any preparation steps before you asked from a model to do the large scale change or there were no steps involved? For example, did you simply ask for the change or did you give a model a chance to learn about the codebase. I am genuinely asking, I'm curious because I haven't had a chance to use those models at work.

> For example, did you simply ask for the change or did you give a model a chance to learn about the codebase. I've tried it both with personal projects and work. My personal project/benchmark is a 3d snake game. O3 is by far the best, but even with a couple of hundred lines of code it wrote itself it loses coherence and can't produce changes that involve changing 2 lines of code in a span of 50 lines of code. It eit…

Thanks but IIUC you're describing a situation where you're simply using a model without giving it a chance to learn from the whole codebase? If so, then I was asking for the opposite where you would ingest the whole codebase and then let the model spit out the code. This in theory should enable the AI model to build a model of your code.

> if we're all replaced by AI, who will write the frameworks and programming languages themselves?

What for? There's enough programming languages and there's enough of the frameworks. How about using an AI model to maintain and develop existing complex codebases? IMHO if AI models become more sophisticated and are able to solve this, then the answer is pretty clear who will be doing it.

Re: Firing programmers for AI is a mistake

#314
post #243

Earlier quoted context omitted.

>Of course both these assumptions are wrong, the quality of code produced by AI will improve dramatically as model evolves. How are you so sure?

I do feel with the rise of "reasoning" class of models, it's not hard to believe that code quality will improve over time.

Doesn't sound like improving dramically.

Re: Firing programmers for AI is a mistake

#315

Earlier quoted context omitted.

Part of the problem is that many working developers are still in companies that don't allow experimentation with the bleeding edge of AI on their code base, so their experiences come from headlines and from playing around on personal projects. And on the first 10,000 lines of code, the best in class tools are actually pretty good. Since they can help define the structure of the code, it ends up shaped in a way that w…

My company allowed us to use it but most developers around me didn't reach out to the correct people to be able to use it. Yes I find it incredibly helpful and try to tell them. But it's only helpful in small contexts, auto completing things, small snippets, generating small functions. Any large scale changes like most of these AI companies try to push them being capable of doing it just falls straight on its face. I…

I've found it very easy to end up "generating" yourself into a corner with a total mess with no clear control flow that ends up more convoluted than need be, by a mile.

If you're in mostly (or totally) unfamiliar territory, you can end up in a mess, fast.

I was playing around with writing a dead-simple websocket server in go the other evening and it generated some monstrosity with multiple channels (some unused?) and a tangle of goroutines etc.

Quite literally copying the example from Gorilla's source tree and making small changes would have gotten me 90% of the way there, instead I ended up with a mostly opaque pile of code that *looks good* from a distance, but is barely functional.

(This wasn't a serious exercise, I just wanted to see how "far" I could get with Copilot and minimal intervention)

Re: Firing programmers for AI is a mistake

#318

Earlier quoted context omitted.

I can say my company stopped contracting for test system design, and we use a mix of models now to achieve the same results. Some of these have been running without issue for over a year now.

As in writing test cases? I’ve seen devs write (heavily mocked) unit tests using only AI, but these are worse than no tests for a variety of reasons. Our company also used to contract for these tests…but only because they wanted to make the test coverage metric to up. They didn’t add any value but the contractor was offshore and cheap. If you’re able to have AI generate integration level tests (ie call an API then en…

Amazingly, there is industry outside tech that uses software. We are an old school tangible goods manufacturing company. We use stacks of old grumbling equipment to do product verification tests, and LLMs to write the software that synchronizes them and interprets what they spit back out.

Re: Firing programmers for AI is a mistake

#319
post #132

That’s what people said about outsourcing too. The corporate meat grinder keeps rolling forward anyway. Every single department and person believes the world will stop turning without them but that’s rarely how that plays out.

I believe AI is the excuse, but that this is just to cover another wave of outsourcing.

Re: Firing programmers for AI is a mistake

#320

I think a more interesting question is what the impact will be on the next generation looking at CS/SWE as a potential profession. It's been considered a pretty "safe" profession for a long time now. That will change over the next 10 years. Will parents advise their kids to avoid CS because the job market will be so much smaller in 10 years' time?

I'm sure that's happening right now. On the flipside will companies who hire in 4 years look at those CS/SWE kids as lessor skilled devs because they relied so much on AI to pass classes and didn't really learn?

There was a similar effect during the dot com boom / crash.

Everyone and their dog got a CS degree, and the average quality of that cohort was abysmal. However, it also created a huge supply of extremely talented people.

The dot-com crash happened, and software development was "over forever", but the talented folks stuck around and are doing fine.

People that wanted to go into CS still did. Some of them used stack overflow and google to pass their courses. They were as unemployable as the bottom of the barrel during the dot com boom.

People realized there was a shortage of programmers, so CS got hot again for a bit. Now LLMs have hit and are disrupting most industries. This means that most industries need to rewrite their software. That'll create demand for now.

Eventually, the LLM bust will come, programming will be "over forever" again, and the cycle will continue. At some point after Moore's law ends the boom and bust cycle will taper off. (As it has for most older engineering disciplines.)

Post reply on HN