Hilariously, I discovered this very technique a couple weeks ago when Claude Code presented it out of the blue as an option with an implemented example when I was trying to find some optimizations for something I'm working on. It turned out to be a really smart and performant choice, one I simply wasn't aware of because I hadn't really kept up with new SQLite features the last few years at all.
Lesson learned: even if you know your tools well, periodically go check out updated docs and see what's new, you might be surprised at what you find!
I've been struggling with this throughout the entire LLM-generated-code arc we're currently living -- I agree that it is wack in theory to take existing code and adapt it to your use-case without proper accreditation, but I've also been writing code since Pulp Fiction was in theaters and a lot of it is taking existing code and adapting it to my use-case, sometimes without a fully-documented paper trail.
Not to mention the moral vagaries of "if you use a library, is the complete articulation of your thing actually 100% your code?"
Is there a difference between loading and using a function from ImageMagick, and a standalone copycat function that mimics a function from ImageMagick?
What if you need it transliterated from one language to another?
Is it really that different than those 1200 page books from the 90's that walk you through implementing a 3D engine from scratch (or whatever the topic might be)? If you make a game on top of that book's engine, is your game truly yours?
If you learn an algorithm in some university class and then just write it again later, is that code yours? What if your code is 1-for-1 a copy of the code you were taught?
It gets very murky very quick!
Obviously I would encourage proper citation, but I also recognize the reality of this stuff -- what if you're fully rewriting something you learned decades ago and don't know who to cite? What if you have some code snippet from a website long forgotten that you saved and used? What if you use a library that also uses a library that you're not aware of because you didn't bother to check, and you either cite the wrapper lib or cite nothing at all?
I don't have some grand theory or wise thoughts about this shit, and I enjoy the anthropological studies trying to ascertain provenance / assign moral authority to remarkable edge cases, but end of the day I also find it exhausting to litigate the use of a tool that exploited the fact that your code got hoovered up by a giant robot because it was public, and might get regurgitated elsewhere.
To me, this is the unfortunate and unfair story of Gregory Coleman [0] -- drummer for The Winstons, who recorded "Amen, Brother" in 1969 (which gave us the most-sampled drum break in the world, spawned multiple genres of music, and changed human history) -- the man never made a dime from it, never even knew, and died completely destitute, despite his monumental contribution to culture. It's hard to reconcile the unjustness of it all, yet not that hard to appreciate the countless positive things that came out of it.
I don't know. I guess at the end of the day, does the end justify the means? Feels pretty subjective!
What amazes me is how many programmers have absolutely no concept about copyright at all. This should be taught as a basic component of any programming course.
I love this, it's a very clever and funny way to solve the problem. Makes me think about how there are infinite routes from A to B, some more scenic and whimsical than others.. as well as all the people I've met along the way who would be so pissed and pedantic about how this isn't a "real solution" LOL
The problem is that you have to define the problem enough to avoid the fact that it's trivial to output the string "1,2,Fizz,4,Buzz,......" and fulfill the assignment. You can, in fact, output "$1,$2,Fizz,$4,Buzz,..." where $ is any prefix itself divisible by 15 (there are other templates for the other situations but it clearly does repeat endlessly.)
Weirdly, I think Perplexity is getting a lot of mainstream name recognition because of podcasts. All the big slop pods like Rogan, Theo Von, etc are sponsored by Perplexity and the hosts constantly name check it by asking to “look stuff up on Perplexity”. Honestly pretty smart marketing all things considered.
Other F1 sponsors - Gemini on McLaren along with FxPro and Android, Kick on Sauber, Crypto.com on trackside hoardings, Atlassian on the Williams, 1Password on the RedBull
Does Rogan even know what Perplexity is or is he just reading ad copy? Has it come up in a podcast? I think he only has ever mentioned Grok and ChatGPT. Dont even think Claude has ever come up. He has done that crap before, just reading an ad without any usage of the product. They all do it.
I already wrote something else in here, but one other thought I had afterwards was related to IKEA carts -- they have four 360-degree casters, which makes them extra prone to just flying in literally any direction with a bit of wind if they're not returned to the corrals. Strangely enough, I rarely ever encounter an abandoned cart there, or full corrals; they're almost always empty! Curious if IKEA policy is far more rigorous than a grocery store on cart retrieval and return.
Last time I went to IKEA I couldn’t physically get the cart beyond the loading area. There were barricades setup that seemed sized specifically to stop carts from leaving the area.
As someone who went there alone, this was a real problem. The setup really assumes at least two people are showing up. One to wait with the purchased items, and another to get the car.
I’ve avoided IKEA because of this. I don’t know how to deal with it logistically.
Many people only use the carts to the loading area which has a well-patrolled corral next to it (any employee tasked with helping you load returns to the building with some or all of the carts).
The 360x4 casters are pretty insane the first time you realize it.
Parallel but unrelated, you can play these tones [0] to unlock shopping cart wheels that have locked up on you. The literal only times I ever abandon a cart (not return it to the store or cart corral) is when they lock up and I can't move the god damned things -- and the rare times it has happened have been in the middle of aisles where cars are supposed to drive, FULLY LOADED CART, before I ever get to the car to unload.
I'm a bit late to the conversation but I'm on month 4 (?) of building a (greenfield) desktop app with Claude Code + Codex. I've been coding since Pulp Fiction hit theaters, and I'm confident I could have just written this thing from scratch without LLMs with a lot fewer headaches, but I really wanted to get my hands dirty with new tools and see what they are and aren't capable of.
Some brief takeaways:
1. I'm on probably the 10th complete-restart iteration; I had a strong vision for what it was going to be, with a very weak grasp on how to technically achieve it, as well as a tenuous-at-best grasp on some of what turned out to be the most difficult parts (clever memory management, optimizations for speed, wrangling huge datasets, algorithms, etc) -- I started with a CLI-only prototype thinking I could get it all together reasonably quickly and then move onto a hand-crafted visual UI that I'd go over with a fine-toothed comb.
I'm still working on the fundamentals LOL with a janky UI that I'll get to when the foundation is solid.
2. By iteration 4 or 5, I realized I wanted to implement stuff that was incompatible with the less-complicated foundations already laid; this becomes a big issue when you vibe code and have it write docs, and then change your mind / discover a better way to do it. The amount of sprawl and "overgrowth" in the codebase becomes a second job when you need to pivot -- you become a glorified hedge trimmer trying to excise both code AND documentation that will very confidently poison the agents moving forward if you don't.
3. Speaking of overconfidence, I keep finding myself in situations where the LLMs (due to not being able to contextualize the entire codebase at any single time) offer solutions/approaches/algorithms that work (and work well!) until you push more data at it. For validation purposes, I started with very limited datasets, so I could hand-check results and audit the database. By the time you're at a million rows, spot-checking becomes really hard, shit starts crashing because you didn't foresee architectural problems due to lack of domain experience, etc. You start asking for alternative solutions and approaches, you get them, but the LLM (not incorrectly) also wants to preserve what's already there, so a whole new logic path gets cut, and the codebase grows like a jungle. The docs get stale without getting pruned. There's conflicting context. Switch to a different LLM and sometimes naming conventions mysteriously shift like it's speaking a different dialect. On and on.
Are the tools worth it? Depends. For me, for this one, on the whole, yes; it has taken an extremely long time (in comparison to the promises of 10x productivity) to get to where I've been able to try out a dozen approaches that I was unfamiliar with, see first-hand what works and what doesn't, and get a real working grasp of how off-the-rails agentic coding can take you if you're just exploring.
I am now left with some really good, relevant code to reference, a BUNCH of really misguided code to flush down the shitter, a strong mental map of how to achieve what I'm building + where things are supposed to go, and now I'm starting yet another fresh iteration where I can scaffold and piece together the whole thing with refactored / reformatted / readable code. And then actually implement the UI I've been designing lol.
I get the whole "just bully the LLM until it seems like it works, then ship it" mentality; objectively that's not much different than "just bully the developer until it seems like it works, then ship it" mentality of a product manager. But as amazing as these tools are for conjuring something into existence from thin air, I really think the devil is truly in the details, and if you're making something you hope to ever be able to build upon and expand and maintain, you have to go far beyond "vibes" alone.
I left a comment [0] on the other thread, and this is irrelevant if you aren't using Photoshop, but there's a plugin called DITHERTONE Pro that gives you a lot of control over the dither algorithm used + color grade. For actual design, I tend to use this since I'm already in PS cobbling together an image, and you can tweak the results in realtime to dial it in how you want.
I also have used didder [1] a couple times for dithering via CLI / script. Its results can be pretty good too, just more for repeatable batch operations and you need to make sure your palettes and chosen algorithms will produce what you're actually looking for.
I use a Photoshop plugin for complex dithering (DITHERTONE Pro [0] -- this is NOT AN AD lol, I'm not the creator, just a happy customer and visual nerd)
I'm only dropping it in here because the marketing site for the plugin demonstrates a lot of really interesting, full-color, wide spectrum of use-cases for different types of dithering beyond what we normally assume is dithering.
I was in the same boat on a side project (Electron, Claude Code) -- I considered Playwright but ended up building a simple, focused API instead that allows Claude to connect to the app to inspect logs (main console + browser console), query internal app data + state, and execute arbitrary JS.
It's sped up debugging a lot since I can just give it instructions like "found a bug that does XYZ, I think it's a problem with functionABC(); connect to app, click these four buttons in this order, examine the internal state, then trace through the code to figure out what's going wrong and present a solution"
I was pretty resistant at first of delegating debugging blindly like that, but it's made the workflow pretty smooth to where I can occasionally just open the app, run through it as a human user and take notes on bugs and flow issues that I find, log them with steps to reproduce, then give Claude a list of bugs to noodle on while I'm focusing on stuff LLMs are terrible at (design, UI, frontend work, etc)
Lesson learned: even if you know your tools well, periodically go check out updated docs and see what's new, you might be surprised at what you find!