I was doing a code review this week. There was nothing wrong with the code in terms of structure or performance, but it was doing this really weird operation with an ID after DB insert. I asked about it and the author was like “yeah, that’s weird; I don’t know why the AI did that. I’ll remove it.” My dude, I know you can write good code. Don’t be lazy!
i dont understand that. i use ai for help reading through old stuff or to help me remember how tondo a thing i havent done in two years but blindly copy pasting blows my mind.
Same. I also code up about 50% of stuff so all the structure is there, effectively as guardrails, before using AI. Then prompting it instructions that are effectively the solution, so it doesn’t come up with its own.
Then, read through it all, replace things that could’ve been done better, and test.
On average it’s maybe 15-20% quicker than manually coding the whole lot. Try skip any of those steps and the chances of it blowing out increase to the point I just end up doing it all anyway and it’s taken twice as long because of it.
It’s alarming when people don’t even check.
On average it’s maybe 15-20% quicker than manually coding the whole lot.
Out of interest, how much is this 15-20% increase in productivity costing in tokens?
You’d really need to know the fully burdened cost of an hour of the person’s time who’d be doing the work, versus the cost of the tokens plus all the overheads involved in its administration and use of the AI solution (tokens, support, training). Same goes with the downsides-- you’d need to know how the rate of serious bugs changes when you incorporate the slop. Some of the defects will make it through reviews and testing and into prod.
It’d be minimal since I’m doing all the hard work initially and feeding it logic to follow. I find open vibe coding does rip tokens and usually ends up with an overcomplicate mess. Many rabbit holes the AI creates and sends itself down, so a lot more unnecessary lines and often entire redundant blocks.
If someone’s going to do that, at the least break it up into sections to save tokens and time. But ideally, just get some coding experience under the belt of have a crack at it yourself first so it’s easy to identify the pitfalls and where clear instructions is needed.
I’ve been vibing a bit in my spare time, and in the beginning I didn’t look too much at the cost because I was more interested in quickly reaching some sort of mvp state but then I had to manually troubleshoot a thing and wow it was so full of hardcoded bullshit, which was so insanely far from how I was im envisioning it.
I had to backtrack a lot and then started doing like you and tell it what I wanted the code to look like.
I suspect it’s the same people that blindly copied stackoverflow code without understanding it. Which is likely where the LLMs are getting most of its answers from in the first place.
and these people were always the majority.
so people saying that genai amplifies, they are correct, it amplifies the bullshit and the bad things.
there were always more mediocre and useless people that top performers.
it has been a miracle that anything has worked good enough so far.
I worked with a guy that 100% used AI to dev everything. didn’t even check to see if it would work before submitting a MR.
It got to the point that I stopped reviewing them and just rejected them outright with a simple comment, “doesn’t work”.
eventually he was fired. the evidence? the four months of shitty MRs he opened. the best part was, when I said “doesn’t work”, I was never wrong. none of his changes worked.
The lazy part is not questioning the bullshit they noticed and did nothing about - not using the tool
I disagree on that; we lose the muscles we don’t use and I’ve already seen that happening. It’s also making people want to jump straight to implementation without proper design and I think that’s a recipe for trouble.
Again, cowboys have been skipping steps and doing things lazily and poorly well before AI. Everyone knows people who jump straight into an IDE instead of following proper workflows. Yes, skills you don’t practice take a hit. In a professional setting there is such a substantial productivity hit to avoid all AI use, compared to correct and proper use. It will soon be infeasible to take such at anti AI stance and remain in the industry
cowboys have been skipping steps and doing things lazily and poorly well before AI
Of course, but I think not understanding what they’re committing is more dangerous than before (even allowing for the classic “I copied and pasted this from xxxx site”). This is also true when people are fully trusting AI to review code as well.
We use AI for code reviews which I do find useful. It’s still wrong part of the time (sometimes ridiculously so). So far, it’s also failed to provide accurate documentation for various repos which seems like something rather basic. I’m not against all AI (though I do have ethical and environmental concerns with several of the commercial options). I will not have them write code for me, though.
As for the future, we’ll just have to wait and see. I’ve seen a lot of AI budgets exceeded and/or cut. I do think it’s not there yet for a number of tasks but is suitable (again minus certain concerns) for others.
Machines cannot take responsibility for problems, which is why I feel containment barriers cannot be entirely AI. AI reviews are fine (and catch a lot of wild issues humans miss) if a human genuinely reviews it too
I’ve lost count of how many snippets I’ve reviewed that were verbatim pasted from stack overflow pre-AI lol
My view is that humans produce a lot of garbage, and AI tooling currently amplifies your productivity. If you’re careless, don’t take pride and normally commit tech debt then with AI tooling that’s going to be amplified 10-100x. The more careless you are the faster you can commit more garbage - especially if you’re skipping on unit/integration/functional testing
Machines cannot take responsibility for problems, which is why I feel containment barriers cannot be entirely AI.
Where I work AI is being pushed hard, but the company has made it their policy that there must be a human in the loop. Ownership of the code written by AI is down to the person using the AI. “Oops, don’t know why the AI wrote that!” Is not a valid answer to bugs being introduced into production.
I’m seeing senior engineers of 15+ years no longer writing code and churning out a ton more work. They are disappointed they don’t write code anymore but working with the AI is the job they have to do to be able to afford to live. They say the cognitive load has shot up for them, they are constantly spinning plates.
To make the plate spinning job easier they have implemented guard rails to ensure the agents don’t do anything stupid. I’m seeing a number of stories posted to Lemmy where the AI does dumb shit but the stories don’t apply any accountability to the developers using it.
Hahaha either we work at the same place or it’s identical across the industry
especially if you’re skipping on unit/integration/functional testing
That’s a career-limiting move where I work. I draw a hard line on that. You don’t get many chances to blow up prod because you left out mandatory process steps. You might not get sacked the first time (though you should), but it if happens again, you’d better be contemplating your future life as a barista, or pounding farts out of shirt-tails in a steam laundry.
This is also true when people are fully trusting AI to review code as well.
Holy shit.
We use AI for code reviews which I do find useful.
What’s it going to tell you that a static analysis tool wouldn’t? (And we all know what a hell of false positives you get into with those).
I think not understanding what they’re committing is more dangerous than before
This kind of reasoning applies to every new tool. 20 years ago I was saying the same thing about work from co-workers who started programming on Java and didn’t understand what their beloved HashMap actually does under the hood.
Eventually we adapt to either the new tools or to the new dangers, the ones who don’t just become fossils.
Eventually we adapt to either the new tools or to the new dangers
Another option is to stop using new tools and frameworks that don’t benefit us. Adoption should be based on a good cost/benefit ratio, not treated as an inevitability.
It’s also good to re-examine old choices and shitcan them when they’re no longer earning their keep. We were using NiFi for something non-core that we do, and replacing it with a simple hand-coded solution gave us a massive performance bump that’s more maintainable as well. Our use case was well outside NiFi’s sweet spot, so we shouldn’t have used it in the first place. But the person who made that decision is long gone, and it’s always someone else who ends up having to clean up those messes. Here’s hoping that someday I find that guy in a dark alley with no camera coverage.
IDK, cobol programmers still do well these days
That’s one of my major beefs with AI: it worsens the signal/noise ratio throughout the dev process. The two greatest enemies of good software are complexity and its deformed cousin, extraneous crap. AI increases both, making it harder to address the real underlying problems.
Yeah these interaction are becoming quite fraught because there is extreme danger of AI use just shifting the burden from one person to another. That guy wrote the code super fast with AI, but you had to do an additional round trip during code review with him to eliminate that weirdness. He gets a bonus for doing twice the work in half the time, you get nothing.
I know it’s because LLMs are bad at what they do, but I like to imagine that all these weird things getting slipped into code are an attempt to create skynet without us noticing
blame your leadership
he’s not getting paid for good code
There was nothing wrong with the code in terms of structure or performance, but it was doing this really weird operation with an ID after DB insert
So there was plenty wrong with the code.
And it hasn’t been fixed.
“Bro, its totally just you prompted it wrong”
In my experience, AI is an amplifier.
Good engineers will produce more good code, because they ask the right questions, know what good looks like and check the output.
Bad engineers will produce reams more bad code. The mistakes they make will be amplified. They will give wrong and incomplete instructions, won’t see what the problems are with the result and will ship it anyway.
This amplification also means people will spend a larger proportion of time reviewing than coding, which I think is less interesting.
All of this is stuff that can, to some extent, be addressed with policy. You help and instruct juniors, encourage people to better understand and own their code, or at worst reprimand them if they don’t.
You can adjust expectations of product managers and explain to them that more is not better, as it always has been. Faster development can often come with bugs and tech debt and this is more of the same.
All I’ve said above is puts aside the ethical arguments of using or not using AI of course. That’s a separate can of worms entirely.
Good engineers will produce more good code, because they ask the right questions, know what good looks like and check the output.
Best code is the code that is never written in the first place. But that concept is difficult to explain and measure for management purposes. Just because “AI” can automate well-structured, tested boilerplate for “good” developers does not mean all that boilerplate should be there.
Amen. And LLMs have a bias for producing text. And the more questions I ask it, for example to solve more edge cases, it quickly escalates on the existing suggestion rather than find a new approach.
Right. When management counted lines as progress, the software was sluggish because of bloat.
Nah, good engineers are retiring, bad engineers are running rampant. You give yourself away calling us engineers, we were never, except for some yearly title increase instead of money. Just programmers, and that is fine. Engineer is a whole other thing from the steam age, my BSc was in Math, worked fine to get me in.
Any shaved ape can code. One thing that distinguishes worthwhile coding from crap is adherence to engineering principles. Nitpicking about the semantics of the word “engineer” avoids the incontrovertible fact that empirically derived principles and best practices exist and that software engineering is a thing.
Coincidentally, my MSc is in mathematics and statistics, after a dual BSc in math and physics, so we’re from similar starting points. My education as a software engineer and later as a systems architect only came once I began coding. There’s a considerable body of empirical knowledge in the literature (along with too much irreproducible fluffy bullshit), but in my experience, the general awareness of that knowledge is worse among the newer generation of coders than older ones. I suspect that’s because they generally assume that the toolchain and processes do it for them.
The widespread adoption of Scrum has been another source of knowledge loss: it’s used in a number of situations where it does more harm than good, and even where it could succeed, it’s often misapplied (partially because some agile principles are impossible to implement in most real-life organizations, so misapplication is the only posssible kind of application). There are times when architecture and design matter greatly, and some agile practicioners seem to actually believe that they can be done on the fly or major shortcuts can be taken. “We’re not doing waterfall!” You know what? I’ve been in the business since before some of those fools were born, and I’ve never done a waterfall project. It was already an anti-pattern in Fred Brooks’s 1970 magnum opus. Agile vs waterfall was always a false dichotomy. It’s just that some of the OG agile people were too ignorant to know that, or too self-interested to admit it.
empirically derived principles and best practices exist and that software engineering is a thing.
The thing I find most vexing about “software engineering” is that the majority of it comes down to sociology/psychology more than it does science. People make mistakes. They mis-communicate, under-specify, assume, overlook, forget, and screw up.
Programmers practice somewhere between lawyers, authors and graphic artists, and other than the graphic art side of their endeavors, most people never “read” their product. The most valuable principles of software engineering have nothing to do with the complexity of sort algorithms, logic trees or other abstract concepts they were teaching in “computer science” back in the 1980s. The most valuable principles come down to: how do you manage the problems inherent in the situation of human beings writing a bunch of code that almost nobody ever sees which can be fraught with problems that almost nobody will detect until years after the original authors have all but forgotten what they did?
There are different ways to go about “programming” - if you’re “just a programmer” that’s fine, you’re essentially doing window dressing for a department store, the world needs a lot of you. There are engineering aspects to software too, and if you let "just a programmer"s handle all of that, you will find out what they are lacking as soon as the engineering gets tested in use.
AI is an amplifier.
So very much this ^^^.
If you put in the same time and effort creating software using AI that you would have put in coding by hand, in my experience you get better software, much more thorough documentation and automated testing, and fewer “oops” moments down the line. Not perfection, but better.
If you just give a loosely specified prompt and take the first functional looking thing that comes out, you can get code 10x faster than ever before, and it’s going to be a 100x bigger mess to maintain.
A rule of thumb (aka useless constant applied to imaginary metrics) that my colleagues and I have found is: 80%. Work on an assumption that what you get back from each AI pass is about 80% good or right. Work to identify the 20% that needs more refinement, do another pass, now you’re up to 96% good - and honestly probably already better than most first pass ready for a pull request code we used to submit 2 years back. Do a third pass on that and you’ve probably got something that’s not going to give any trouble in all but some really rare cases, and you got it in about half the time you would have spent on lower quality output.
I have been trying, with limited success, to get our junior engineers to use AI to review their own code before submitting pull requests. Some do a single pass and their PRs are pretty good, one says he “doesn’t believe in AI” and his code typically needs 3-4 review passes before it’s even acceptable, even though he’s clearly using AI to write the documentation. AI review is how they’re finding all these zero day exploits in widely used products, it works, it finds maybe 80% of things you’re looking for (if you keep the scope focused inside its context window capacity.) We are having slightly more success with all the junior engineers by having them submit 5-10 small pull requests per 2 week sprint instead of one big one. This not only helps human reviewers understand the bite sized chunks, it also means the AI reviews are more thorough. It also means the architectural definition steps are much more critical because review of tiny chunks misses more of the architectural level picture.
The biggest ethical question I have about using AI centers on management of management expectations. If management really thinks the human contribution value in software creation has disappeared overnight - I’d look for different management, because that ship just steered straight into an iceberg field. Some of them may pull off the Kessel run in less than 12 parsecs, but most won’t.
In my experience the time spent getting AI to do what I want can just be used to write good code in the first place.
I was just planning to do some sort of write up on this topic, although it will be internal only.
Of the three projects I’m currently on
- existing code base where AI sometimes has good ideas but almost never able to implement them successfully. This is legacy code, all human generated, and is probably too tightly coupled. Test framework is tightly coupled to the environment so ai cannot run it
- new tool implementation to give cheaper and faster context across all repos (Spotify Backstage)
- new code base almost entirely ai generated. Much more loosely coupled. There is no test /mock framework available, so it’s all scripts, which the ai is able to run at will to refine its guesses
There’s definitely distinct conditions where ai can be the right tool and can succeed vs when it can’t. In managements blind rush to vibe code everything, they need to better understand where it works and where it doesn’t
In particular, functionality I’m working on this week
- existing code base ”modify function x to cover scenario y” at best gives a useful strategy
- new code base “implement function x similar to existing code base, but that also covers scenario y” seems to work
It can be like that, and other times it can spit out perfectly good work that similar jobs have taken me a week in the past in under an hour. Depends on the task, depends a bit on how you ask, and depends on the model. Claude Sonnet/Opus 4.5 and higher have gotten pretty good about actually saving time and producing useful results.
Except when trying to draw 3D cats in Blender, I can say with authority now: Opus 4.8 on High/Max thinking still can’t pin the tail on a cat correctly without a half dozen very specific annotated views showing it where it goes. It claims it’s having trouble because the cat is lying down… our cat lays down 22 hours a day, suck it up and learn what they look like already.
This is the first comment section i’ve seen on lemmy with a reasonable discussion about AI use that wasnt instantly downvoted into oblivion for being pro-AI
Usually this place is full of the “EVERYTHING IS SLOP” crowd without any nuance as to how it is being actually used to do small tasks well under the supervision of a qualified person.
This comment thread reads 100% like AI astroturfing. AI is not an amplifier, there’s literally no evidence from any study that’s been done that backs that. That’s just AI company marketing.
“AI IS AMAZING AND INEVITABLE!!!” = astroturfing
“AI sucks at X, but sometimes useful at Y… use with caution.” = astroturfing
“AI SUCKS AT LITERALLY EVERY TASK!!! ITS ALL SLOP!!! SLOP SLOP SLOPPITTY SLOP!!!” = only organic discussion and reasonable take…
Look, there are 100s of valid reasons why AI sucks and is unethical… in fact, it’s pretty much 100% built on unethical methods, no doubt…
But “AI sucks at everything and literally has zero good use cases” is not a real argument, but it seems to be the most popular opinion around here.
I disagree with 90% of the pro-AI stuff out there, i’m just pointing out that its rare to hear a reasonable discussin on the topic here that isnt just 100% hate
If AI actually adds value, it should be trivial to demonstrate that value-add in a way that passes scientific rigor.
The underlying problem is that we don’t have a good way to measure code value. Software quality is most closely coporable to a weird combination of scientific paper, mechanical diagnostic, and toy instructuon. And we don’t have good ways to measure those, either.
There was apparently one study from Stanford:
Note that the headline is misleading – stanford apparently trainded an AI model to “rate code” in a way that agreed with some of their staff and then ran that on a bunch of projects. The “good at simple and new, bad at complex and old” matches my intuition, but isn’t really a stronger test than counting minutes spent in a project or dollars spent on programming with or without AI.
And all AI output is slop. It’s just that for some things slop is good enough.
~Which really should be an argument more for discarding those things than boiling oceans to generate more of them, but capitalism loves doing wasteful things~
The AI company marketing (and development) I see still seems to focus mostly on the “we can give a really non-specific prompt and get a functioning app out of thet” - which is missing the point for my uses of it.
My company is very interested in leveraging the new tools where we can, but not laying anybody off (yet) - I think the target is hoping that our exploration time is being roughly balanced with increases in efficiency, which is more or less how we’re managing it for the past few months.
And… there it is.
It can work as you say, but some companies are pushing 10x (or whatever) with fewer people, so quality is guaranteed to go to shit.
Bad & meh engineers get praised because they “waste” less time directing ai and reviewing output - barely working is good enough in the race to market.
I’ve seen things as serious as a privileged user for one customer having admin access to all customers being discovered during the last minute pentest literally days before the planned product launch. That product is supposed(and likely will) to move 250M USD for customers in the second half of this year. Under the current policy at my day job, coming all the way from the top, reviewing ai generated code at all should be an exception reserved for 0.1% most critical code. Yes, in finance.
Finance software is astoundlingly sloppy.
I was working in a university town, happened to get hired in at decent market rates by a biomed startup that didn’t mind paying for me. When they left town, I stayed, and a precious few other companies would pay “my rate” - so I ended up cold calling on quite a few places just to see what they were about. I stumbled into the software development manager’s office of a company that did ATM and POS software - they used the same tech stack I was using for biomed. After a few minutes the manager stopped the conversation and said “sure, fine, I want you, but: can I afford you? What’s your current salary?” I told him, he laughed and said: “Well, I’m the highest paid software guy in the building and I don’t make half that. Mostly we hire kids from the Uni who think they want the experience, they turn over every few months on average. I’ve told management how bad that is for the quality of our software, they don’t care.”
The major difference is that payment processors and money transfer agents are heavily regulated and require a government issued license to operate. At least KYC is not yet handled by ai…
I can guarantee, the code coming out of that shop was slop, 20 years ago.
Insane stuff.
Hopefully, those are the sorts of companies that should fail or get sued, so they learn their lesson. Not holding my breath though.
Companies have been doing insane shit for the sake of saving a buck or getting to market fast for decades, it’s nothing new. AI may or may not just make it worse.
It comes down to risk-reward. If the risk is low enough, they take it - assuming the additional reward outweighs the consequences.
When your decision makers can just declare corporate bankruptcy when the risk finally happens, with no personal exposure other than loss of future income? You can bet they’ll take that risk every time.
The neck of the finance woods my employer is in is highly regulated.
Just failing to notify a regulator on time you blocked a transaction attempt involving a sanctioned individual means hundreds of thousands in fines per transaction (not up to, flat 6-digit fine) + potential prison time (can’t remember if it was up to 15 or 20 years)
Those are the threats, how often does it happen? How often is it blamed on software from a company that has somehow become untouchable? The day before I was talking with the guy that makes the software for gas station interface panels, I had one of those interface panels hit me up for my zipcode as they all did back in the day… I accidentally, but quite certainly, typed it in wrong and hit enter… 3 seconds later I’m approved and pumping gas. Software guy initially said that shouldn’t happen, but when I told him it happened to me at such and such gas station last Thursday he started hand waving about how sometimes the information isn’t actually verified…
Fines are usually severely reduced as a part of a settlement, but they do happen. As for prison… for a white collar crime in US? LOL
I’ve read that because they have less and less experience actually writing code junior developers are having trouble analyzing the code produced.
Good engineers will produce more good code, because they ask the right questions, know what good looks like and check the output.
So what’s the point then ?
There have been coding frameworks like game engines for decades, if system coding is beyond your ability.
If AI can’t write usable code from the start its worthless.
Maybe you’ve misunderstood something.
No matter what framework or language you are using, AI can make the development process faster. It can help you debug a problem, write tests and refactor code. In some situations, it will be faster than writing code yourself, in others not.
Provlem being is that it is not an equal amplifier.
Good engineer spends a morning going back and forth and maybe gets something done that wild have taken them all day.
Bad engineer puts first draft slop in production in a couple of minutes.
Bad engineer gets to put out something every few minutes, good engineer works too make it actually right instead of merely looking specifically right.
That’s true, but spaghetti code was always faster to write than good code before as well. I will agree that the speed gap probably has grown though. That’s why tools like AI need discipline.
If managers and engineers don’t understand that their code will turn into garbage and the business will get reputational harm and lose customers / get sued / have more tech debt to fix and they’ll eventually learn their lesson. In the meantime it’s going to be a painful process where upper management see extra speed, expand their scope or downsize their staff, then learn that they have crumbling foundations and need to adjust. This has publically happened a few times already. Things will stabilize in time.
Complication is, broadly speaking, much of the decision making only thinks to when their current bonus stock vests. So long term thinking is not well rewarded. If you think long term, then your short term thinking competitor screws you up long enough anyway.
I strongly suspect the next step is for a dramatic reduction in the compensation for software development. If it’s not really significantly any more profitable than another trade, then you won’t see as many people who seem to actively hate it trying to do it anyway.
Reminds me of a conversation I overhead, a guy trying to impress a girl with how much money he was going to get back in college. He was going into software development to make big money. Girl asks “but I thought you were majoring in communications, why do that if you want to do software?”. “Oh, well, I tried but I couldn’t understand the course work, so dropped it, figured I’d just get some degree, and then just get some certification and do software development for the money without the dumb coursework”. Basically since the late 90s we’ve had a flood of those types, and this phenomenon just exacerbates the problem.
exactly; well said
No it’s not because it causes brain damage. If you look at slop all day you no longer produces good code even you’re good engineer, you’re producing slop code because your standards keep getting lower and lower until you become bad engineer but you even haven’t figured it out. If good engineers would produce good code with AI we would have working software. Look how quality of software lowered after AI. We used to say that developers from coding bootcamps were bad now we’re lowering standards even more to praise investors.
You only have to snorkel through the mile of shit if you let the shit-pipe in in the first place.
I mean, the pull requests will arrive.
Especially if they are security related, even if only 5% are anything, that’s still quite a few actual bugs. 😞
The Shawshank Software
Yep… I’m leaving the industry after 20+ years because of this industry hellscape
It seems I’m the only software engineer on Lemmy who loves having AI. It’s not perfect, but it’s so much better than doing everything from scratch and it’s far more reliable for solving obscure runtime errors than chasing down all the typically dead-end results on a search engine for the stack trace. Or maybe I’m just the only one willing to endure the down votes. Either way, AI has been an exceptional boon in my daily workload.
I see an LLM as my good-but-not-perfect assistant, there to code up boring bits “loop thru this data and extract…”, “improve this bit of code please”, and to help with errors “why does this code give that error”.
I never let it do big slabs of code, and always run and check its code incrementally.
It is my code and the LLM just makes it easier to do. Thanks LLM.
This is probably a fine and responsible way of using LLM, but sadly the loudest voices are those crowing about coding being a “solved” problem and bragging about being 10x more productive by doing very little and certainly not reviewing refactoring and understanding the generated code.
Only gotcha for this is LLM is being offered well below cost, will you still want yo use it at 5x or 10x the cost?
No. I stopped using Copilot after the price increase. Now I do everything locally using Qwen. There’s a significant decrease in quality, not because Qwen is inherently worse, but because I only have 12GB of VRAM, but at least it’s affordable, and still better than no AI.
deleted by creator
When 60-80% or so of your PR can be refactored away then it’s a crap PR and honestly never should have been one.
So their time savings in getting AI help to write their code means that you spend more of your presumably more expensive time doing reviews and educating them about slop removal instead of some higher-value activity. Sounds like you’re veering into negative ROI for the AI use if that’s true.
Luckily, I don’t review PRs very often, I have people to do that. But the general principle is that the content of a PR is the responsibility of the submitter, regardless of its source. Wrong algorithm? Their fault. No-good UTs? Their fault. Inappropriate or unsafe dependencies? Their fault. Slop? Their fault.
Luckily, with the work we do, there’s often nothing someone could train an LLM on, so we don’t see all that many PRs with AI-generated content, unless we’re using some well-known commodity library or framework in a common way. And that was always the easy stuff anyway.
A slop PR should be the submitter’s responsibility, but if they’re trying to push out unreviewed slop, you know they’re just going to ask an LLM to refactor it instead of looking at it themselves. The best response is just to reject it outright and have someone else work on a new solution.
I have had a fair amount of success getting AI to do those refactorings, reducing 2000 lines of code to 400, and generating 3000 lines of documentation (including flowcharts) explaining how the 400 lines work, adding 1200 lines of automated testing to prevent regressions, etc. etc.
deleted by creator
I started by designing all those files around last September-October timeframe. By November I was realizing: the AI knows better how to make those files than I do, so instead of writing SKILL.md or whatever, I describe to the agent what I want it to configure and explain to me how it’s going to do it. It makes SKILL.md for me, I review it - correct the (usually few and far between) things that are misquoting my intent - and tell it to install it. In areas like softtware development that’s been working pretty well, and getting more and more invisibly automated by the tools since then.
Claude Opus 4.8 dropped a few weeks back “best graphical understanding ever” - well, I’m trying to use it to do some Blender work, it sucks - it’s worse at it than the code writers were in January 2025.
I recently helped evaluate it for company use. My test considered of vibecoding an App that takes a Pipewire screencast and does some basic image processing on each frame. In C#, which doesn’t have great options for talking to Pipewire. I did several runs with various iterations of Claude.
On the upside, it had few problems navigating DBus to negotiate a screencast handle. So that’s one annoying API out of the way.
On the downside, all attempts at taking to libpipewire through P/Invoke failed, usually because Claude hallucinated parts of the API or set constants to incorrect values. I only got a working program when I allowed the use of a prerelease Pipewire NuGet package.
The generated code was of acceptable quality but I wouldn’t allow it into a codebase without a refactor. The code has zero consistency and one time the whole solution didn’t have any namespaces. The fact that the LLM writes and rewrites the code during a single prompt means that you can get mild spaghetti as an initial state.
Honestly, I can see it for something like rapid prototyping or implementing basic scaffolding for an annoying API. But damn is Claude bad at detail work.
There’s a lot of existential dread out there… try talking with an out of work actress about AI and find out how she really feels…
I agree, but that’s a result of fascism, not technology. How it’s being utilized should be the target of ire, not the technology itself. The benefits of AI should be shared by all of society, but instead it’s being used to create even more wealth disparity. That actress should have access to Universal Basic Income and be able to do the work she feels passionate about, no matter what it is. Instead we have oligarchs extracting ever more from a suffering populace.
How it’s being utilized should be the target of ire, not the technology itself.
try talking with an out of work actress about how it’s being utilized, their only answer is to ban it all.
That actress should have access to Universal Basic Income
As should we all have had for the past 25 years… keep wishing.
try talking with an out of work actress about how it’s being utilized, their only answer is to ban it all.
I know, it’s irrational anger and misplaced.
As should we all have had for the past 25 years… keep wishing.
Agreed. And since the alternative is giving up hope,I will indeed keep wishing 🤞
It’s a great tool… and it’s only getting better.
But more importantly, it’s not going away. You can hate it until the sun explodes but this technology exists now and the world isn’t just going to forget about it. Your best bet is to figure out how to use it efficiently so that you don’t end up the guy that pushes shitty AI code and instead the guy who was able to get a lot done by using AI in a meaningful way and produce good work
Amen!
If I got an AI-written codebase hard to navigate, I’d bill the AI usage it took to clean it up and, on top of it, the hours I have to put to actually do the job. We can definitely use AI to write good code, but it takes the kind of professional criteria that vibe coding lacks in order to do that.
We can definitely use AI to write good code
Get a different job. Now!
have you seen some human written code before? Someone who knows what they’re doing with AI can definitely generate better code
- it’s not AI, it’s statistical word prediction with ZERO understanding of context
- yes. statistical word prediction can be better than some idiot programmers. But I don’t compare my kitchen machine skills with those of a toddler either.
well, you’re free to die on that hill I guess
Taking what you give it into context it’s kind of the whole selling point of LLMs. If you get garbage output maybe you’re using it wrong. In the end it’s just a tool, if you can’t use it, that’s on you.
If you want to burn the world to see how hot it gets, you’ll have to compete with AI for that as well. It’s already doing that pretty well.
Meanwhile in infrastructure land, we got fired cuz “AI replaces us”. Have fun with your unpatched servers and firewalls, dickheads
im pretty sure this isn the reason, its the dread of being laid off, and unable to find another job, because these companies think AI replaced them. i had one person i know that was laid off since 2023, and another had been put on hold indefinitely.
There can be different reasons for different people. I personally have zero fear of being laid off (strong worker protection laws in Germany) and finding a new job this year was surprisingly easy (50-ish applications with no cover letters -> 3 interviews -> 3 offers) and I still feel the exact dread that is described in the article. The industry sucks in multiple different ways rn.
Computers are too powerful. Any kind of horrendous slop is now capable of running acceptably.
Until it doesn’t and you don’t understand the code.
No one understands the code. It’s far too complex and abstracted. In any case, just get another computer and/or toss in more code. There’s 4TB of storage and 64GB of RAM, so what? You want a purple circle, that’s going to take at least 55 library calls through dozens of languages.
The ‘existential’ part of this is interesting to unpack — most engineers I’ve talked to aren’t scared of being replaced, they’re scared of becoming prompt janitors. That identity shift (from craftsperson to curator) is genuinely harder to process than any technical upskilling. The engineers who seem to be adapting fastest are the ones treating AI output like junior dev PRs: review ruthlessly, never merge blind. Curious whether @sanitation sees that pattern in the comments here too — and for anyone evaluating tooling around that workflow, https://cxgo.ai/l/mnjNhC6 has some context on where we’re trying to help.
