Hacker News Reader

Comment by elliotbnvl | Hacker News Reader

Yes! I’ve seen this myself, folks moving back into development after years or decades.

They're not moving back into development. They're adopting a new approach of producing software, which has nothing to do with the work that software developers do. It's likely that they "left" the field because they were more interested in other roles, which is fine.

So now that we have tools that promise to offload the work a software developer does, there are more people interested in simply producing software, and skipping all of that "busy work".

The idea that this is the same as software development is akin to thinking that assembling IKEA furniture makes you a carpenter.

That IKEA analogy is pretty good, because plenty of people use IKEA furniture to solve the "I need a bookshelf" problem - and often enjoy the process - without feeling like they should call themselves a carpenter.

I bet there are professional carpenters out there who occasionally assemble an IKEA bookshelf because they need something quick and don't want to spend hours building one themselves from scratch.

Definitely. I'm not disparaging the process of assembling IKEA furniture, nor the process of producing software using LLMs. I've done both, and they have their time and place.

What I'm pushing back on is the idea that these are equivalent to carpentry and programming. I think we need new terminology to describe this new process. "Vibe coding" is at the extreme end of it, and "LLM-assisted software development" is a mouthful.

Although, the IKEA analogy could be more accurate: the assembly instructions can be wrong; some screws may be missing; you ordered an office chair and got a dining chair; a desk may have five legs; etc. Also, the thing you built is made out of hollow MDF, and will collapse under moderate levels of stress. And if you don't have prior experience building furniture, you end up with no usable skills to modify the end result beyond the manufacturer's original specifications.

So, sure, the seemingly quick and easy process might be convenient when it works. Though I've found that it often requires more time and effort to produce what I want, and I end up with a lackluster product, and no learned skills to show for it. Thus learning the difficult process is a more rewarding long-term investment if you plan to continue building software or furniture in the future. :)

Little bit of a sweeping generalization there. There are a huge range of ways in which LLMs are being leveraged for software development.

Using a drill doesn’t make you any less of a carpenter, even if you stopped using a screwdriver because your wrists are shot.

It's called being a systems analyst or product manager. Upskill into these roles (while still accepting individual contributor pay) or get left behind.

Do you see any reason why AI and software will not soon take over system analyst or product manager roles? If we can go from natural language prompt to working code, it seems like not too big of a step to set up a system that goes straight from user feedback to code changes.

I'm sorry, "upskill"? The roles you mentioned don't require any more advanced skills than those required for software development—just a different set of skills.

And an IC is not "left behind" if those roles don't interest them. What a ridiculous thing to say. A systems analyst or product manager is not a natural progression for someone who enjoys software development.

Only it’s a bit like me getting back into cooking because I described the dish I want to a trainee cook.

Depends on how you're using the LLMs. It can also be like having someone else around to chop the onions, wash the pans and find the ingredients when you need them.

The head chefs at most restaurants delegate the majority of details of dishes to their kitchen staff, then critique and refine.

This approach seems to have worked out for both Warhol and Chihuly.

As long as you get the dish you want when before you couldn’t have it — who cares?

Sure, as long as you don’t expect me to digest it, live with it, and crap it out for you, I see no problem with it.

My expectations don’t change whether or not I’m using AI, and neither do my standards.

Whether or not you use my software is up to you.

So you're saying that if you go to any famous restaurant and the famous face of the restaurant isn't personally preparing your dinner with their hands and singular attention, you are disappointed.

Got it.

Are you even cooking if you did not collect your own ingredients and forge your own tools??

Isn't that still considered cooking? If I describe the dish I want, and someone else makes it for me, I was still the catalyst for that dish. It would not have existed without me. So yes, I did cook it.

Work harder!

Now I’m a life coach because I’m responsible for your promotion.

Ok, maybe my analogy wasn't the best. But the point I was trying to make is that using AI tools to write code doesn't meant you didn't write the code.

Very apt analogy. I'm still waiting for my paycheck.

> If I describe the dish I want, and someone else makes it for me, I was still the catalyst for that dish. It would not have existed without me. So yes, I did "cook" it.

The person who actually cooked it cooked it. Being the "catalyst" doesn't make you the creator, nor does it mean you get to claim that you did the work.

Otherwise you could say you "cooked a meal" every time you went to MacDonald's.

Why is the head chef called the head chef, then? He doesn’t “cook”.

To differentiate him from the "cook", which is what we call those who carry out the actual act of cooking.

Well, don’t go around calling me a compiler!

If that's what you do, then the name is perfectly apt. Why shy away from what you are?

The difference is that the head chef can cook very well and could do a better job of the dish than the trainee.

"head chef" is a managerial position but yes often they can and do cook.

I would argue that you technically did not cook it yourself - you are however responsible for having cooked it. You directed the cooking.

Flipping toggle switches went out of fashion many, many, many years ago. We've been describing to trainees (compilers) the dish we want for longer than most on HN have been alive.

Actually, we’ve been formally declaring the logic of programs to compilers, which is something very different.

(Replying to myself because hn)

That’s not the only difference at all. A good use of an LLM might be to ask it what the difference between using an LLM and writing code for a compiler is.

Equally a good use for a legacy compiler that compiles a legacy language. Granted, you are going to have to write a lot more boilerplate to see it function (that being the difference, after all), but the outcome will be the same either way. It's all just 1s and 0s at the end of the day.

Sorry friend, if you can’t identify the important differences between a compiler and an LLM, either intentionally or unintentionally (I can’t tell), then I must question the value of whatever you have to say on the topic.

The important difference is the reduction in boilerplate, which allows programs to be written with (often) significantly less code. Hence the time savings (and fun) spoken of in the original article.

This isn't really a new phenomenon. Languages have been adding things like arrays and maps as builtins to reduce the boilerplate required around them. The modern languages of which we speak take that same idea to a whole new level, but such is the nature of evolution.

No, when we write code it has a an absolute and specific meaning to the compiler. When we write words to an LLM they are written in a non-specific informal language (usually English) and processed non-deterministically too. This is an incredibly important distinction that makes coding, and asking the LLM to code, two completely different ball games. One is formal, one is not.

And yes, this isn’t a new phenomenon.

It's different in some ways (such is evolution), but is not a distinction that matters. Kind of like the difference between imperative and declarative programming. Different language models, but all the same at the end of the day.

I hope you are joking.

The only other difference mentioned is in implementation, but concepts are not defined by implementation. Obviously you could build a C compiler with neural nets. That wouldn't somehow magically turn everything into something completely different just because someone used a 'novel' approach inside of the black box.

The only difference is that newer languages have figured out how to remove a lot of the boilerplate.

Reply on news.ycombinator.com