A lot of the arguments people use against vibe coding sounds a lot like "You shouldn't use a high-level programming language unless you understand the assembly it compiles to."

I think I know who did that meme. We had a programmer by that name who did just that.

I know I'm gonna get flamed for this, but here goes.

I have vibe coded a system at work that has enabled me to deliver value in a fraction of the time I expected. My verification steps have been around whether it does the things I told it I wanted it to do. I'm not maintaining the syntax and I'm not expecting anyone else to. Ever.

That said, our teams that deliver products that touch customer data or financial records....they shouldnt (and dont) engineer this way. The tech isnt there (yet).

Let the flaming commence.

You make the billionaires proud, such a good lil capitalist

Why couldn't this apply any to a non profit or public service? What makes it inheritingly capitalist?

Or are you presuming the model is owned by a for profit corporation?

For having a job? You're unemployed, aren't you?

And what form of employment do you have which doesn't support billionaires?

I'm just trying to do my job in the system I'm in friend.

So... Just like any other legacy system you inherit.

I once heard someone describe legacy systems as systems without test coverage. I think it's not the best description, but it's certainly an interesting perspective.

It's part of why it bothers me when folks say they use LLMs to make unit tests. If anything, you should be writing tests by hands to get a solid specification then let the AI make the code. Of course this is a false dichotomy, but I'm just saying if you have to choose between those two options in some weird hypothetical bizarro world.

Not the best description doesn't cut it, it's just false description. I can easily write a system with 100% test coverage, bugged as hell and containing so many weird abstraction tricks that it takes a significant effort to figure out even what is happening in the simplest scenario. And yes, part of that hundred percent coverage is going to be llm style: test that something does what you already know it does

actually, be exactly like bill. boss wants slop, boss gets slop.

boss wants incomprehensible buggy code? that's right, boss gets incomprehensible buggy code.

Be sure to ask Claude to remove all comments, tests, and dry runs, then ask if there's a good way you can make the code more complicated without increasing runtime more than 40%.

Sorry, you were hired as a prompt engineer, your prompt wasn't good enough to make perfect code, so you are fired

Nah. A bunch of llm code review agents say that produced code is of high quality, fire anyone who said it would have taken for them to implement same functionality more time than I have spent

That's only fine as long as there aren't coworkers who have to fix all that shit

you mean by unionizing right?

Not if boss wants my name (and thus responsibility) on it.

i'm losing a job, they are hopefully losing a business.

Does Bill have the flaming frenzy within?

He better not have his spine poked by anything sharp :)

(in cade I failed at it: reference to Midra)

Asking an LLM to add comments is actually pretty much the worst thing you can do. Comments aren't meant to be documentation and LLMs have a habit of writing documentation in the comments. Documentation is supposed to be in the documentation, not in the code. LLMs are often trained on things like tutorials, where super obvious statements are commented to allow people to learn and follow along. In actual code you absolutely do not do this, obvious statements should be obvious by themselves. At best it's extra work to read and maintain the comments for obvious statements, at worst they are incorrect and misleading. I've worked on systems where the comments and the code weren't in line with each other and it was a continual guess if the comment is the way it was supposed to work, or if the code is correct and the comment wrong.

So when do you actually add comments? That's actually very hard, something people argue about all the time and a bit of an art form to get right. For example if I have some sort of complex calculation, but it's based on a well known algorithm, I might comment the name of that algorithm. That way I can recognize it myself right away and someone that doesn't know it can look it up right away. Another good indicator for comments are magic numbers. It's often smart to put these in constants, so you can at least name them, but a small little comment to indicate why it's there and the source can be nice. Or when there is a calculation and there's a +1 for example in there somewhere, one might ask why the +1, then a little comment is nice to explain why.

Comments should also serve like a spidey sense for developers. Whenever you are writing comments or have the urge to add some comments somewhere, it might be an indicator the code is messy and needs to be refactored. Comments should be short and to the point, whenever you start writing sentences, either start writing documentation or look at the code why it's required to explain so much and how to fix that.

Another good use for comments is to warn away instincts for future devs. For example in a system I worked on there is a large amount of code that seems like it's duplicate. So a new dev might look at it and see a good place to start refactoring and remove the duplicated code. However the duplication was intentional for performance reasons, so a little comment saying the dupe is intentional is a good idea.

I've also seen comments used to describe function signatures, although most modern languages have official ways of doing that these days. These also might border on documentation, so I'd be careful with that.

LLMs also have a habit of writing down responses to prompts in the comments. For example the LLM might have written some code, you say: Hey that's wrong, we shouldn't set x to y, we should set it to z. And the LLM writes a comment like // X now set to Z as requested. These kinds of comments make no sense to people reading the code in the future.

Keep in mind comments are there to make it easier for the next guy to work on the code, and often that next guy is you. So getting it right is important and hard, but very much worth while. What I like to do is write code one day and then go back and read it the next day or a few days later. And not the commit, with the diff and the description, the actual files beginning to end. When I think something is weird or stands out, I'll go back and edit the code and perhaps add comments.

IMHO LLMs are terrible at writing code, it's often full of mistakes and oversights, but one of the worst parts is the comments. I can tell code was AI generated right away by the comments and those comments being present are a good indicator the "dev" didn't bother to actually read and correct the code.

There's also the class of comments that explain strange business decisions.

# Product guy said to return January 1st if the user doesn't have a birthday on record

Kind of arbitrary but someone with decision making power decreed it.

this is among the most important comment types that exist imo

it may not seem like it but 20 years and 5million lines later when shit behaves odd because of some non standard code practice this type of comment is a life saver

Kind of arbitrary but someone with decision making power decreed it.

Here, under protest is this code. Every time the user doesn't have a birthday, we return January 1st. Do we really mean that?

Excellent comment and I fully agree with almost everything. Just one tiny nitpick:

For example if I have some sort of complex calculation, but it’s based on a well known algorithm, I might comment the name of that algorithm.

Unless you really need this complex calculation to be inline (e.g. for performance reasons) it would be better to move it into a function or method and include the algorithm in the name instead of adding a comment.

Very good! Your spidey senses are working perfectly. Hey I want to comment this calculation, why don't I move it into a function so the name can explain what it does. Good call!

Sometimes the algorithm is inlined for performance, sometimes it's a class with a bunch of functions that as a whole is primarily based on an algorithm, so comments might make sense in those cases. Most of the times it's a library, so the name of the library kinda gives it away and hopefully has good documentation as well.

i want it in a function

fully include the pre implementation long hand in comments and the book / expert reference

the number of times i’ve found longer algos not doing as advertised is scary

improperly used statistical algos given the data sets and hand waving results are so common

gee i wonder why testing shows no improvement

Comments aren't meant to be documentation

Documentation is supposed to be in the documentation, not in the code.

Some tooling generates documentation from comments. Like rustdoc or LDoc.

I'll be honest, I mostly skimmed through your comment. Sorry if it's something you touch upon later on.

They're doing more than math.

Huh? Did you mean to reply to me? I never mentioned math.

I was as an allusion to a vowel off the "math" from the length that you even mention not reading the entire volume of.

If you get it, you get it. If you don't, that is, in and of itself, respectable.

I disagree that comments are an indication of messy code. The purpose of comments are to 1) translate low level concepts into higher ones for improved readability and 2) to maintain information in the design process that can't be represented by the code itself.

Obviously I don't have to comment mathematical operations, but it makes sense to comment the algebra of how I derived an equation and it's use in the code. Now, I could refactor that section of code into a function in order to give it a name, but that would make it more difficult to read as the programmer would then have to find the definition of that function somewhere else in the file. It is objectively more spaghetti-like to pull out single-use code into a function rather than just label the block of code with a comment.

Fwiw that's not what vibe coding means

What does it mean? Because just yesterday I saw this guy live streaming a vibe coding session, and he sounded exactly like “Bill”.

Bill doesn't understand liability clauses in contracts when he sells his vibe coded shit as a SaaS platform and gets popped because AI forgot about SQL injection.

OWASP Top 10 is pretty much a list of suggestions for vibe-coders.

vibe coders are the best thing to happen to anyone looking for common vulnerabilities

meh that’s a different support package

I recently got moved to another team after my company restructured. Several repos have zero documentation. Most of those don't even have comments on the functions. LinkXxxx(some args) like Xxxx to /what?!/ It's also an over-engineered mess with multiple layers of abstraction. I can't wait to finish figuring out what everything does and re-write (and document it) like a sane person. This code presumably had no AI involvement which I'd argue is even worse since real humans made these shit decisions. Don't get me starting on their testing (and mostly lack thereof)...

Worker suggested using AI to write some documentation. Another coworker did. I immediately spotted a bunch of hallucinated shit. Good times. I want to know in my head what a thing does, how it works, and how it fits into the architecture. I can't do that if an AI is just deciding stuff; it's like a quiz back in school where I would memorize shit for about one week before 99% of it left my brain forever.

Sometimes documentation doesn't help. My workplace used to be waterfall and we still have systems analysts producing documentation

One piece of work came to my team as "this calculation fails in this case and we can't tell why"

Looking at it there were two updates in the documentation showing updates ten years ago the first fixing that corner case with the second fixing a side effect of the fix

Why didn't it work? It was never built, or perhaps built but never merged

On the good side we have an excellent plan for how to fix that corner case, on the bad side we aren't funded to do that amount of work so we have to half arse a solution

The documentation I mean here should be in the repo and checked as a part of the PR process. I don't mean it should be a manual, I just mean a readme should at least describe what the service does (it has such a generic name in my case that it's not self-evident and is so broad in scope I don't know what happened). The functions also have terrible naming and no comments to describe what they do. So, as a guy just coming into this team after re-org with no idea what all this stuff does, I was completely lost. They also changed which services which teams owned, further making it difficult to get knowledge.

Woever made this image should learn the difference between line spacing and paragraph spacing…

This is an example
of line spacing which
clearly shows it's together

And now this is a new
bit that is separate from
the above bit

Readability is important.

“Did you just have Claude ship all this code?”

“Yep”

“You shouldn’t ship code you don’t understand…”

“Good point. Claude, go understand this code for me!”

If Claude understand code, Claude ship code just fine. If Claude understand but you don't, you no ship code, let Claude do!

Got pulled into a meeting where a web dev contractor we hired stated, “I can’t promise these changes, it depends on how we can get CoPilot to do them”. I don’t think my bosses care because they want their bosses to know that they are, “working with AI”.

A lot of big companies are basically forcing you to be Bill. They try to track AI usage, and make sure everyone is using it. Because they invested so much in AI, they need to force it, to make it a self fulfilling prophecy. It’s truly one of the dumbest things to behold.

If the company also trains AI, I'm guessing they're also forcing use to gather training data. I.e. tracking feedback, corrections, etc.

So it's enshittification, but they've doused the whole shebang with rocket fuel and set it ablaze.

Nightmarish. Can you make the AI write up new documentation every time you want to push a change, so it looks like you're using it frequently but you still get to write the code yourself?

I would love letting LLM deal with documentation. It's the bane of my existence.

Tried that, result was shitty documentation and as someone who reads other peoples documentation for a living I will NOT subject other people or my future self to that.

Kill Bill. Wait...

Well... Heck. I recently vibe coded an app for a specificish use case. I didn't even think about commenting my code. It was the first time I've ever done such a thing..

I'll go and comment it all.

Thanks for the reminder OP

Now that's a good vibe coder

I should also go do that

The code is the comment anyway. The only thing you should comment is things that are way the hell out in left field about why that bit of code exists when it shouldn't.

And suddenly, I'm reminded of JoCo's "Code Monkey".

I hate Bills, taking all my money.

But he isn't the Microsoft ceo anymore

I hate most of the companies paying people to write code though, isn't it a good thing if their code is shit that no one can understand and doomed to collapse under its own weight?

midwest.social

Rules

  1. No porn.
  2. No bigotry, hate speech.
  3. No ads / spamming.
  4. No conspiracies / QAnon / antivaxx sentiment
  5. No zionists
  6. No fascists

Chat Room

Matrix chat room: https://matrix.to/#/#midwestsociallemmy:matrix.org

Communities

Communities from our friends:

Donations

LiberaPay link: https://liberapay.com/seahorse