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

461–470 of 886 posts

Re: Firing programmers for AI is a mistake

#461

Post by jddj »

lolinder wrote: post #381
hombre_fatal wrote: post #303

Earlier quoted context omitted.

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…

> Why wouldn't this be the case for people using LLM like it was for everyone else? I feel like it's a bit different this time because LLMs aren't just an abstraction. To make an analogy: Ruby on Rails serves a similar role as highways—it's a quick path to get where you're going, but once you learn the major highways in a metro area you can very easily break out and explore and learn the surface streets. LLMs are a G…

> LLMs are a GPS, not a highway.

I love these analogies and I think this one is apt.

To adapt another which I saw here to this RoR thread, if you're building furniture then LLMs are powertools while frameworks are ikea flatpacks.

Re: Firing programmers for AI is a mistake

#462

Post by t-writescode »

chubot wrote: post #160
ActionHank wrote: post #143

Earlier quoted context omitted.

There is little evidence that AI is replacing engineers, but there is a whole lot of evidence that shareholders and execs really love the idea and are trying every angle to achieve it.

The funny thing is that "replacing engineers" is framed as cutting costs But that doesn't really lead to any market advantage, at least for tech companies. AI will also enable your competitors to cut costs. Who thinks they are going to have a monopoly on AI, which would be required for a durable advantage? --- What you want to do is get more of the rare, best programmers -- that's what shareholders and execs should b…

> Instead, those programmers will be starting their own companies and competing with you

If so, then why am I not seeing a lot of new companies starting while we're in this huge down-turn in the development world?

Or, is everyone like me and trying to start a business with only their savings, so not enough to hire people?

Re: Firing programmers for AI is a mistake

#463

Post by guccihat »

When the AI dust settles, I wonder who will be left standing among the groups of developers, testers, scrum masters, project leaders, department managers, compliance officers, and all the other roles in IT.

It seems the general sentiment is that developers are in danger of being replaced entirely. I may be biased, but it seems not to be the most likely outcome in the long term. I can't imagine how such companies will be competitive against developers who replace their boss with an AI.

Re: Firing programmers for AI is a mistake

#464

Post by gip »

msaspence wrote: post #441
gip wrote: post #408

I think that some engineers will still be needed to maintain old codebases for a while yes. But it's pretty clear that the codebases of tomorrow will be leaner and mostly implemented by AI, starting with apps (web, mobile,...). It will take more time for scaling backends. So my bet is that the need for software engineering will follow what happened for stock brokers. The ones with basic to average skills will disappe…

What makes you think that AI is going to produce leaner codebases? They are trained on human codebases. They are going to end up emulating that human code. It's not hard to imagine some improvement here, but my gut is there just isn't enough good code out there to train a significant shift on this.

Good question and I have no strong answer today. But I think we'll find a way to tune models to achieve this very soon.

I see such a difference between what is built today and codebases from 10 years ago with indirections everywhere, unnecessary complexity,.. I interviewed for a company with a 13yo RoR codebase recently after a few mins looking at the code decided I didn't want to work there.

Re: Firing programmers for AI is a mistake

#465

Post by rapind »

blibble wrote: post #426

ultimately Facebook and Google are completely unimportant, if they disappeared tomorrow the world would keep going however, I for one can't wait for unreliable garbage code in: - engine management systems - aircraft safety and navigation systems - trains and railway signalling systems - elevator control systems - operating systems - medical devices (pacemakers, drug dispensing devices, monitoring, radiography control…

What irks me the most about AI is the black box mutability. Give it the same question of reasonable complexity and get a slightly different answer every time.

I also dislike mass code generation tools. The code generation is basically just a cache of the AIs reasoning right? So it's sort of pre-optimization. Eventually, once cheap enough, I would assume the AI reasons in real time (producing temporary throw-away code for every request). But the mutability issue is still there. I think we need to be able to "lock-in" on the reasoning, but that's a challenge and probably falls apart with enough inputs / complexity.

Re: Firing programmers for AI is a mistake

#466

Post by iainctduncan »

inetknght wrote: post #445
iainctduncan wrote: post #343

I work in tech diligence. This means the companies I talk to cannot lie or refuse to answer a question (at risk of deals failing through and being sued to obvilion). Which means we get the hear the real effects of tech debt all time. I call it the silent killer. Tech debt paralyzes companies all the time, but nobody hears about it because there's zero advantage to the companies in sharing that info. I'm constantly go…

> 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 demonstrate that what they said is true, and it would break the contract they've signed with the potential acquirer, that would be extremely risky. I have heard of cases where people did, it was discovered after the deal, and it retroactively cost the seller a giant chunk of cash (at risk of even more giant law suit). 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. For example, if someone said something vague about responsivness, we'll look into it, ask to see the actual load metrics, ask how they test it and profile, and so on.

I got into because I had been the CTO of a startup that went through an acquisition, knew someone in the field, didn't mind the variable workload of being a consultant, and have the (unusual) skill set: technical chops, leadership experience, interviewing and presenting skills, project management, and the ability to write high quality reports. Having now been in the position of hiring for this role, I can say that finding real devs who have all those traits is not easy!

Re: Firing programmers for AI is a mistake

#467

Post by strangescript »

dham wrote: 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…

As context sizes get larger (and remain accurate within the size) and speeds increase, especially inference, it will start solving these large complex code bases.

I think people lose sight of how much better it has gotten in just a few years.

Re: Firing programmers for AI is a mistake

#469

Post by larve »

This is missing the fact that budding programmers will also embrace these technologies, in order to get stuff done and working and fulfill their curiosity. They will in fact grow up to be much more "AI native" than current more senior programmers, except that they are turbocharging their exploration and learning by having, well, a full team of AI programmers at their disposal.

I see it like when I came of age in the 90ies, with my first laptop and linux, confronted with the older generation that grew up on punchcards or expensive shared systems. They were advocating for really taking time to write your program out on paper or architecting it up front, while I was of the "YOLOOOO, I'll hack on it until it compiles" persuasion. Did it keep me from learning the fundamentals, become a solid engineer? No. In fact, the "hack on it until it compiles" became a pillar of today's engineering: TDD, CI/CD, etc...

It's up to us to find the right workflows for both mentoring / teaching and for solid engineering, with this new, imo paradigm-changing technology.

Re: Firing programmers for AI is a mistake

#470

Post by menaerus »

Jcampuzano2 wrote: post #393
menaerus wrote: post #216

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.

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?

Then again, and I am repeating myself from other comments I made here in the topic, there's also Devon which pre-processes the codebase before you can do anything else. That kinda makes me wonder if current limitations that people observe in using those tools are really representative of what might be the current state of the art.

Post reply on HN