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

541–550 of 886 posts

Re: Firing programmers for AI is a mistake

#541

Post by skydhash »

weatherlite wrote: post #449
skydhash wrote: post #438

Earlier quoted context omitted.

The fact that you don't see why is the issue. Both python and JS are very permissive and their runtime env is very good. More often than not, you're just dealing with logic bugs and malformed domain data. A kernel codebase like Linux is one where there are many motivated individual trying every trick to get the computer to do something. And you're usually dealing with leaner abstractions because general safety logic…

> More often than not, you're just dealing with logic bugs Definitely. More often than not you're dealing with logic bugs. So the thing solving them will sometimes have to be able to reason quite well across large code bases (not every bug of course, but quite often) to the point I don't really see how it's different than general intelligence if it can do that well. And if it gets to the point its AGIish , I don't se…

> So the thing solving them will sometimes have to be able to reason quite well across large code bases

The codebase only describes what the software can do currently, never the why. And you can't reason without both. And the why is the primary vector of changes which may completely redefines the what. And even the what have many possible interpretations. The code is only one specific how. Going from the why, to the what, to a specific how is the core tenet of programming. Then you add concerns like performance, reliability, maintainability, security...

Once you have a mature codebase, outside of refactoring and new features, you mostly have to edit a few lines for each task. Finding the lines to work one requires careful investigation and you need to carefully test after that to ensure that no other operations have been affected. We already have good deterministic tools to help with that.

Re: Firing programmers for AI is a mistake

#542

Post by woah »

marcosdumay wrote: post #433
zozbot234 wrote: post #357

Earlier quoted context omitted.

Excel is a "no-code" system and people seem to like it. Of course, sometimes it tampers with your data in horrifying ways because something you entered (or imported into the system from elsewhere) just happened to look kinda like a date, even though it was intended to be something completely different. So there's that.

> Excel is a "no-code" system and people seem to like it. If you've found any Excel guru that don't spend most of their time in VBA, you have a really unusual experience.

Huge numbers of accountants and lawyers use excel heavily knowing only the built in formula language. They will have a few "gurus" sprinkled around who can write macros but this is used sparingly because the macros are a black box and make it harder to audit the financial models.

Re: Firing programmers for AI is a mistake

#543

Post by dkjaudyeqooe »

sunami-ai wrote: post #506

I agree with the statement in the title. Using AI to write code does two things: 1. Everything seems to go faster at first until you have to debug it because the AI can't seem to be able to fix the issue... It's hard enough to debug code you wrote yourself. However, if you work with code written by others (team environment) then maybe you're used to this, but not being able to quickly debug code you're responsible fo…

Essentially: people are vastly overestimating AI ability and vastly underestimating HI ability.

Humans are supremely adaptable. That's what our defining attribute as a species is. As a group we can adapt to more or less any reality we find ourselves in.

People with good minds will use whatever tools they have to enhance their natural abilities.

People with less good minds will use whatever tools they have to cover up their inability until they're found out.

Re: Firing programmers for AI is a mistake

#544

Post by woah »

wesselbindt wrote: post #361
weatherlite wrote: post #308

Earlier quoted context omitted.

There's no need for tens of millions of OS Kernel devs , most of us are writing business logic CRUD apps. Also, it's not entirely clear to me why LLMs should get extremely good in web app development but not OS development, as far as I can see it's the amount and quality of training data that counts.

> as far as I can see it's the amount and quality of training data that counts Well there's your reason. OS code is not as in demand or prevalent as crud web app code, so there's less relevant data to train your models on.

The OS code that exists is much higher quality so the signal to noise ratio is much better

Re: Firing programmers for AI is a mistake

#545

Post by MyOutfitIsVague »

sanderjd wrote: post #392
MyOutfitIsVague wrote: post #383

Earlier quoted context omitted.

Excel is hardly "no-code". Any heavy use of Excel I've seen uses formulas, which are straight-up code.

But any heavy use of "no-code" apps also ends up looking this way, with "straight-up code" behind many of the wysiwyg boxes.

Right, but "no-code" implies something: programming without code. Excel is not that in any fashion. It's either programming with code or an ordinary spreadsheet application without code. You'd really have to stretch your definitions to consider it "no-code" in a way that wouldn't apply to pretty much any office application.

Re: Firing programmers for AI is a mistake

#546

Post by inetknght »

iainctduncan wrote: post #466
inetknght wrote: post #445

Earlier quoted context omitted.

> I work in tech diligence. This means the companies I talk to cannot lie or refuse to answer a question Nice. How do I get into that kind of position? > Tech debt paralyzes companies all the time, but nobody hears about it because there's zero advantage to the companies in sharing that info. If nobody hears about it, then how do you hear about it? Moreover, what makes you think it's tech debt and not whatever reason…

Sure I can clear it up. What happens is once they are into a potential deal, they go into exclusivity with the buyer, and we get brought in for a wack of interviews and going through their docs. Part of that period includes NDAs all around, and the agreement that they give us access to whatever we need (with sometimes some back and forth over IP). So could they lie? Technically yes, but as we ask to see things to dem…

> I can say that finding real devs who have all those traits is not easy!

Sounds like some very high bar to meet, that's for sure!

> We typically have two days of interviews with them and we specifically talk about tech debt.

> Our job is to ask the right questions and ask to see the right things to get the goods. We get to look at code, Jira, roadmap docs, internal dev docs, test runner reports, monitoring and load testing dashboards, and so on.

Call me a skeptic but, given that scope, I have trouble believing that two days is sufficient to iron out what kinds of tech debt exist in an organization of any size that matters.

Re: Firing programmers for AI is a mistake

#547

Post by batuhandumani »

rpcope1 wrote: post #326
batuhandumani wrote: post #28

Such writings, articles, and sayings remind me of the Luddite movement. Unfortunately, preventing what is to come is not within our control. By fighting against windmills, one only bends the spear in hand. The Zeitgeist indicates that this will happen soon or in the near future. Even though developers are intelligent, hardworking, and good at their jobs, they will always be lacking and helpless in some way against th…

AI generated slop like your comment here should be a ban-worthy offense. Either you've fed the it through an LLM or you've managed to perfect the art of using flowery language to say little with a lot of big words.

I used for just translation. What makes you think this my thoughts are AI? Which parts specifically?

Re: Firing programmers for AI is a mistake

#548

Post by menaerus »

Jcampuzano2 wrote: post #530
menaerus wrote: post #470

Earlier quoted context omitted.

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 o…

Several millions lines of code. Can't remember any project that I was involved with and that was less than 5MLoC. C++ system level programming.

Overhyped or not Devon is using something else under the hood since it is pre-processing your whole codebase. It's not "realtime" since it simulates the CoT meaning that it "works" on the patch the very same way a developer would. and therefore it will give you a resulting PR in few hours AFAIR. I agree that a workable example on more complex codebase would be more interesting.

> I've tried using all the available commercial models and none work better than as a helpful autocomplete, test, and utility function generator

That's the why I mentioned qwen because I think commercial AI models do not have such a large window context size. Perhaps, therefore an experience would have been different.

Re: Firing programmers for AI is a mistake

#549

Post by layer8 »

lordswork wrote: post #456
layer8 wrote: post #365

Earlier quoted context omitted.

When I see stuff like https://news.ycombinator.com/item?id=42994610 (continued in https://news.ycombinator.com/item?id=42996895 ), I think the field still has fundamental hurdles to overcome.

This kind of error doesn't really matter in programming where the output can be verified with a feedback loop.

This is not about the numerical result, but about the way it reasons. Testing is a sanity check, not a substitute for reasoning about program correctness.

Re: Firing programmers for AI is a mistake

#550

Post by throwaway0123_5 »

weatherlite wrote: post #449
skydhash wrote: post #438

Earlier quoted context omitted.

The fact that you don't see why is the issue. Both python and JS are very permissive and their runtime env is very good. More often than not, you're just dealing with logic bugs and malformed domain data. A kernel codebase like Linux is one where there are many motivated individual trying every trick to get the computer to do something. And you're usually dealing with leaner abstractions because general safety logic…

> More often than not, you're just dealing with logic bugs Definitely. More often than not you're dealing with logic bugs. So the thing solving them will sometimes have to be able to reason quite well across large code bases (not every bug of course, but quite often) to the point I don't really see how it's different than general intelligence if it can do that well. And if it gets to the point its AGIish , I don't se…

I agree with this. An AI that can fully handle web dev is clearly AGI. Maybe the first AGI can't fully handle OS kernel development, just as many humans can't. But if/once AGI is achieved it seems highly unlikely to me that it will stay at the "can do web dev but can't do OS kernel dev" level for very long.
Post reply on HN