Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firing programmers for AI is a mistake

defragzone.substack.com

Post reply on HN
Print view View original

521–530 of 886 posts

Re: Firing programmers for AI is a mistake

#521

Post by arscan »

What are these fired programmers going to do? Disappear? They’ll build stuff, using the same plus-up AI tooling that enabled their old boss to fire them. So guess what, their old boss just traded employees for competitors. Congrats, I guess?

Zuck declaring that he plans on dropping programmer head-count substantially, to me indicates that they’ll have a much smaller technological moat in the future, and they won’t be paying off programmers to not build competing products anymore. I’m not sure he should be excited about that.

Re: Firing programmers for AI is a mistake

#522

Post by yoyohello13 »

ryanjshaw wrote: post #73
pyrale wrote: post #11

We have fired all our programmers. However, the AI is hard to work with, it expects specific wording in order to program our code as expected. We have hired people with expertise in the specific language needed to transmit our specifications to the AI with more precision.

What job title are you thinking of using?

Tech Priest

Re: Firing programmers for AI is a mistake

#525

Post by peoplefromibiza »

hombre_fatal wrote: post #303
csmpltn wrote: post #214

Earlier quoted context omitted.

I think that LLMs are only going to make people with real tech/programming skills much more in demand, as younger programmers skip straight into prompt engineering and never develop themselves technically beyond the bare minimum needed to glue things together. The gap between people with deep, hands-on experience that understand how a computer works and prompt engineers will become so insanely deep. Somebody needs to…

I think we who are already in tech have this gleeful fantasy that new tools impair newcomers in a way that will somehow serve us, the incumbents, in some way. But in reality pretty much anyone who enters software starts off cutting corners just to build things instead of working their way up from nand gates. And then they backfill their knowledge over time. My first serious foray into software wasn't even Ruby. It wa…

[dead]

Re: Firing programmers for AI is a mistake

#526

Post by fragmede »

nerder92 wrote: post #279
Madmallard wrote: post #176

Earlier quoted context omitted.

What makes you think (1) will be true? It is only generating based on training data. In mature code bases there is a massive amount of interconnected state that is not already present in any github repository. The new logic you'd want to add is likely something never done before. As other programmers have stated, it seems to be improving at generating useful boilerplate and making simple websites and such related to…

> It is only generating based on training data This is not the case anymore, current SOTA CoT models are not just parroting stuff from the training data. And as of today they are not even trained exclusively on publicly (and not so publicly) available stuff, but they massively use synthetic data which the model itself generated or distilled data from other smarter models. I'm using and I know plenty of people using A…

Try Devin or OpenHands. OpenHands isn't quite ready for production, but it's informative on where things are going and to watch the LLM go off and "do stuff", kinda on its own, from my prompt (while I drink coffee).

Re: Firing programmers for AI is a mistake

#527

Post by ryandrake »

reverius42 wrote: post #496
ryandrake wrote: post #322

Earlier quoted context omitted.

What's the far future end-state that these shareholders and execs envision? Companies with no staff? Just self-maintaining robots in the factory and AI doing the office jobs and paperwork? And a single CEO sitting in a chair prompting them all? Is that what shareholders see as the future of business? Who has money to buy the company's products? Other CEOs?

Just a paperclip maximizer, with all humans reduced to shareholders in the paperclip maximizer, and also possibly future paperclips.

> all humans reduced to shareholders

That seems pretty optimistic. The shareholder / capital ownership class isn't exactly known for their desire to spread that ownership across the public broadly. Quite the opposite: Fewer and fewer are owning more and more. The more likely case is we end up like Elysium, with a tiny <0.1% ownership class who own everything and participate in normal life/commerce, selling to each other, walled off from the remaining 99.9xxx% barely subsisting on nothing.

Re: Firing programmers for AI is a mistake

#528

Post by rootnod3 »

bee_rider wrote: post #454
whynotminot wrote: post #230

Earlier quoted context omitted.

Isn’t this kind of thing the story of tech though? Languages like Python and Java come around, and old-school C engineers grouse that the kids these days don’t really understand how things work, because they’re not managing memory. Modern web-dev comes around and now the old Java hands are annoyed that these new kids are just slamming NPM packages together and polyfills everywhere and no one understands Real Software…

The real hardcore experts should be writing libraries anyway, to fully take advantage of their expertise in a tiny niche and to amortize the cost of studying their subproblem across many projects. It has never been easier to get people to call your C library, right? As long as somebody can write the Python interface… Numpy has delivered so many FLOPs for BLAS libraries to work on. Does anyone really care if you call…

I think the problem is that with the over-reliance on LLMs, that expertise of writing the foundational libraries that even other languages rely on, is going away. That is exactly the problem.

Re: Firing programmers for AI is a mistake

#529

Post by whynotminot »

commandlinefan wrote: post #396
whynotminot wrote: post #230

Earlier quoted context omitted.

Isn’t this kind of thing the story of tech though? Languages like Python and Java come around, and old-school C engineers grouse that the kids these days don’t really understand how things work, because they’re not managing memory. Modern web-dev comes around and now the old Java hands are annoyed that these new kids are just slamming NPM packages together and polyfills everywhere and no one understands Real Software…

My son is a CS major right now, and since I've been programming my whole adult life, I've been keeping an eye on his curriculum. They do still teach CS majors from the "ground up" - he took system architecture, assembly language and operating systems classes. While I kind of get the sense that most of them memorize enough to pass the tests and get their degree, I have to believe that they end up retaining some of it.

I think this is still true of a solid CS curriculum.

But it’s also true that your son will probably end up working with boot camp grads who didn’t have that education. Your son will have a deeper understanding of the world he’s operating in, but what I’m saying is that from what I’ve seen it largely hasn’t mattered all that much. The bootcampers seem to do just fine for the most part.

Re: Firing programmers for AI is a mistake

#530

Post by Jcampuzano2 »

menaerus wrote: post #470
Jcampuzano2 wrote: post #393

Earlier quoted context omitted.

There are simply no models that can keep in context the amount of info required in enterprise codebases before starting to forget or hallucinate. I've tried to give it relevant context myself (a tedious task in itself to be honest) and even tools that claim to automatically be able to do so fail wonderfully at bigger than toy project size in my experience. The codebase I'm working on day to day at this moment is give…

The largest context that I am aware that an open-source model (e.g. qwen) can manage is 1M tokens. This should translate to ~30kLoC. I'd envision that this could in theory work even on large codebases. It certainly depends on the change to be done but I can imagine that ~30kLoC of context is large enough for most of the module-specific changes. Possibly the models that you're using have a much smaller context window?…

If you don't mind me asking, what size of codebases do you typically work on? As mentioned I've tried using all the available commercial models and none work better than as a helpful autocomplete, test, and utility function generator. I'm sure maybe big players like Meta, OpenAI, MS, etc do have the capability of expanding its context for their own internal projects and training specifically on their code, but most of the rest of us can't feasibly do that since we don't own our own AI moat.

Even on my personal projects and smaller internal projects that are small toy projects or utility tools I sometimes struggle to get them to build anything significant. I'm not saying its impossible, but I always find it best at starting things from scratch, and small tools. Maybe its just a sign that AI would be best for microservices.

I've never used Devon so I can't speak to it, but I do recall seeing it was also overhyped at best and struggled to do anything it was purported to be able to in demos. Not saying that this is still true.

I would be interested in seeing how Devon performs on a large open source project in real-time (since if I recall their demos were not real-time demonstrations) for instance just to evaluate its capabilities.

Post reply on HN