A surprisingly robust approach to human verification would be to abandon visual classification entirely and instead exploit culturally embedded call-and-response patterns. There are obvious concerns regarding age and demographic bias, but these could potentially be addressed through a rotating corpus of challenges. More interesting is the adversarial question: while an LLM can trivially retrieve the expected response, can it distinguish between merely knowing the response and knowing when to come in?
When I say uh you say 'ah' Uh ah Uh Ah
Now when i say freeze y'all stop on a tidime
when I say freeze you just freeze one time
when i say freeze y'all stop on a dime
FREEZE
Now - all the ladies in the place, if you got real hair, real fingernails, if you got a job, you going to school and yall need nobody to help you handle yo business make some noise
NOOIISE
So - Dr. D. J. Kool has clearly been working on this thesis for some time
I found that rather entertaining, thank you. It reminds me of Rick n Morty, S01 E04, when they start rapping on stage and making more and more specific requests to get the matrix they're stuck in to glitch out.
Congrats and welcome to the wonderful world of ports.
I would say yes, verifying that the code not only does what you expect but also doesn't do anything of the things you do not expect, is the main bottleneck.
That is: do-all-the-things, please, and don't-do-all-the-non-things, as well.
Ideally, one can reason through their application at a high-level and have a "spec" or specification that the LLM can build from and check against.
You can also have the LLM go back through and tell you about any vulnerabilities you need to address before shipping.
I don't know exactly what you are shipping, but in general: never give the LLM root access or command-line access in a deployed app. Give it the minimal permissions necessary to accomplish its work/role. Pin versions [if you're working with version 5, explicitly say that, rather than just using the "latest" one since that's a moving target].
Some things are not obvious until deployed to a live environment, so do thorough testing. You can have an LLM generate test cases and run a "test suite" to check your code does all-the-things and none-of-the-non-things [undesirable outcomes] this way.
But again, when you have many moving gears finally coming together in a product, in a real, online environment, your best bet is doing lots of testing first to give yourself confidence you've caught most of the edge-cases, and that there are no "catastrophic" edge-cases lurking, unaccounted for.
If you still have any specific questions or want to zoom in on any aspect of software creation, please ask us
Thanks, this is really helpful. I never thought about the “doesn’t do anything I didn’t expect” part. That actually seems harder to verify than just checking if the feature works.
When you say you use specs, tests and LLM reviews before shipping, how do you personally know when you’ve tested enough to actually feel confident shipping? Is there a point where you just have to trust it and ship?
Every app is a state machine. If you have not learned about Finite State Machines (FSMs) I highly recommend you take a weekend or two and watch some videos, read some stuff on them.
Learn to draw your own Finite State Machines.
Essentially, we identify "states" of our "program" and then we move between them via transition lines/arrows. Eventually we encounter an "accepting state" and then the "program" is done. In reality, programs don't ever really get to "done" mode, but algorithms do.
Consider a simple task like eating cereal in the morning:
1) Get bowl
2) Get cereal
3) Get nondairy milk
4) Pour cereal into bowl
5) Pour just enough milk to keep cereal crunchy
6) Use spoon to take a bite
7) Crunch
8) If there is still cereal, go back to bowl with spoon, number 7; otherwise, go to 9
9) Done! Do the dishes, I guess.
Now if you draw that out as circles with arrows, you end up with some state transitions going backwards, some going forwards, and some looping back on themselves.
Reasoning about your app should be the same. There should be a "finite number of states" and well-understood transitions between the states.
When you have tested all the states and all the transitions between them, you have tested 100% of your program. 100% when it's gritty and dirty and connected to the rest of the "real world" [is tough] because it's not existing in isolation, 100% is like the ideal but you can be happy with 80-90% certitude you've covered it "all."
Guess you depend on how you measure. As "released product to the public" then probably yes. Cumulative training hours spent actually creating and adjusting the weights during training? Probably no.
Maybe, I do not know how the number of neurons in a child's brain and the connections compare to Claude and its training but I would think it is comparable. Also, while a child might sleep the brain does not just switch off, there is still stuff going on that adds to the child's development.
I am, here, not counting time for separate instances of Claude (so 10 instances running for a year is not 10 years). So, I think the 8yo is still older.
Full disclosure, I am not a neurologist or computer scientist (although I find both interesting). I would consider fair criticism of this fair and would even like to see what those in those fields would have to say.
What are they scraping the gentoo bugzilla for? I'm confused. Unless you're actively using Gentoo why would this be a resource? Very confusing. Also you'd think we'd have LLM BitTorrent by now, where if they want to scrape something we get a DHT hash for the content and share it with one another, rather than melt servers with the millionth request of the day.
They're mining the written output of technical talent discussing troubleshooting, bug finding, patches, inter-dependencies, etc. It's an AI trainer's wet dream.
Also: where exactly are AI companies incentivized to be anything but shitty 'neighbors'?
Spam, DDoS attacks and other network abuse used to cause your hosting company or provider to call you and tell you to knock it off or you'll get disconnected, if your provider was reputable. If your provider wasn't reputable, it was likely a matter of time before they would get a nasty call from their upstream provider.
Now it just gets you a thank-you from the sales team for all the bandwidth you bought.
Meanwhile, do any of the cloud providers have any incentive to do anything about this? Hell no. They're making money off you having to ramp up extra or bigger instances. They're making money off the bandwidth. They're making money off the people doing the crawling, too. They're incentivized to do the exact opposite of effectively help you with your AI bot problem.
At this point they've mostly run out of material, so ANY type of content is valuable. Your small personal website, why would they scrape that? It's 10.000 additional words, wouldn't want to miss that. My Github repos.... got to get buggy code from somewhere I guess.
I get what you're asking, and I'm wondering the same. Not all sources are created equally and we see the results all the time. LLMs outputs nonsense all the time, like Flock cameras containing 5 grams of gold and ounces of copper, because they are completely on critical of their sources. Perhaps there's some weights that says: Kernel mailing list, MariaDB documentation and Microsofts Learning sites are 100% trust, Reddit 50%, 4Chan 10%, but I doubt it.
Anthropic might care a little bit, seeing as they scan books, but again, is it just all books? Because other than some flowery language I don't really see the point in scanning a 1970s paperback only spy novel.
> Each figure is the shareholder wealth a founder’s company created, now held by index funds, pensions, employees and co-founders, minus what the founder kept.
