• 0 posts
  • 5 comments
Joined 3 years ago
Cake day: June 20th, 2023
  • Interestingly what I’ve said here ☝️ ️comes with an interesting implication. There used to be a type of software “engineer” that couldn’t actually think through a problem and implement a good software solution. They were valuable because they could refactor, write code, but not think through a problem. These are the people who have the most to lose at the moment, and also the ones that find the least value on AI, because AI only does really well the single thing they could do.

  • I appreciate the intent behind that sentence, and the problem is that is written (or said) by people who don’t understand coding.

    Syntax was never the hard part. Code syntax is a set of rules that you can teach a machine and it’s “easy” enough for an LLM to grasp it. The problem here is that this phrase does a “code = syntax” but ignoring all the difficult things that actually are in the code. Architecture, design, tradeoffs, translation of vague requirements into concrete software components…

    All of those things are terribly hard, and the reason why many LLM-first coding projects get abandoned at 70% and then companies need to hire a Software Development consultancy to mop up their mess.

  • Unfortunately AI doesn’t work like that. Any way to explain it would be an oversimplification but I can try.

    The training data (songs) are used to create the weights. This is a bunch of numbers that are on their own meaningless - they don’t map to specific songs, but to attributes such as “tone” “rhythm”… And like that but many (millions of) abstract attributes that don’t make sense as people, but make sense to computers.

    So if the thing makes a song that is very “rhythmic” but also “tonal”, there’s no specific training song that contributed to that - all did, and it’s a mess to decypher how much each contributed to each attribute. Except the resulting song doesn’t use two parameters, uses many millions, so it’s essentially impossible to know.