25+ yr Java/JS dev
Linux novice - running Ubuntu (no windows/mac)

  • 0 Posts
  • 765 Comments
Joined 2 years ago
cake
Cake day: October 14th, 2024

help-circle


  • “Don’t tell me what isn’t so,” has to be something I say on an hourly basis when I use AI. If you ever correct anything, it just writes itself little notes like doing something dumb would be the obvious behavior otherwise.

    “This service does not use JPA, it uses JDBC, so don’t add Hibernate to the dependencies.”

    Motherfucker, what? Four words: “this service uses JDBC.” I swear it’s a gimmick to make AI use more tokens.





  • Do you have any scientific evidence to support this claim?

    Yes, thank you — you provided it. According to the paper cited, people with more familiarity with AI are much better at detecting its output than an average person. But I already knew that empirically.

    What model are you using?

    Mostly a fine tuned GLM 5.2 purpose-built for writing. Not that I haven’t also used frontier models but they suck at uncensored roleplay with violence and conflict and evil bad guys and such. GLM still fails with errors of attribution and state.

    Bold claim from someone who spends hours writing AI stories for themself. Then again, I guess I am assuming you consider yourself a person who enjoys reading.

    shrug It’s pretty bad but it’s better than no roleplaying at all. Plus the interface lets me edit whatever I want so I can fix any outright errors.

    I am completely certain I could get a decent AI model to output a full length book in that genre and she wouldn’t notice.

    That is interesting. The only time I really tried to use AI to write was a noir mystery. Dear god did it suck. It couldn’t follow instructions at all. Show don’t tell is probably more on display in noir than other genres and it couldn’t do it without constant correction. It kept falling back to its standard voice of third person omniscient instead of unreliable narrator.

    There were parts that were written well, but a lot that was just grating and gratuitous. I had to edit like 85% of the output. I had to keep arguing with ChatGPT to write differently. And every once in a while it would swallow its own writing because it tripped its own content warnings. I suppose that’s neither here nor there on the writing quality, but we are far from having an AI write a novel without being full of tells.

    AI isn’t there yet in terms of a quality or undetectability. And it doesn’t look to me like it’s going to get there any time soon.


  • That isn’t really a rebuttal of my statement. It’s not even particularly salient. Sure your average person might like AI writing and not be able to tell it from human works — just like they can’t tell the authenticity of a photograph of Aunt Margaret from a photograph of Trump meeting an alien from Rigel IV. But there are plenty of people who can, and so anyone trying to pass slop off as their original work will be discovered. It’s just a matter of time.

    That being said, I use AI quite a bit in writing stories — though it’s more like solo roleplaying. I don’t think it’s particularly good at all, but it does while away the hours sometimes, as long as your expectations are low. I can’t see anyone who enjoys reading being enamored with AI. My wife reads over 300 books per year, and she spots it pretty easily.




  • This is how RAG pipelines work. You chunk up text and then embed it, which gives you a vector representation of the text. You store that in a database keys in the vector Then when you want to inject relevant information for a prompt, you embed the prompt to get a vector, and then dump the a handful of most similar chunks into context to provide additional information.

    So this semantic similarity question has been in my mind for a while to answer the question of what names would be the most “intuitive” for an LLM.

    Does it work? shrug I guess we’ll find out.


  • Naturally, the LLM can generate interpretations and probabilities which are not correct. Yet, we believe that an LLM is a good-enough measure of semantic ambiguity for our needs.

    You’re asking an LLM to invent a probability distribution over meanings. Embedding models are explicitly trained to represent semantic similarity geometrically. Why not use the right tool for the job over “slop”?

    1. Download you an embedding model — you can run it on garbage, or pay for an API if you want.
    2. Embed the identifier
    3. Embed the symbol’s implementation summary (or docstring)
    4. cosine(name_embedding, description_embedding)
    5. Have LLM suggest alternatives and repeat
    6. Rank names by semantic similarity.

    ETA:

    I present: https://gitlab.com/MagickShel/namer

    It doesn’t generate the list of names to test, though. I leave that to the imagination of the user.

    ETAA:

    There is a class of naming it doesn’t work great on. I probably overstepped and was a bit of an ass. This just gave me the inspiration to do basically the thing you did here, the way I have told myself for months it should be done.

    Also, there is a class of naming - jargon and acronyms - where your approach works better. I still prefer something more deterministic, but credit where credit is due.


  • My server sits in Frankfurt. So everyone overseas waits forever for what is basically a text file. Unacceptable.

    Mate my first internet connection was a 2400 baud modem. Waiting a whole second for a text file is entirely acceptable.

    No, I get it, and good job. It’s about figuring out how to do it, and good job there. I’d have done the same back in the day. I have a raspberry pi with an ssd just begging for something to do. I have more ideas than time, though. Work is consuming all of my IT energy. I’m living vicariously through you.


  • The difference between what you describe and what I describe, is that a 100% match isn’t a hit. Nor is a 90/7/2/1. You need something with meaningful variability. Even within formal papers there are places where word choice is arbitrary as the article explains.

    Of course, you’re lacking the context of the full prompt and just feeding in the raw text. Again it gets way more reliable the more text you have.

    But it’s moot because the more text you have the more tells will sneak in and you probably don’t even need an AI checker. Those phrases that AI loves but humans use comparatively rarely. It’s not a tell — it’s the whole game!


  • I’m not convinced that they even know 100% how Anthropic is doing it. I can think of an easier way that doesn’t corrupt the text: just find a bunch of tokens where there is a good spread of token possibilities, and the more often the most likely one is chosen, the more likely it’s AI.

    That being said, it doesn’t seem much different from what any of us do to identify AI text — it has lots of tells anyway.




  • I agree with your last paragraph. We had about 6 weeks of unlimited AI spend before the costs reached executive leadership, and in that time I saw the least experienced developers spend the most with the least to show for it.

    But I will say that another factor is thinking that if you get 10% gains from a little AI, then a lot of AI will get you 100%.

    But I find the article is right about repo-wide docs. At least on their own. I find having small markdowns (often in the form of skills/commands), focused on specific tasks reduces spend (especially when your execution agent is a low cost model, leaving the reasoning to dedicated agents) and gives better outcomes. Loading massive docs into every task reduces the attention to the task at hand and often confuses AI as the reasoning part of the model becomes overwhelmed and starts inferring wrong things confidently.

    I suppose it heavily depends on the scale of the repo though. A large microservice with multiple upstream services it needs to call spends a lot tokens on API which is unnecessary for most tasks. And then it decides to use the wrong one… I have stories lol.


  • This aligns with my experience, largely. Of course it’s still my job to maximize LLM effectiveness within my organization. Which is a delicate balancing act to protect my teams from overeager executive leadership looking for huge gains.

    My own summary is that AI can be an accelerator, but the harder you lean into it, the worse outcomes will be. No matter how much code is written, you still need actual human minds to understand it and they can only handle so much volume before getting overwhelmed.

    Also, if AI gives you 20% productivity gains, but that 20% goes into playing with AI trying to get more, you haven’t really gained anything. Usage needs to be standardized rather than developers constantly negotiating with AI trying to coax out better outcomes.