Works going full AI crazy. 10x the amount of projects, only half work
So im having a "issue" that might not be an issue? Ill explain.
Most of work is going full AI. We have around 20 developers. Its about 3/4 that are using AI to do ALL the work with Claude. Earlier in the year, everyone got a ton of AI credits and the amount of "Finished" products have popped out in mass. The amount of projects we have had is skyrocketing.
Now for the problem. Half the projects have terrible bugs. Pages that go no where, bugs that are VERY hard to find in the code (because its filled with code smells). And sometimes the site/program/etc... will just stop working for no reason because they decided to use some old version of react instead of anything modern. Because AI.
Even the ones that work will often be very difficult to debug if its just something the AI did or something the user did.
So a LOT of AI projects are getting abandoned...for more AI remake projects. I cant even call it iterations because no one learned anything making the last project.
Now once in a while I do use AI. It was part of my research back almost 20 years ago. But its mostly for one offs like creating a command line argument in python or give the the reference page for xyz feature. But I dont have it write the entire codebase for me. Seems like a recipe for disaster. And ive seen it bork a couple of peoples machines before.
I dunno am I the old man yells at clouds now?
46 replies
Well, lets see!
...and those are all of the reasons i care to come up with. It definitely makes you feel more productive, while not actually being productive. Sure, you prompted the cuckbot and it farted out an answer in 3 minutes, but now youre spending 2 hours fixing it when it could have taken you 1 hour to just write the damn thing correctly the first time. Or you can roll the dice, push to prod, clock out early, and hope no one traces that issue back to you while you collect a check and drink margaritas with mamacitas in style (as our world and your company burn down together)
Just wait until they make your PMs "engineers" because "Claude can do the work" so they literally just prompt Claude all day and raise the shittiest PRs without know how to even use Git or Virgin, Claude does it all for them.
MFW when management discovers the rapid prototyping technique, but forgets that they’re only prototypes.
You got the right point.
The problem is quite clearly not AI - it is totally possible to use the latest models to make very high quality software. Your colleagues are either a) not using the latest models, or b) not testing enough, maybe not even getting the AI to do testing. Pages that go nowhere are trivial for AI to test and fix.
Your team should focus on the outcome - it sounds like you're getting low quality results. They need to improve their workflow so they get high quality results instead.
However it sounds like you aren't in a position of power so I'd say either deal with it, quit, or probably the best option would be to learn how to use AI well yourself (it's not hard) and then help/educate your coworkers.
It’s not about model quality, but how you use them.
Even the most maxed-out Claude agent is fine at automating small modules, but ultimately things will go off the rails without humans to watch them, steer them, and architect the larger program. That’s just a fundamental limitation of these autoregressive models, and that is not changing in the near future, no matter how much we scaffold them to plan and test.
What’s happening to OP’s workplace is “Claude going off the rails.” It’s people letting it rip without any oversight or understanding of the code it’s producing, which is what makes those projects ultimately unmaintainable.
I do think there’s a lot of promise in architecting LLMs to produce mathematically verifiable code, like Mistral and some others have researched. But again, that’s more at the low level, and it’s not going to fix high level hallucinations or gaps.
So would it be fair to say LLMs are fine for small chunks of code as long as you know exactly what that code does? That's the only use I've gotten, but I'm anything but a real dev.
And medium chunks. Medium chunks require a good agentic framework, but they can handle sizable chunks of code.
It can also help you brainstorm/debug, as long as you recognize the sycophantic tendency.
And yes. If you can’t understand what it’s written (or mathematically prove the module functions correctly), that’s a problem.
I guess I’m saying LLMs are bad at “architecting” big projects. They aren’t intelligent, they are ephemeral constructs akin to weather prediction models that don’t have a mind, nor any memory, nor any adaptiveness. They simply do not understand things like a person does, and they cannot grasp some things, so it’s up to the person to provide the framework and point them at monotonous tasks to automate.
Ah! No, I never suspected LLMs would work for architecture.
This thread got me to sign up for the free version of Claude, which promptly hosed a very simple Powershell script I had on hand. BUT, it did give me ideas on speeding it up, things I hadn't thought of. I'll take another pass without so many beers in my blood.
TBH I would recommend some of the competing APIs over free Claude.
Xiaomi’s token plan, in particular. It’s dirt cheap (a couple of bucks for a whole year), Mimo 2.6 is great, but they’re a “dark horse” in the LLM race now. They aren’t widely known like Deepseek/GLM, and their models are under-hyped, hence they aren’t popular and are pricing things accordingly.
Why I haven't even started using AI ☝️
Its a strange feeling. I kinda get it, its easy to turn off your brain. But thats KINDA why I get paid. To think right? To solve the issue whatever it is.
These coding LLMs are essentially like a vacuum that sucks your brain dry. Anything you do with it is used to train: those comments you leave in a PR, the instructions you give within the chat thread, the manual fixes you make to the broken output, etc. So you lose ability, while the models gain ability.
The logical extreme here is that, in the future, the only way humanity will be able to code/write/design/whatever is through LLM products, because everyone forgot and stopped learning.
Whether or not you think that's progress, I think everyone can agree that what is definitely bad is that those models are centralized and controlled by a small group people (who also happen to be the worst people). It is the ultimate tech bro monopoly strategy, to win complete control over 100% of the high skill sectors of our economy. Any child not born to a billionaire family circle will only be able to make a living from physical labor.
Not very extreme from what I see.
It regularly happens for a lot of things to smaller extents (who can make a computer to run their code? I'll hypothetically give you RISC V source and lots of money for materials and see if you can manage without giving said money to the company that creates fabrication machines) and AI just reduced the bar for the user, in a way that enough people might just want to give up trying to understand how stuff works.
Yeah. It's not why I became a programmer, to tell something else to program for me. Might as well find another job in that case.
Our job is to think of logic patterns that solve problems, not necessarily to manually type them out ourselves.
Its valid that the typing part means something to you, im just saying it is possible to integrate it without turning your own brain off.
i disagree with this take, when i type code out i start to see flaws in my own logic and am able to adapt it because i can start to see the bigger picture as it comes together. also when i start to see code smells i can decide to change my approach and refactor it to fit the problem better.
AI just gives you what you ask sometimes. sure it does it quickly but it doesn't care about those logic bugs while introducing more through misunderstanding of intent. good luck finding it in review, especially when you have 10 PRs of 5-10k lines to review in a day because your manager has lost their mind and other developers appear to forget libraries exist. oh and you had feedback on one of those PRs? well lets just regenerate a complete new codebase and start from scratch.
i forget who said it but they mentioned it's a DDOS on human intelligence and energy and i really have to agree.
The reason why I like the typing part is because it forces me to really think about my code. Often enough I realise that the model I had in mind for my code is not perfect and that it makes sense to change it now, so that future development gets easier. If I would have outsourced the typing to the AI, its possible, that I would have not realised that. This is especially important, when thinking about how I want to integrate a subsystem into the rest of my codebase, because that is nothing I would outsource to AI.
I enjoy the typing part as well, yes.
Use it to skip the part where you type it all out yourself, and go straight to the part where you review the draft code.
Its not a 'do my job for me' imo its predictive text on roids.
The part where I type it out is the part where I come up with better ways to do it, though.
Also the part where I store a mental map of it so I know where to look when something breaks.
You are most emphatically not.
AI is as good as the human in the loop. Two rules would help in the long run: accountability (AI proposes, dev accepts, therefore dev gets the 2AM call when it hits the fan) and understanding (thou shalt not commit code thou cannot explain). If you have the power to push these, you have a fighting chance. Otherwise ask Claude to polish your CV.
It's a really mixed bag. I was a bit of an AI laggard for work stuff, while most of my org went all-in. Some stuff worked, most stuff didn't. Things that didn't work:
But some stuff did work, and most of it was our more senior and technical staff's usage of claude. I'll admit that after I saw my peers hop on board and truly accomplish impressive (functional) things, I dabbled more and I think I have a rule of thumb that helps me. If I'm already a SME, claude may turn me into a super dev. I can smell bad smells, stop it early, and generally know what decisions I need to make up front. If I don't already know what I want, I NEVER let claude drive. Letting claude make decisions is a BAD IDEA.
So honestly I think it depends on who's using it and how.
My problem is that it's killing the next generation. When used properly, AI is replacing junior work. In a decade, all the current seniors will be a decade older and burning out and there won't be any new ones to take their places.
This was an issue before LLMs, Senior developers just doing all the work because it was easier and they were under pressure of a deadline. Maybe if a Senior over committed and they had to YOLO with a junior to do a small part to have any chance of meeting expectations, that would be easier to replace with a LLM. But in that case, is a junior really learning anything that they couldn't by self learning anyway?
If you really think the answer is still yes. There is usually, always something to throw someone at and seeing what sticks, It will just fall in the maintenance realm and not on some critical path. That's how I was "trained", got almost no feedback because it wasn't important, and ultimately failed because I was mislead and had to do it twice.
Training someone up has always been intentional IMO, LLMs just makes "necessary" accidental "training" easier to avoid.
Worse case if a junior is hired, there is work to find for them, and throw them at.
Oh I agree with that as well. I have no idea how I would be a junior on this industry now, nor do I even know how to manage juniors anymore given management's expectations. We're gonna have a real dearth in some years and I don't know what's gonna happen.
That's by design. Nvidia, OpenAI, Anthropic, etc will fill that void.
Or it will go like Bitcoin where specialty made chips will take over instead of GPUs yet again. And then the big players will go kaput or have to shift as quickly as possible. I think those above are looking for bag holders myself, but I may be too close to the product persay.
It feels SOO much like bitcoin did when it came out. I think the only reason we dont see it happening as much is the algorithms themselves are still in a state of flux. Once we have that done pat, specialty chips can do what software/gpu is doing in parallel at a MUCH faster rate. Also reduces bill of materials. Most of the really interesting models are made by the community and well...china/companies.
Almost as if the senior staff sees it as a tool in a toolbox instead of a subcontractor.
It comes down to knowing what a UX is, and how everything underneath works together. This is "computers" all over again. Growing up alongside the evolution of the stack gives you a special background in what goes wrong, why it goes wrong, and how to fix it. Jumping into it when it's gotten so abstracted it's not possible to understand the stack from the ground up is where this sort of slop comes from.
Its pretty good at SQL that already exists! And it of course heavily depends on the model. And theres the rub. I think we spend 1.5x for devs now cause of the tokens haha.
Claude can do some crazy stuff thats for sure. But I recall there was code generators that did entire apps before the AI boom. And they were more reliable but more static. And it keeps making like .75 of what you ask, then you have to spend twice as long to debug. At least in my opinion. And worse is that no one can read the code so they dont know what it does. The devs just go, well ill ask cluade to do it instead of taking responsibility. (old man noises)
Eh 🤷♂️. Call it anecdotal if you want, but this is my experience:
The imbeciles who manage our ERP silently pushed some update that must have removed some indexes because suddenly several complex queries were one or two orders of magnitude slower.
While I got to work on optimizing them, a colleague who's outsourced most of his thinking to LLMs got what according to him was “the most powerful model” (some flavour of claude, I assume) to take a look at one particular affected query relevant to the project he was working on.
To be fair it went for more or less the same approach I was taking (storing intermediate results in table variables, spending memory to save speed, though it used temporary tables instead for some reason), but in a significantly more inelegant and inefficient way than I would have (for instance, it put SELECT *s — from tables with hundreds of columns! — into the temporary tables, when we only needed a few columns; an absurd waste of memory; it also missed several other optimizations, being apparently happy with “good enough” instead of trying to be thorough).
Happy with the result he pushed it into production, while I kept working on the rest of the queries, managing to also bring them back to reasonable times.
Couple days later, ticket comes in about that specific query being slow again, for particular parameters. I'm not sure what was wrong (the design of the database is absolute unadulterated shit, but it belongs to the ERP anthropoids and we can look but not touch, and have to work around it), but in some specific cases some joins produced many duplicate results, leading to massive slowdowns. While diagnosing that I also noticed that some of the values it produced weren't correct.
So I rewrote the whole thing based on the work I'd done with the other queries, and now it works properly and efficiently, and significantly faster (at least until the ERP assholes break something again).
TL;DR, sure, the machine quickly produced an apparently working solution (I don't know what the cost of the tokens was, though), in much less time than I could, but the result was ugly, poorly thought out (which, I mean, since it was made by something that can't think and just statistically processes language, I'm not sure to which extent can be a criticism of the technology, but is a criticism of those using it), less efficient than mine (and I wouldn't call myself any kind of SQL master or guru, I just meddle), and failed in some particular cases. I was not impressed.
I also think org rot is real and is a different problem. Or at least... related but distinct.
Corpo leadership is completely brainrotted by promises of LLM sentience and firing half the company and I have no idea how to manage upwards on that front.
I think the sloperators I see at my company are people who weren't fantastic in the first place. If you were already a "rockstar" or a "10x" dev, claude probably makes you a 12-15x dev. But if you're just a person who works hard, and you aren't at a point where you understand when and why it's OK to break rules, I think your output is gonna suffer and make your team suffer as a result.
I have no idea how i would be a junior in this environment but I know as a senior/staff, claude has let me do more than I could before, and my defect rate is not higher than pre-LLM. Mostly because I'm a SME and I bring my judgement and humanity to the design, and claude is just there to generate diffs for me to read and nudge.
Sorry for the barrage of comments, I've just been thinking and talking about this a lot recently and I tend to think out loud.
So, here's where I think I'm gonna lose you. These days I read diffs but I so rarely read entire files. I generally know how pieces of things fit together, and I generally know how the systems are architected, the tech stacks, and I can still read functions and syntax... but I wouldn't say I "know how it works" at a code level at this point. Once I accepted that it's OK to know the high level, and verify the diff/PR level, it's OK to not have 100% awareness on implementation, using claude became a lot less... smelly to me.
It's not an easy thing to let go of, but the reality that I've experienced is that generally, claude can write good, secure functions. From a purely mechanical perspective, it'll probably do a better job than I would on syntax, knowing the nooks and crannies of libraries, etc. But I review the diffs to be sure. However, I, the human, know what I want and generally how it should be done.
I'd say that learning where to not bother with claude and where it works well was a bit of a thing to figure out, but I really don't spend hours debugging claude slop. Cause honestly in qualified hands, it doesn't really write slop. It does write slop if you let it, or ask it to take on too much scope, but... "work this ticket for me, pay attention to x y z and don’t change a b or c" is well within a reasonable model's capabilities.
I'd never pressure anyone into using LLMs and I have large ethical issues with the industry, but the idea that claude only slops doesn't match with my lived experience in the past 6 months. I suspect when the finances of this whole thing go boom, KIMI and other open source models are gonna be able to run on rented GPUs for relatively cheap. Deepseek's (reported) profit margins on inference seem to pay for the hardware (inc. GPU) in months... $1.6M per card in 5 years for revenue (not profit).
Obviously these models are not intelligent and cannot be, but they can be very powerful code generators.
If my processes fuck up i think its something like 2 mill in transactions that fuck up. Haha. So yeah...
I mean I've never had data loss, pre or post LLM land so... but yes, risk tolerance is your own.
Honest question, in your opinion, how experienced was the development team prior to AI being introduced? What level of code quality could be expected? And what was the average velocity for development projects?
I have substantial development experience prior to AI and after. I also have spent the last eight years at of the the lagest technology companies advising a wide variety of our customers on implementation.
I can tell you that both my own experience and what I see at customers is that if you already produce low-quantity code and/or are not truly development minded, then the AI tools will largely reflect that. They are tools and require proper direction just like a human. If I give it a three paragraph prompt to create some app it will probably do it and it might even work, but it likely won't be reliable as you have experienced. However, if I put on my software architect hat and give it a detailed instruction file which coding standards, architectural patterns, frameworks, etc. It will usually produce a pretty good product.
As the age old computer adage goes: Garbage in, garbage out.
At work you have to have a college degree and at least 5 years of experience. Generally thats the case. I think at most we have one person 20ish years of experience. all the way to two years straight out of college.
Well we had CI/CD, testing,etc... in prior projects. Now its just a toss up what does what. Its better now actually haha. Because docker and other containerization tools mostly rather than AI.
I get that giving it a VERY specific detailed prompt can get better responses...but at that point, I can just prompt myself and call it good. I am the AI/worker at that point.
What is your question exactly? Do you guys test and review the code? It sounds like you don't.
We do PRs.
This might help, but tell Claude to do Test Driven Development [TDD] which will require each feature/function/etc.to have a test case and a pass before it can exit the worktree before a PR.
Also look into graphify which does a bit of "explain what this does" and makes things very easy to describe the code in a systematic way. AST is here again.
I'm having success with an agentic orchestration model that doesn't move on unless they pass the tests. And if they fail they hand off to a smarter model. I have to guide it and sometimes ask basic questions about why we're trying to load docker locally when I have guthub actions to do it, but if you know that much you can just poke it with a stick occasionally. The graph is updated and I have records for design decisions and reports on failure as well as tests to pass.
This is definitely a different approach and I can easily see how some people don't get it; and it's probably tied to doing things the hard earned way. Less developer and more TPM in terms of mindset.
I think throughput [lines of code, commits, PRs, beans, etc] is a worthless metric, velocity means speed + direction. A poorly guided version is just scattered all over, make it work and that's it, until the next round of changes.
But it's definitely a different game now.
Define what you want, have the tests written, lock the tests and then have the code written.
Ok and what kinds of review comments do people leave? How often are PRs rejected? Do you have CI running your test suite? Why do you think so many bugs are getting through? Usually you need a strong culture of people demanding rigorous testing methodology in order for bugs to get caught early in the dev lifecycle.
You’re not yelling at clouds. But AI isn’t going anywhere, least of all in software dev. If anything I’d suggest learning and exploring patterns like spec-driven dev and how best to build skills and agents.
I lead engineering for my company and it’s taken a tremendous amount of work to scaffold for quality. Everyone runs loops and ships much more quickly. But, like I said, that takes a lot of work and isn’t easy to capture in a one-off comment.
Lots of cool shit to learn, see, and do though!
Well given that my research was literally AI...Its a prediction engine in most cases. Hell I give feedback on hugging face regularly. I used to use hugging face to create specific models like the command line one a bit ago. Specific models for one specific thing. It was fun for a while, but then I got burnt out because everyone just distills without understanding what they are distilling.
I had a fantastic time making a bullshit simulator using startreck jargon. that was fun.