Live data from Hacker News

Firing programmers for AI is a mistake

defragzone.substack.com

661–670 of 886 posts

Re: Firing programmers for AI is a mistake

#661
post #144

There's such a huge disconnect between people reading headlines and developers who are actually trying to use AI day to day in good faith. We know what it is good at and what it's not. It's incredibly far away from doing any significant change in a mature codebase. In fact I've become so bearish on the technology trying to use it for this, I'm thinking there's going to have to be some other breakthrough or something…

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…

One of my first bosses was a big Perl guy. I checked on what he was doing 15 years later and he was one of 3 people at Windstream handling backbone packet management rules.

You just don’t run into many people comfortable with that technology anymore. It’s one of the big reasons I go out of my way to recruit talks on “old” languages to be included at the Carolina Code Conference every year.

Re: Firing programmers for AI is a mistake

#662

I'm not sure why people are so sure one way or the other. I mean, we're going to find out. Why pretend you have a crystal ball and can see the future? A lot of articles like this just want to believe something is true and so they create an elaborate argument as to why that thing is true. You can wrap yourself up in rationalizations all you want. There is a chance firing all the programmers will work. Evidence beats a…

This. Articles like this are examples of motivated reasoning and seem to be coming from a place of insecurity by programmers who feel their careers threatened.

Re: Firing programmers for AI is a mistake

#663

Earlier quoted context omitted.

Long before any use of LLMs, OsmAnd would direct you, if you were driving past Palo Alto, to take a congested offramp to the onramp that faced it across the street. There is no earthly reason to do that; just staying on the freeway is faster and safer. So it's not obvious to me that patently crazy directions must come from watching people's behavior. Something else is going on.

OsmAnd doesn't use traffic data. You can enable traffic map layers by feeding a reverse-engineered URL, though.

I'm not talking about use of traffic data. In the abstract, assuming you are the only person in the world who owns a car, that route would be a very bad recommendation. Safety concerns would be lower, but still, there's no reason you'd ever do that.

Re: Firing programmers for AI is a mistake

#664

Earlier quoted context omitted.

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…

And you have had luck with models like the one you mentioned and Devon generating significant amounts of code in these codebases? I would love to be able to have this due to the productivity gains it should allow but I've just never been able to demonstrate what the big AI coding services claim to be able to do at a large scale. What they already do is a decent productivity boost but not nearly as much as they claim…

As I already said in my first comment, I haven't used those models and any of them would have been forbidden at my work.

My point was rather that you might be observing suboptimal results only because you haven't used the models which are more fit, at least hypothetically, for your use case.

Re: Firing programmers for AI is a mistake

#665

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.

I've worked in finance for 20 years and this is the complete opposite of my experience. Excel is ubiquitous and drives all sorts of business processes in various departments. I've seen people I would consider Excel gurus, in that they are able to use Excel much more productively than normal users, but I've almost never seen anyone use VBA.

Re: Firing programmers for AI is a mistake

#666

Earlier quoted context omitted.

All previous examples have been of the "no code" variety, where you press buttons and it controls presets that the creators of the authoring tool have prepared for you. This is the first time where you can talk to it and it writes arbitrary code for you. You can argue that it's not a good idea, but it is a novel development.

A no code solution at its most basic level is nothing more or less than a compiler. You wouldn’t argue that writing in a high level language doesn’t let you produce arbitrary code because the compiler is just spitting out presets its author prepared for you. There are 2 main differences between using an LLM to build an app for you and using a no code solution with a visual language. 1. The source code is English (whi…

I just outright disagree. What this Vibe Coding is a substitute for is to finding a random dev on Fiverr, which inherently suffers from your "1 and 2". And I'd argue that vibe coding already offers you more bang for your buck than the median dev on Fiverr.

Re: Firing programmers for AI is a mistake

#667

Earlier quoted context omitted.

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…

Yeah I've found its good for getting something basic started from scratch, but often times if I try to iterate, it starts hallucinating very fast and forgetting what it was even doing after a short while. Newer models have gotten better at this and it takes longer before they start making things gibberish but all of them have their limit. And given the size of lots of enterprise codebases like the ones I'm working in…

That is also my experience. I use ChatGPT to help me iterate a Godot game project, and it does not take more than a handful of prompts for it to forget or hallucinate about something we previously established. I need to constantly remind it about code it suggested a while ago or things I asked for in the past, or it completely ignores the context and focus just on the latest ask.

It is incredibly powerful for getting things started, but as soon as you have a sketch of a complex system going it loses its grasp on the full picture and do not account for the states outside the small asks you make. This is even more evident when you need to correct it about something or request a change after a large prompt. It just throws all the other stuff out the window and hyperfocus only on that one piece of code that needs changing.

This has been the case since GPT 3, the even their most recent model (forgot the name, the reasoning one) has this issue.

Re: Firing programmers for AI is a mistake

#668
I have been doing this for 30 years now. The software industry is all about selling variations of the same stuff over and over and over. But in the end, the more software there is out there, the more software is needed. AI might take it over and handle it all, but at some point, it would be cruel to make humans do it.

Re: Firing programmers for AI is a mistake

#669

Earlier quoted context omitted.

I see that you deleted your previous response which was unnecessarily snarky while my question was genuine and simple I suppose. > And frankly, if you can't automate context, How about ingesting the whole codebase into the model? I have seen that this is possible with at least one such tool (Devon) and which I believe is using gpt model underneath meaning that other providers could automate this step too. I am curiou…

> How about ingesting the whole codebase into the model? You keep referring to this vague idea of "ingesting the whole codebase". What does this even mean? Are you talking about building a code base specific rag, fine tuning against a model, injecting the entire code base into the system context, etc.?

It is vague because the implementation details you are asking me for are closed source, for obvious reasons. I can only guess what it does but that's besides the point. The point is rather that Devon or 1M window context qwen model might be better or more resilient towards the "lack of context" than what the others were suggesting.

Re: Firing programmers for AI is a mistake

#670

Earlier quoted context omitted.

The problem is now that the LLM GPS will lead you to the wrong place once a day on average, and then you still need either open the map and study where you are and figure out the route, or refine the destination address and pray it will bring you to the correct place. Such a great analogy!

Strangely this reminds me of exactly how you would navigate in parts of India before the Internet became ubiquitous. The steps were roughly: Ask a passerby how to get where you want to go. They will usually confidently describe the steps, even if they didn't speak your language. Cheerfully thank them and proceed to follow the directions. After a block or two, ask a new passerby. Follow their directions for a while an…

Indeed. My experience in India is that people are friendly and helpful and try to help you in a very convincing way, even so when they don't know the answer. Not so far off LLM user experience.
Post reply on HN