[GuB-42]

I think the article could be more accurately titled "A Guide to Gen AI / LLM Vibecoding for Programmers who hate their job"

To me, someone who actually love programming, it makes vibe coding look like hell.

> The workflow of vibe coding is the same as managing scrums or helping a student through a research thesis

Which programmer wants that?! Just hearing the word "scrum" makes me want to run away and I know I am not alone here. Helping a student through a research thesis doesn't sound so bad, because as a human, helping people feels good. But here, there is no student, no human feelings, and you are not even helping the AI become better in the long term.

[uncircle]

> I think the article could be more accurately titled "A Guide to Gen AI / LLM Vibecoding for Programmers who hate their job"

Given how “vibe coding” is all about explaining clearly the requirements and defining context, it’s for programmers who should have chosen middle management as a career.

To actual programmers that enjoy the craft, using an LLM means ruining the beautiful art of abstraction and mental visualisation of a complex piece of logic, by putting it through the very lossy process of explaining it into words. It would be a bit like a composer or a painter having to use words instead of leveraging their well-honed instinct.

[starfallg]

The reality is that hacking code isn't always beautiful. Most of the time, it is mundane grunt work.

You can always leave the core logic for your to work on and have the AI handle all the bits that you don't like to do. This is what we do for modelling for example, AI helps with the interface and data backends, the core modelling logic is hand-crafted.

[dijksterhuis]

> mundane grunt work.

this is my favourite kind of work. i can switch my brain off and just do something repetitive for a bit.

boredom is necessary for good ideas.

[uncircle]

Yeah, but what about your productivity? You could commit and have to maintain 40% more code for the same pay if you had used an LLM.

[dijksterhuis]

> You could commit and have to maintain 40% more code for the same pay if you had used an LLM.

that ... doesn't sound like a positive argument for using LLMs... was this sarcasm that totally passed me by?

[uncircle]

It was indeed sarcasm

[channel_t]

Yup. I think programmers are giving themselves too much credit here. I love programming, but let's not kid ourselves, at most organizations at least 75% of the code needed to make something a working product is BS. I'd rather prompt an LLM agent to take care of that while I review it so that I can spend my limited energy on the more interesting bits. I find the exercise of prompting an LLM to generate boring code to my exact specifications far more intellectually stimulating than doing any of that stuff by hand, and the time that I have invested in this area has paid dividends in making the code cleaner, more consistent, and more coherent.

[tharkun__]

Sounds like you really like code reviews. You must be a unicorn.

I find most programmers don't like code reviews. They do it because it's required by their job and most will just click the approve button. Or I guess in a more dysfunctional org, argue about formatting or something, which should just be done automatically so that nobody has to even think about it.

What they like doing is the coding and problem solving.

And now you want to make programming into code review?

How's that gonna go?

[jf22]

I've been middle management for half my career and the role has never been about explaining or requirements or defining context like I do with an LLM to code...

[CuriouslyC]

I choose the tech stack and architect the project.

I choose the language patterns and code organization.

I step in to solve hard problems when agents flounder.

What about that says middle management? It's just getting rid of all the low iq parts of the job.

[JohnMakin]

almost every job ive ever had has been to build stuff. frequently programming is used to build stuff. programming is not my job, building stuff is. it’s perfectly normal (and a sign of a more mature engineer, imho) to prefer building stuff to the annoying stuff that gets in the way of building stuff, especially since many languages are obnoxious to work with.

[polishdude20]

I agree. I'm hired to build stuff and make it work. I get satisfaction from building stuff people want and use. If I can use an LLM to help me focus more on what the user wants in all for it.

I feel good because real humans are using what I've built and they like it.

[Sharlin]

Yes; in particular English is an incredibly obnoxious language to try to build software with. (Replace English with any natural language if you want.)

[kiitos]

building stuff is the application of programming, not the platonic form of it

if you see programming as a necessary but ultimately annoying means to an end, that's fine, you do you, but there are many other folks who don't look at it that way, and they're no more or less right or wrong than you are

[recursive]

I think I enjoy programming. Vibe coding removes most of the parts that I like. It already looks like hell. I'm probably a minority, but I don't think I'm alone in this.

[ako]

I really like creating software solutions, vibe coding removes the part that is most tedious. LLMs allow me to experiment with different solutions and different designs faster.

[afro88]

Do you enjoy the work you had to put in for every single PR? I'm not trying to make a "surely there's 1" annoying argument, but a "surely there's 5-10%".

For me, that's:

- working in legacy parts of the codebase

- anything that requires boilerplate that can't be code genned

- actually writing the code of unit tests (the fun part is making code testable, and coming up with what to test)

- fixing lint issues that can't be auto fixed yet

- removing old feature toggles

- building a temporary test harness

The list goes on. That's not hell. That's getting someone else on the team to do all the stuff you don't enjoy, without ruining someones day.

[dgfitz]

> working in legacy parts of the codebase

This is why most of us get paid what we do, I’m sure you realize that. There is immense value in having engineers on a team/at a company that can do this.

> anything that requires boilerplate that can't be code genned

It is important to understand the boilerplate. It is also important to understand what is boilerplate and what isn’t. After these things are grasped, usually it’s a copypasta.

> actually writing the code of unit tests (the fun part is making code testable, and coming up with what to test)

If you don’t know how to write unit tests you don’t know how to write testable code. If you do know how to write unit tests you understand the value in maintaining them when you make code changes. Passing that off to a statistical next token predictor renders the tests largely useless

> fixing lint issues that can't be auto fixed yet

You should be thankful you didn’t write code in the 80s if this is a real stance. More thankful still that you rarely need to interact with code sans a linter or autocomplete. There are lots of technologies out there where this isn’t possible. Off the top of my head would be yocto recipes.

> removing old feature toggles

I’m not clear what this even means? You mean, doing your job?

> building a temporary test harness

Generate one, I don’t care. You’ll never know if it’s any good unless you go over the whole thing line by line. At which point, you didn’t save time and didn’t “level up” any skills

[roadside_picnic]

> Which programmer wants that?!

Agreed.

My LLM usage has quickly become a more efficient way to solve problems that basically require copy/pasting from some documentation I have to look up where me doing it myself is more error prone.

I was recently doing a fairly complex set of data transformations and understanding what the data means remained essential. AI tends to fail spectacularly at really understanding the nuances of data (that often requires understanding the underlying business logic generating the data).

However it's very useful when I have to do a bunch of window functions, where I can describe the operation but don't want to look up the syntax. Or just writing SQL when I can explain exactly what I need it to do.

Similarly working with Pytorch involves a fair bit of what I consider pseudo-boilerplate where the code itself is quite boring, but contains just enough complexity that it can't be simply automated away. Hand rolling this stuff often leads to small errors/bugs, but LLMs can do a spectacular job of quickly generating this, provided you do know exactly what you're looking to build.

What's interesting is that this has still been a major speed boost, because looking up how to do some tedious thing you just forgot how to do can really break flow.

[lubujackson]

I like coding. I've been doing it for a couple decades. I disagree with the "managing scrum" metaphor. Sure, you can use LLMs that way. And there is some truth to the fact that it may feel more like writing detailed Jira tickets than actually programming at times if you are trying to have it make huge changes... BUT coding with LLMs is really just a higher level abstraction. And the good news of that is LLMs are more deterministic than they seem, which is a lot of what people are fearful of losing by giving LLMs "the reins".

One nice thing about programming is that the computer is a dumb funnel for your human brain to encoded actions. If the program doesn't work, you did something wrong, missed a semicolon etc. This still applies to LLMs. If the LLM gave you shit output, it is your fault. You gave it shit input. If the model you used was the wrong one, you can still get good results, you just have to put in more work or break the problem down more first. But it's still programming. If you treat using LLMs that way, and start to apply your normal programming approaches to your prompts, you can find a workflow that satisfies your demands.

But even if you only use LLMs to rubber duck a problem, by literally typing "The program is doing X,Y,Z but it's only supposed to do Z. I already looked at A,B,C and I have a theory that G is causing the issue but I'm not seeing anything wrong there." and just paste that in the chat you might be surprised what it can turn up. And that's a fine use case!

LLMs are broadly useful and there are certainly elements of programming that are the "shit-shoveling" parts for you, from debugging to writing tests to planning or even re-writing Jira tickets, LLMs can help at different levels and in different ways. I think prescriptive calls to "code this way with LLMs" are shortsighted. If you are determined to write each line yourself, go for it. But like refusing to learn IDE shortcuts or use a new tool or language, you are simply cutting yourself off from technological progress for short term comfort.

The best part of programming to me is that it is always changing and growing and you are always learning. Forget the "AI eating the world" nonsense and treat LLMs as just another tool in your toolkit.

[cheema33]

If someone enjoys building houses with a hammer and nail, they still can. Other like using tools.

You will always be able to write code by hand. But you will not be able to keep up with other engineers who master using AI tools. I am a software engineer, I like building things. And I don't use binary or assembly, or C or any other lower level languages for good reasons. AI is just another higher level abstraction. A tool that allows me to build things a little faster. I use it every day.

[wsintra2022]

IDE’s are tools, languages are tools, LLMs are code generators, not quite the same thing.

[ChrisRackauckas]

Hey, definitely agree in many respects! I have been programming for over a decade because I love to. And the worst part the job has always been giving feedback to a student/engineer who clearly just doesn't care and makes the same mistake again, like why should I keep reading your code instead of working on the fun hard problem I've been wanting to?

But, what I found over time is that as my role grew, the amount of work that could be done grew exponentially. In grad school I had one project to work on, by postdoc there was 10 papers that could be juggled, now there's so many different projects/collaborations/contracts/etc. that I could be a part of that it's all just a matter of "do I have time for that?". Then the team sizes start to grow: having one student turns into 5, into a lab, into a team at one company, then a growing team at another, and an open source organization. In one decade life changed from "wake up, figure out what to program, make it" to "wake up, see the deluge of issues and PRs, start code review, try to get that done so I can start 'my' day", and I think most people in programming tend to have a trajectory like that. The role changes from "build something" to "find out where others are getting stuck and unblock them", plus 200+ issues files about trivial shit. The goal here is to to have the LLMs handle the trivial shit, I unblock someone, and then finally the glory hour of me getting to build something is back!

But I think this is why there are lots of very smart people who have decided they wanted to be individual contributors in Silicon Valley instead. And they are really well-respected, and you want them in your squad! If that's the direction you want to go, then you probably also are of the kind that avoids LLMs a bit (and are thus a good person to have on a team, balancing velocity people with precision people). But if you want to start driving bigger projects, sooner or later teams grow as that's the only way to put out the bigger grander idea.

But I do think that if Anthropic made a Claude stuffed animal with a very punchable face it would be a very hot selling add-on as while this can accelerate the day, sometimes it makes the stupidest decisions and you really have to think "okay it doesn't hate me, it's not trying to spite me, it doesn't even know me, but damn it tried to hide that it commented out the one most crucial test!"