[–] 8 points 2 weeks ago (1 child)

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.

  • source
  • parent
  • context
  • [–] 2 points 2 weeks ago* (last edited 2 weeks ago) (4 children)

    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.

  • source
  • parent
  • context
  • [–] 2 points 2 weeks ago* (last edited 2 weeks ago)

    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.

  • source
  • parent
  • context
  • [+] -9 points 2 weeks ago (5 children)

    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.

  • source
  • [–] [S] 3 points 2 weeks ago* (last edited 2 weeks ago)

    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.

  • source
  • parent
  • context
  • [–] 1 point 2 weeks ago

    the only way humanity will be able to code/write/design/whatever is through LLM products, because everyone forgot and stopped learning

    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.

  • source
  • parent
  • context
  • [–] 4 points 2 weeks ago

    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.

  • source
  • parent
  • context
  • [–] 8 points 2 weeks ago (1 child)

    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.

  • source
  • parent
  • context
  • [–] 8 points 2 weeks ago (4 children)

    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.

  • source
  • parent
  • context
  • [–] 3 points 2 weeks ago

    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.

  • source
  • parent
  • context
  • [–] 5 points 2 weeks ago (3 children)

    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.

  • source
  • parent
  • context
  • [–] 5 points 2 weeks ago (1 child)

    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.

  • source
  • parent
  • context
  • [–] 2 points 2 weeks ago* (last edited 2 weeks ago)

    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.

  • source
  • parent
  • context
  • [–] -1 points 2 weeks ago* (last edited 2 weeks ago) (3 children)

    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.

  • source
  • parent
  • context
  • view more: ‹ prev next ›