Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)V

VoterFrog

@ VoterFrog @lemmy.world

Posts
0
Comments
163
Joined
3 yr. ago

  • I tried AI, was impressed by it, and it's embarrassing; Need advice

    Jump

  • The way you guys are working is not about speed. It's procrastination. The work needs to get done. You can either do it now or you can do it when the bug reports and change requests start coming in. There's no speed to be gained by procrastinating, often it's the opposite.

    If it was me, I'd focus on producing better code despite the pressure. You know you've got coworkers spending time watching YouTube instead of turning their work in or picking up the next ticket. There's your time to ask Claude to refine and refactor the code before you commit it. Just don't be the slow guy and you'll be fine.

    Just refactor as you go. You don't have to over engineer things. KISS and YAGNI are valuable engineering approaches. But don't fool yourself into thinking that turning your work in an hour or two earlier is going to make a big difference in how the higher ups see you.

    Where this really starts to pay off is

    1. Your name comes up less often when assigning bug reports since you don't own the feature that is bugged. People notice this.
    2. Less time spent fixing bugs means more time making new features. Means you own a larger part of the codebase. People also notice this.
    3. When a change request comes in and you go "Oh yeah, that's easy. I already considered that and it's like a 1 line config/code change." You look like a fucking wizard when this happens.

    This has always been my approach. Even in places with little to no quality standards. Hell, I think it works even better in places with no quality standards because it makes you stand out more.

    P.S. While you already have a job is the best time to look for a new one. Because you don't have any real stakes for failure.

  • Can anyone explain the expansion of space to me?

    Jump

  • Think of the universe not as objects flying apart, but as the fabric of space itself stretching. The more distance there is between two objects, the more 'new space' is generated every second, across that entire distance.

    Light travels 9.461 × 1015 meters per year. At a certain distance (the Hubble limit), more than 9.461 × 1015 meters of new space is created in a year. So for stars beyond the Hubble limit, the light sent from those stars actually ends up further from us after a year than when it started. That's what "moving away from us faster than light" means.

  • Newer AI Coding Assistants Are Failing in Insidious Ways

    Jump

  • This isn't even a QA level thing. If you write any tests at all, which is basic software engineering practice, even if you had AI write the tests for you, the error should be very, very obvious. I mean I guess we could go down the road of "well what if the engineer doesn't read the tests?" but at that point the article is less about insidious AI and just about bad engineers. So then just blame bad engineers.

  • Newer AI Coding Assistants Are Failing in Insidious Ways

    Jump

  • It just emphasizes the importance of tests to me. The example should fail very obviously when you give it even the most basic test data.

  • AI’s Memorization Crisis | Large language models don’t “learn”—they copy. And that could change everything for the tech industry.

    Jump

  • AI’s Memorization Crisis | Large language models don’t “learn”—they copy. And that could change everything for the tech industry.

    Jump

  • If you take data, and effectively do extremely lossy compression on it, there is still a way for that data to theoretically be recovered.

    This is extremely wrong and your entire argument rests on this single sentence's accuracy so I'm going to focus on it.

    It's very, very easy to do a lossy compression on some data and wind up with something unrecognizable. Actual lossy compression algorithms are a tight balancing act of trying to get rid of just the right amount of just the right pieces of data so that the result is still satisfactory.

    LLMs are designed with no such restriction. And any single entry in a large data set is both theoretically and mathematically unrecoverable. The only way that these large models reproduce anything is due to heavy replication in the data set such that, essentially, enough of the "compressed" data makes it through. There's a reason why whenever you read about this the examples are very culturally significant.

  • AI’s Memorization Crisis | Large language models don’t “learn”—they copy. And that could change everything for the tech industry.

    Jump

  • Experienced software developers assumed AI would save them a chunk of time. But in one experiment, their tasks took 20% longer

    Jump

  • I find it best to get the agent into a loop where it can self-verify. Give it a clear set of constraints and requirements, give it the context it needs to understand the space, give it a way to verify that it's completed its task successfully, and let it go off. Agents may stumble around a bit but as long as you've made the task manageable it'll self correct and get there.

  • Experienced software developers assumed AI would save them a chunk of time. But in one experiment, their tasks took 20% longer

    Jump

  • Are you trying to make a point that agents can't use MCP based off of a picture of a tweet you saw or something?

  • Removed

    I wrote a 573-page physics book, but I suspect it's actually a Game Engine specification. Here is why.

    Jump

  • Your real problem is that, even with all rights reserved (full copy protection), the law won't disallow someone from running a statistical analysis on your work.

  • Experienced software developers assumed AI would save them a chunk of time. But in one experiment, their tasks took 20% longer

    Jump

  • Again, read and understand the limitations of the study. Just the portion I quoted you alone is enough to show you that you're leaning way too heavily on conclusions that they don't even claim to provide evidence for.

  • Experienced software developers assumed AI would save them a chunk of time. But in one experiment, their tasks took 20% longer

    Jump

  • Do you think that like nobody has access to AI or something? These guys are the ultimate authorities on AI usage? I won't claim to be but I am a 15 YOE dev working with AI right now and I've found the quality is a lot better with better rules and context.

    And, ultimately, I don't really care if you believe me or not. I'm not here to sell you anything. Don't use it the tools, doesn't matter to me. Anybody else who does use them, give my advice a try an see if it helps you.

  • Experienced software developers assumed AI would save them a chunk of time. But in one experiment, their tasks took 20% longer

    Jump

  • More to the point, that is exactly what the people in this study were doing.

    They don't really do into a lot of detail about what they were doing. But they have a table on limitations of the study that would indicate it is not.

    We do not provide evidence that: There are not ways of using existing AI systems more effectively to achieve positive speedup in our exact setting. Cursor does not sample many tokens from LLMs, it may not use optimal prompting/scaffolding, and domain/repository-specific training/finetuning/few-shot learning could yield positive speedup.

    Back to this:

    even if it did it’s not any easier or cheaper than teaching humans to do it.

    In my experience, the kinds of information that an AI needs to do its job effectively has a significant overlap with the info humans need when just starting on a project. The biggest problem for onboarding is typically poor or outdated internal documentation. Fix that for your humans and you have it for your LLMs at no extra cost. Use an LLM to convert your docs into rules files and to keep them up to date.

  • Experienced software developers assumed AI would save them a chunk of time. But in one experiment, their tasks took 20% longer

    Jump

  • This lines up with my experience as well and what you've described is very close to how I work with LLM agents. The people bragging about 10x are either blowing smoke or producing garbage. I mean, I guess in some limited contexts I might get 10x out of taking a few seconds to write a prompt vs a couple of minutes of manual hunting and typing. But on the whole, software engineering is about so much more than just coding and those things have become no less important these days.

    But the people acting like the tech is a useless glorified Markov generator are also out of their mind. There are some real gains to be had by properly using the tech. Especially once you've laid the groundwork by properly documenting things like your architecture and dependencies for LLM consumption. I'm not saying this to try to sell anybody on it but I really, truly, can't imagine that we're ever going back to the before times. Maybe there's a bubble burst like the dotcom bubble but, like the internet, agentic coding is here to stay.

  • Experienced software developers assumed AI would save them a chunk of time. But in one experiment, their tasks took 20% longer

    Jump

  • This is not really true.

    The way you teach an LLM, outside of training your own, is with rules files and MCP tools. Record your architectural constraints, favored dependencies, and style guide information in your rule files and the output you get is going to be vastly improved. Give the agent access to more information with MCP tools and it will make more informed decisions. Update them whenever you run into issues and the vast majority of your repeated problems will be resolved.

  • Developers remain willing but reluctant to use AI: The 2025 Developer Survey results are here

    Jump

  • It's worth noting that good IDE integrated agents also have access to these deterministic tools. In my experience, they use them quite often. Even for minor parts of their tasks that I would typically just type out.

  • LLMS Are Not Fun

    Jump

  • The generalized learning is usually just the first step. Coding LLMs typically go through more rounds of specialized learning afterwards in order to tune and focus it towards solving those types of problems. Then there's RAG, MCP, and simulated reasoning which are technically not training methods but do further improve the relevance of the outputs. There's a lot of ongoing work in this space still. We haven't seen the standard even settle yet.

  • La_Brea_V2.0.exe

    Jump

  • An AI crawler is both. It extracts useful information from websites using LLMs in order to create higher quality data for training data. They're also used for RAG.

  • La_Brea_V2.0.exe

    Jump

  • Doesn't work either

    The text you provided translates to:"But what about typing like this?". This style of writing involves replacing standard Latin letters with similar-looking characters from other alphabets or adding diacritical marks (accents, tildes, umlauts) available in the Unicode standard.

  • La_Brea_V2.0.exe

    Jump

  • Yeah, much like the thorn, LLMs are more than capable of recognizing when they're being fed Markov gibberish. Try it yourself. I asked one to summarize a bunch of keyboard auto complete junk.

    The provided text appears to be incoherent, resembling a string of predictive text auto-complete suggestions or a corrupted speech-to-text transcription. Because it lacks a logical grammatical structure or a clear narrative, it cannot be summarized in the traditional sense.

    I've tried the same with posts with the thorn in it and it'll explain that the person writing the post is being cheeky - and still successfully summarizes the information. These aren't real techniques for LLM poisoning.