> With AI, everyone’s output looks like a Ferrari, so it is hard to know what the internals are like.
Based on my experience, this is a significant issue with AI generated code. You wouldn't expect a real Ferrari supercar to have random internal mechanical components that are, for no reason, completely inappropriate for a high-speed car design. With AI generated code, such inappropriate components can appear randomly at any point in the implementation stack. And very often, they are deeply buried under non-trivial algorithms and are thus not easy to spot.
Fighting with a robot requires also a different kind of attention. When you're reviewing the human code, you can quite easily guess an overall seniority and competency level of the author and then you can adjust your level of attention to every detail. E.g. if the solution requires an understanding of some core idea, ones the human understands this core idea, you can be quite sure that it is consistently implemented everywhere. With AI, 90% of the PR could be expertly implemented but then, for no obvious reason, 10% could be low-quality surprise. I've never seen such unbalanced output from human programmers.
Yes, but those 10% of a problematic code is not easy to find without a very detailed study of the whole PR. And since most of the code looks (and usually is) very well-written, the human brain somehow doesn't expect to find those low-quality or sub-optimal parts in such code. That's why I wrote that reviewing the AI code requires different kind of attention.
Definitely not "most people". I've checked the sources of this project and it is quite clear that author is now quite knowledgeable in a theory of computer programming languages. He definitely knows a lot about lexing/parsing, AST generation, type checking, bytecode etc. Most people have no idea and interest in such topics.
Not claiming the author doesn't. My claim is that this can be done by most people, and they can do it WITHOUT understanding any of the topics you mentioned.
We likes this "same, complex set of mannerism" when using LLM for programming. If you ask LLM to write a certain function for you, it gives you statistically obvious implementation. But maybe for writing an original book, this feature is not so desirable
It does not. Sometimes it will spawn a mess of ad hoc python, sometimes it will do curl and sed, and very very occasionally it will use the correct tool for the job if it remembers to use the skill you developed in the previous session.
Yes, sometimes it does something unexpected when used as a tool for programming. And in that context, it is seen as an unwanted feature. In fact, that was my point. However, I disagree that it does a good job only "very very occasionally". That is not my experience at all.
This is really impressive work. Both RapidCam and the Cabinet Design Studio seem fairly polished already. I'd love to learn more about the process behind these creations.
Amazing job! The live editor capabilities are really well-thought.
I've inspected the code briefly [1] and it seems that there is a fairly sophisticated domain specific parser which handles live updates, history tracking and WebAssembly hot reaload. It also uses AssemblyScript [2] as an intermmediate language.
I wonder whether all if this was implemented manually or with the help of LLMs. In either case, author has my respect.
Tysm! Technically, about the audio engine, the language is fully Turing complete, compiling bytecode which then gets swapped out in realtime and executed by a VM running in WebAssembly/AssemblyScript. All the gens/effects/filters are implemented in a custom DSL that gencodes AssemblyScript classes with all the permutations of parameters whether they're scalar or audio inputs in order to achieve the maximum performance possible. I had a lot of help from the LLMs but all of the components had been previously implemented by hand as well multiple times in previous versions, so I had a clear direction. If you have any questions feel free to ask, we also have a Discord you can find it in the homepage at the footer.
The sad part of these cassette player remakes is that they don't have a Dolby NR (Noise Reducton) [1] system. I remember that without at least Dolby C-type NR, the sound from tape was really noisy. I wonder if the applicable patents have already expired.
I think this is a lost cause. Even if the mainstream services are blocked or forced to comply, there will always be hundreds of lesser-known tools and services offering the same features. At this point, nobody has the power to close this can of worms.
Besides, who is going to decide when people's images are sexualized enough? Are images of Elon Musk in bikini alright because he's not a woman or a child?
Based on my experience, this is a significant issue with AI generated code. You wouldn't expect a real Ferrari supercar to have random internal mechanical components that are, for no reason, completely inappropriate for a high-speed car design. With AI generated code, such inappropriate components can appear randomly at any point in the implementation stack. And very often, they are deeply buried under non-trivial algorithms and are thus not easy to spot.
reply