Staff Engineer here. Our CTO told us in March two things. One, if we didn't get on board with AI then we would be unemployable in 3 months and two, we had to use AI for everything. Literally everything. I asked (as a senior engineer of 19 years) if that included simple bug fixes I see that take minutes vs 30+ describing the problem. The answer was "absolutely". Our budget is $400K /month to Anthropic and we exceeded that 3 weeks into May
Update on this: those people who didn't incorporate it into their workflow have been let go. Last night they released 1/6th of the staff.
Our budget is $400K /month to Anthropic and we exceeded that 3 weeks into May
Fucking hell, that's so much money to burn on management's AI addiction. Have to wonder how your finance department feels about burning almost half a million a month.
Also, wild that management is telling you that not letting your skills degrade by handing everything off to an AI is what'll make you unemployable.
They think once the ball is rolling, then they can phase out the humans.
They think that AI usage is like training a junior dev, that it starts out hopeless but over time can operate without the expertise.
They don't realize that invoking AI doesn't work that way, that the context window is the only accumulation of anything germain to your codebase, and that the model doesn't evolve based on that interaction.
So they don't care about the skills, they want to get to the point where they can toss a prompt into Claude and have it all taken care of, thinking that their employee usage of it somehow accelerates that outcome.
That's just a handful of enthusiastic interns, except that you aren't investing in cultivating future talent...
Burn that budget. Make the CFO pull their hair out when they look at expenses vs revenue. For once, bean counters might save us from this BS.
If they're anything like my company's executive team, they're using AI to make their decisions too. They're being spoonfed the issue isn't AI underperforming, it's you.
They'll soon fire you first before capitulate on the notion their AI implementation sucks.
400k a month is quite a bit of GPU power. I do not understand why software companies aren't at least offsetting their Claude usage with open source models running on their own hardware. It seems like a no brainer. Opus is really good but most tasks aren't that complex and a smaller model will work just as well.
Sometimes I'm sad I quit software development as a job. So much room for malicious compliance with this AI bullshit. And if something goes wrong you can just blame it on the AI you were forced to use. The fun I could have had..
Ours said the same thing back in December. Our principal engineer said we had to start using the chatbot for all coding.
I’ve tried it but at some point it gets faster for me to do it myself 50% of the time. And some of the other times it’s just flat out wrong. The times it gets it right are great; but I hate feeling like I’m relying on a slot machine for my job.
I just started using it just to commit and for PRs to make it look like I’m using it all the time. Burns tokens and execs can’t tell the difference.
Towards the end of the month I just start generating mindless crap so I don't get "dinged" for under-using AI.
The rest of the month I always set the model to the most expensive to try to naturally burn through my quota and get marginally less annoyed by the even worse suggestions from the default models.
Since burning through tokens really involves letting it invoke commands, I don't really burn that much naturally since I don't like reviewing and approving commands and I'm sure as hell not going to let it just run comands at will.
It's always the damn suits.
Here it seems like panic in the face of things like the CopyFail/DirtyFrag/Fragnesia/ssh-keysign-pwn stuff.
That if he didn't let AI 'fix' the issues it can find first, then someone will hit rsync with devastating CVEs.
Problem is he saw that the tool was offering to 'fix' things that perhaps weren't quite right and saw a credible proposal to implement fixes, but the fixes were for bugs no one cared about or noticed and weren't security related, but incurred side effects that people did notice.
If you have a non-security bug that's been in place since 2019 and the only thing that noticed was an LLM analysis of your codebase, it may be best to let sleeping dogs lie...
For those who don't know, "tridge" is legendary.
He casually reverse engineered Microsoft's SMB protocol, creating Samba, back when windows file sharing was a key part of Microsoft's lock in. He also isn't just the maintainer of rsync, he invented the algorithms it uses. People who worked with him consider him a genius and a guru.
How much you want to bet he's just bombarded by the "ai security reports arms race" I saw on here a couple days ago, where people use LLMs to find security holes in open source projects (likely a form of 'fuck the dev' training)? I mean, for hundreds of reports to come in, some of which I'm sure are legitimate, is overwhelming to a team... and he's just one dude.
Edit. Looks like I may have been right. User Chairman Meow posted an excerpt from Discord that basically says that. Even legends get lonely, it seems.
Yep. A solo dev working on a project. Legitimate security flaws found by people who don't know much of anything about coding, but can prompt an LLM. They don't even understand the bugs they're submitting, so if he has questions they can't help.
His choice is either to spend all of his free time trying to patch these bugs, or to look for help. It's very hard to find help as a solo dev on an unsexy but essential tool. So, he turned to LLMs to help. And, who knows, maybe he's able to use them slightly more responsibly than other devs. But, LLMs almost inevitably lead to their own bugs because LLMs are always confident, and are designed to produce something that looks as much as possible like real working code, but without any actual thought or analysis behind them.
If you read the discord chat logs, it makes sense. He's being bombarded by security vulnerabilities discovered via LLMs, from people who barely know how to code and can't even explain the flaw that their LLM discovered. He's a solo maintainer, and his choice is either to leave these security vulnerabilities open, or to turn to LLMs to try to keep up with the need for patches.
I don't think he made the right choice, but I think he's probably a much better programmer than me.
This is about to be a big thing. LLMs are very good at finding exploits and creating scripts to exploit them. Now a script kiddy is much more powerful. Companies are trying to figure out how to respond. Red Hat's Project Lightwell is one such project.
Another is
It’s going to be a bloodbath.
I don't think he made the right choice, but I think he's probably a much better programmer than me.
I'm a senior dev that works with LLMs these days and been running dozen people teams before and reading slop code is a skill that needs to be built through months/years of work no matter how good of a programmer you are - it's a different skill set.
Honestly what happened to language models is a shame. Good tools perverted to try and do every job. LLMs dont really have a place and eat up so much resources with what effects to a okay scaffolding tool in code, and a piece of shit liar everywhere else. I remember seeing this shit being used in medicine almost 15 years ago thinking thats gonna be a cool technology to we expand. It was fucken not.
Neural networking has so much potential in so many places, yet of course the industry collectively zoomed in on LLMs specifically and is trying to sell them as a panacea to the world's problems.
As though a mechanical parrot knows anything about good coding practices, or literally anything outside of mimicking speech patterns.
My theory is it's because LLM's could talk directly to the C-suite.
The reason labs focus on LLMs is that language is a great substrate for generalization. Good luck trying to one-shot out of distribution problems using classic neutral networks. They've tried for decades to make it happen but LLMs surpassed those results in a few years.
I understand that idea, but at the same time @placebo@lemmy.zip has a point.
There's a good reason why you generally don't get a CPU to do graphics and why FPGAs are usually only put on dev units.
Specialist hardware is generally much more efficient cost and energy wise than generalist hardware for a given task.
And I imagine that must be true for neural networks too, as that layer of language processing on top of any task naturally can't be as efficient/performatative as specialist software/networks made for the job.
And I imagine that must be true for neural networks too, as that layer of language processing on top of any task naturally can’t be as efficient/performatative as specialist software/networks made for the job.
Oh yeah definitely, a specialized model for each task would be more efficient on the inference side but can you imagine the cost of training a million specialized models ? For example you could think of natural language processing as it was done before : one model for sentiment analysis, one model for chronological analysis, one model for identifying legal terms etc... need to classify color descriptions in natural language ? Well here you go train another model. A small model (comparatively) but also one you'll have to re-train if you want to change the task even slightly.
A LLM has the advantage of being able to generalize a lot of different tasks on the same model, including some that are wildly out of distribution (meaning you hadn't even thought of them and they are not explicitly stated in the training data). So yeah, you pay a big training tax to train one large model, but then it pays off because that same model can perform on a million different tasks.
At least that's the thesis. I'm not qualified to judge whether it is proving worth it, but that's the reason why the industry massively shifted towards LLMs.
you saw LLMs being used in medicine almost 15 years ago? was it something else because the the transformer model was invented in 2017
Almost all of the latest commits on the project now :/
No other way to review long patches besides LGTM says only profession that keeps doing that
The project's issue tracker has been pretty wild recently, for example https://github.com/RsyncProject/rsync/issues/929
God both sides are toxic AF and here I am simply want to know if correlation is causation.
It is. Reading thus lemmy threads gives commits or links to other commenters. My fav is this one https://neuromatch.social/...
That's a great post, that well displays the issues with AI tests! For my own personal curiosity I looked at the testing rewrite of rsync, specifically the chgrp_test because it was the smallest test I quickly found. If you look at the original shell script, all it does is call chgrp and then fail if it doesn't work. In the Python rewrite on the other hand the LLM calls chown to change the group and only if that fails, it tests chgrp. So if for some reason chown works but chgrp would fail, the original shell script would easily catch that (cause why do you test for chown anyways) while the Python rewrite doesn't even call chgrp in case chown works.
Even though, this might not be as much of a problem in practice, I think it illustrates that the AI tends to write tests where it already anticipates and tries to fix potential issues, which absolutely goes against the use of tests!
I think it illustrates that the AI tends to write tests where it already anticipates and tries to fix potential issues, which absolutely goes against the use of tests!
LLMs just generate "statistically probable" text, all it's doing is generating text that looks like how you'd write tests, they may or may not actually test anything.
Lol this is hilarious! I want to see the prompt they used cause my god they didn't think it through
https://packages.debian.org/stable/rsync
Package: rsync (3.4.1+ds1-5+deb13u3)
slow and steady beybeee
Oh great. We have 3.4.3 in testing, so uh, next stable will probably have it.
I'm starting to think that I don't want to use Arch anymore and thus always be among the first to get all the new slop.
Debian + KDE Plasma got me to switch over from Mint. It just feels right.
There have been a LOT of updates recently though. Normally I update pretty often because part of the reason for using Debian is my expectation that an update has been pretty thoroughly vetted before it gets pushed out to stable, and that stability/reliability is one of the priorities of the distro.
I just hope that holds true, and that if LLMs are involved it's those cases where they stumble upon an obscure security flaw that humans confirm.
Involving LLMs is not the problematic part, it's having them write code that the maintainer doesn't understand. Finding issues, suggesting optimizations, helping to write comments or commit messages are all perfect uses of LLMs for critical tools like rsync.
Sounds like the real issue is funding for the maintainers though.
There's a downgrade utility for a reason lol. You always have that option and it's not particularly hard to use. Most of the time it's fine but yeah shit like this does happen from time to time.
It's good to see AI sloppers already being confronted, dropped, and outcompeted.
It's a bit sad since it's the guy who has been doing this for decades and doing such a good job.
Now Claude comes along and he's convinced he has to slop it up or else get trampled by AI security scanning efforts.
Yeah, the human story here is saddening. Worst part is it can end up being his legacy, decades of diligent work and one misstep in the eyes of (part of) the community and now his work will be considered trash.
I agree with the sentiment but I'm not following on this incident. Who is outcompeting tridge and making a better rsync?
Whoever gets there first if rsync literally stopped working.
But when it worked there was no work being done. The repo just stayed there, working. Doing nothing.
A few LLM commits have kickstarted the process of a lot of people checking their rsync versions, choosing the correct one. And so on. That is work that wasn't being done before, and now it is done thanks to LLMs. Truly a wonder of our times.
Okay, I imagine that using an LLM is like having several Tasmanian Devils on your team.
The funny part is how people are so willing to jump from one thing they perceive as slop, to an entirely different thing they’ve never audited yet now somehow trust. 🤪
There’s gotta be a good market for hackers just forking and promising no AI to bring in all the reactionary suckers.
Such a dumb take. We trust (or don't trust) the maintainers, not the software qua software. You think that's a typo and that's fine, ask your fucking friend about it, it knows. Idiot
If it's written in Python
I'm a new and non-power-user of rsync. It seems like a pretty straightforward utility. What active development is even needed?
All software need active development. Dependencies change, new features are requested, bugs appear, ... Even the most simple utilities are concerned
That sounds mostly like maintenance, not active development, except for the feature requests.
This graph feels relevant:
Yes, it's from a github issue thread somebody linked somewhere in this comment section.
You're not a dev so this is a great question actually. It is not straightforward at all, it's actually a really complicated problem and it does not solve itself
Just gonna copy what tridge said:
bottom line is if you want to be useful then pick holes in the test suite, find things it doesn't cover, find interactions between options it doesn't pin down, report those and offer fixes for that.
Why ask for forks or alternatives?
rsync sucks now it really sucks
This is a duplicate thread but sure, imma just copy paste from my previous comment.
Here's the Discord dump for those who don't want to join (Tor not allowed, sorry I don't have a better file host, AI brought down 0x0.st). No further commentary.
[30.05.2026 10:05] andrewtridgell
I reviewed it. The rsync project has been essentially a single developer project for about 20 years now
[30.05.2026 10:06] andrewtridgell
Wayne did it all himself for a long time, now I'm back doing it
[30.05.2026 10:06] realketas
why is it one man job, it seems like too complex for that
[30.05.2026 10:06] realketas
i can't even imagine
[30.05.2026 10:06] andrewtridgell
nobody else volunteers. Its the same story with thousands of open source tools
[30.05.2026 10:07] realketas
it runs entire planet, just one man does it eh
[30.05.2026 10:07] realketas
sad too
[30.05.2026 10:07] andrewtridgell
the linux kernel has thousands of paid full time devs. rsync has zero.
[30.05.2026 10:15] andrewtridgell
the most insane part is that security releases can't be community tested. Those security releases are going to be a huge part of lots and lots of open source projects for a while to come yet, just look at the rate of CVEs over the last couple of months, its gone nuts. You can't do a beta release of a security fix as its embargoed. So for the most critical fixes you *can't* have anyone else look at it. The people reporting the flaws mostly don't have the skills as they used AI to find the bugs. So the maintainer is the sole person to review the most critical security changes, and that is how the madhouse called the internet and IT security is designed. The only defence I have is to build the most comprehensive and accurate test suite I can, so when I need to deal with yet another security report I can at least quickly identify what else the fix breaks. Luckily I can do that work (the dev of the test suite) in public.
[30.05.2026 10:22] andrewtridgell
bottom line is if you want to be useful then pick holes in the test suite, find things it doesn't cover, find interactions between options it doesn't pin down, report those and offer fixes for that.
Basically, it's a solo dev being swamped by LLM security reports, and since those are embargoed only maintainers can review them... and since nobody else has volunteered, he has to do it himself.
He primarily used several AIs to rewrite the test suite from shell (slow, lacking coverage) to python (parallelised, improved coverage). He says he's extensively reviewed everything, but I guess the suite doesn't cover everything. And the test suite changes can be community reviewed.
The dev has been actively inviting people to join as a maintainer and poke holes in the test suite, but it seems nobody has stepped up. I can't really blame the dev here, he just seems unable to keep up without others helping him out. He's tried to use AIs as sensibly as he could, and I'm not entirely sure if it's slop fixes that cause the issues (or if an "unassisted" fix would have caught it).
A very important question is being hypothesized here and I hope we all come to a conclusion sooner rather than later.
Is it better for a FOSS project to be abandoned because a single maintainer is overwhelmed? OR Should a single maintainer use LLM tools to continue a project they no longer are able to handle?
I personally see abandoned projects easier to pick up when left "as is" for someone to eventually come in. Doing massive amounts of ai code that eventually breaks the functionality (or presumably does), and then expecting people to come in to a larger shit storm seems daunting.
Fact is there's a bunch of 50+ engineers that have been looking after these fundamental components for a long time, and people aren't coming through to hand things off too. It won't be long before they'll have come to the end of their working lives and things will be abandoned.
I would prefer they walked away rather than resort to LLM agentic coding.
If you want to pick up this project you can take the last pre-llm version.
Or go work with the dev who is actively begging for volunteers instead of trying to make a whole new project.
I see a lot of bitching in that thread but no offers to help maintain the project.
Doesn't excuse slop in the slightest. An unmaintained or abandoned project is infinitely better than updating and corrupting the codebase with slop.
I suppose the problem is that this was evidently brought on by trying to use AI to be proactive about security risks from AI findings. So an abandoned rsync would gather cves.
That said, it looks like he has used Claude to poke at bugs no one noticed, security issue or no. Like a promise about a combination of flags having a certain effect that didn't happen. So fine, technically you didn't live up to your man page, but no one complained, so maybe the risk of change isn't worth the change.
If it's a security issue, then... ok fine, you have to give it a try, but it looks like stirring things up to try to fix years of maybe not right, which is a risky proposition.
I suppose the problem is that this was evidently brought on by trying to use AI to be proactive about security risks from AI findings. So an abandoned rsync would gather cves.
It would gather CVEs, yes, but at least the codebase would not change so fast that even the maintainer themselves can no longer keep up with understanding all the changes. I've looked at a few commits and there's way too many lines of code for the maintainer to have carefully reviewed and understood them all.
But an abandoned rsync would have two great advantages:
- it would give stronger support / user interest to a fork
- distros would not face the decision whether or not to upgrade to a version with slop in it
If it’s a security issue, then… ok fine, you have to give it a try, but it looks like stirring things up to try to fix years of maybe not right, which is a risky proposition.
Also - if a tool finds a security risk, then I want a human maintainer to wrap their head around the attack vector to come up with the correct patch to counter the actual attack vector. Slop machines have zero understanding, so if you need to put out a house fire with people in it, a slop machine might as well drain all oxygen from the air. The fire will be gone after that. But so will the people.
Which commit was the slop that caused the issue?
It's not like bugs didn't happen before AI, so to be so confident it's slop that caused the issue you surely know which commit caused the issue?
I'm incredulous about the direction of AI development tools, but this whole thing is turning into attacks on the guy and acting like bugs didn't happen before AI.
It looks like one of the issues is around openat2 which has only been around for 6 years or so. Rsync assumes that it's available and has no fall back. I'm not sure what openat2 is or what was used before or why the change was made. I'm guessing it was an error but as ai was deemed to be involved everyone lost their shit
Are you sure you want dumbasses like me to contribute? I thought we hated enshittification? (This goes for AI code too)
Enshitification is more about adding shitty anti-features than sucking at maintaining something. A codebase falling apart due to AI contributions should be called something else, like slopification. There might be an older term for codebase losing quality because of incompetent maintainers.
Borg doesn't have any indications of any slop involvement and borgmatic has a strong stance against it ("in order to continue to earn its place as trusted backup software, borgmatic must remain handwritten by humans instead of vibe coded by generative AI").
Borg doesn’t have any indications of any slop involvement
Sorry to be the messenger, but they aren't opposed to it: CONTRIBUTING.md#responsible-ai-usage.
As long as they genuinely stick by what they write there, that doesn't sound too unreasonable, does it?
That's nice. But Borg isn't rsync and can't replace it. Rsync is a thousand times more versatile. Not to mention usable.
YOU GOT CHAT GIPPITy'ed
I wonder about the timing of this. I just got a backup NAS out at my mom's house some miles away and for one or two beautiful days I was sending Rsync differential backup jobs through the vendor interface for backups over Wireguard. The NAS is still on my network over WG, comes back up in that way after a reboot…but for the last week, those backup jobs just break with a useless error. I haven't had the time to look under the hood at logs but I've been assuming this was slopping config on my part cause I'm new at it. But it would almost be a relief if it was just a bad update (before the graver implications of the situation set in on my mind). I wish I had enough background in this stuff to be useful, but I'm just a bystander and a grateful, useless end user.
Oh, they have things called tests, also recently reimagined in slop.
It looks like some issues were introduced by rewriting the shell-based tests in Python. Or rather by AI rewriting the shell-based tests in Python....
I guess OpenRsync is the answer now
I still have my Commodore 128 and 512K memory expansion. When modern computers become so grotesquely over bloated that all they do is burn CPU and RAM on running mutually contradictory programs riddled with bugs no one understands, I'll be there using GEOS...
"Who cares" is exactly what we think about your braindead comments regarding a tool you don't even use. You complain about "bloat", all while wasting data storage drive space with your whiny, useless comments. You are bloat in human form.
Switch to openrsync
Correction, because nobody else wanted to maintain it.
And this has started to become an anti-AI culture war thing, with many of the bugs attributed angrily to AI being bugs that have existed in the code for years.
Wherein backups falling consists entirely of one self report of the users self written backup script not working followed by him seeing commit messages indicating usage of ai with zero effort to show work diagnose the cause or bisect to failing commit despite poster being a hobbyist who dabbles in programming.
Trust me bro.
You should try reading the rest of the comments section. It's not just this one dude.
Did someone else Post an actual analysis
Completely unjustifiable to complain about something FREE AND OPEN SOURCE
The developer owes nothing to anyone and is CERTAINLY not owed backlash for using the tools available to try and continue to help others
This kind of reaction is how to ensure the death of FOSS projects. It’s bullying, it’s insensitive, and worst of all it helps no one.
That framing is missing a lot. Open source software is way more than about using the code. For me, it is not the bugs and quality that concern me most about things like this (though I do have concerns with that too). It's about the broader issues with LLMs in terms of cooperate power, environmental impact, etc. Calling it out is less about any one project and more about stopping the whole open source ecosystem from spiraling into an LLM-dependent mess. LLMs themselves can easily become the death of FOSS in a broader sense
LLMs flip the power dynamics of development on their head. For starters, the outputs are likely no longer copyrightable in many jurisdictions, which undermines copyleft licenses (rsync is under GPL for example).
The kind of code that LLMs generate also tend to add complexity rather fast where it becomes more and more difficult for any human to understand it. Becoming dependent on LLMs makes development more of a question of computing power rather than effort. Companies will be able to spend more than you. FOSS will not be able to compete nearly as well. It's also an inherent dependency on big tech companies who will be happy to exploit that the second they can or cut you off it you start to hit their bottom line. Software cannot be free in terms of freedom if modifying it in a reasonable amount of time starts to almost require a tool controlled by someone else
Using "Open Source" (which has somehow become "public weights" to most) / local LLMs are hardly freedom from this either given that they will always be behind given the massive financial costs to make models, unlike traditional software. If you find any advantage or way to reduce resource usage to make a better model, the bigger tech companies will just quickly scale that up far bigger than you can and meet or exceed what you have. It still just as well makes your ability to modify software dependent on the hardware you have. How free is open source software if it becomes increasingly difficult to modify without an expensive GPU?
I recommend demonstrating your values with helpful actions like donating to FOSS projects, forking them, etc
The lack of control and sustainability you’re articulating represents one side of the basic nature of FOSS.
There are no shareholders.
The other side of it is that it’s open source - someone else can pick up from here and do it their way and there’s nothing stopping them or you.
There’s no good reason to go after the developer.
I have worked on open source projects. I cannot fork sheer number of projects going towards LLMs alone. This is a losing proposition. Open source is not an individualistic action. This is a collective action, and we need developers of open source to live the values of open source
someone else can pick up from here
A big point of my comment earlier was that making a project increasingly LLM generated makes it harder for someone to pick up as quickly. A huge amount of complexity can be added insanely fast. In this rsync example, the entire testing system was changed overnight (while generating issues in the process). The projects become harder to work on in general
EDIT: also to add, this still has the issues of not knowing where the un-copyleftable code lies and/or having to rework large portions of the project are if you want to keep that
actually the dev does owe the community something. I'm sure the dev has enjoyed many fruits of the labor they put into rsync, but most of all are clout and opportunities.
the dev was able to access high profile high paying jobs because of the success of rsync. they were able to become well known enough in the community to speak to large groups about their project and other topics as well. they were given a platform to voice their opinion and rally support behind topics or other projects.
the dev benefited by the good will of the community.
now, the community that the dev worked with, used, to attain the position they currently hold is complaining that something is wrong. the project is broken. the dev has ignored the problems and continues to use the tool causing all the problems.
no. the dev owes us an explanation at the very least.
- why are they leveraging a flawed tool to maintain such an important and integral solution for the entire world?
- why do they ignore the complaints from the community?
- are they willing to hand over development to a new dev or group that will maintain it properly?
No, they don't. You're acting like all those benefits you listed are payment or compensation for the work they did. If those serve as compensation, they don't create a forward obligation. The paycheck you get at work doesn't entitle your employer to your continued labor.
The community isn't owed shit for the guy giving them something useful that may have looked good on his resume. It's entitled as fuck to think you're owed something because someone built something you found valuable enough that someone else wanted to hire them.
To answer your questions:
- because it's their project and they thought it was the right tool for the job. What answer were you expecting?
- because the community isn't working on the project.
- probably not.
Seriously. Demanding someone give up control of their personal project because it's too important for them to run as they see fit, but not important enough to support or help maintain.
Fork it and maintain it yourself. Literally nothing is stopping you. You're just as equipped as he is, other than not being the inventor of the underlying technology.
Lol. No, so far any and all "big announcements" from Claude, including: vibing a c compiler, forking zig or Mythos being magic with security were either embellished or plain lies.
(And no, in this situation it wasnt any security issues being patched lol)
In this particular case, it looks like he set Claude about finding all sorts of anomolies. So it identified scenarios that had been there years that technically wasn't what was originally intended.
In the process of fixing the "bugs" no one noticed or cared about, it introduced bugs that people very much noticed and cared about.
Using AI properly is a skill guys it does not come automatically
Also you need to demand it performs regression tests properly.
Honestly popular models are so good these days if it produces wrong result its the fault of the one in front of the screen.
We are not at the point of AGI so dont expect AI to read your mind
Yes because most people who hate AI dont even know the ABC of AI or that they hate AI for a completely wrong reason. I dont like AI everywhere either but if we continue hating this greatest achievement of 21st century so far unconditionally we will never get to the light
Yess
If you ask it to it will
How du you use ai properly?
probably fucks it every night begging for electrogonorrhea.
How do you know?
First you write your requirements properly in a text or a markdown file. It should properly explain what you want and more importantly what you dont want. Then you give that to AI and dont forget to include "ask any number of clarifying questions before we begin"
Next, be prepared to answer all of its clarifying questions. If you dont know you can ask it to suggest recommended option and pros and cons of each approach
Yeah it will take an entire day. Deal with it. If your requirement is not to just create a few pages of html and css it may take upto half day to a full day but once you are clear. Ask it to write specs and plan and it will.
Then when you are happy with the plan it will start building it. At that point you can step off and let it do its thing
I have the problem that I defined coding patterns, eslint rules etc. But at some points it just ignores it.
It seems it just doesn't have those defined rules available at all times.
You said to explicitly define things that the agent shouldn't do?
Using Claude code if that matters.
Where do you define it? Do you define it in CLAUDE.md? That thing gets loaded on every conversation so it should pick up.
Ohh and one thing, you are only supposed to put there something that is absolutely necessary. Things like "This project uses Typescript" is absolutely unnecessary because its something claude will auto infer. Something like "Do not push into master branch" should be there. Also as it gets loaded on every conversation, you should keep it short or else your token usage blows up.
You can have something like "YOU MUST STRICTLY FOLLOW GUIDELINES LISTED IN commit_guidelines.md BEFORE YOU RUN ANY GIT COMMANDS" if you feel your CLAUDE.md is getting too large.
But honestly, you should ask CLAUDE itself to write CLAUDE.md with strict and proper guardrails rather than yourself
@lemmy.world
"We did it, Patrick! We made a technological breakthrough!"
A place for all those who loathe AI to discuss things, post articles, and ridicule the AI hype. Proud supporter of working people. And proud booer of SXSW 2024.
AI, in this case, refers to LLMs, GPT technology, and anything listed as "AI" meant to increase market valuations.
go to feed...
@lemmy.world
"We did it, Patrick! We made a technological breakthrough!"
A place for all those who loathe AI to discuss things, post articles, and ridicule the AI hype. Proud supporter of working people. And proud booer of SXSW 2024.
AI, in this case, refers to LLMs, GPT technology, and anything listed as "AI" meant to increase market valuations.
go to feed...
What is it about LLMs that makes so many devs' brains melt?
save