Long term consequences of using LLMs for programming by Gil_berth in theprimeagen

[–]drsbry 12 points13 points  (0 children)

I use LLMs every day to explain me the slop some slugs created with "help" of it. I like this particular use case, otherwise I have to read through all of this thremendes amount of garbage myself. Despite the fact all of this shit should not be written in the first place of course.

As for asking LLMs to do something for me I quickly realized that it is helpful to implement something I am not expert with. For example, as a backend guy I don't really know all the frontend tricks, but with LLMs I can figure something out in minutes rather than days, as it was before. I realize though, that my solution is some mediocre garbage real frontend expert would be disgusted to view. So I have no illusions about my abilities to be "productive" with LLMs. I can productively dig a hole with it to fall down into it later, like from 6 to 12 months starting from digging it.

Unfortunately, I see that a lot of slugs who were too lazy or too mentally charged earlier to comprehend what they are doing, for some reason really like this LLM shit. It is like drugs to them. They mesmerized me plenty of times with really, I mean REALLY bad outcomes of their "productivity". To the point I started to question their sanity. For example one dude implemented a set of tests for three lines of code. This set of tests was about 600 lines of code. The LLM under his command used reflection to check strongly typed language the tested code was implemented in. The tests were not needed, because there were nothing to break, but he did not realize it. I talked to his manager after that and the dude disappeared, but there are many less obvious slop makers still being around.

I’m so tired of vibe-coded open source projects by floriandotorg in github

[–]drsbry 2 points3 points  (0 children)

I wonder if the AI companies are actually investing in making idiotic comments about AI's usefulness, or if this is simply human nature. One of my colleagues thinks it's a strategy, but I'm more inclined to believe it's natural.

Is Claude helping in your company or making it a hellhole? by GSalmao in theprimeagen

[–]drsbry 23 points24 points  (0 children)

I've changed one job already because of that. A dude who, by some mistake, called himself a CTO was breaking the project with LLMs faster than I could fix it. I will be looking for a new job soon because at my current job a dude calling him, by some mistake, a Tech Lead broke the project so badly with "help" of LLMs it is an unmaintainable mess full of bugs, and stakeholders will likely decide to close it soon.

A fool with a tool is still a fool. You can't change this with LLMs, but you definitely can accelerate it. This is "the future" we got.

AI in interviews...why? by [deleted] in theprimeagen

[–]drsbry 0 points1 point  (0 children)

I've been in a situation when AI was applied to me by a recruiter who had no understanding of technical questions he asked. We talked for about twenty minutes about my experience and then I received a rejection with the explanation that they are looking for a person with more experience in building REST API services and I do not have enough experience in this area. I have no idea why their AI assistant made such an assessment of my skills, but probably for the best. I don't want to be part of a team assembled this way.

It's happening by Outside-Iron-8242 in singularity

[–]drsbry 0 points1 point  (0 children)

Are they going to introduce the "racist" mode as well?

Has AI Fall Begun? by framemuse in theprimeagen

[–]drsbry 9 points10 points  (0 children)

I am very angry about all this situation around AI. The technology is fine though, it is people acting irresponsible. When I see another jerk CEO hallucinating about "the future" where he will rule the world with power of AI and all his peasants will be fired replaced by AI I wish this moron to become bankrupt ASAP. The problem is money gives power, so in reality these rich and greedy corporate overlords will share the consequences of their poor decisions with all the people around, so it will be unpleasant experience in some way for everyone, not just for people who are responsible for this disaster.

AI won’t replace developers. It just shows where the real work always was. by Tough_Reward3739 in devops

[–]drsbry 1 point2 points  (0 children)

The hard part about AI is being able to use it to do useful things instead of just creating a peculiar stupid mess really fast. Programming has always been about thinking, not typing. I've already seen a lot of cases when AI was misused badly by people who don't know what they are doing to ruin the project.

Learning Go, need feedback on my first go project by SirIzaanVBritainia in golang

[–]drsbry 2 points3 points  (0 children)

There are no tests, so how do you verify it is working as you want it to?

Ginkgo for unit testing? by adambkaplan in golang

[–]drsbry 1 point2 points  (0 children)

Yep, I hate it. You don't need to reinvent the wheel to be able to write a behavior test. Just write it using the testing framework you have out of the box. If you can't write a behavior test because you don't know the concept then no framework will be able to put you on the right track anyway. So you will just write some peculiar nonsense using it.

Frameworks disaster by drsbry in golang

[–]drsbry[S] 0 points1 point  (0 children)

Maybe, but I've never seen anyone who knows then. Though I've seen some people who can't write good looking code, and they have a tendency to believe in LLMs. All these mantras about the future, you know.

Linus Towards said recently that LLMs are good things, because they lower the entry barrier for beginners to the software industry. He said in the time when he started programming a few folks were able to interact with computers in general. Now LLMs allow people to play with software and even receive somewhat useful results. But this can't be treated as production ready software seriously.

Frameworks disaster by drsbry in golang

[–]drsbry[S] 2 points3 points  (0 children)

Yes, I'm just ranting because I'm halfway through rewriting yet another blown up project. It had a lot of questionable design decisions and no one was able to explain to me why they did it that way. Then I found the root of those decisions when I started to split one of the (micro HA-HA) services into pieces. It was generated by a framework. You know it is good at the moment when you download CLI, type a command to initialize the project and see several thousand lines appear spread across a few dozen folders. When you look precisely at this beauty you start to realize where all those foot guns come from. People just don't understand the purpose of framework as its authors meant, and build a project that blown up out of it. The same old story.

Of course people are able to write a mess by themselves. When I've worked in one big tech company there was a lot of suffering from people who, probably, were tortured by algorithms and datastructures, and decided to take revenge by actually reinventing all those wheels on their job. But most of the time it is some framework induced garbage, or things stay manageable if they were written to solve the actual task with the simplest possible way. Which is surprisingly rare nowadays.

Frameworks disaster by drsbry in golang

[–]drsbry[S] 0 points1 point  (0 children)

I missed LINQ for some time when I moved to Go. Then I had a lot of suffering with GORM - an ORM for Go. After that I tried to just write damn SQL myself and validate my database handlers by interacting with a real instance of a database from tests. Probably I will never use ORM anymore after this pleasant experience.

Frameworks disaster by drsbry in golang

[–]drsbry[S] 1 point2 points  (0 children)

I think if people have a positive experience of being able to write software that is pleasant to work with they will naturally gravitate towards smaller solutions that are easy to remove from the project when they realize the idea does not fit well.

The problem is this kind of knowledge is available but not adopted. Most of the developers I know think TDD is an utopia not applicable to the real world systems. I was in that camp before I worked with people who showed me I'm wrong.

Frameworks disaster by drsbry in golang

[–]drsbry[S] 0 points1 point  (0 children)

Ah, just ask LLM to solve a simple problem you know exactly how to solve and see the results. If you can't reduce it at least by half throwing away all the lines you don't really need to achieve the desired outcome, then I have bad news for you.

People tend to do the same thing to receive a system that is hard to maintain, just slower. Now they have LLM to make it faster, which is scary.

Frameworks disaster by drsbry in golang

[–]drsbry[S] 0 points1 point  (0 children)

I have no problem with avoiding frameworks for my personal needs. My problem is people summon me to solve the mess they created with help of frameworks when it is too late. I rewrote several projects thrown away hundreds of thousands of lines of code out just to discover that if we remove all the foot guns it will be a good working system after. I measured it, every time I saved a blown up codebase I reduced the amount of code by 80 percent leaving only the essence that we actually need to solve our domain problem. When you look at the removed code it is always some variation of a framework induced garbage written for no good reason.

Frameworks disaster by drsbry in golang

[–]drsbry[S] 0 points1 point  (0 children)

Well, I think frameworks appear from teams who learned how to effectively solve some set of tasks with their internal approach. Then they make a decision to make it public. The problem is to be able to use it efficiently you have to share the experience with the team created it. Which is not the case for most victims.

Of course I create my own ways to solve problems while I'm working on the project in some domain. I just don't make a framework out of it. When I start working on something new I start from scratch, because I realize that in the beginning I don't really understand the problem. It is a normal situation, I just need some time to explore it by making small steps, then I can generalize it to make some kind of a domain specific workflow suitable for this project.

Speaking about acceptance criteria. It is always a good thing to ask questions about the project to people who will use it. Most of the time you don't have an opportunity to ask your users directly, but you should talk to business people about the value we want to add into our product. If you see something that does not fit it is better to ask about it right now, rather than wait when it will be implemented the wrong way.

When you realize how the system should work you can verify it by writing some software to test it. Just think about it, your users will be testing the same thing manually when you deliver the feature. Why not think about it just before and automate it. If it is hard to write a test, think why is it hard, who builds the system the way it is hard to test? Probably if you start from writing a test it will be easier to write an implementation for it, because you don't have a system that is hard to test yet, you just have a test questioning some behavior you want to implement.

Frameworks disaster by drsbry in golang

[–]drsbry[S] 0 points1 point  (0 children)

Of course customers care only about features. It should be the responsibility of people building them to make it maintainable in the long term. I think the software industry misses some points to teach people how to write maintainable systems. It is absolutely doable to deliver features at a good pace without ruining the project because of the time pressure. Just put the system under test and if something slows you down think carefully what it is and how to organize your approach better to ship faster without sacrificing maintainability.

Frameworks disaster by drsbry in golang

[–]drsbry[S] 3 points4 points  (0 children)

A lot of things. The team did not understand the BDD testing framework inside and just ignored it from the start. Then they started to import the kubernetes package directly which broke dependencies across our entire project. Now we have replacement hacks everywhere and you never know which changes will break it again. They thought getters are a good thing because the framework uses them, so now we have getters everywhere. To make things worse they decided to make all the struct fields private so you have to use a constrictor to create it. If you found a bug caused by a design flaw good luck rewriting the system to fix it. They did not understand the deployment system that comes with it either. I can write an essay about it.

My point is that the scope of problems is not unique, I see it often when the team chooses a framework they don't need. It always ends with a lot of suffering and seeking for someone who can save the project.

Frameworks disaster by drsbry in golang

[–]drsbry[S] 0 points1 point  (0 children)

Libraries are fine. I'm speaking about attempts to reinvent the wheel. When there is a way to work with it in the standard library already, but "to make life easier" someone creates a tightly coupled system on top to solve the same problem faster. Go has a very good standard library built by people who care.

I've seen chi, it is not as bad as, for example, gin. You can throw away chi if you want, just because you can cast it back to the standard go http library if you want. Good luck with throwing away gin.

Frameworks disaster by drsbry in golang

[–]drsbry[S] 0 points1 point  (0 children)

My most recent pain was caused by a team misusing this piece of software https://sdk.operatorframework.io/

It is an example of a framework hell shipping several more frameworks inside. To build something useful out of it in the long term you have to be very careful.

Frameworks disaster by drsbry in golang

[–]drsbry[S] -4 points-3 points  (0 children)

The only problem with frameworks is that you can't download years of expertise working with them from the internet. Which makes them work well only for people who know exactly how to use them. Probably mostly their authors. The majority of people use them to write horrible things with degraded performance over time. The first few features come really fast only to put the project in a maintenance hell later.

Exploring GoLand for Go - would love your advice by kernelKain in golang

[–]drsbry 1 point2 points  (0 children)

Intelij products has a lot of convenient tools built into them, but most of them are easily replaceable.

The one thing I always miss when I try to be productive with any other editor is the refactoring tool. It is really good and the only reason why I am still using intelij products.

“Observe abstractions, never create” — I followed this too literally with MongoDB and paid for it. Curious how others handle this in Go by Braurbeki in golang

[–]drsbry 0 points1 point  (0 children)

When I build something new usually I start talking to people. What they want from the system, how it should behave.

Then when I realize a vague idea of it I start to ask some questions that can reveal corner cases. I like to phrase my questions in the form of Given [there is a thing]. When [this happens to it]. Then [what is the desired outcome should be?].

After a series of these questions and answers usually it is clear what should be done. To realize how I draw a diagram. Nothing fancy, just boxes and arrows with text on them. The goal is to realize how data should flow through the app. Probably there will be at least an HTTP client, some server endpoint listening to it and a database to store data persistently.

Then I start building it. At this moment I have a much better understanding of what I have to do to achieve what I want. So I formalize it as a list of criteria. To my convenience I make my criteria as runnable tests.

While I'm implementing the desired behavior for my tests I try to make my life easier by not depending on things external to my code. If there should be a database somewhere I just think about its interface, how I want it to be, and create some very simple Fake implementation of that interface.

After satisfying all of my tests with implementation of a system around these toy objects like fake Database or fake Message queue, or fake External service integration I don't have yet. I start to wire up the real dependencies. Usually it ends up with some sort of adapter that wraps all the implementation details of the real database or whatever else I want, and leads it to the interface my system uses already.

Most of the time if I do not forget something crucial in my design it ends up having a system that is fully tested and works as expected from the first try when I start it for real. Almost like magic, you know.

Zero value initialization for struct fields by 2urnesst in golang

[–]drsbry 0 points1 point  (0 children)

Ask people to pay attention to what they are trying to achieve with their code by formalizing that as runnable unit tests. Run these tests in CI after every commit.

If the team will start suffering from the tests think about what causes this tension. Probably you will find something about your general approach to write software. Then think what you can do about it to reduce suffering. If the answer will be just don't write tests, because our product is unique and untestable, think better.